Ta strona jest tłumaczeniem z angielskiego.

LGPL i Java

autor: David Turner

Artykuł został napisany w listopadzie 2004 r. gdy bieżącą wersja była LGPLv2.1. Od tamtej pory została opublikowana LGPLv3. Główne zagadnienia dotyczą także LGPLv3, ale niektóre szczegóły, takie jak numery paragrafów, uległy zmianie.

FSF zawsze uważała, że dynamiczne łączenie aplikacji z bibliotekami tworzy pojedynczą pracę pochodną, czerpiącą zarówno z kodu biblioteki, jak i kodu aplikacji. Licencja GPL wymaga, aby wszystkie dzieła pochodne również były wydane na warunkach licencji GPL. Efekt ten można określić słowem „dziedziczenie”. Dlatego też, jeżeli aplikacja korzysta z bibliotek GPL, musi ona również być na licencji GPL. Natomiast biblioteki na licencji GNU Lesser General Public License (LGPL) mogą być wykorzystywane przez oprogramowanie prawnie zastrzeżone.

W lipcu 2003 roku, Slashdot opublikował artykuł, w którym napisano, że ja stwierdziłem, iż w przypadku Javy LGPL nie działa tak, jak powinna. Artykuł ten bazował na niezrozumieniu mojej odpowiedzi na pytanie wysłane na licensing@gnu.org, zaś wielokrotne próby sprostowania tematu podjętego przez Slashdot nie przyniosły efektów. Od tego czasu otrzymałem wiele pytań na ten temat, nadesłanych zarówno na licensing@gnu.org, jak i na mój adres prywatny.

Stanowisko FSF przez ten czas nie uległo zmianie: LGPL działa zgodnie z założeniami ze wszystkimi znanymi językami programowania, z Javą włącznie. Aplikacje, które korzystają z bibliotek LPGL, nie muszą być wydawane na licencji LGPL. Muszą jedynie spełniać wymagania nałożone przez LGPL w sekcji 6: pozwalać na łączenie z aplikacją nowych wersji biblioteki oraz na inżynierię wsteczną w celu debugowania skutków takiej zmiany.

W typowej dla Javy konfiguracji każda wykorzystywana przez aplikację biblioteka dostarczana jest w postaci osobnego pliku JAR (Java Archive). Aplikacje używają dyrektywy „import”, aby odwołać się do klas zaimplementowanych w tych bibliotekach. Podczas kompilacji sygnatury funkcji wywoływanych przez aplikację sprawdzane są z zawartością biblioteki, tworzone jest dowiązanie. Tym samym aplikacja zasadniczo staje się pochodną biblioteki. Tak więc posiadacz praw autorskich do biblioteki musi zezwolić na rozprowadzanie takiego oprogramowania. Licencja LGPL pozwala na to.

Jeżeli zamierzacie rozpowszechniać aplikację korzystającą z bibliotek LGPL, spełnienie wymagań LPGL nie jest wcale trudne. Jedyne, co musicie zrobić, to zaznaczyć w swojej licencji możliwość modyfikowania biblioteki przez innych użytkowników oraz pozwolić na inżynierię odwrotną swojego kodu w celu zdebugowania wprowadzonych zmian. Nie znaczy to wcale, że musicie udostępnić kod źródłowy lub informacje o wewnętrznej budowie swojej aplikacji. Oczywiście niektóre zmiany wprowadzone przez użytkowników mogą spowodować, że biblioteka przestanie współpracować z Waszym programem. Nie powinniście się tym jednak przejmować, gdyż ludzie, którzy będą to zmieniać, są odpowiedzialni za to, aby biblioteka i współpracujące z nią programy działały prawidłowo.

W momencie, kiedy razem ze swoją aplikacją rozpowszechniacie bibliotekę (albo tylko samą bibliotekę), jesteście zobowiązani do dołączenia kodu źródłowego biblioteki. Lecz jeżeli wasza aplikacja wymaga, aby to użytkownik zadbał o obecność biblioteki, nie musicie dołączać kodu źródłowego biblioteki.

Jedyna różnica pomiędzy Javą a C z punktu widzenia LGPL jest taka, iż Java jest językiem zorientowanym obiektowo wspomagającym dziedziczenie. LGPL nie zawiera żadnych specjalnych reguł dotyczących dziedziczenia, gdyż nic takiego nie jest potrzebne. Dziedziczenie tworzy zależności pomiędzy bibliotekami i aplikacjami w ten sam sposób, jak tradycyjne łączenie bibliotek, dlatego też LGPL pozwala na tworzenie tych zależności tak samo, jak na zwykłe wywołanie funkcji.