Co to jest licencja open source? Kod i modele AI — poradnik

Licencja open source to umowa, która pozwala każdemu używać, zmieniać i rozpowszechniać kod — pod warunkami zapisanymi w tekście licencji. Licencje permisywne (MIT, Apache 2.0, BSD) wymagają głównie zachowania not prawnych. Licencje copyleft (GPL, AGPL) każą oddać kod źródłowy przy dystrybucji albo — w AGPL — przy udostępnieniu zmienionego programu przez sieć. W AI dochodzi trzecia warstwa: licencje modeli, które często tylko wyglądają na otwarte. Dla zarządu najważniejsze pytanie nie brzmi „czy to open source?”, ale „co możemy z tym zrobić w naszym modelu biznesowym?”.

Poradnik jest dla zarządu i liderów IT firm od 50 osób, które budują systemy AI z komponentów open source i modeli z otwartymi wagami. Na końcu jest mapa wszystkich wpisów o licencjach na blogu. To nie jest porada prawna — warunki konkretnej licencji oceni prawnik. Szerszy kontekst — z jakich warstw składa się własny stos AI — daje poradnik o AI OS, a o wyborze samego modelu pisze poradnik o modelach językowych.

Co sprawia, że licencja jest „open source”

Słowo „open source” ma właściciela definicji. Open Source Initiative (OSI) prowadzi Open Source Definition — dziesięć kryteriów, które licencja musi spełnić. Najważniejsze dla firmy:

• swobodna redystrybucja i dostęp do kodu źródłowego,
• prawo do tworzenia dzieł pochodnych,
• zakaz dyskryminacji osób i grup (punkt 5),
• zakaz ograniczania dziedzin zastosowania (punkt 6), np. „nie do celów komercyjnych”.

Licencja, która przeszła przegląd OSI, trafia na listę licencji zatwierdzonych. Popularne są tam MIT, Apache 2.0, licencje BSD, GPL, LGPL, MPL 2.0 i EPL 2.0 (stan na 6.10.2026).

Punkty 5 i 6 rozstrzygają najwięcej sporów w AI. Jeśli licencja mówi „nie dla firm powyżej progu użytkowników” albo „nie do tych zastosowań”, to nie jest licencja open source — nawet jeśli kod i wagi można pobrać jednym kliknięciem.

Obok są licencje source-available: kod widać, ale prawa są ograniczone. Przykład to Business Source License 1.1, która sama stwierdza, że nie jest licencją open source, i po dacie zmiany (najpóźniej po czterech latach od publikacji wersji) przechodzi na licencję zgodną z GPL. Dla zarządu to sygnał: widoczny kod nie oznacza prawa do konkurencyjnej usługi.

Rodzaje licencji: od permisywnych do copyleft

Licencje układają się na jednej osi: ile obowiązków przechodzi na Was, gdy zmieniacie kod albo przekazujecie go dalej. Poniżej skrót według tekstów licencji i klasyfikacji choosealicense.com (serwis GitHub, źródło pomocnicze).

Permisywne: MIT, BSD, Apache 2.0

Pozwalają wbudować kod w zamknięty produkt. Warunek to zachowanie not o prawach autorskich i tekstu licencji. Apache 2.0 dodaje trzy rzeczy, które zarząd powinien znać:

• licencję patentową od współtwórców — wygasa, jeśli firma pozwie kogoś, twierdząc, że kod narusza jej patent,
• obowiązek oznaczenia zmienionych plików i przekazania pliku NOTICE,
• brak prawa do znaków towarowych — fork nie może udawać oficjalnego produktu.

MIT i BSD nie mają wyraźnej licencji patentowej. BSD 3-Clause zabrania używania nazw autorów do promocji bez zgody.

Słaby copyleft: LGPL, MPL, EPL

Obowiązek oddania źródeł dotyczy tylko objętej licencją części: biblioteki (LGPL), pliku (MPL 2.0) albo modułu (EPL 2.0). Własna aplikacja może pozostać zamknięta, ale zmiany w samym komponencie przy dystrybucji trzeba udostępnić. W LGPL użytkownik ma też móc podmienić bibliotekę na zmienioną wersję.

Silny copyleft: GPLv2 i GPLv3

Gdy przekazujecie program na GPL albo dzieło od niego pochodne — w aplikacji, urządzeniu, obrazie kontenera — odbiorca dostaje kod źródłowy i te same prawa. GPLv3 dodaje postanowienia patentowe i, w części urządzeń konsumenckich, obowiązek umożliwienia instalacji zmienionej wersji. Granica „dzieła pochodnego” wymaga oceny prawnika — jedna biblioteka GPL nie zawsze „zaraża” cały produkt, ale też nie można tego zakładać z góry.

