LGPLv3: biblioteka otwarta, aplikacja może pozostać własna

LGPLv3 pozwala wykorzystywać objętą nią bibliotekę w aplikacji na innych warunkach, lecz użytkownik powinien zachować możliwość korzystania ze zmienionej wersji tej biblioteki zgodnie z licencją. To ważne przy dystrybucji produktów AI z bibliotekami multimediów, danych lub obliczeń. Pełny tekst GNU LGPLv3 dodaje uprawnienia do GPLv3 i precyzuje zasady „Combined Work”.

Co trzeba sprawdzić przy dystrybucji?

LGPLv3 nie jest prostym hasłem „można linkować bez obowiązków”. Przy przekazywaniu programu trzeba dołączyć wymagane informacje o bibliotece, licencje i — zależnie od sposobu połączenia — umożliwić ponowne połączenie aplikacji ze zmodyfikowaną biblioteką albo zastosować odpowiedni mechanizm biblioteki współdzielonej. Gdy firma zmienia samą bibliotekę, te zmiany podlegają warunkom LGPL. Tekst określa także szczególne wymagania dotyczące informacji instalacyjnej w odpowiednich sytuacjach.

Przy statycznym linkowaniu, pakowaniu mobilnym lub zamkniętym urządzeniu temat wymiany biblioteki jest bardziej złożony niż przy klasycznym dynamicznym linkowaniu. Agent kodujący nie powinien odpowiadać na podstawie samej nazwy pliku .so; trzeba przejrzeć sposób budowy i dostarczenia programu. Zapisz dokładny identyfikator SPDX, bo LGPLv2.1 i LGPLv3 różnią się szczegółami.

Co to daje suwerenności?

Odbiorca może naprawiać wspólną bibliotekę bez konieczności otrzymania całego kodu biznesowego aplikacji. To pomaga utrzymywać warstwę infrastruktury używaną przez konkurujących producentów. Producent zachowuje własne moduły i dane. Jeśli jednak format projektu, firmware albo API modelu są zamknięte, sama wymienialność biblioteki nie daje możliwości migracji całego AI OS.

Przykład: aplikacja inferencyjna używa biblioteki LGPLv3 do dekodowania obrazu. Firma wysyła urządzenie klientowi. Test suwerenności ma dwa poziomy: czy klient może uruchomić zmienioną wersję biblioteki zgodnie z licencją oraz czy może wyeksportować obrazy i przenieść model na inny runtime. Pierwszy wynika z zasad LGPL, drugi z architektury produktu.

Jak podjąć decyzję?

Przed wydaniem przeprowadź kompilację z alternatywną, zgodną wersją biblioteki. Zachowaj kod modyfikacji, noty i instrukcję wymiany. Jeśli produkt sprzętowy blokuje każdą zmianę biblioteki, sprawdź warunki instalacyjne przed sprzedażą, a nie po reklamacji. MPL 2.0 określa copyleft według pliku, a GPLv3 ma inny zakres dla całego objętego dzieła. Wybór zależy od tego, czy chcesz otwartą bibliotekę, otwarty program czy oba elementy.

Przykład dla programisty

Serwer AI korzysta z biblioteki LGPLv3 do konwersji dokumentów. Programiści nie zmieniają biblioteki, ale pakują ją razem z aplikacją w kontenerze. Przy wydaniu klientowi sprawdzają, czy sposób pakowania pozwala użytkownikowi zastąpić bibliotekę zgodną wersją oraz czy informacje licencyjne są dostępne. Następnie robią próbę: budują obraz z poprawioną biblioteką i uruchamiają ten sam zestaw dokumentów. To test praktycznej wymienialności, a nie tylko teoretycznego prawa do kodu.

Jeśli biblioteka jest zmodyfikowana, zespół musi utrzymywać źródła tych zmian i odpowiednie informacje dla odbiorców. Jeżeli aplikacja działa wyłącznie jako usługa i nie jest przekazywana odbiorcy, analiza obowiązków wygląda inaczej; nie przenoś bezrefleksyjnie scenariusza dystrybucji na SaaS.

Biblioteka może być wymienialna, a aplikacja nadal powiązana z jednym dostawcą OCR, jednym modelem lub nieudokumentowanym formatem dokumentów. W tabeli zależności rozdziel bibliotekę, usługę, dane i operatora. LGPLv3 zabezpiecza pierwszą z tych warstw. Dla pozostałych potrzebujesz testu alternatywnego API i eksportu danych.