Licencje open source w firmie: MIT, GPL, AGPL i licencje z ograniczeniami

Firma, która uruchamia aplikację open source na własnym serwerze, zwykle nie płaci za licencję. Nie oznacza to jednak, że licencja jej nie dotyczy. Każda licencja określa, co wolno zrobić z programem, a część z nich nakłada obowiązki dopiero w konkretnych sytuacjach: przy zmianie kodu, przy przekazaniu programu dalej albo przy udostępnieniu zmienionej wersji przez sieć.

Ten tekst porządkuje podstawy. Nie jest poradą prawną. Przy nietypowym zastosowaniu, na przykład osadzaniu cudzego kodu we własnym produkcie, skonsultujcie licencję z prawnikiem.

Co oznacza „open source” według definicji OSI

Określenie „open source” ma konkretną definicję. Open Source Initiative opisuje ją w dziesięciu kryteriach. Jedno z nich mówi wprost, że licencja nie może ograniczać używania programu w określonej dziedzinie, na przykład w działalności gospodarczej.

To kryterium jest ważne dla firm. Licencja, która zabrania używania programu komercyjnie albo świadczenia usług wokół niego, może mieć jawny kod źródłowy, ale nie spełnia definicji open source. Producenci takich licencji często sami to zaznaczają i używają innych nazw, na przykład „fair-code” albo „source available”.

Licencje zezwalające: MIT i Apache 2.0

Licencja MIT daje prawo do używania, kopiowania, modyfikowania i rozpowszechniania programu bez ograniczeń, pod jednym warunkiem: informacja o prawach autorskich i treść licencji muszą zostać dołączone do kopii programu.

Apache 2.0 działa podobnie, ale dodaje dwie rzeczy istotne dla firm. Każdy współautor udziela licencji na swoje patenty związane z wkładem w program. Licencja wymaga też zachowania informacji o zmianach w zmodyfikowanych plikach i dołączenia pliku NOTICE, jeśli projekt go ma.

Dla firmy, która uruchamia taki program na własnym serwerze, obie licencje oznaczają w praktyce minimum obowiązków. Więcej uwagi wymagają przy wbudowywaniu kodu we własny produkt, bo wtedy trzeba zadbać o informacje licencyjne w dystrybucji.

Licencje copyleft: GPL

GPL należy do licencji z zasadą copyleft. Wolno używać, zmieniać i sprzedawać program. Fundacja Wolnego Oprogramowania pisze w swoim FAQ, że prawo do sprzedaży kopii jest częścią definicji wolnego oprogramowania.

Warunek pojawia się przy rozpowszechnianiu. Jeśli firma przekazuje innym zmienioną wersję programu, musi udostępnić jej kod źródłowy na tej samej licencji. Ten sam FAQ wyjaśnia jednak, że GPL nie wymaga publikowania zmian, których organizacja używa wewnętrznie. Firma może zmodyfikować program i korzystać z niego u siebie, nie wypuszczając zmian na zewnątrz.

AGPL: copyleft także przez sieć

Aplikacje webowe nie są zwykle przekazywane użytkownikom jako pliki. Działają na serwerze, a użytkownik otwiera je w przeglądarce. Dlatego powstała licencja GNU AGPL, której sekcja 13 rozszerza copyleft na korzystanie przez sieć.

Jeśli zmodyfikujecie program na licencji AGPL, zmieniona wersja musi wyraźnie oferować wszystkim użytkownikom, którzy korzystają z niej zdalnie, możliwość otrzymania kodu źródłowego. Obowiązek dotyczy modyfikacji kodu. Samo uruchomienie niezmienionej aplikacji i jej konfiguracja w panelu administracyjnym to jeszcze nie zmiana programu.

Wiele popularnych aplikacji dla firm, takich jak systemy helpdesk, menedżery haseł i wiki, jest na licencji AGPL. Dla firmy, która wdraża je bez zmian w kodzie, licencja nie tworzy dodatkowych obowiązków. Jeśli planujecie zmiany w kodzie, ustalcie przed wdrożeniem, jak będziecie udostępniać kod zmienionej wersji.

Open core: bezpłatny rdzeń i płatne moduły

Część projektów udostępnia rdzeń na licencji open source, a wybrane katalogi kodu na licencji komercyjnej producenta. Zwykle trafiają tam funkcje ważne dla firm: logowanie przez katalog domenowy, jednokrotne logowanie, rozszerzony dziennik audytu.

To uczciwy model, o ile wiadomo o nim przed wdrożeniem. Problem pojawia się, gdy ktoś uruchamia obraz instalacyjny, w którym są oba rodzaje kodu, i korzysta z funkcji płatnych bez licencji. Przed wyborem sprawdźcie, które funkcje są w wersji bezpłatnej, i nie włączajcie pozostałych bez umowy z producentem.

Licencje z jawnym kodem, które nie są open source

Kilka znanych licencji ma jawny kod, ale ogranicza zastosowania. Trzy przykłady, z którymi spotykamy się najczęściej:

