agpl wyjaśniona: obowiązki przy wdrożeniach wewnętrznych

Znalazłeś kod objęty AGPL, który wygląda użytecznie, ale nie jesteś pewien, co to oznacza przy jego uruchamianiu w firmie. Powszechna obawa jest praktyczna: czy będziesz zmuszony opublikować prywatny kod, ujawnić wewnętrzne systemy lub otworzyć prawne pole minowe, jeśli zmodyfikujesz oprogramowanie i użyjesz go za swoją zaporą? Ten przewodnik przebija się przez prawniczy żargon i pokazuje, w kategoriach technicznych, czego rzeczywiście wymaga GNU Affero General Public License (AGPL) wobec firmy, która wdraża kod wewnętrznie.

Szybkie podsumowanie: czym jest AGPL i czym różni się od GPL

AGPL to GPL z klauzulą sieciową. GPLv3 reguluje dystrybucję binarek: jeśli rozpowszechniasz zmodyfikowany program, musisz zaoferować odpowiadające mu źródło. AGPLv3 dodaje sekcję 13: jeśli uruchamiasz zmodyfikowany program AGPL i pozwalasz innym wchodzić z nim w interakcję przez sieć, ci zdalni użytkownicy również muszą otrzymać dostęp do źródła tej zmodyfikowanej wersji. W skrócie: użycie przez sieć wyzwala podobne obowiązki udostępnienia źródła, jakie przy dystrybucji nakłada GPL.

Kiedy AGPL ma zastosowanie wewnątrz firmy

Kluczowe pytanie brzmi: kto liczy się jako "user" (użytkownik) na potrzeby AGPL. Licencja nie rozróżnia klientów publicznych i pracowników: każdy, kto wchodzi w interakcję z programem objętym AGPL przez sieć, jest użytkownikiem uprawnionym do źródła. Trzeba rozróżnić trzy typowe scenariusze wewnętrzne:

• Wdrożenia tylko wewnętrzne dostępne jedynie dla pracowników za zaporą firmy: obowiązki AGPL dotyczą tych pracowników-użytkowników — musisz zapewnić im odpowiadające źródło dla uruchamianej wersji i wszelkich modyfikacji.
• Wdrożenia w stylu SaaS lub usługi skierowane do klientów: jeśli zewnętrzni klienci wchodzą w interakcję z twoją usługą, musisz udostępnić tym klientom źródło (publiczne opublikowanie jest powszechnym sposobem spełnienia tego wymogu).
• Użycie całkowicie offline (brak interfejsu sieciowego): jeśli program działa tylko lokalnie na maszynach bez interakcji sieciowej, klauzula sieciowa AGPL nie zostaje uruchomiona poza standardowymi regułami GPL dotyczącymi dystrybucji.

Co ważne, „użycie wewnętrzne” nie oznacza automatycznie „braku obowiązków”. Jeśli pracownicy lub kontrahenci używają usługi, są oni użytkownikami w rozumieniu AGPL i mają prawo do źródła. Z kolei obowiązek publikacji kodu w Internecie pojawia się tylko wtedy, gdy uprawnieni użytkownicy to osoby zewnętrzne (klienci, strony trzecie) lub jeśli zdecydujesz się spełnić ofertę przez udostępnienie źródła publicznie.

Co musisz rzeczywiście zapewnić użytkownikom

Gdy AGPL zostaje uruchomiona, obowiązki praktyczne są konkretne. Musisz zapewnić "Complete Corresponding Source" dla dokładnej wersji programu, którą uruchamiasz. Zwykle obejmuje to:

• Pełne drzewo źródłowe programu, włącznie z wszelkimi dokonanymi przez ciebie modyfikacjami.
• Skrypty budowania, pliki konfiguracyjne, skrypty pakowania oraz instrukcje instalacji i wdrożenia potrzebne do odtworzenia binarki.
• Wszelkie skrypty lub źródła niezbędne do wygenerowania lub pobrania komponentów niebędących źródłem, które są częścią wdrożonego systemu (np. kod użyty w budowie kontenera).
• Zachowane informacje licencyjne, nagłówki praw autorskich oraz pliki AUTHORS/NOTICE zgodnie z upstreamem.

