To jest pierwszy artykuł z serii poświęconych wyborowi modelu do lokalnego użycia. Kwestia licencjonowania modeli może wydawać się nudna i mniej istotna niż inne aspekty, które powinniśmy rozważać, jednak warto to przemyśleć: poświęciłeś czas i pieniądze na badanie modelu z każdej perspektywy, a niewielka luka prawna może uniemożliwić jego użycie w zamierzony sposób.

Dlatego rozpocznę od tematu: licencjonowanie.

Licencja na używanie

Znajomość licencji przypisanej modelowi LLM jest kluczowa, ponieważ określa co możesz legalnie zrobić z tym modelem oraz jego komponentami (kod, wagi, dokumentacja). Duże firmy traktują własność intelektualną swobodnie w odniesieniu do innych, ale mogą być bardzo rygorystyczne wobec swoich produktów. Dokumenty licencyjne mogą zostać użyte przeciwko Tobie w nieprzyjemny sposób, i nie – wielkie koncerny nie otworzą sprawy w sądzie^[1]. Na przykład pobiorą część pieniędzy należnych Ci z Twojego filmu na YouTube, jeśli wykorzystałeś muzykę wygenerowaną ich modelem. Czy to nie jest niesprawiedliwe? Przecież przeszukują sieć i wykorzystują pracę innych osób do trenowania modeli bez ponoszenia kosztów własności intelektualnej (IP). To jak mogą obciążyć Cię opłatą za muzykę zastosowaną w tle Twojego filmu, twierdząc, że posiadają „prawa własności intelektualnej” do niej? Tak, mogą i będą to robić. Nemo dat quod non habet odnosi się jedynie do Ciebie (twórcy, autora, artysty) a nie do wielkich firm.

Licencjonowanie jest ramą prawną, która określa, w jaki sposób kod, dane lub wytrenowane parametry mogą być używane, modyfikowane, udostępniane i spieniężane. W praktyce licencja LLM zazwyczaj składa się z dwóch warstw:

• Licencja na poziomie kodu – odnosi się do skryptów treningowych, silnika inferencji, wrapperów API itp.; podąża za standardowymi licencjami oprogramowania (MIT, Apache 2.0, GPL…).
• Licencja wag lub modelu – reguluje dystrybucję i użycie wytrenowanych parametrów; może być odrębnym dokumentem lub dodatkiem w karcie modelu.

Te dwie warstwy często są niezależne: możesz mieć kod licencjonowany na zasadach MIT, ale wagi mogą być dostępne jedynie „do badań” lub wymagać licencji komercyjnej. Zrozumienie obu aspektów jest niezbędne przed wdrożeniem lub redystrybucją modelu. To może być bardzo skomplikowane, dlatego warto dokładnie przeczytać licencję modelu. Wdrożenie może zostać rozszerzone o klauzule, których zwykle się nie spodziewasz.

Co oznaczają licencje „tylko do badań”?

Odrębna licencja „research‑only” jest stosunkowo nowa w licencjonowaniu open‑source i nie jesteśmy do tego przyzwyczajeni. Choć sama klauzula ma długą historię, dziś nabiera bardziej zniuansowanego charakteru w kontekście modeli AI:

• Ograniczony zakres użycia – klauzula „research‑only” zazwyczaj zezwala na niekomercyjne eksperymentowanie i ocenianie, ale zakazuje dowolnego monetyzowanego (spieniężanego) wdrożenia lub redystrybucji wytrenowanych parametrów.
• Ograniczenia dystrybucji – nie możesz po prostu skopiować wag do publicznego repozytorium, umieścić ich w aplikacji ani udostępnić poprzez komercyjne API. Nawet udostępnienie niewielkiego podzbioru może naruszyć warunki, jeśli mogłoby zostać użyte do odtworzenia pełnych możliwości modelu.
• Limity prac pochodnych – niektóre licencje wyraźnie zakazują tworzenia nowych modeli na bazie udostępnionych parametrów bez explicit permission (wyraźnej zgody) lub nawet zabraniają publikacji wyników inferencji.

Ponieważ wiele LLM‑ów jest rozpowszechnianych pod takimi klauzulami, zespoły chcące uruchomić je w produkcji muszą często negocjować odrębną licencję komercyjną lub korzystać z usługi hostowanej (np. API OpenAI). Nawet wtedy należy zachować dużą ostrożność. Limity prac pochodnych lub ograniczony zakres użycia mogą odnosić się do artefaktów generowanych przez model.