• Sustainable Use License. Używa jej n8n, o którego zastosowaniach piszemy we wpisie o automatyzacjach n8n. Licencja pozwala korzystać z programu do wewnętrznych celów firmy. FAQ producenta dopuszcza płatne tworzenie, wdrażanie i utrzymanie przepływów dla klientów, ale nie pozwala udostępniać n8n jako usługi, w której klienci sami budują przepływy.
• Business Source License 1.1. Opracowana przez MariaDB. Ogranicza użycie produkcyjne poza tym, na co pozwala dodatkowa zgoda licencjodawcy, a po dacie zmiany, najpóźniej po czterech latach od wydania danej wersji, kod przechodzi na wskazaną licencję otwartą.
• Licencje z klauzulą marki. Licencja Open WebUI zakazuje zmiany oznaczeń marki programu, poza wyjątkami opisanymi w jej tekście. Z programu można korzystać, ale nie można go sprzedawać pod własną nazwą.

Żadna z nich nie jest „gorsza” sama w sobie. Każda wymaga jednak przeczytania przed wdrożeniem, bo to od sposobu użycia zależy, czy potrzebna jest licencja komercyjna.

Czego pilnować przy licencjach oprogramowania w firmie

1. Edycja programu. Ta sama aplikacja może mieć wersję bezpłatną, wersję z subskrypcją i wersję rozwojową, której producent nie zaleca do produkcji. Licencję sprawdza się dla konkretnej edycji i konkretnego pliku instalacyjnego.
2. Kto kupuje licencję. Jeśli wdrożenie wymaga płatnej edycji, licencję powinna kupić firma, która z niej korzysta. Wtedy po zmianie dostawcy usług wszystko zostaje u niej.
3. Zmiany w kodzie. Konfiguracja i integracja przez API zwykle nie są modyfikacją programu. Zmiany w kodzie na licencji GPL lub AGPL wymagają decyzji, jak udostępnicie kod, jeśli przekażecie program dalej albo udostępnicie go przez sieć.
4. Nazwy i logotypy. Licencja na kod nie daje praw do znaków towarowych. Nazwy produktu nie umieszcza się we własnych nazwach usług ani domenach.
5. Lista na piśmie. Spis aplikacji z licencją, edycją i datą sprawdzenia ułatwia audyt i rozmowę z kontrahentem, który pyta o oprogramowanie w Waszej firmie.

Jak sprawdzamy licencje aplikacji open source

W katalogu aplikacji, które wdrażamy na serwerach klientów, przy każdej pozycji podajemy licencję z linkiem do jej tekstu i najważniejsze ograniczenia wersji bezpłatnej. Licencje, które nie spełniają definicji open source, oznaczamy osobno. Szczegóły są na stronie wdrożenia i utrzymania aplikacji open source oraz w katalogu aplikacji.

Najczęściej zadawane pytania

Czy możemy używać aplikacji open source w działalności komercyjnej?

Tak. Definicja open source wyklucza ograniczanie zastosowań, w tym działalności gospodarczej. Ograniczenia mogą mieć licencje, które tylko udostępniają kod, dlatego zawsze sprawdzamy, czy licencja spełnia definicję.

Czy firma informatyczna może brać pieniądze za wdrożenie aplikacji na licencji AGPL?

Tak. AGPL nie zabrania płatnych usług. Warunki dotyczą udostępniania kodu zmienionej wersji użytkownikom, którzy korzystają z niej przez sieć.

Czy musimy publikować zmiany w programie na licencji GPL?

Nie, jeśli używacie ich tylko wewnątrz organizacji. Obowiązek udostępnienia kodu pojawia się, gdy przekazujecie zmienioną wersję na zewnątrz.

Źródła

• Open Source Initiative, The Open Source Definition, https://opensource.org/osd (dostęp 2.10.2026)
• Open Source Initiative, The MIT License, https://opensource.org/license/mit (dostęp 2.10.2026)
• Apache Software Foundation, Apache License 2.0, https://www.apache.org/licenses/LICENSE-2.0 (dostęp 2.10.2026)
• Free Software Foundation, Frequently Asked Questions about the GNU Licenses, https://www.gnu.org/licenses/gpl-faq.en.html (dostęp 2.10.2026)
• Free Software Foundation, GNU Affero General Public License, https://www.gnu.org/licenses/agpl-3.0.en.html (dostęp 2.10.2026)
• MariaDB, Business Source License 1.1, https://mariadb.com/bsl11/ (dostęp 2.10.2026)
• n8n, Sustainable Use License, https://github.com/n8n-io/n8n/blob/master/LICENSE.md (dostęp 2.10.2026)
• n8n, License FAQ, https://docs.n8n.io/n8n-community-license/community-license/license-faq (dostęp 2.10.2026)
• Open WebUI, Open WebUI License, https://github.com/open-webui/open-webui/blob/main/LICENSE (dostęp 2.10.2026)

Stan na 2 października 2026 r.