--- title: "Co to jest licencja open source? Kod i modele AI — poradnik" url: "https://majchrzycki.com/blog/co-to-jest-licencja-open-source-poradnik-dla-firm" description: "MIT, Apache 2.0, GPL, AGPL i licencje modeli Llama czy Gemma: co firma może zrobić z kodem i wagami, kiedy musi oddać źródła i jak to sprawdzać." --- # Co to jest licencja open source? Kod i modele AI — poradnik 6 października 2026· Aktualizacja: 6 października 2026·9 min czytania·[Krzysztof Majchrzycki](https://majchrzycki.com/o-mnie) Temat: [Open Source AI](https://majchrzycki.com/blog/filar/open-source-ai) **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](https://majchrzycki.com/blog/co-to-jest-ai-os-poradnik-dla-firm), a o wyborze samego modelu pisze [poradnik o modelach językowych](https://majchrzycki.com/blog/co-to-jest-llm-poradnik-dla-firm). ## Co sprawia, że licencja jest „open source” Słowo „open source” ma właściciela definicji. Open Source Initiative (OSI) prowadzi [Open Source Definition](https://opensource.org/osd) — 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](https://opensource.org/licenses). 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](https://mariadb.com/bsl11/), ż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](https://choosealicense.com/licenses/) (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](https://www.apache.org/licenses/LICENSE-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](https://opensource.org/license/agpl-v3) 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 Mapa licencji od permisywnych do licencji modeli. Permisywne (MIT, BSD, Apache 2.0): zamknięty produkt wolno, wystarczą noty i licencja. Słaby copyleft (LGPL, MPL, EPL): oddajecie zmiany w komponencie. Silny copyleft (GPL): przy dystrybucji źródła całego dzieła pochodnego. Sieciowy copyleft (AGPL): także przy dostępie przez sieć. Licencje modeli z ograniczeniami: polityka użycia, progi, terytorium. Wniosek: licencja dotyczy artefaktu — kod, wagi i dane sprawdzacie osobno. Mapa licencji: im niżej, tym więcej obowiązków przy zmianie i przekazaniu dalej. Uproszczenie autora na podstawie tekstów licencji i klasyfikacji OSI. ## 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](https://opensource.org/ai/open-source-ai-definition) 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](https://dev.meta.ai/llama/llama4/license/) 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](https://dev.meta.ai/llama/llama4/use-policy/) 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](https://opensource.org/blog/metas-llama-license-is-still-not-open-source) 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](https://ai.google.dev/gemma/terms): 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](https://opensource.googleblog.com/2026/03/gemma-4-expanding-the-gemmaverse-with-apache-20.html) (2.04.2026). Ta sama nazwa rodziny, dwa różne reżimy prawne — numer wersji ma znaczenie. - **gpt-oss (OpenAI).** [Repozytorium](https://github.com/openai/gpt-oss) 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](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)). 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](https://spdx.dev/about/overview/) 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](https://spdx.org/licenses/) 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](https://openchainproject.org/license-compliance)) 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. Karta decyzji „Czy możemy użyć tego komponentu?”. Sześć kroków: ustal licencję każdego artefaktu (kod, wagi, dane) — brak licencji oznacza brak zgody; sprawdź, czy licencja jest zatwierdzona przez OSI — jeśli nie, przegląd prawnika; nazwij sposób użycia: wewnętrznie, SaaS czy dystrybucja; przy copyleft i dystrybucji albo AGPL i sieci zaplanuj udostępnienie źródeł lub zmień komponent; spełnij obowiązki not, NOTICE i marki; wpisz komponent do rejestru i SBOM. Uproszczenie autora, nie porada prawna. Czy możemy użyć tego komponentu: sześć pytań przed wpisaniem zależności do systemu. Uproszczenie autora, nie porada prawna. ## 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](https://choosealicense.com/no-permission/), 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](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu): 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](https://majchrzycki.com/blog/licencja-mit-suwerennosc-ai-os) — najprostsza licencja i czego nie rozwiązuje. - [Apache 2.0: licencja open source dla firmowego AI](https://majchrzycki.com/blog/licencja-apache-2-0-suwerennosc-ai-os) — patenty, `NOTICE` i redystrybucja. - [BSD 2-Clause: prosta licencja dla przenośnego kodu](https://majchrzycki.com/blog/licencja-bsd-2-clause-suwerennosc-ai) — różnice wobec BSD 3-Clause i MIT. - [BSD 3-Clause: otwarty kod bez prawa do cudzej marki](https://majchrzycki.com/blog/licencja-bsd-3-clause-suwerennosc-ai) — 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](https://majchrzycki.com/blog/licencja-lgpl-3-0-suwerennosc-ai-os) — relinkowanie i pułapki dystrybucji. - [MPL 2.0: copyleft na poziomie pliku w firmowym AI](https://majchrzycki.com/blog/licencja-mpl-2-0-suwerennosc-ai-os) — łączenie otwartego i zamkniętego kodu. - [EPL 2.0: otwarty komponent w ekosystemie enterprise](https://majchrzycki.com/blog/licencja-epl-2-0-suwerennosc-ai-os) — 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](https://majchrzycki.com/blog/licencja-gpl-2-0-suwerennosc-ai-os) — kiedy trzeba przekazać kod i co znaczy GPL-2.0-only. - [GPLv3: copyleft, patenty i prawo do zmiany urządzenia](https://majchrzycki.com/blog/licencja-gpl-3-0-suwerennosc-ai-os) — patenty, informacja instalacyjna i luka SaaS. - [AGPLv3: otwarty serwer AI także przy dostępie przez sieć](https://majchrzycki.com/blog/licencja-agpl-3-0-suwerennosc-ai-os) — 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](https://majchrzycki.com/blog/llama-meta-model-otwarte-wagi-firma) — licencja społecznościowa i polityka użycia. - [Gemma od Google: mały model pod kontrolą firmy](https://majchrzycki.com/blog/gemma-google-model-lokalny-kod-biznes) — Gemma 4 na Apache 2.0. - [Co to jest LLM? Modele językowe — poradnik dla firm](https://majchrzycki.com/blog/co-to-jest-llm-poradnik-dla-firm) — modele otwarte i zamknięte, miejsce uruchomienia. - [Jak wybrać partnera do wdrożenia open source AI?](https://majchrzycki.com/blog/jak-wybrac-partnera-do-wdrozenia-open-source-ai) — kryteria wyboru, w tym znajomość licencji. - Open Source AI - Licencje - Suwerenność - Zarząd ## Sprawdźmy, na czym naprawdę stoi Wasz system AI Prezentacja dla zarządu: przejdziemy przez warstwy Waszego systemu — kod, modele, dane i usługi — i nazwiemy, które decyzje licencyjne wymagają rejestru, a które prawnika. Niezależnie od vendora i partnera. [Umów prezentację dla zarządu](https://majchrzycki.com/wspolpraca/prezentacja-systemu-ai-dla-zarzadu) FAQ ## Najczęstsze pytania Czy open source znaczy, że możemy z kodem zrobić wszystko? Nie. Licencja open source pozwala używać, zmieniać i rozpowszechniać kod, ale stawia warunki. Licencje permisywne (MIT, Apache 2.0, BSD) wymagają głównie zachowania not i tekstu licencji. Licencje copyleft (GPL, AGPL) przy dystrybucji albo udostępnieniu przez sieć wymagają przekazania kodu źródłowego na tej samej licencji. Do tego dochodzą znaki towarowe, których licencja kodu zwykle nie obejmuje. Czy GPL zmusza nas do opublikowania kodu, jeśli udostępniamy aplikację jako SaaS? Sama GPL — zwykle nie, bo obowiązki powstają przy przekazaniu kopii programu, a według tekstu GPLv3 sama interakcja z użytkownikiem przez sieć nie jest przekazaniem. Inaczej jest z AGPLv3: jeśli zmodyfikujecie program na AGPL i użytkownicy łączą się z nim przez sieć, musicie zaoferować im kod źródłowy zmodyfikowanej wersji. Konkretny przypadek oceni prawnik. Czy Llama od Meta to model open source? Według OSI — nie. Licencja Llama ogranicza, kto i do czego może używać modelu, a to kłóci się z definicją open source. Llama 4 ma własną licencję społecznościową z progiem 700 mln aktywnych użytkowników miesięcznie, obowiązkiem oznaczenia „Built with Llama” i polityką dopuszczalnego użycia. Dla modeli multimodalnych Llama 4 polityka nie udziela praw firmom z główną siedzibą w UE (wyjątek: użytkownicy końcowi gotowego produktu). Czym różnią się „otwarte wagi” od open source AI? Otwarte wagi oznaczają tylko, że można pobrać parametry modelu, często na licencji z ograniczeniami. Open Source AI Definition 1.0 (OSI, 2024) wymaga więcej: wag, pełnego kodu trenowania i uruchamiania oraz informacji o danych treningowych wystarczających do zbudowania zasadniczo równoważnego systemu — wszystko na warunkach zgodnych z definicją OSI. Czy model na licencji Apache 2.0 jest w pełni bezpieczny prawnie? Apache 2.0 daje szerokie prawa do kodu i wag, łącznie z licencją patentową od współtwórców. Nie rozstrzyga jednak, na jakich danych model trenowano, czy repozytorium nie ma osobnej polityki użycia (gpt-oss od OpenAI ma obok licencji plik z polityką użycia) i czy narzędzia wokół modelu mają tę samą licencję. Sprawdzajcie każdy artefakt osobno. Co to jest SBOM i czy jest nam potrzebny? SBOM (Software Bill of Materials) to spis składników oprogramowania z wersjami, pochodzeniem i licencjami. Standard SPDX (ISO/IEC 5962:2021) zapisuje licencje jednoznacznymi identyfikatorami, np. Apache-2.0, a SPDX 3.0 ma też profile dla AI i zbiorów danych. Jeśli dostarczacie oprogramowanie klientom albo budujecie system z wielu komponentów, SBOM jest najtańszym sposobem, by wiedzieć, co macie. Kto w firmie powinien odpowiadać za licencje open source? Właściciel produktu odpowiada za decyzję biznesową, zespół techniczny za rejestr i SBOM, a prawnik za interpretację nietypowych warunków. Standard ISO/IEC 5230 (OpenChain) opisuje taki program zgodności: gdzie działa proces, kto ma jakie role i jak utrzymać go w czasie. To nie jest porada prawna — warunki konkretnej licencji oceni prawnik. ## Czytaj dalej - [Jak wybrać partnera do wdrożenia open source AI?](https://majchrzycki.com/blog/jak-wybrac-partnera-do-wdrozenia-open-source-ai) - [GPLv2: źródła dla odbiorcy i granice suwerenności](https://majchrzycki.com/blog/licencja-gpl-2-0-suwerennosc-ai-os) - [LGPLv3: biblioteka otwarta, aplikacja może pozostać własna](https://majchrzycki.com/blog/licencja-lgpl-3-0-suwerennosc-ai-os) - [GPLv3: copyleft, patenty i prawo do zmiany urządzenia](https://majchrzycki.com/blog/licencja-gpl-3-0-suwerennosc-ai-os)