GPLv2: źródła dla odbiorcy i granice suwerenności

GPLv2 jest silną licencją copyleft: przy przekazaniu objętego nią programu lub dzieła pochodnego odbiorca ma otrzymać odpowiednie prawa i dostęp do kodu źródłowego zgodnie z warunkami licencji. To ogranicza sytuację, w której ktoś sprzedaje binarium, ale blokuje użytkownikowi możliwość samodzielnej poprawki. Punktem odniesienia jest oryginalny tekst GNU GPL w wersji 2.

Co uruchamia obowiązki GPLv2?

Samo używanie programu wewnątrz firmy nie jest tym samym co jego dystrybucja. Gdy firma przekazuje klientowi binarium objęte GPLv2, musi spełnić warunki dotyczące licencji i kodu źródłowego. Tekst przewiduje różne sposoby dostarczenia źródeł lub ważnej oferty ich udostępnienia; szczegóły zależą od sposobu dystrybucji. Zmodyfikowane pliki wymagają oznaczenia zmian. Nie wystarczy link do oryginalnego upstreamu, jeśli w binarium są własne modyfikacje.

Sprawdź dokładny identyfikator: GPL-2.0-only to nie to samo co GPL-2.0-or-later. W pierwszym przypadku nie należy samodzielnie zakładać prawa przejścia na GPLv3. To ważne przy łączeniu zależności i planowaniu migracji produktu. Ocena, czy konkretny sposób połączenia kodu tworzy dzieło objęte GPL, jest zależna od faktów — przy istotnym komercyjnie produkcie trzeba ją przeprowadzić przed wydaniem.

Suwerenność: co zyskuje odbiorca?

Odbiorca programu zyskuje praktyczną drogę do niezależnego utrzymania jego objętej licencją części: kod i prawo zmiany. W sprzęcie AI może to mieć znaczenie dla oprogramowania hosta lub kontrolera. GPLv2 nie gwarantuje jednak, że użytkownik będzie mógł zainstalować zmienione binarium na każdym urządzeniu; temat urządzeń blokujących modyfikacje jest jedną z różnic wobec GPLv3.

GPLv2 nie rozwiązuje także całego vendor lock-in. Sprzęt może wymagać zamkniętego firmware, model może mieć odrębną licencję, a dane mogą pozostawać w nieeksportowalnym formacie. Co więcej, samo udostępnienie programu jako usługi przez sieć nie jest typowym wyzwalaczem obowiązku wydania źródeł zmian — to tzw. luka SaaS, dla której porównuje się AGPLv3.

Praktyczny test dla firmy

Przed wysłaniem urządzenia lub kontenera klientowi sporządź listę objętych GPL komponentów, wersji i zmian. Zbuduj odpowiadające im źródła na czystej maszynie; zachowaj skrypty kompilacji oraz sposób uzyskania źródeł przez odbiorcę. Następnie sprawdź osobno, czy klient może przenieść dane i czy sprzęt pozwala uruchomić poprawioną wersję. Tak odróżnisz zgodność z licencją od realnej suwerenności użytkownika.

Dlaczego wersja licencji ma znaczenie?

Kod oznaczony GPL-2.0-only nie staje się automatycznie kodem GPLv3 po aktualizacji projektu. Jeżeli nowa zależność ma warunki niezgodne z GPLv2-only, plan migracji może wymagać wymiany komponentu lub zgód autorów. Dlatego do dokumentacji architektury wpisuj dokładny identyfikator SPDX i informację, czy projekt dopuszcza późniejsze wersje. Nie traktuj „GPL” jako jednej licencji niezależnej od numeru.

W kontekście suwerenności GPLv2 daje odbiorcy źródła, ale nie gwarantuje pełnej dokumentacji urządzenia czy danych. Firmowy AI OS może zawierać jądro lub narzędzia objęte GPLv2, a równocześnie wymagać niedostępnego firmware GPU. Rozdzielenie praw do kodu i możliwości uruchomienia go na sprzęcie jest kluczowe w ocenie niezależności.

Umowa z dostawcą a licencja OSS

Jeżeli firma kupuje urządzenie z kodem GPLv2, powinna umieć otrzymać dokładnie odpowiadające mu źródła zgodnie z licencją. Dodatkowo może wymagać od sprzedawcy procedury odzyskania systemu, eksportu danych i okresu poprawek. Tych zobowiązań nie należy dopisywać w wyobraźni do GPL. Licencja ustanawia bazowe prawa do objętego oprogramowania; umowa i architektura zapewniają ciągłość działania biznesu.