Tłumaczenia tej strony

O Netscape Public License

Richard Stallman

(Pierwsza wersja tego artykułu została napisana w marcu 1998 i dotyczyła szkicu NPL. Naszym pierwszym artykułem na ten temat było „Netscape rozważa wydanie swojej przeglądarki jako wolnego oprogramowania”).

Publiczna Licencja Netscape (Netscape Public License, NPL) w postaci, jaką ostatecznie opracowano w 1998 r., jest licencją wolnego oprogramowania, ale ma trzy zasadnicze słabe punkty. Pierwsza wada niesie ze sobą złe przesłanie filozoficzne, druga stawia społeczność wolnego oprogramowania na słabszej pozycji, zaś trzecia stwarza poważny praktyczny problem wewnątrz naszej społeczności. Dwa z tych defektów dotyczą także Publicznej Licencji Mozilli. Z powodu tych skaz apelujemy, abyście nie korzystali z NPL ani MPL dla pisanego przez siebie wolnego oprogramowania.

1. Nie wszyscy użytkownicy są równi

Pierwszy kłopot, jaki zauważyłem w NPL, stanowi to, że nie daje ona Netscape'owi i reszcie z nas równych praw, tak jak robi to GNU GPL. Zgodnie z NPL, możemy korzystać z kodu Netscape'a tylko w sposób określony w tej licencji, ale Netscape może korzystać z naszych modyfikacji całkiem dowolnie, nawet w prawnie zastrzeżonych wersjach programu.

Wskazany tu problem jest subtelny, gdyż nie czyni programu nie-wolnym. Nie powstrzymuje nas od rozprowadzania programu ani jego modyfikowania, nie odmawia nam żadnej konkretnej swobody. Z czysto pragmatycznego punktu widzenia może wcale nie wyglądać na problem.

Sedno problemu kryje się w głębszym przesłaniu, jakie niesie ten warunek. Zaprzecza ono idei współpracy między równymi sobie, na której opiera się nasza społeczność, i sugeruje, że praca nad wolnym oprogramowaniem może oznaczać wkład w rozwój prawnie zastrzeżonego programu. Należy się spodziewać, że ci, którzy przyjmą ten warunek, zmienią się pod jego wpływem, a taka zmiana nie wzmocni naszej społeczności.

Jedno z proponowanych rozwiązań tej asymetrii to ustalenie ograniczonego czasu jej obowiązywania – może przez trzy czy pięć lat. Byłaby to znaczna poprawa, ponieważ limit czasowy zaprzeczałby stwarzającemu problem podtekstowi.

Praktyczne skutki tego warunku są minimalizowane prze inną ujemną stronę NPL: nie opracowano jej po to, żeby realizować ideę licencji copyleft. Innymi słowy, nie przyłożono specjalnych starań, żeby zagwarantować, że wykonane przez użytkowników modyfikacje będą dostępne jako wolne oprogramowanie.

W Publicznej Licencji Mozilli (Mozilla Public License, MPL) ten problem nie występuje. Na tym polega główna różnica między MPL a NPL.

2. Nie jest licencją typu copyleft

NPL ma formę licencji typu copyleft: stwierdza wprost, że wszelkie modyfikacje dokonane przez użytkowników muszą być wydane na warunkach NPL. Ale odnosi się to tylko do modyfikacji istniejącego kodu, nie do dodanych podprogramów, jeśli umieszczono je w osobnych plikach. W praktyce oznacza to, że jeśli się chce, zrobienie prawnie zastrzeżonych zmian jest łatwe: wystarczy umieścić większość własnego kodu w osobnym pliku i nazwać zbiór Większą Pracą (Larger Work). Tylko wywołania podprogramów dopisane do starych plików będą musiały być wydane na warunkach NPL, a same z siebie nie są zbyt przydatne.

Brak prawdziwego mechanizmu copyleft nie jest katastrofą, nie powoduje, że program jest nie-wolny. Na przykład, w warunkach dystrybucyjnych X.org w ogóle nie próbowano stosować zasad copyleft, a pomimo to X.org jest wolnym oprogramowaniem. Również BSD jest wolnym oprogramowaniem typu copyleft, choć starsze warunki BSD obarczone są poważną wadą i nie powinny być naśladowane – jeżeli chcecie wydać wolne oprogramowanie, ale nie jako copyleft, proszę, wykorzystajcie zamiast niej licencję X.org. Także oprogramowanie wydane na NPL zalicza się do wolnego oprogramowania i, samo w sobie, niewykorzystanie w niej idei copyleft nie powoduje, że NPL jest gorsza niż inne licencje wolnego oprogramowania, które go nie stosują.

Tym niemniej, choć to nie katastrofa, to jednak wada. A ponieważ NPL przypomina copyleft, niektórych użytkowników może to zmylić, i mogą zaadoptować NPL do własnych potrzeb, sądząc, że uzyskują dla swojego oprogramowania korzyści płynące z copyleft, choć wcale tak nie jest. Żeby się tego ustrzec, będziemy musieli intensywnie popracować nad wyłożeniem ludziom sprawy, która nie jest tak prosta, żeby wyjaśnić ją w paru słowach.

3. Niezgodność z GPL

Najpoważniejszy praktyczny problem NPL tkwi w jej niezgodności z GNU GPL. Nie da się w jednym programie połączyć kodu wydanego na NPL z kodem objętym GNU GPL, nawet przez konsolidację odrębnych plików obiektowych czy bibliotek – wszystko jedno, jak się to zrobi, będzie naruszało raz jedną, raz drugą licencję.