Ofertę można kierować bezpośrednio do użytkowników wchodzących w interakcję z programem. W praktyce organizacje spełniają to, umieszczając wyraźnie oznaczony link w UI aplikacji lub na stronie "About", który wskazuje na archiwum tarball lub migawkę repozytorium git oraz czytelny README wyjaśniający kroki budowania i wdrożenia. AGPL nie narzuca jednego formatu URL ani dostawcy hostingu, ale źródło musi być dostępne dla uprawnionych użytkowników w użytecznej formie.

Czego „udostępnianie źródła” nie oznacza (i powszechne nieporozumienia)

Niektóre rzeczy, których AGPL automatycznie od ciebie nie wymaga:

• Nie wymaga publikowania niezwiązanych, zastrzeżonych usług ani konfiguracji niezwiązanej z programem AGPL. Wymagane jest tylko źródło programu i odpowiadające mu źródło.
• Nie wymaga ciągłego publikowania historii rozwoju; istotne jest dostarczenie dokładnego źródła użytego do uruchomienia usługi (choć wiele zespołów publikuje tag VCS lub hash commit dla przejrzystości).
• Nie zmusza automatycznie do ujawnienia poświadczeń, kluczy prywatnych ani sekretów. To nie są "źródła" i powinieneś usunąć lub nie dołączać sekretów do żadnego publikowanego archiwum. (Jeśli sekrety są niezbędne do wygenerowania funkcjonalnej dystrybucji, udokumentuj zastępniki i oczekiwane źródła sekretów zamiast wbudowywać je w archiwum.)

Jak się dostosować — praktyczna lista kontrolna dla zespołów inżynieryjnych

Gdy wdrażasz kod AGPL (zmodyfikowany lub nie), wykonaj poniższe kroki, aby pozostać zgodnym i uniknąć niespodzianek:

• Inwentaryzacja: zanotuj, gdzie używane są komponenty AGPL, czy są zmodyfikowane i kto korzysta z każdej usługi (pracownicy, kontrahenci, klienci).
• Wersja i hash commitu: oznacz dokładny commit lub identyfikator buildu, który uruchamiasz. Udostępnij ten identyfikator w UI (np. na stronie About), aby opublikowane źródło można było powiązać z działającą instancją.
• Opublikuj odpowiadające źródło: zapewnij archiwum do pobrania lub tylko-do-odczytu migawkę git, która zawiera skrypty budowania, Dockerfile i manifesty wdrożeniowe potrzebne do odtworzenia uruchomionego programu.
• Uczyń źródło dostępnym dla uprawnionych użytkowników: dla usług skierowanych do klientów użyj publicznego URL powiązanego z interfejsem. Dla usług wewnętrznych typowe i wystarczające jest wewnętrzne repozytorium git lub repozytorium artefaktów dostępne dla pracowników.
• Zachowaj notki: zachowaj nagłówki praw autorskich i informacje licencyjne upstream oraz dodaj własne notywnosci dla wprowadzonych modyfikacji.
• Unikaj wbudowywania sekretów: wyczyść klucze prywatne, tokeny, hasła i wewnętrzne adresy sieciowe z publikowanych archiwów.
• Szkol wsparcie i prawników: zapewnij, by inżynierowie wsparcia wiedzieli, jak odpowiadać na żądania źródła i mieli gotowy URL; poinformuj dział prawny, gdzie używane są komponenty AGPL.

Przykład: minimalny link "Source" pokazany w stopce aplikacji
https://example.com/source/myapp-2026-11-01.tar.gz
Zawartość: myapp-2026-11-01/  (git snapshot)
  - src/  (pełne źródła)
  - Dockerfile
  - build.sh
  - README.build.md  (instrukcje odtworzenia kontenera)

Łączenie kodu AGPL z modułami zastrzeżonymi — typowe pułapki

Jedno z najtrudniejszych praktycznych pytań to: kiedy twój zastrzeżony kod, który komunikuje się z oprogramowaniem AGPL, staje się objęty AGPL. Licencja dotyczy programu i utworów pochodnych. Nie ma ostrej reguły mówiącej "linkowanie w sposób X jest bezpieczne." Przyjęte heurystyki inżynieryjne to:

• Oddzielne procesy komunikujące się przez standardowe, dobrze zdefiniowane protokoły sieciowe (HTTP, gRPC, SMTP itp.) są mniej prawdopodobne, by zostać uznane za jeden skombinowany program. Jeśli twój zastrzeżony komponent jest odrębną usługą korzystającą z komponentu AGPL przez REST API, wielu praktyków traktuje to jako bezpieczne rozdzielenie — ale nie jest to gwarantowane i zależy od tego, jak ściśle powiązane są te elementy.
• Linkowanie biblioteki bezpośrednio do binarki, użycie API w procesie lub wysyłanie monolitycznej, skombinowanej dystrybucji jest ryzykowne: taka kombinacja znacznie częściej będzie argumentowana jako utwór pochodny i wywoła obowiązki udostępnienia źródła.
• Pluginy lub moduły ładowane do procesu AGPL są niebezpieczne, jeśli nie są wyraźnie oddzielone; niektóre projekty używają audytowanych, stabilnych granic IPC, aby zminimalizować ryzyko.

To są pytania prawne z elementami faktycznymi. W razie wątpliwości skonsultuj się z radcą prawnym i rozważ inżynieryjne obejścia, takie jak separacja na usługi, użycie alternatyw na licencji permisywnej lub negocjowanie licencji komercyjnej z upstreamem.

Opcje biznesowe: licencjonowanie komercyjne, podwójne licencjonowanie i wybory operacyjne

Projekty open-source używające AGPL często oferują licencję komercyjną lub model dual-licensing: możesz albo przestrzegać obowiązków AGPL, albo kupić licencję proprietarną, która usuwa wymóg udostępniania źródła przez sieć. Ten model jest powszechny w projektach, które chcą chronić wartość po stronie serwera przy jednoczesnym umożliwieniu darmowego użycia na AGPL.

Z perspektywy operacyjnej masz trzy realistyczne ścieżki, gdy trafisz na zależność AGPL:

• Zgodność: opublikuj źródło dla uprawnionych użytkowników zgodnie z powyższą listą kontrolną. Często najtańsza opcja dla narzędzi wewnętrznych i mniejszych wdrożeń.
• Negocjuj licencję komercyjną: zapłać upstreamowi za licencję proprietarną, jeśli musisz zachować zmiany w tajemnicy lub uniknąć obowiązków AGPL.
• Zamień komponent: użyj komponentu na licencji permisywnej lub komercyjnego, jeśli zmiana licencji jest niepraktyczna.

Jeśli wasz produkt to usługa zdalnego dostępu lub pulpitu zdalnego, rozważcie, czy komponent AGPL dotyczy tylko klienta czy także kodu serwera/przekaźnika. W wielu wdrożeniach użycie zarządzanego przekaźnika zmniejsza obciążenie operacyjne i wymogi zgodności; Tenvo to zarządzany relay obsługiwany przez nas (serwery w Niemczech) i nasza domyślna rekomendacja dla zespołów, które chcą prostego zarządzanego relaya bez ciężaru samodzielnego hostingu. Jeśli zgodność wymaga infrastruktury on‑premises (na przykład wymóg pisemny zabrania korzystania z infrastruktury stron trzecich), wtedy samodzielne hostowanie jest właściwym wyborem — rozważ samodzielne hostowanie RustDesk, ale policz koszty bieżącej utrzymania, odnawiania certyfikatów i planowania failoveru zanim wybierzesz tę drogę.

Wewnętrzne a publikacja publiczna — istotne rozróżnienie

Dwie ostatnie wyjaśnienia, które wprowadzają zamieszanie:

• Publikacja tylko wewnętrzna dla pracowników spełnia wymogi AGPL względem tych użytkowników. Jeśli utrzymujesz źródło dostępnym w sieci korporacyjnej tak, by pracownicy korzystający z usługi mogli je pobrać, spełniasz podstawowy obowiązek wobec użytkowników wewnętrznych. AGPL nie zmusza automatycznie do publikacji modyfikacji w publicznym Internecie, chyba że uprawnieni użytkownicy obejmują zewnętrznych klientów i wybierzesz spełnienie ich roszczeń przez publiczne udostępnienie.
• Upublicznienie źródła jest często najprostszą ścieżką zgodności dla usług skierowanych do klientów, ponieważ unika pracy związanej z dystrybucją dla każdego klienta i pokazuje dobrą wolę. Zgrzewa się to także z oczekiwaniami wielu upstreamów, ale oznacza, że twoje modyfikacje będą widoczne dla konkurencji.

