Tłumaczenia tej strony

LGPL i Java

autor: David Turner

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 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 LPGL (Lesser General Public License) 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 podjętego przez Slashdot tematu 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. 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.

Więcej o licencjach