Sieciowy copyleft: AGPLv3

GPL ma tzw. lukę SaaS. Według tekstu GPLv3 sama interakcja z użytkownikiem przez sieć, bez przekazania kopii, nie jest przekazaniem programu. AGPLv3 tę lukę zamyka w sekcji 13: jeśli zmodyfikujecie program, wersja zmieniona musi zaoferować użytkownikom łączącym się przez sieć możliwość pobrania kodu źródłowego. Dla firmy, która sprzedaje platformę jako usługę, to najważniejsza licencja do sprawdzenia.

Licencje modeli i „otwarte wagi”

Modele AI często mają licencje pisane przez vendora. Mogą zawierać politykę dopuszczalnego użycia, progi wielkości licencjobiorcy, obowiązki oznaczeń i ograniczenia terytorialne. Szczegóły w osobnej sekcji niżej.

Porównanie w jednej tabeli

Grupa	Przykłady	Zamknięty produkt	Kiedy oddać źródła	Na co uważać
Permisywne	MIT, BSD 2/3-Clause, Apache 2.0	tak	nigdy (tylko noty i licencja)	NOTICE i oznaczenie zmian w Apache, marka
Słaby copyleft	LGPLv3, MPL 2.0, EPL 2.0	tak, poza komponentem	zmiany w bibliotece, pliku lub module przy dystrybucji	sposób połączenia z aplikacją
Silny copyleft	GPLv2, GPLv3	zwykle nie przy dystrybucji	przy przekazaniu programu lub dzieła pochodnego	urządzenia, obrazy kontenerów, aplikacje u klienta
Sieciowy copyleft	AGPLv3	nie dla zmienionego programu	także gdy użytkownik łączy się przez sieć	SaaS i platformy dla klientów
Licencje modeli	Llama 4 Community License, Gemma Terms of Use	zależy od warunków	zwykle nie dotyczy	polityka użycia, progi, terytorium, oznaczenia
Source-available	Business Source License 1.1	zależy od warunków	—	to nie jest open source

Co to znaczy dla firmy: pięć sytuacji

Ta sama licencja daje różne skutki zależnie od tego, co robicie z komponentem. Zarząd powinien znać pięć sytuacji:

1. Użycie wewnętrzne. Instalujecie narzędzie na własnych serwerach dla pracowników. Prawie każda licencja open source na to pozwala bez dodatkowych obowiązków.
2. Modyfikacja. Zmieniacie kod pod własne potrzeby. Dopóki nic nie wychodzi poza firmę, copyleft zwykle nie wymaga publikacji. Wyjątek: AGPL, gdy zmieniony program obsługuje użytkowników przez sieć.
3. Dystrybucja. Przekazujecie oprogramowanie klientowi: instalator, aplikację mobilną, urządzenie, obraz kontenera. Tu uruchamiają się warunki GPL, LGPL, MPL, EPL i obowiązki not w licencjach permisywnych.
4. SaaS. Klienci korzystają przez przeglądarkę albo API. GPL zwykle nie wymaga wtedy oddania kodu, AGPL — tak, dla zmienionego programu.
5. Patenty i marka. Apache 2.0 i GPLv3 mają postanowienia patentowe, MIT i BSD — nie wprost. Żadna z nich nie daje prawa do cudzego znaku towarowego.

Najczęstsza pomyłka nie dotyczy GPL, tylko zmiany modelu biznesowego. Narzędzie wewnętrzne staje się produktem dla klientów, a nikt nie wraca do licencji komponentów. Agent kodujący doda nową zależność szybciej, niż ktokolwiek przeczyta jej plik LICENSE — i z pełnym przekonaniem napisze w opisie zmiany „licencja OK”.

Modele AI a open source: wagi, kod i dane

Model AI to nie tylko kod. To co najmniej cztery artefakty: kod uruchamiania, kod trenowania, wagi (parametry) i dane treningowe. Każdy może mieć inną licencję albo żadnej.

Definicja Open Source AI (OSAID 1.0)

OSI wydało Open Source AI Definition 1.0 28.10.2024. System AI jest open source, jeśli daje cztery wolności: używać w dowolnym celu bez pytania o zgodę, badać działanie, modyfikować (także zmieniać wyniki) i udostępniać dalej. Do tego trzeba dostać „preferowaną formę do modyfikacji”:

• informacje o danych — na tyle szczegółowe, by wykwalifikowana osoba mogła zbudować zasadniczo równoważny system,
• pełny kod trenowania i uruchamiania, w tym przetwarzania i filtrowania danych,
• parametry, czyli wagi i ustawienia modelu.