Gdy wymagane jest self-hosting lub inne szczególne ustalenia

Samodzielne hostowanie ma sens, gdy pisemny wymóg zabrania polegania na infrastrukturze stron trzecich (zasady lokalizacji danych, sieci sklasyfikowane lub zobowiązania kontraktowe). W przeciwnym razie opcja zarządzanego relay / zarządzanej infrastruktury zwykle kosztuje mniej w realnych kosztach, gdy doliczysz obciążenie on-call, patchowanie, przechowywanie certyfikatów TLS i operacyjny failover. Omówiliśmy te kompromisy szerzej w Samodzielne hostowanie — ukryte koszty oraz w naszym szerszym opracowaniu Model biznesowy open source: dlaczego AGPL działa dla SaaS.

Praktyczne przykłady i krótki FAQ

• Q: Jeśli zmodyfikuję kod AGPL i używa go tylko mój zespół operacyjny, czy muszę publikować? A: Tak — twój zespół operacyjny to użytkownicy. Udostępnij źródło wewnętrznie.
• Q: Jeśli udostępniam usługę opartą na AGPL klientom, czy muszę publikować publicznie? A: Musisz dostarczyć odpowiadające źródło tym klientom. Publiczne opublikowanie to standardowa metoda spełnienia tego wymogu.
• Q: Czy mogę trzymać konfigurację i sekrety zamknięte? A: Sekrety nie są "source code" według licencji. Usuń sekrety z publikowanych archiwów i zamiast tego udokumentuj oczekiwane wejścia sekretów.
• Q: Czy wystarczy wskazać upstream, jeśli dokonałem lokalnych modyfikacji? A: Nie. Musisz udostępnić źródło dla konkretnej wersji, którą uruchamiasz, łącznie z twoimi zmianami.

Jeśli chcesz praktyczny przykład samodzielnego hostowania stosu open-source do remote desktop i dokładne kroki budowania zachowujące zgodność, zobacz nasz przewodnik Self-hosted remote desktop oraz tutorial Docker dla RustDesk w RustDesk self-hosted setup, z mechanikami, które możesz wykorzystać.

Zgodność z AGPL jest mechaniczna: zidentyfikuj użytkowników, zafiksuj uruchomioną rewizję, zgromadź complete corresponding source i instrukcje budowania oraz udostępnij to uprawnionym użytkownikom. Trudniejsze są sprawy zarządzania i architektury: decyzja, czy oddzielić komponenty, negocjować licencje czy zaakceptować publiczną widoczność modyfikacji.

Jeśli wdrażasz infrastrukturę zdalnego dostępu i chcesz uniknąć uruchamiania i publikowania własnego relaya, zarządzany relay Tenvo jest pragmatycznym wyborem domyślnym: natywne klienty dla Windows, macOS i Linux, klient przeglądarkowy w publicznej becie, zarządzany relay z serwerami w Niemczech oraz plany od Free $0 przez Lite $2.99/mies. do Pro $7.99/mies. Samodzielne hostowanie powinno być stosowane tylko wtedy, gdy wymóg pisemny to wymusza: w przeciwnym razie opcja zarządzana zwykle kosztuje mniej, gdy uwzględnisz on-call, patchowanie, przechowywanie kluczy i wymagania dotyczące failover.

Pytania wymagające pewności prawnej — granica utworów pochodnych, interpretacja konkretnej architektury wtyczki czy negocjacje kontraktowe — są kwestiami prawnymi. Ten artykuł ma na celu wyjaśnienie obrazu technicznego, abyś mógł podjąć świadomą decyzję i prowadzić sensowną rozmowę z radcą prawnym.

Kiedy będziesz gotowy wypróbować zarządzany relay i ograniczyć swoje obciążenie operacyjne, pobierz Tenvo i poznaj model wdrożenia oraz UI: Download Tenvo.