Wolne, lecz w okowach - pułapka Javy

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. Definicja Wolnego Oprogramowania). 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Ĺźywalny 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. Java Specification Participation Agreement oraz J2ME™ Personal Basis Profile Specification)

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 BASH, 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 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. JeĹźeli nie ma go w katalogu, moĹźecie porĂłwnać jego licencję z listą licencji wolnego oprogramowania.

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.

Zobacz teĹź:

Dziwny przypadek Suna nocną porą