GPLv3: copyleft, patenty i prawo do zmiany urządzenia

GPLv3 chroni możliwość otrzymania i zmiany kodu programu przy jego przekazywaniu, a w określonych urządzeniach konsumenckich również możliwość zainstalowania zmienionej wersji. Ma szersze postanowienia patentowe i antyblokujące niż GPLv2. Nie oznacza to, że każdy produkt zawierający jedną bibliotekę GPLv3 trzeba automatycznie publikować w całości; zakres dzieła i sposobu połączenia wymaga osobnej oceny. Źródłem jest tekst GNU GPLv3.

Co dzieje się przy dystrybucji?

Licencja pozwala używać i modyfikować program wewnętrznie. Gdy firma przekazuje objęte nią dzieło w kodzie lub postaci wykonywalnej, musi przestrzegać warunków dotyczących licencji, odpowiedniego kodu źródłowego i praw odbiorcy. W pewnych transakcjach dotyczących zdefiniowanego w licencji „User Product” dystrybucja binarium pociąga też obowiązek przekazania informacji potrzebnej do instalacji zmodyfikowanego programu. Przewodnik GNU wyjaśnia cel tej reguły: kod źródłowy ma być użyteczny, nie tylko dostępny do czytania.

Przy łączeniu zależności sprawdź, czy komponent ma GPL-3.0-only czy GPL-3.0-or-later. Dla biblioteki, którą produkt ma jedynie wykorzystywać, rozważ odrębne zasady LGPLv3. Nie zakładaj, że kontener, proces lub połączenie sieciowe samo rozstrzyga o powstaniu jednego dzieła. Techniczna architektura jest ważna, lecz ostateczna interpretacja licencji zależy od faktów.

Suwerenność firmy i jej klientów

GPLv3 wspiera odbiorców, którzy chcą naprawić urządzenie lub program bez wyłącznej pomocy dostawcy. Z punktu widzenia producenta systemu AI to zobowiązanie: trzeba umieć dostarczyć źródła zgodne z wydanym binarium i utrzymać proces dokumentowania zmian. Nie wystarczy chaotyczne repozytorium z bieżącą gałęzią, jeśli klient ma konkretną starszą wersję.

Licencja nie zapewnia otwartych modeli, danych ani dostępu do GPU. Nie wymusza też ogólnie ujawnienia zmian w programie tylko dlatego, że działa jako usługa sieciowa. Jeśli celem projektu jest również uprawnienie użytkownika usługi do źródeł zmienionego programu, porównaj AGPLv3.

Przykład testu zgodności i wyjścia

Firma sprzedaje urządzenie edge AI z oprogramowaniem GPLv3. Dla konkretnego wydania buduje archiwum źródeł, skryptów i instrukcji instalacji, sprawdza je na czystej maszynie oraz testuje, czy urządzenie uruchamia zmienioną wersję tam, gdzie wymaga tego licencja. Osobno bada, czy dane użytkownika da się wyeksportować, a model wymienić. Pierwszy test dotyczy GPLv3; drugi mierzy realny vendor lock-in całego rozwiązania.

O czym powinien pamiętać dostawca AI OS?

Proces wydawania musi wiązać binarium z odpowiadającym mu źródłem, konfiguracją kompilacji i zmianami. To zadanie dla CI, nie jednorazowe przygotowanie archiwum po zgłoszeniu klienta. Jeżeli agent AI modyfikuje kod GPLv3, jego diff przechodzi zwykłe review i jest uwzględniony w wydaniu źródeł. Nie ma wyjątku dlatego, że kod wygenerował model. Zespół powinien też zachować informacje o pochodzeniu zależności, bo program może mieć więcej niż jedną licencję.

Z punktu widzenia odbiorcy warto wykonać próbę niezależnej poprawki: zmienić drobną funkcję, zbudować program i uruchomić go na dostarczonym urządzeniu. Jeśli blokadę powoduje sprzęt albo brak narzędzi, trzeba ustalić, czy ma zastosowanie wymóg informacji instalacyjnej. Nie wszystkie serwery czy urządzenia podlegają mu tak samo; dlatego protokół powinien wskazywać konkretny typ produktu i sposób jego przekazania.

Firma może otrzymać źródła programu GPLv3, lecz pozostać zależna od dostawcy modelu, danych treningowych lub usługi aktywacyjnej. W architekturze zapisuj te zależności osobno. GPLv3 chroni prawa do programu, ale nie obiecuje pełnej suwerenności technologicznej produktu AI.