Wszystko na warunkach zgodnych z definicją OSI. OSAID nie wymaga publikacji samych danych, tylko informacji o nich. Mimo to wiele popularnych modeli z „otwartymi wagami” tej definicji nie spełnia.

„Otwarte wagi” to nie open source

Otwarte wagi oznaczają, że parametry można pobrać. Nic więcej. Przykłady (stan na 6.10.2026, tylko ze źródeł vendorów):

• Llama 4 (Meta). Licencja społecznościowa Llama 4 od 5.04.2025: firmy z ponad 700 mln aktywnych użytkowników miesięcznie potrzebują osobnej licencji, produkt musi pokazywać „Built with Llama”, a nazwa modelu pochodnego zaczyna się od „Llama”. Polityka dopuszczalnego użycia dla modeli multimodalnych Llama 4 nie udziela praw osobom z miejscem zamieszkania w UE ani firmom z główną siedzibą w UE. Wyjątek dotyczy użytkowników końcowych produktu, który taki model zawiera. Dla polskiej firmy, która chce dostrajać i wdrażać model sama, to warunek do sprawdzenia przed pilotem. OSI oceniło licencję Llama 3.x jako niezgodną z open source, właśnie z powodu punktów 5 i 6.
• Gemma (Google). Wcześniejsze modele Gemma mają Gemma Terms of Use: politykę zakazanych zastosowań, obowiązek przeniesienia ograniczeń na odbiorców i prawo Google do ograniczenia użycia przy naruszeniu. Za model pochodny uznaje się też model po destylacji, ale nie wyniki modelu. Gemma 4 to pierwsze modele Gemma na Apache 2.0 (2.04.2026). Ta sama nazwa rodziny, dwa różne reżimy prawne — numer wersji ma znaczenie.
• gpt-oss (OpenAI). Repozytorium ma licencję Apache 2.0 i obok osobny plik z polityką użycia. Warto przeczytać oba.

Wniosek: przy każdym modelu zapiszcie licencję wag, licencję kodu i to, co wiadomo o danych. Etykieta „open” na stronie produktu niczego nie przesądza.

Licencje a AI Act

AI Act przewiduje częściowe ulgi dla modeli AI ogólnego przeznaczenia udostępnianych na wolnych i otwartych licencjach, z publicznymi wagami i architekturą (art. 53 ust. 2 rozporządzenia 2024/1689). Ulgi zwalniają z części obowiązków dokumentacyjnych i nie obejmują modeli z ryzykiem systemowym. Dotyczą przede wszystkim vendorów modeli, nie firmy, która model wdraża. Zakres w Waszym przypadku oceni prawnik.

Jak sprawdzać licencje: rejestr, SPDX i SBOM

Kontrola licencji nie wymaga działu prawnego na pełen etat. Wymaga stałego miejsca, w którym zapisujecie, co macie.

1. SBOM dla każdego systemu. SBOM (Software Bill of Materials) to spis składników z wersjami, pochodzeniem i licencjami. Standard SPDX jest normą ISO/IEC 5962:2021, a SPDX 3.0 ma profile dla AI i zbiorów danych — można w nim opisać także model i dane.

2. Identyfikatory SPDX zamiast opisów. Lista licencji SPDX nadaje każdej licencji jednoznaczny identyfikator: MIT, Apache-2.0, GPL-3.0-only, AGPL-3.0-or-later. Różnica między „only” a „or-later” bywa istotna przy łączeniu komponentów.

3. Rejestr licencji z decyzją. Dla każdego komponentu: artefakt (kod, wagi, dane), identyfikator licencji, sposób użycia (wewnętrznie, SaaS, dystrybucja), obowiązki, właściciel i data przeglądu. Licencje spoza listy OSI dostają osobną ścieżkę — do prawnika.

4. Program zgodności. Norma ISO/IEC 5230 (OpenChain) opisuje, czego wymaga dobry program zgodności licencyjnej: gdzie działa proces, kto ma jakie role i jak utrzymać go w czasie. Nie trzeba się certyfikować, żeby skorzystać ze struktury.

5. Kontrola przy każdej zmianie. Nowa zależność, nowa wersja modelu albo nowy sposób udostępnienia (np. przejście z narzędzia wewnętrznego na SaaS) to nowy przegląd. W systemach budowanych z agentami kodującymi automatyczne skanowanie licencji w procesie budowania jest tańsze niż ręczne śledztwo po roku.

Typowe pułapki

