AGPLv3: otwarty serwer AI także przy dostępie przez sieć

AGPLv3 dodaje do mechanizmu GPLv3 obowiązek dotyczący zdalnych użytkowników zmodyfikowanego programu: powinni móc otrzymać odpowiedni kod źródłowy wersji, z którą komunikują się przez sieć. Dzięki temu operator nie może łatwo zatrzymać wszystkich zmian serwera tylko dlatego, że świadczy usługę bez wydawania binarium. To cel opisany w tekście licencji zatwierdzonym przez OSI i w jej sekcji o interakcji sieciowej.

Co AGPLv3 obejmuje, a czego nie?

Obowiązek sieciowy dotyczy zmodyfikowanej wersji programu objętego AGPL, gdy użytkownik wchodzi z nią w interakcję zdalnie. Nie oznacza automatycznie, że każdy sąsiedni serwis, osobny model i cała infrastruktura chmurowa muszą być publikowane. Granica objętego dzieła zależy od architektury i faktów. Sama nazwa „AGPL” w README nie wystarcza do oceny, czy konkretna funkcja produktu znajduje się w otwartym repozytorium.

Gdy firma tylko uruchamia niezmieniony program, powinna sprawdzić wymagania tego konkretnego przypadku, a nie mechanicznie powtarzać poradę dla modyfikacji. Przy dystrybucji obowiązują również zasady GPLv3. W projektach komercyjnych często spotyka się osobne oferty licencyjne od właściciela praw; istnienie takiej oferty nie zmienia warunków kopii otrzymanej na AGPL.

Suwerenność użytkownika usługi

AGPL może wzmocnić wspólną bazę oprogramowania serwerowego. Jeśli dostawca poprawia kod i udostępnia usługę użytkownikom, licencja utrudnia zamknięcie tych zmian bez udostępnienia źródeł objętego programu. To pomaga odbiorcom usług AI zbudować własną instancję. Nadal potrzebują jednak danych, konfiguracji, modeli i procesu migracji. Otwarty serwer bez eksportu danych może być słabą drogą wyjścia.

Przykład: firma używa serwera orkiestracji agentów AGPLv3 w usłudze dla klientów. Zmienia harmonogram zadań i API. Przed uruchomieniem sprawdza, które zmiany są w objętym programie, przygotowuje właściwy kod źródłowy i sposób jego udostępnienia użytkownikom. Osobno dokumentuje eksport zadań oraz połączeń do modeli. To jednocześnie test zgodności i realnego vendor lock-in.

Kiedy wybrać inną licencję?

Jeśli celem jest swobodne wdrażanie także zamkniętych usług bez obowiązku dzielenia się zmianami, Apache 2.0 będzie prostsza. Jeśli chcesz udostępniać zmiany dopiero przy dystrybucji programu, porównaj GPLv3. AGPLv3 jest świadomym wyborem dla wspólnej warstwy serwerowej, nie domyślną etykietą „bardziej otwarte”.

Dwa warianty tej samej platformy

Wariant A: operator uruchamia niezmieniony serwer AGPLv3, a własną logikę biznesową trzyma w oddzielnym systemie komunikującym się przez udokumentowane API. Wariant B: operator zmienia kod serwera, dodając obsługę nowego typu agenta. Wariant B wymaga szczególnie uważnego sprawdzenia obowiązku wobec zdalnych użytkowników zmienionego programu. Nie wystarczy opisać całej architektury jednym słowem „mikroserwisy”; sprawdź, gdzie faktycznie znajdują się modyfikacje i jaki kod tworzy objęty program.

Z punktu widzenia klienta oba warianty mogą być podobnie trudne do opuszczenia, jeśli dane nie są eksportowane. Dlatego zapis w zamówieniu powinien obejmować format eksportu, częstotliwość kopii i procedurę uruchomienia własnej instancji. AGPL ułatwia dostęp do kodu w określonym zakresie, lecz nie dostarcza automatycznie działającej kopii usługi.

Przy każdej wersji usługi zachowaj źródła odpowiadające wdrożeniu, historię zmian i sposób uzyskania ich przez uprawnionych użytkowników. Przetestuj to jak funkcję produktu: użytkownik otrzymuje informację, gdzie pobrać źródła, a zespół potrafi z nich odbudować serwer. Jeśli firma ma osobne warunki komercyjne od właściciela praw, przypisz je do właściwych artefaktów i nie mieszaj z kopiami AGPL.