Konflikt bierze stąd, że GPL poważnie traktuje copyleft: opracowano ją specjalnie po to, żeby zagwarantować, że wszystkie zmiany i rozszerzenia wolnego programu będą również wolne. Dlatego nie ma w niej żadnej luki pozwalającej na zgodne z literą prawa nadanie zmianom w programie statusu „proprietary”, prawnie zastrzeżonych, przez umieszczenie ich w osobnym pliku. Żeby zlikwidować tę lukę, w GPL nie pozwolono na łączenie programu wydanego na zasadach copyleft z kodem, na który nałożono inne ograniczenia lub warunki, jak w NPL.

Brak zgodności z GPL nie powoduje, że program nie jest wolny, nie wzbudza zasadniczych zastrzeżeń etycznych. Ale należy się spodziewać, że przysporzy naszej wspólnocie poważnego kłopotu: podzieli kod podstawowy na dwie grupy, których nie można mieszać. Z praktycznego punktu widzenia, problem jest bardzo istotny.

Rozwiązanie go przez zmianę GPL jest możliwe, ale wiązałoby się to z porzuceniem koncepcji copyleft, co wyrządziłoby więcej szkody niż pożytku. Problem da się jednak rozwiązać przez wprowadzenie niewielkich zmian w NPL (poniżej przedstawiono konkretną propozycję).

4. Uwaga na temat nazw

NPL oznacza Netscape Public License, ale GPL nie oznacza GNU Public License. Pełną nazwą naszej licencji jest: GNU General Public License, w skrócie GNU GPL. Czasem ludzie pomijają słowo „GNU” i piszą tylko GPL.

(To nie problem, to tylko fakt, o którym powinniście wiedzieć).

Konkluzja

Ponieważ problem nr 3 jest najpoważniejszy, mam nadzieję, że ludzie uprzejmie i racjonalnie wyjaśnią Netscape'owi, jak ważne jest, by go rozwiązać. Rozwiązania istnieją – firma musi się tylko zdecydować, żeby z nich skorzystać.

Oto możliwy sposób na dopuszczenie łączenia kodu objętego NPL z kodem objętym GPL. Można to zrealizować dodając do NPL dwa poniższe paragrafy:

A.1. You may distribute a Covered Work under the terms of the GNU
     General Public License, version 2 or newer, as published by the
     Free Software Foundation, when it is included in a Larger Work
     which is as a whole distributed under the terms of the same
     version of the GNU General Public License.

A.2. If you have received a copy of a Larger Work under the terms of a
     version or a choice of versions of the GNU General Public
     License, and you make modifications to some NPL-covered portions
     of this Larger Work, you have the option of altering these
     portions to say that their distribution terms are that version or
     that choice of versions of GNU General Public License.

A.1. Masz prawo rozprowadzać Przedmiotową Pracę [w NPL występuje termin:
     Przedmiotowy Kod - tłum.] na warunkach Powszechnej Licencji
     Publicznej GNU, wydanej przez Fundację Wolnego Oprogramowania,
     w wersji 2 lub nowszej, gdy Praca ta zawarta jest w Większej
     Pracy, która jako całość rozprowadzana jest na warunkach tej
     samej wersji Powszechnej Licencji Publicznej GNU.

A.2. Jeśli otrzymałeś kopię Większej Pracy na warunkach pewnej wersji
     Powszechnej Licencji Publicznej GNU lub mając do wyboru jedną
     z jej wersji, a wykonałeś modyfikację tych części Większej Pracy,
     które objęte są NPL, przysługuje ci możliwość zmiany sposobu
     licencjonowania tych fragmentów na warunki tej wersji
     lub tego wyboru wersji Powszechnej Licencji Publicznej GNU.

Takie zapisy pozwalają na łączenie kodu objętego NPL z kodem wydanym na GPL i dystrybucję powstałej pracy na warunkach GNU GPL.

Pozwalają ludziom na wydawanie własnych zmian tak połączonych dzieł na warunkach GNU GPL, ale najprościej wydawać je na NPL.

Kiedy korzystaliby z zalet punktu A.2, wykonane przez nich modyfikacje byłyby wydawane tylko na warunkach GNU GPL, więc Netscape nie mógłby wykorzystać tych zmian w swoich prawnie zastrzeżonych wersjach. Zrozumiałe, że Netscape uznałby to za niekorzystne.

Niemniej jednak, NPL łatwo ustępuje konstruktorom prawnie zastrzeżonego oprogramowania, którzy chcieliby, żeby opracowane przez nich modyfikacje były całkowicie niedostępne dla Netscape'a. Wystarczy, że umieszczą swój kod w osobnych plikach i nazwą połączoną całość Większą Pracą. W gruncie rzeczy, jest im to łatwiej zrobić, niż użytkownikom GPL byłoby skorzystać z punktu A.2.

Jeżeli Netscape może się pogodzić z istniejącym (w praktyce) problemem prawnie zastrzeżonych modyfikacji, to z pewnością problem modyfikacji na warunkach GPL jest w stosunku do nich niewielki. Jeśli Netscape jest przekonany, że względy praktyczne zachęcą większość autorów świata prawnie zastrzeżonego oprogramowania do wydania swoich poprawek tak, aby trafiły z powrotem do Netscape'a, choć nic ich do tego nie zmusza, to te same przyczyny powinny tak samo działać także w świecie wolnego oprogramowania. Netscape powinien zrozumieć, że proponowane zmiany są do przyjęcia i przyjąć je, żeby uniknąć stawiania ludzi rozwijających wolne oprogramowanie przed trudnym dylematem.

Inne teksty