• Brak licencji to nie wolność. Kod na GitHubie bez pliku LICENSE nie daje praw do użycia — obowiązuje wtedy zwykłe prawo autorskie, a prawa zostają przy autorze.
• Licencja repozytorium ≠ licencja wag. Framework na Apache 2.0 może uruchamiać model na licencji z polityką użycia. Sprawdzajcie artefakt, nie projekt.
• Zmiana licencji w nowej wersji. Projekt może przejść z licencji open source na source-available. Starsze wersje zostają na starej licencji, ale aktualizacje już nie. Rejestr z numerem wersji pokazuje to od razu.
• SaaS z komponentem AGPL. Zmiana kodu w komponencie AGPL i udostępnienie go klientom przez sieć oznacza obowiązek zaoferowania źródeł tej zmiany.
• Obraz kontenera to dystrybucja. Przekazanie klientowi obrazu z bibliotekami GPL uruchamia obowiązki GPL, nawet jeśli Wasz kod jest osobny.
• Noty i NOTICE. Najczęstsze naruszenie licencji permisywnej jest nudne: brak tekstu licencji i not w paczce dla klienta.
• Ograniczenia terytorialne i progi. Licencje modeli potrafią wykluczyć firmy z UE z części praw albo wymagać osobnej umowy powyżej progu użytkowników. Tego nie ma w żadnej licencji zatwierdzonej przez OSI.

Jak zacząć: trzy kroki dla zarządu

Krok 1. Spis tego, co już macie. Poproście zespół o SBOM jednego najważniejszego systemu, z modelami i danymi. Jeśli nikt nie potrafi go wygenerować, to jest pierwsza informacja.

Krok 2. Zasada wyboru komponentów. Jedna strona: które grupy licencji są dozwolone bez pytania (zwykle permisywne), które wymagają przeglądu (copyleft, AGPL), a które prawnika (licencje modeli i licencje spoza listy OSI).

Krok 3. Przegląd przy zmianie modelu biznesowego. Każde przejście z narzędzia wewnętrznego na produkt dla klientów albo SaaS zaczyna się od przeglądu licencji. To tańsze niż przepisywanie komponentu po fakcie.

Jeśli po kroku 1 okazuje się, że nie wiecie, z jakich warstw składa się Wasz system AI i które z nich są naprawdę otwarte, problem nie leży w jednej licencji. Wtedy pomaga rozmowa zarządu o architekturze i zależnościach. Na tym polega prezentacja dla zarządu: nazwiemy warstwy systemu, zależności i decyzje do podjęcia, niezależnie od vendora i partnera.

Mapa wpisów o licencjach open source w AI

Wszystkie wpisy o licencjach w czterech grupach — od najmniej do najbardziej wymagających. Każdy wpis serii omawia jedną licencję: co pozwala, jakie nakłada obowiązki i co znaczy dla suwerenności firmy.

A. Licencje permisywne

Kod można wbudować w zamknięty produkt; obowiązki dotyczą głównie not.

• Licencja MIT: wolność użycia a suwerenność biznesowa — najprostsza licencja i czego nie rozwiązuje.
• Apache 2.0: licencja open source dla firmowego AI — patenty, NOTICE i redystrybucja.
• BSD 2-Clause: prosta licencja dla przenośnego kodu — różnice wobec BSD 3-Clause i MIT.
• BSD 3-Clause: otwarty kod bez prawa do cudzej marki — klauzula zakazu rekomendacji i prawo do forka.

B. Słaby copyleft

Własna aplikacja może zostać zamknięta, zmiany w komponencie — nie.

• LGPLv3: biblioteka otwarta, aplikacja może pozostać własna — relinkowanie i pułapki dystrybucji.
• MPL 2.0: copyleft na poziomie pliku w firmowym AI — łączenie otwartego i zamkniętego kodu.
• EPL 2.0: otwarty komponent w ekosystemie enterprise — moduły, patenty i źródła zmian.

C. Silny i sieciowy copyleft

Przy dystrybucji — a w AGPL także przez sieć — odbiorca dostaje kod źródłowy.

• GPLv2: źródła dla odbiorcy i granice suwerenności — kiedy trzeba przekazać kod i co znaczy GPL-2.0-only.
• GPLv3: copyleft, patenty i prawo do zmiany urządzenia — patenty, informacja instalacyjna i luka SaaS.
• AGPLv3: otwarty serwer AI także przy dostępie przez sieć — obowiązki operatora platformy.

D. Modele, otwarte wagi i wdrożenie

Licencje modeli i wybór partnera do wdrożenia open source AI.

• Llama od Meta: własne wdrożenie modelu AI — licencja społecznościowa i polityka użycia.
• Gemma od Google: mały model pod kontrolą firmy — Gemma 4 na Apache 2.0.
• Co to jest LLM? Modele językowe — poradnik dla firm — modele otwarte i zamknięte, miejsce uruchomienia.
• Jak wybrać partnera do wdrożenia open source AI? — kryteria wyboru, w tym znajomość licencji.