Tłumaczenia tej strony

Wolne, lecz w okowach - pułapka Javy

Autor: Richard Stallman
12 kwietnia 2004

Jeśli wasz program jest wolnym oprogramowaniem, to zasadniczo jest dobry etycznie – ale istnieje pułapka, której musicie się strzec. Wasz program, choć sam w sobie wolny, być może ograniczany jest przez niewolne oprogramowanie, od którego zależy. Ponieważ problem ten najbardziej widoczny jest obecnie w przypadku programów napisanych w Javie, nazywamy go Pułapką Javy.

Program jest wolny, kiedy jego użytkownicy mają pewne kluczowe swobody. Z grubsza rzecz ujmując, są to: wolność uruchamiania programu, wolność studiowania go i zmiany jego kodu źródłowego, wolność redystrybucji źródeł i binariów oraz wolność publikowania poprawionych wersji (zob. http://www.gnu.org/philosophy/free-sw.pl.html). To, czy dany program jest wolnym oprogramowaniem, zależy wyłącznie od jego licencji.

To, czy program może być używany w Wolnym Świecie, przez ludzi, którzy zamierzają żyć w wolności, jest pytaniem bardziej złożonym. Nie decyduje o tym licencja samego programu, gdyż żaden program nie działa w odosobnieniu. Każdy program zależy od innych programów. Musi na przykład zostać skompilowany lub zinterpretowany, więc zależy od kompilatora czy interpretera. Jeśli jest kompilowany do kodu bajtowego, zależy od interpretera tego kodu. Ponadto, do działania potrzebuje bibliotek, a może też wywoływać inne odrębne programy działające jako osobne procesy. Dany program może zależeć od innych, żeby w ogóle działać lub wymagać ich tylko dla pewnych funkcji. Tak czy owak, cały program lub jego część nie mogą funkcjonować bez oprogramowania, od którego są zależne.

Jeżeli niektóre z wymaganych przez program elementów nie są wolne, to znaczy, że całość lub część programu nie dadzą się uruchomić w całkowicie wolnym systemie – nie nadaje się on do używania w Wolnym Świecie. Jasne, możemy rozprowadzać ten program i trzymać kopie w swoich komputerach, ale niewiele z tego pożytku, jeśli nie będzie działał. Taki program jest wolnym oprogramowaniem, lecz w praktyce został spętany przez niewolne oprogramowanie, od którego jest uzależniony.

Ten kłopot może się pojawić w każdego rodzaju oprogramowaniu, w dowolnym języku. Na przykład, wolny program działający tylko w Microsoft Windows jest ewidentnie bezużyteczny w Wolnym Świecie. Ale program działający na GNU/Linuksie także może być bezużyteczny, jeśli zależy od innego niewolnego oprogramowania. W przeszłości główną przyczyną takich kłopotów były Motif (zanim powstał LessTif) oraz Qt (zanim twórcy tej biblioteki uczynili ją wolnym oprogramowaniem). Większość kart graficznych 3D wykorzystuje w pełni swoje możliwości tylko z niewolnymi sterownikami, co także powoduje tego rodzaju problemy. Ale głównym źródłem tego problemu jest obecnie Java, gdyż osoby piszące wolne oprogramowanie często uważają, że Java jest sexy. Zaślepieni przez swoje zafascynowanie językiem, przeoczają kwestię zależności i  wpadają w Pułapkę Javy.

Wykonana przez firmę Sun implementacja Javy nie jest wolna. Blackdown także nie jest wolne, jest przeróbką zastrzeżonego kodu Suna. Standardowe biblioteki Javy też nie są wolne. Mamy wolne implementacje Javy, takie jak GNU Compiler for Java (GCJ) i GNU Classpath, ale nie udostępniają one jeszcze wszystkich funkcji. Nadal to nadganiamy.

Gdy piszecie program w Javie na platformie Javy oferowanej przez Suna, jesteście podatni na nieświadome wykorzystywanie funkcji występujących tylko w implementacji Suna. Kiedy się zorientujecie, może się okazać, że korzystacie z nich od miesięcy, a ponowne wykonanie pracy zajęłoby kolejne miesiące. Moglibyście wtedy powiedzieć: „To za dużo roboty, żeby zaczynać od początku”. Wówczas wasz program wpadnie w Pułapkę Javy, stanie się nieużyteczny w Wolnym Świecie.

Niezawodną metodą uniknięcia Pułapki Javy jest posiadanie w systemie wyłącznie wolnej implementacji Javy. Wtedy, jeśli skorzystacie z jakiejś cechy Javy lub biblioteki, której wolne oprogramowanie jeszcze nie obsługuje, zorientujecie się od razu i natychmiast będziecie mogli przepisać kod.

Sun nadal rozwija dodatkowe „standardowe” biblioteki Javy, a niemal wszystkie z nich są niewolne. W wielu przypadkach nawet specyfikacja biblioteki jest tajemnicą handlową. Zaś ostatnia licencja Suna dotycząca specyfikacji bibliotek zakazuje wydawania implementacji częściowych, czegokolwiek mniej niż pełna implementacja specyfikacji (zob. np. http://jcp.org/aboutJava/communityprocess/JSPA2.pdf oraz http://jcp.org/aboutJava/communityprocess/final/jsr129/j2me_pb-1_0-fr-spec-license.html).

Na szczęście, ta licencja pozwala na wydanie implementacji jako wolnego oprogramowania – temu, kto otrzyma taką bibliotekę, wolno ją zmienić i nie musi się trzymać specyfikacji. Jednak efektem tej klauzuli jest zakaz korzystania z modelu wspólnej pracy nad projektem do wytworzenia wolnej implementacji. Zastosowanie tego modelu pociągałoby za sobą publikowanie niekompletnych wersji, czego nie wolno robić tym, którzy przeczytali specyfikację.

W pionierskim okresie Ruchu Wolnego Oprogramowania uniknięcie zależności od niewolnych programów było niemożliwe. Zanim mieliśmy do dyspozycji kompilator GNU C, każdy program napisany w C (wolny czy nie) zależał od niewolnego kompilatora C. Zanim dysponowaliśmy biblioteką GNU C, każdy program zależał od niewolnej biblioteki C. Zanim mieliśmy Linuksa, pierwsze wolne jądro, każdy program zależał od niewolnego jądra. Zanim mieliśmy Basha, każdy skrypt powłoki musiał być interpretowany przez niewolną powłokę. To, że nasze pierwsze programy początkowo były skrępowane przez owe zależności, było nie do uniknięcia, ale zaakceptowaliśmy to, gdyż planowaliśmy stopniowe ich uwalnianie. Nasz ostateczny cel, samodzielny system operacyjny GNU, mieścił w sobie wolne zamienniki dla wszystkich tych zależności. Jeśli osiągnęlibyśmy ten cel, oswobodzilibyśmy wszystkie nasze programy. I tak się stało: mając system GNU/Linux, możemy teraz uruchamiać je na wolnych platformach.

Obecnie sytuacja wygląda inaczej. Mamy potężne wolne systemy operacyjne i wiele wolnych narzędzi programistycznych. Każde zadanie, jakie chcecie wykonać, możecie wykonać na wolnej platformie – bez konieczności akceptowania choćby tymczasowej zależności od niewolnego oprogramowania. Główną przyczyną tego, że obecnie ludzie wpadają w pułapkę, jest to, że się nad tym nie zastanawiają. Najłatwiej rozwiązać problem Pułapki Javy ucząc ludzi, żeby do niej nie wpadali.

Żeby uchronić swój napisany w Javie kod przed Pułapką Javy, zainstalujcie i wolne środowisko programistyczne Javy i używajcie go. Ogólnie rzecz biorąc: jakiegokolwiek języka programowania używacie, miejcie oczy otwarte i sprawdzajcie status programów, od których zależy wasz kod. Najprostszym sposobem zweryfikowania, czy dany program jest wolny jest poszukanie go w Katalogu Wolnego Oprogramowania (http://www.fsf.org/directory). Jeżeli nie ma go w katalogu, możecie porównać jego licencję z listą licencji wolnego oprogramowania (http://www.gnu.org/licenses/license-list.pl.html).

Próbujemy oswobodzić schwytane w pułapkę programy Javy, więc jeśli lubicie język Java, zachęcamy was do pomocy w rozwijaniu zbioru bibliotek GNU Classpath. Wypróbowanie działania swoich programów z kompilatorem GCJ i GNU Classpath i zgłoszenie kłopotów z klasami już zaimplementowanymi, też jest pomocne. Niemniej jednak, zbudowanie GNU Classpath wymaga czasu; jeśli wciąż dodawane będą kolejne niewolne biblioteki, to pewnie nigdy nie będziemy mieć wszystkich najnowszych. Dlatego, prosimy, nie nakładajcie swoim wolnym programom kajdan. Kiedy piszecie dziś jakiś program użytkowy, napiszcie go tak, aby od początku działał korzystając z wolnego oprogramowania wspomagającego.

• Dziwny przypadek Suna nocną porą
• Inne teksty