Idealna pułapka

Najpierw widzisz licencję kodu modelu. Zazwyczaj jest to licencja open‑source, taka jak MIT, Apache 2.0 lub BSD. Każdy może modyfikować i dystrybuować skrypty treningowe, pliki konfiguracyjne czy wrappery inferencji, a Ty oczywiście możesz używać ten kod. Zwykle nie ma ograniczeń dotyczących wyników korzystania z kodu, dopóki nie wchodzi w grę druga warstwa licencji. A tutaj prawdziwe restrykcje, które Cię interesują, są ukryte pod mnóstwem żargonu prawniczego.

W praktyce oznacza to:

• Możesz stworzyć własnego trenera LLM korzystając z open-source pipeline, ale nie możesz publikować checkpointu, chyba że uzyskasz odpowiednie prawa.
• Jeśli chcesz jedynie wykorzystać inferencję na prywatnym serwerze, to oczywiście możesz. Niektóre licencje pozwalają na dość swobodne „research‑use” lub „non‑commercial use” wag bez ich dystrybucji. Sprawdź, jak brzmią zapisy dotyczące „wdrożenia na wewnętrzne serwery”, ponieważ możesz sądzić, że zakaz dotyczy jedynie sprzedaży usług opartych na wdrożonym modelu. W rzeczywistości jednak każde komercyjne użycie pracy pochodnej (np. wygenerowanej muzyki) jest zabronione.

Ta prawna pułapka wykorzystuje naszą niechęć do czytania długich, skomplikowanych tekstów. Zachęcam Cię do przeczytania mojego wpisu o podsumowaniach generowanych przez AI. Jeśli uważasz mnie za nudnego, to proszę powstrzymać się od publikowania w sieci informacji o tym, jak złośliwy YouTube „zdemonetyzował” Twoje konto.

Można znaleźć warunki licencji w różnych miejscach

Z jakiegoś „nieznanego” powodu warunki licencji są rozproszone po wielu lokalizacjach. Ponownie: w świecie AI masz dwie licencje, nie jedną. Istnieją typowe miejsca, gdzie można odnaleźć licencje modelu, ale nie oczekuj przyzwoitości ze strony dużych firm. Zawsze sprawdzaj linki w treści licencji, przypisy i wszystko, co wydaje się podejrzane – nawet przez moment. Pewien poziom paranoi może być w tej sytuacji korzystny.

Sprawdź Model Card (w repozytorium lub na hubie). Powinna tam znajdować się szczegółowa licencja, przykłady użycia, wymagania dotyczące atrybucji oraz wszelkie ograniczenia wskazane przez autorów. Szukaj sekcji zatytułowanych „License”, „Usage Restrictions” albo „Commercial Use”. Model Card wyświetlany w LM Studio lub podobnym oprogramowaniu zawiera jedynie podsumowanie z linkami do pełnych dokumentów. Zostałeś ostrzeżony!

Sprawdź plik LICENSE w repozytorium, z którego zamierzasz pobrać model. Ten plik reguluje użycie na poziomie kodu; zazwyczaj jest prosty, jeśli licencja to MIT/Apache.

Pole „Licence” na hubie pokazuje krótki opis i często odsyła do pełnego tekstu licencji lub zewnętrznych warunków świadczenia usług. Jeśli widnieje „Commercial Use: Not allowed”, musisz uzyskać pozwolenie na wszelkie monetyzowane wdrożenia.

Wagi wymagają osobnej licencji. Niektóre repozytoria zawierają dodatkowy plik WEIGHTS_LICENSE, który wyjaśnia uprawnienia dotyczące danych checkpointu (modelu). Powinien istnieć link lub odniesienie do tego pliku w już wymienionych miejscach. Jeśli nie jest dołączony, Twoja czujność powinna być od tego momentu bardzo wysoka. Jestem przekonany, że to nie jest „omission” (pominięcie) ani „mistake” (błąd).

Uczynienie lokalnego systemu zgodnym

Powinieneś wykonać następujące kroki, aby zapewnić zgodność:

1. Inwentaryzacja wszystkich zasobów
   • Sporządź listę wszystkich plików, które planujesz pobrać, przechowywać lub hostować: bazę kodu, skrypty treningowe, pliki konfiguracyjne, wagi checkpointu oraz wszelkie pochodne artefakty.
   • Pamiętaj, że pochodne artefakty mogą być definiowane inaczej niż Ty zwykle je określasz.
2. Powiąż każdy zasób z jego licencją
   • Utwórz tabelę mapującą (zasób → licencja). Jeśli zasób nie ma wyraźnej licencji, traktuj go jako „proprietary” (własny) aż do momentu udowodnienia, że jest inaczej.
3. Przeczytaj pełne teksty
   • Nie opieraj się jedynie na nagłówku („MIT” lub „Research‑Only”). Zweryfikuj, czy nie ma ukrytych klauzul dotyczących redystrybucji wag lub prac pochodnych.
   • Przeczytaj ponownie opis klauzul „CC” (Creative Commons Attribution). Wikipedia jest w tym przypadku przydatnym źródłem.
4. Sprawdź kompatybilność
   • Niektóre licencje (np. GPL) wymagają copyleft, co może wpływać na licencję własnego projektu, jeśli połączysz go z tak licencjonowanym kodem open‑source.
   • Jeśli kod modelu jest MIT, a wagi są własnościowe, zazwyczaj nie występuje konflikt, ponieważ zasoby są odrębne, ale ich łączenie w jednym produkcie może nadal wywołać obowiązki dystrybucyjne względem połączonego artefaktu.
5. Skonsultuj się z prawnikiem
   • W przypadku wdrożeń wysokiego ryzyka (głównie komercyjnych SaaS) zaangażuj specjalistę ds. własności intelektualnej, który potrafi interpretować subtelne sformułowania licencji lub negocjować indywidualne warunki z autorami modelu.

Jeśli używasz LLM „prywatnie” do „eksperymentów”, możesz odłożyć wszystkie te kroki. Jednak robisz to z jakiegoś powodu, prawda? Chcesz pokazać wyniki swojej pracy innym ludziom, a nawet jeśli nie robisz tego dla pieniędzy, pułapki prawne w licencjach mogą Cię ugryźć. Nie oszukuj się, myśląc że jedynie się uczysz. Lepiej być ostrożnym niż żałować po fakcie.

Nigdy nie zakładaj niczego. Kod i parametry są odrębnymi własnościami intelektualnymi; licencje nie przechodzą automatycznie na elementy składowe systemu. Nie ignoruj klauzul dotyczących atrybucji lub cytowania. Wiele licencji „research‑only” wymaga, aby każde publiczne udostępnienie uznawało oryginalnych autorów, czasem w określonym formacie cytowania (np. wpis BibTeX). Nie spełnienie tego może być traktowane jako niewłaściwe użycie, nawet jeśli nie monetyzujesz.

Ponownie: licencja może zezwalać na eksperymentowanie, ale wyraźnie zakazywać wdrożenia w usługach skierowanych do klientów lub udostępniania API w chmurze. Błędna interpretacja może prowadzić do roszczeń o naruszenie warunków.

Nie zapominaj, że licencje nie mają zastosowania do modeli hostowanych przez innych. Niektóre modele są udostępniane pod licencją platformy, która różni się od licencji repozytorium źródłowego, szczególnie gdy zostają przepakowane przez organizację taką jak Hugging Face. Możesz mieć wszystkie niezbędne prawa do modelu używanego lokalnie, ale usługa hostingowa może te prawa nadpisać. Jeszcze raz: zostałeś ostrzeżony!

Co zrobić, jeśli chcesz wykorzystać LLM komercyjne, ale nie masz praw?

Po pierwsze, nie traktuj mojego wpisu jako porady prawnej. Istnieje mnóstwo rozwiązań, z których możesz wybrać najwygodniejsze, jeśli chcesz monetyzować swoją pracę. Przedstawię Ci jedynie trzy z nich:

• Skontaktuj się z autorami – wiele otwartych grup badawczych oferuje licencje komercyjne za opłatą lub na określonych warunkach (np. ograniczone poziomy użycia). Przedstaw im swój zamierzony przypadek użycia, szacowane natężenie ruchu oraz plany wdrożenia.
• Użyj alternatywnych modeli – poszukaj forków utrzymywanych przez społeczność, które wyraźnie udostępniły wagi pod bardziej liberalnymi licencjami. Niektóre organizacje przetrenowują modele na tej samej architekturze i publikują własne bardziej „liberalne” checkpointy.
• Hostuj poprzez usługę API – zamiast samodzielnie pobierać checkpoint, skorzystaj z komercyjnej usługi (np. OpenAI GPT‑4, Cohere, Anthropic). Te serwisy zajmują się zgodnością licencyjną w Twoim imieniu; Twoja aplikacja wywołuje połączenie do komercyjnego endpointu HTTP.^[2]

Aby prowadzić prawdziwy biznes, musisz używać autentycznych umów handlowych. Nie polegaj w tym przypadku na „śmieciach” generowanych przez AI. Jest to prawdą dla każdego kontraktu handlowego i tak samo tutaj: zawsze konsultuj się z prawdziwym prawnikiem.^[3]

Podsumowanie

Sieć bezpieczeństwa prawnego dla modeli AI jest warstwowa i zniuansowana. Traktuj bazę kodu oraz checkpoint modelu jako dwa odrębne elementy własności intelektualnej i przeczytaj każdą licencję w całości. Dopasuj zamierzone wdrożenie do tych warunków, zanim przejdziesz poza „eksperymentowanie” z modelem. Jeśli nie jesteś pewny lub Twój przypadek użycia znajduje się w szarej strefie – szczególnie w kontekście komercjalizacji – zachowaj ostrożność. Najbezpieczniejszą drogą jest uzyskanie wyraźnej zgody od autorów albo przejście na już komercyjnie licencjonowaną usługę hostowaną. Pamiętaj jednak, że usługi hostowane mogą rościć sobie prawa do wygenerowanych rezultatów, tak jak Suno robi to w przypadku twórców treści na YouTube.

Dla tych, którzy preferują kluczowe wnioski, oto krótka lista najważniejszych działań, które powinieneś wykonać przy wyborze modelu:

• Potwierdź licencję kodu (MIT/Apache itp.) i czy pozwala ona na modyfikację lub redystrybucję.
• Zweryfikuj licencję wag – sprawdź, czy obowiązuje „research‑only”, „non‑commercial” oraz ograniczenia dystrybucji.
• Dopasuj swój model wdrożenia do tych limitów: wyłącznie wewnętrzna inferencja vs publiczne API.
• Potwierdź swoje prawa do wyników generowanych przez model: tekst, obrazy, wideo lub muzyka.
• Przestrzegaj wszelkich wymogów dotyczących atrybucji/cytowania.
• Zachowuj dokumentację każdej kopii licencji, której użyłeś; będzie to dowód w razie audytu zgodności.

Bądź ostrożny – teraz znajdujesz się w dżungli. To nie „sztuczna inteligencja” czai się w cieniu, lecz bardzo realne firmy starające się odzyskać przynajmniej część pieniędzy zainwestowanych w bańkę systemów AI.

---

1. Jednak często robią to przeciwko sobie: Microsoft kontra OpenAI, xAI kontra wszyscy inni, na przykład.↩︎
2. Teraz musisz sprawdzić umowę z dostawcą usługi, ale jest to łatwiejsze niż robienie wszystkiego od podstaw.↩︎
3. Aby nie było aż tak poważnie: narzędzie do uzupełniania tekstu, którego używam w moim systemie, zaproponowało zamiast „prawdziwego prawnika” określenie „uczciwy prawnik”.↩︎

Autor: Michał Materny

Konsultant i trener z ponad 20-letnim doświadczeniem w zarządzaniu procesami biznesowymi, systemami ERP i optymalizacją procesów produkcyjnych. Przeszkolił ponad 2500 uczestników oraz zrealizował liczne projekty i wdrożenia. Specjalizuje się w architekturze przedsiębiorstw i systemów (TOGAF, ArchiMate, ARIS), modelowaniu procesów biznesowych, zarządzaniu ryzykiem oraz planowaniu i harmonogramowaniu produkcji, Lean, TPS, TQM, TOC. Współpracuje z Architecture Center i The Open Group (TOGAF), przy tworzeniu nowych standardów w obszarze architektury IT. Jest wykładowcą w Wyższej Szkole Europejskiej im. ks. J. Tischnera oraz prezesem IPG Materny – firmy wdrażającej oprogramowanie wspomagające zarządzanie.