Punkt wyjścia: skąd biorą się problemy licencyjne przy AI do kodu
Masowe użycie Copilota i ChatGPT w codziennym programowaniu
GitHub Copilot, ChatGPT i podobne narzędzia stały się dla wielu programistów domyślnym „drugim oknem” IDE. Podpowiadają całe funkcje, generują testy, piszą migracje baz danych, refaktoryzują klasy. W praktyce oznacza to, że coraz więcej produkcyjnego kodu ma w sobie mniejszy lub większy udział generatu z AI – często bez świadomej decyzji architekta czy działu prawnego.
Dla pojedynczego developera to ogromna wygoda: mniej żmudnego pisania, szybsze prototypy, gotowe przykłady konfiguracji. Z perspektywy organizacji pojawia się jednak pytanie: co dokładnie trafia do repozytorium i na jakich zasadach można tym potem handlować, licencjonować, przekazywać klientom lub udostępniać jako open source.
Problem nie polega wyłącznie na tym, że „AI może się pomylić”. Chodzi o to, że modele uczone na ogromnych zbiorach kodu (w tym licencjonowanego na GPL, AGPL czy innych licencjach copyleft) mogą w niektórych sytuacjach generować fragmenty bardzo podobne do istniejących utworów chronionych prawem autorskim. W skrajnych przypadkach mogą to być wręcz dłuższe fragmenty 1:1 z popularnych repozytoriów czy odpowiedzi ze Stack Overflow.
Napięcie między wygodą a compliance prawnym
Organizacje, które mają standardy compliance licencyjnego (np. korporacje, software house’y z klientami korporacyjnymi, firmy pracujące dla sektora publicznego), zwykle przez lata budowały procesy kontroli open source: przeglądy licencji, narzędzia typu SCA (Software Composition Analysis), wytyczne dla użycia bibliotek. AI rozsadza ten porządek, bo generuje kod na żądanie, bez jawnego dołączania paczek.
W efekcie, nawet jeśli w projekcie nie ma formalnie zależności od konkretnej biblioteki GPL, to kod generowany przez AI może funkcjonalnie i fragmentami tekstu być do niej bardzo zbliżony. Dla systemów SCA to „czysta” implementacja, dla prawnika – potencjalna mina. Pytanie brzmi: czy w takim przypadku powstaje obowiązek stosowania się do licencji pierwotnego utworu (np. udostępnienia kodu źródłowego, zachowania noty copyright, wskazania autorów)?
Sytuację dodatkowo komplikuje to, że większość regulaminów narzędzi AI przerzuca ryzyko na użytkownika. Vendorzy przyznają wprost, że nie gwarantują braku naruszeń praw autorskich, a jednocześnie nie dają pełnej transparentności co do danych treningowych. To powoduje napięcie między wymogami działu prawnego a praktyką zespołów developerskich.
Inspiracja vs kopiowanie: gdzie przebiega granica
Każdy programista korzysta z cudzej wiedzy: czyta dokumentację, przegląda kody na GitHubie, ogląda przykłady z blogów. Różnica polega na tym, że człowiek zazwyczaj adaptuje rozwiązanie: zmienia nazwy, łączy kilka przykładów, dodaje własną logikę. Model AI natomiast został wytrenowany na konkretnych przykładach i może – w pewnych kontekstach – odtworzyć je w formie bardzo zbliżonej lub identycznej.
Prawo autorskie chroni sposób wyrażenia (konkretną implementację), a nie sam pomysł czy ogólny algorytm. Jeśli AI podpowie banalny fragment typu pętla iterująca po tablicy, jest to na tyle ogólne, że zazwyczaj nie ma mowy o ochronie. Jeżeli jednak wygeneruje złożoną funkcję z charakterystycznym układem warunków, komentarzami, nazwami zmiennych i strukturą identyczną z biblioteką na GPL – pojawia się ryzyko, że mamy do czynienia z utworem zależnym lub wręcz kopiowaniem.
Granica nie jest ostro zarysowana. W praktyce analiza musi uwzględniać:
długość i złożoność identycznych fragmentów,
typ rozwiązania (generyczna pętla vs specyficzny algorytm),
powtarzalność – czy podobny kod można znaleźć w wielu miejscach, czy jest unikalny,
elementy rozpoznawcze: komentarze, nazewnictwo, nietypowe konstrukcje.
Kto zadaje niewygodne pytania: programista, klient, prawnik
Na temat licencji kodu generowanego przez AI pytają nie tylko prawnicy. Często impuls pochodzi od:
programistów, którzy zauważyli, że Copilot „dziwnie dobrze” zna pewne fragmenty popularnych bibliotek,
liderów technicznych, którzy odpowiadają za standardy kodu i chcą uniknąć technicznego długu prawnego,
działów compliance / prawnych, bo klienci zaczynają wpisywać do umów klauzule o zakazie użycia określonych narzędzi AI,
klientów końcowych, którzy wymagają oświadczeń, że kod jest wolny od komponentów „zarażających” licencyjnie.
W bardziej dojrzałych organizacjach widać już procedury typu „AI usage policy”, w których określa się, jakich narzędzi można używać, do jakich zadań (np. do testów, ale nie do głównej logiki biznesowej), oraz jakie obowiązują zasady przeglądu kodu generowanego.
Pierwsze procesy i oświadczenia vendorów
Temat nie pozostaje w sferze teorii. Pojawiły się pozwy zbiorowe przeciw GitHubowi, Microsoftowi i OpenAI dotyczące m.in. naruszenia licencji open source i praw autorskich autorów repozytoriów użytych do trenowania Copilota. Wynik tych postępowań jeszcze nie uporządkował rynku, ale sam fakt ich istnienia zmusił vendorów do precyzyjniejszych deklaracji w regulaminach.
Z drugiej strony niektóre firmy (np. w wybranych planach enterprise) zaczęły oferować formy odszkodowania (indemnification) w przypadku roszczeń związanych z naruszeniem praw autorskich przez treści generowane przez ich modele. Jest to jednak z reguły dostępne w płatnych, kontraktowych wariantach usług i obwarowane licznymi ograniczeniami. Dla zwykłego użytkownika narzędzi typu Copilot czy ChatGPT dominują zapisy: „korzystasz na własne ryzyko, my nie gwarantujemy braku naruszeń”.
Podstawy prawne: kiedy kod jest utworem i co to oznacza
Kod źródłowy jako utwór w prawie polskim i unijnym
Prawo polskie (ustawa o prawie autorskim i prawach pokrewnych) oraz prawo unijne traktują program komputerowy jako utwór, jeśli spełnia kryterium „przejawu działalności twórczej o indywidualnym charakterze”. W praktyce oznacza to, że chronione są te elementy kodu, które nie są czysto techniczną koniecznością, ale przejawiają chociaż minimalną oryginalność autora.
Trybunał Sprawiedliwości UE w kilku sprawach podkreślał, że ochrona obejmuje m.in. strukturę programu, organizację kodu, szczegółowe rozwiązania implementacyjne. Odróżnia się natomiast ideę i zasady (np. algorytm sortowania) od konkretnej formy wyrażenia (implementacja w danym języku). Ta różnica ma kluczowe znaczenie dla oceny kodu generowanego przez AI: algorytm jako taki nie podlega ochronie, ale specyficzny sposób jego zapisania już tak.
W codziennej praktyce większość niebanalnego kodu (moduły biznesowe, złożone algorytmy, frameworki) jest traktowana jako utwór. Proste, powtarzalne fragmenty (typowe pętle, podstawowa walidacja) mogą nie spełniać progu twórczości, ale granica nie jest całkowicie ostra.
Co dokładnie podlega ochronie w kodzie
Ochronie prawnoautorskiej mogą podlegać różne warstwy oprogramowania, nie tylko „ciąg znaków” z pliku .java czy .py. W kontekście licencji i AI trzeba brać pod uwagę m.in.:
strukturę i organizację kodu – podział na moduły, klasy, interfejsy, specyficzne wzorce organizacji logiki,
konkretną implementację funkcji – zestaw instrukcji, specyficzny układ warunków, sekwencje wywołań,
komentarze i dokumentację – zwłaszcza jeśli zawierają charakterystyczne sformułowania lub przykłady,
testy – oryginalne zestawy przypadków testowych również mogą być utworem,
interfejsy użytkownika – opisane w kodzie układy, teksty, elementy graficzne.
Nie oznacza to, że każdy wiersz kodu jest automatycznie objęty silną ochroną. Jednak w sporze sądowym biegły może analizować, czy zestaw podobieństw wskazuje na przejęcie twórczego wkładu autora, a nie tylko naturalne podobieństwo wynikające z użycia tego samego języka programowania i standardowej biblioteki.
Idee i algorytmy vs implementacja – znaczenie dla AI
Programiści często mówią: „algorytmy nie są chronione, mogę zaimplementować quicksort jak chcę”. To częściowo prawda – sama idea sortowania przez wybór, podział czy zliczanie nie jest zastrzeżona przez prawo autorskie. Jednak, jeżeli ktoś opublikował specyficzną, rozbudowaną implementację z komentarzami, testami, nietypową strukturą danych, to ta implementacja może być chroniona jako utwór.
AI uczona na kodach z GitHuba „widzi” przede wszystkim konkretną implementację. Podczas generowania może stworzyć:
nową implementację tego samego algorytmu (bez istotnych podobieństw tekstowych) – tu ryzyko naruszenia praw autorskich jest mniejsze,
implementację bardzo podobną tekstowo, różniącą się kosmetycznie – ryzyko rośnie,
fragment identyczny z oryginałem – potencjalne naruszenie, jeśli oryginał jest chroniony i licencja jest restrykcyjna.
To nie jest czysta matematyka. Dwa niezależnie napisane programy mogą być do siebie podobne z przyczyn technicznych. Sąd w realnym sporze badałby m.in. prawdopodobieństwo niezależnego stworzenia tak zbliżonych rozwiązań oraz dostęp do źródła (tu problematyczny jest fakt, że model był trenowany właśnie na tym kodzie).
Krótkie fragmenty: kiedy nie ma ochrony, a kiedy jednak może być problem
W praktyce prawnicy często posługują się pojęciem „progu twórczości”. Krótki, banalny fragment, jak np.:
for (int i = 0; i < list.size(); i++) { … }
jest tak generyczny, że trudno mówić o ochronie. Jednak liczy się nie tylko długość, ale także oryginalność i unikalność. Krótki, ale bardzo charakterystyczny ciąg instrukcji, np. zawierający specyficzną sekwencję wywołań, własne makra i rozpoznawalne nazwy, może być postrzegany jako przejaw twórczości.
AI w typowych zadaniach generuje raczej mieszankę krótkich fragmentów i własnych kombinacji wzorców. Problem pojawia się przy:
specyficznych promptach proszących o „skopiowanie” znanego projektu,
dłuższych sekwencjach generowanych kodów, np. całej klasy,
kodzie, który zbyt dobrze pasuje do jednego konkretnego repozytorium (łącznie z komentarzami).
Dozwolony użytek, cytat, reverse engineering – dlaczego rzadko pomagają przy AI
Czasem pojawia się argument: „przecież wolno korzystać z cudzych materiałów w ramach dozwolonego użytku” lub „można cytować fragmenty”. W kontekście kodu generowanego przez AI te instytucje prawa autorskiego mają ograniczone zastosowanie:
dozwolony użytek osobisty – pozwala korzystać z utworów w wąskim kręgu rodziny i znajomych, nie obejmuje komercyjnego wykorzystania kodu w produktach na rynku,
prawo cytatu – wymaga m.in. oznaczenia źródła i autora, a celem cytatu musi być m.in. wyjaśnianie, analiza, polemika; trudno obronić komercyjne wykorzystanie fragmentu biblioteki GPL jako „cytat” bez zachowania licencji,
reverse engineering – dotyczy określonych przypadków analizy programu dla interoperacyjności; nie usprawiedliwia mechanicznego kopiowania fragmentów kodu.
Z punktu widzenia licencjonowania AI do kodu najważniejsze jest to, że produkcyjny kod w komercyjnym produkcie rzadko da się usprawiedliwić tymi wyjątkami. O ile można analizować wygenerowany fragment w celach edukacyjnych, o tyle jego masowe włączanie do produktu wymaga zapewnienia zgodności z licencjami, tak jak w przypadku każdego innego kodu pochodzącego z zewnątrz.
Źródło: Pexels | Autor: Jakub Zerdzicki
Jak działają Copilot, ChatGPT i podobne modele z perspektywy licencji
Trenowanie modeli na ogromnych zbiorach kodu
Modele takie jak te używane w GitHub Copilot czy ChatGPT uczone są na bardzo rozbudowanych korpusach danych: publicznych repozytoriach GitHub, forach programistycznych (np. Stack Overflow), dokumentacji, blogach, książkach, a w przypadku wersji komercyjnych – czasem także na licencjonowanych zbiorach. Z prawnego punktu widzenia istotne są dwa poziomy pytań:
czy wolno było użyć danego kodu do trenowania modelu (kwestia zgodności wykorzystania z licencją i dozwolonym użytkiem),
co dzieje się z wygenerowaną treścią – czy jest ona na tyle niezależna, by nie naruszać praw do materiałów użytych w treningu.
Generowanie kodu a „zapamiętywanie” fragmentów z treningu
W dyskusjach o Copilocie i podobnych narzędziach często pojawia się teza: „model niczego nie przechowuje, tylko uczy się statystyki, więc nie ma problemu z kopiowaniem kodu”. To uproszczenie. Z technicznego punktu widzenia model nie trzyma w środku pełnych plików repozytoriów, ale w praktyce może generować dosłownie identyczne fragmenty, jeśli:
fragment jest bardzo typowy (np. prosty wzorzec kodu),
albo – przeciwnie – był na tyle często widoczny w danych treningowych w podobnym kontekście, że stał się „domyślną” odpowiedzią na dany prompt.
GitHub przyznał, że niewielki odsetek podpowiedzi Copilota może być zgodny w 1:1 z fragmentami z publicznych repozytoriów. Z prawnego punktu widzenia nie ma znaczenia, że model nie ma w środku „bazy plików”. Liczy się to, czy w rezultacie dostajesz do ręki kod, który jest utworem konkretnego autora i czy warunki jego licencji są respektowane.
W typowych zastosowaniach Copilot czy ChatGPT generują mieszaninę standardowych wzorców i nowych kombinacji. Ryzyko problemów rośnie w dwóch sytuacjach:
używasz bardzo precyzyjnych promptów („zrób mi implementację X tak jak w projekcie Y na GitHubie”),
model ma podpowiadać duże bloki kodu (całe pliki, klasy, frameworki), a nie tylko pojedyncze linijki.
W praktyce sporne jest nie tyle samo istnienie podobieństw, co ich skala i kumulacja. Pojedyncza podobna funkcja to co innego niż cały moduł, który „rozpoznaje” każdy, kto zna dany projekt OSS.
Tryby pracy narzędzi i wpływ na ryzyko licencyjne
Vendorzy zaczęli rozróżniać tryby pracy modeli, które mają znaczenie z perspektywy licencji:
filtry na poziomie outputu – Copilot, Amazon CodeWhisperer i inne dopuszczają wyłączenie podpowiedzi, które zbyt mocno przypominają konkretny plik z publicznego repo (tzw. similarity filtering),
modele trenowane tylko na „bezpiecznych” danych – oferty enterprise, w których trening opiera się na kodzie klienta, licencjonowanych zbiorach lub kuratowanych datasetach,
tryby prywatne – brak użycia kodu klienta do dalszego uczenia modelu, ewentualnie tylko do bieżącej inferencji.
To nie jest magiczna tarcza. Filtry podobieństwa opierają się na progach (np. długość fragmentu, procent zbieżności). Granica bywa arbitralna, a przy bardziej skomplikowanych licencjach (GPL, copyleft) nawet krótszy, charakterystyczny fragment może stanowić problem. Tryby enterprise często zakładają osobne postanowienia kontraktowe, w których dostawca bierze na siebie część ryzyka – ale w zamian mocno ogranicza sposób użycia danych i rezultatów.
Dane wejściowe użytkownika a trening modelu
Osobny wątek to wykorzystanie Twojego kodu w treningu. W wielu narzędziach standardowym ustawieniem jest możliwość użycia wprowadzonych treści (promptów, kodu, komentarzy) do dalszego rozwijania modeli. Z prawnego punktu widzenia dzieje się kilka rzeczy naraz:
udzielasz dostawcy licencji na korzystanie z tego, co wysyłasz (często szerokiej, niewyłącznej, globalnej),
dostawca może łączyć Twój kod z innymi danymi i w praktyce nie da się później „odkręcić” jego wpływu na parametry modelu,
z perspektywy tajemnic przedsiębiorstwa pojawia się ryzyko nieuprawnionego ujawnienia (np. wysyłasz kod objęty NDA do zewnętrznego API).
Producenci narzędzi pod presją rynku i regulatorów (w tym RODO/GPDR) wprowadzili tryby, w których dane klienta nie są wykorzystywane do trenowania modeli ogólnych. Wymaga to jednak najczęściej:
świadomego wyboru odpowiedniego planu (np. enterprise),
konfiguracji opcji „opt-out” w panelu administracyjnym,
zawarcia odrębnych umów regulujących przetwarzanie danych i tajemnicę przedsiębiorstwa.
Oficjalne regulaminy: GitHub Copilot, ChatGPT i inne narzędzia
GitHub Copilot – kluczowe założenia licencyjne
Regulaminy Copilota (łączące warunki GitHuba, Microsoftu i ewentualnie Azure) zawierają kilka istotnych elementów:
prawo do korzystania z outputu – użytkownik otrzymuje szeroką licencję na używanie generowanego kodu w swoich projektach, w tym komercyjnie,
brak gwarancji braku naruszeń – GitHub wyraźnie zastrzega, że nie zapewnia, iż output nie narusza praw osób trzecich ani licencji OSS,
filtry podobieństwa – można włączyć funkcję ograniczającą podpowiedzi zbyt podobne do istniejącego kodu publicznego,
telemetria i dane użytkownika – domyślnie pewne informacje o użyciu i fragmenty kodu mogą być logowane i wykorzystywane do ulepszania usługi, chyba że wyłączysz to w ustawieniach lub korzystasz z wariantu z odrębną umową.
Z perspektywy programisty-praktyka przekaz jest dość prosty: Copilot daje Ci licencję na to, co on wygeneruje w relacji użytkownik–GitHub, ale nie „czyści” tego kodu z roszczeń innych podmiotów. Jeśli wynikowo okaże się, że wygenerowana klasa jest praktycznie kopią biblioteki GPL, ciężar zgodności z licencją spada na Ciebie.
OpenAI / ChatGPT – zapisy o własności treści
OpenAI (w tym warianty API, ChatGPT w modelach konsumenckich i biznesowych) odróżnia:
treści wejściowe (Input) – rzeczy, które wysyłasz do modelu: kod, dokumentację, opisy problemu,
treści wyjściowe (Output) – to, co model zwraca: fragmenty kodu, opisy, testy.
W aktualnych warunkach (dla większości krajów europejskich) użytkownik zachowuje prawa do Inputu, a co do Outputu – otrzymuje szeroką licencję do dowolnego wykorzystania, zwykle z zastrzeżeniem, że korzysta z niego na własne ryzyko. Kluczowe są dwa elementy:
training opt-out – w niektórych planach (np. ChatGPT Team, Enterprise, API) OpenAI deklaruje, że nie wykorzystuje treści klientów do trenowania modeli ogólnych,
indemnification w wyższych planach – w planach enterprise OpenAI i partnerzy mogą oferować ograniczoną ochronę w razie roszczeń IP związanych z outputem.
W darmowych i tańszych wersjach główna linia obrony OpenAI to: masz prawo używać wygenerowanego kodu, ale jeśli narusza on cudze prawa, jesteś za to odpowiedzialny. Dostawca może co najwyżej zaoferować narzędzia pomocnicze (np. wewnętrzne filtry, system raportowania nadużyć).
Inne popularne narzędzia: Amazon CodeWhisperer, Tabnine, lokalne LLM
Warunki pozostałych narzędzi są podobne w strukturze, ale różnią się w detalach. Najczęstsze warianty:
CodeWhisperer – Amazon mocno akcentuje możliwość włączenia „reference tracker”, który pokazuje, czy dany fragment podpowiedzi pochodzi z konkretnego projektu open source. Ułatwia to ocenę licencji, ale nie zastępuje audytu prawnego, zwłaszcza gdy output jest już zmodyfikowany.
Tabnine – przez długi czas promowany jako narzędzie trenowane tylko na kodzie z „dozwolonymi” licencjami lub kontraktowo pozyskanych zestawach. Zmniejsza to ryzyko, lecz go nie eliminuje: nadal można wygenerować kod podobny do innych projektów, a dodatkowo wchodzą w grę prawa współpracujących dostawców treści.
Lokalne modele (np. StarCoder, LLaMA-based, Code Llama) – jeśli prowadzisz inference lokalnie, odpada część problemów związanych z przepływem danych do dostawcy, ale pojawia się inny: na czym trenowany był model? Licencje niektórych open-source’owych LLM zawierają informacje o datasetach; bywa tam mieszanka repozytoriów o różnych licencjach. Odpowiedzialność za wykorzystanie outputu spada na tego, kto go używa, a nie na autorów modelu.
Zdarza się, że zespół IT przyjmuje założenie: „skoro narzędzie jest dopuszczone w dużych korporacjach, to znaczy, że jest bezpieczne”. To skrót myślowy. Duże firmy korzystają z takich rozwiązań zwykle na podstawie indywidualnych umów, z innym poziomem odpowiedzialności, niż standardowe regulaminy dostępne na stronie.
Źródło: Pexels | Autor: Pixabay
Licencje open source a AI: konflikt, który nie jest czysto teoretyczny
GPL i inne copyleft vs generowanie kodu
Licencje copyleft (GPL, AGPL, w łagodniejszym stopniu LGPL) wprowadzają zasadę „zarażania”: połączenie kodu objętego taką licencją z Twoim projektem może wymusić udostępnienie całości na identycznych warunkach. W kontekście AI pojawia się pytanie: czy wygenerowany kod, który jest podobny lub identyczny z kodem GPL, pociąga za sobą obowiązki copyleft?
Scenariusze, z którymi prawnicy realnie się mierzą:
model generuje funkcję, która jest niemal 1:1 kopią funkcji z biblioteki GPL – jeśli ją włączysz do swojego projektu bez zachowania licencji, ryzykujesz zarzut naruszenia i roszczenie o udostępnienie źródeł,
model podpowiada fragmenty z AGPL-owego backendu; ich wykorzystanie w serwisie SaaS może uruchomić obowiązek udostępnienia kodu serwera,
mieszanie kilku takich fragmentów w jednym module powoduje, że w praktyce zaczynasz dystrybuować utwór zależny od kilku różnych komponentów copyleft.
Nie ma jeszcze ugruntowanej linii orzeczniczej dotyczącej tego, jak traktować <empośrednictwo AI między repozytorium GPL a Twoim projektem. W wielu analizach pojawia się podejście zachowawcze: jeśli output daje się łatwo zmapować na konkretny plik GPL (ten sam układ, nazwy funkcji, komentarze), traktuje się go jak utwór zależny od tamtego kodu, a nie jako „dzieło niezależne wygenerowane przez maszynę”.
MIT, BSD, Apache 2.0 – „luźne” licencje a realne obowiązki
Licencje typu MIT, BSD czy Apache 2.0 są postrzegane jako mało restrykcyjne. Nie oznacza to jednak, że można ignorować ich warunki. Konkretne punkty, które kolidują z bezrefleksyjnym użyciem outputu AI:
obowiązek zachowania informacji o autorze i licencji – MIT wymaga pozostawienia oryginalnej noty copyright i zapisu licencji w kopiach istotnych fragmentów oprogramowania,
Apache 2.0 – klauzule patentowe – wprowadza licencję patentową i mechanizmy jej wygaśnięcia w razie pozwu; skopiowanie fragmentu może pociągnąć za sobą włączenie się w ten system,
brak gwarancji i odpowiedzialności – standardowe disclaimery przechodzą na dalszych użytkowników, co bywa istotne przy due diligence.
Jeżeli AI wygeneruje kod praktycznie identyczny z projektem MIT, a Ty umieścisz go w swoim produkcie bez wzmianki o licencji, formalnie naruszasz warunki MIT. Czy autor rzeczywiście wystąpi z roszczeniem? Zależy od kontekstu, skali, branży. Z prawnego punktu widzenia ryzyko jednak istnieje.
Licencje „nietypowe” i zakazy trenowania modeli
Coraz częściej pojawiają się licencje lub postanowienia dodatkowe, które wprost zakazują:
wykorzystywania kodu do trenowania modeli AI,
generowania konkurencyjnych usług z użyciem tego kodu,
odtwarzania istotnych funkcjonalności produktu SaaS.
Z punktu widzenia użytkownika narzędzia AI problemem jest to, że:
nie masz kontroli nad tym, czy autorzy datasetów respektowali takie zakazy,
czasem nie wiesz, czy konkretne repozytoria objęte takimi warunkami w ogóle trafiły do zbioru treningowego,
nawet jeśli chciałbyś zareagować (np. usunąć konkretny fragment), trudno wykazać, z którego źródła pochodzi podobieństwo.
To obszar, w którym potencjalne spory dopiero się rodzą. Niektóre organizacje OSS zaczęły wprowadzać klauzule „no AI training” bardziej jako sygnał polityczny niż narzędzie faktycznego egzekwowania, ale wraz z rosnącą liczbą komercyjnych zastosowań temat może stać się bardziej praktyczny.
„Zarażanie” kodu w praktyce audytu
Audyt licencyjny w projektach korzystających z AI musi iść głębiej niż proste sprawdzenie zależności w package.json czy pom.xml. Typowy, bardziej konserwatywny proces obejmuje:
skanowanie repozytorium narzędziami SCA (Software Composition Analysis) rozszerzonymi o detekcję podobieństw kodu (nie tylko deklaracji zależności),
oznaczenie fragmentów, w których pojawiają się duże, powtarzalne bloki wygenerowanego kodu,
ręczną weryfikację, czy te bloki nie odpowiadają znanym projektom OSS o restrykcyjnych licencjach,
w razie wątpliwości – refaktoryzację lub całkowite przepisanie spornego fragmentu.
Kto faktycznie jest autorem kodu generowanego przez AI
Autor w rozumieniu prawa a „twórca prompta”
Prawa autorskie w większości jurysdykcji dotyczą twórczości człowieka. Maszyna ani korporacja nie są „autorem” w klasycznym sensie prawa autorskiego – mogą być co najwyżej właścicielami majątkowych praw, jeśli te zostały przeniesione przez człowieka.
Przy generowaniu kodu przez modele AI powstaje więc układ trójstronny:
Twórcy kodu z datasetów (np. autorzy projektów open source),
Dostawca modelu (OpenAI, GitHub/Microsoft, Amazon itd.),
Użytkownik modelu, który formułuje prompt i odbiera output.
Jeśli output jest na tyle oryginalny i efektywnie „stworzony” poprzez wybory użytkownika (prompt, modyfikacje, łączenie elementów), to w wielu systemach prawnych to użytkownik będzie uznany za autora lub współautora. Jeżeli natomiast output to faktyczna kopia istniejącego kodu z datasetu, w grę wchodzą prawa pierwotnego autora, a nie „twórcy prompta”.
Regulaminy dostawców zwykle omijają rozstrzygnięcie tej kwestii wprost. Deklarują, że „użytkownik posiada prawa do Outputu” albo „otrzymuje szeroką licencję”, ale nie zmieniają definicji autora w prawie powszechnym. Jeżeli sąd uzna, że dany fragment jest utworem zależnym od projektu GPL, to komunikat z regulaminu nie wyczyści tej zależności.
Automatyczna generacja bez istotnego wkładu człowieka
Pojawia się scenariusz, który przez lata był czysto teoretyczny w IT, a wraz z AI stał się codziennością: kod wygenerowany w dużym stopniu automatycznie, z minimalnym udziałem decyzyjnym człowieka.
Typowy przykład z praktyki:
Developer pisze: „Napisz mikroserwis w Node.js do obsługi koszyka zakupowego z endpointami X, Y, Z”.
Model generuje kompletny serwis, łącznie z konfiguracją, logowaniem i walidacją.
Developer robi drobne poprawki stylistyczne i wysyła kod na produkcję.
Czy w takim przypadku można mówić o „utworze” w rozumieniu prawa autorskiego? Doktryna jest podzielona. Część prawników stoi na stanowisku, że jeśli wkład człowieka ogranicza się do bardzo ogólnego prompta i kosmetyki, to kod może w ogóle nie być chroniony (brak cechy twórczości przypisanej do konkretnej osoby). Inni argumentują, że już sam wybór konkretnych rozwiązań (poprzez iteracyjne prompty, poprawki, integrację z istniejącym systemem) stanowi istotny wkład.
Z perspektywy praktyka IT kluczowe jest nie tyle „czy to utwór”, ale:
czy możesz skutecznie udzielać licencji na ten kod (np. w umowie z klientem),
czy ktoś może podnieść roszczenie, że ten kod narusza jego prawa.
Nawet jeśli sąd uzna, że dany fragment kodu nie jest chronionym utworem, pozostaje potencjalna odpowiedzialność kontraktowa wobec klienta (gwarancje, oświadczenia o oryginalności) oraz ryzyko naruszenia cudzych licencji, jeśli kod jest zbieżny z istniejącym projektem.
Scenariusze własności w zależności od relacji biznesowej
To, kto jest właścicielem majątkowych praw do kodu generowanego z pomocą AI, rzadko wynika z samej technologii. Najczęściej rozstrzygają to umowy między stronami. Kilka typowych układów:
Pracownik – pracodawca: w wielu krajach kod stworzony w ramach obowiązków pracowniczych automatycznie trafia do pracodawcy (tzw. utwór pracowniczy). Jeśli developer używa Copilota/ChatGPT do pisania kodu w godzinach pracy, to nawet przy założeniu, że ma status „autora”, majątkowe prawa będzie posiadać pracodawca – oczywiście z zastrzeżeniem praw osób trzecich (autorów projektów z datasetu).
Freelancer / software house – klient: tutaj decydują zapisy kontraktu. Jeżeli umowa mówi o „przeniesieniu majątkowych praw autorskich do całości kodu źródłowego i dokumentacji” albo o „wyłącznej licencji”, to generowanie kodu przez AI nie jest wyjątkiem. Problem w tym, że wykonawca deklaruje, iż ma pełnię praw do tego, co przekazuje, co może być nieprawdą przy kopiowaniu kodu GPL/Apache/MIT przez model.
Hobby / side-project: autor działający „po godzinach” z reguły zachowuje prawa do projektu, ale jeśli używa tych samych narzędzi i sprzętu co w pracy, można wejść na terytorium sporów wewnątrzfirmowych (postanowienia o IP w umowach o pracę, polityki „invention assignment”). Dodanie AI do miksu nie ułatwia wykazania, jaki był wkład pracownika, a jaki „maszyny”.
Konflikt: regulaminy dostawcy vs. umowy z klientami
Wiele software house’ów i działów IT deklaruje w umowach z klientami coś w stylu:
„Wykonawca oświadcza, że posiada pełnię praw autorskich do stworzonego oprogramowania oraz że nie narusza ono praw osób trzecich, w tym licencji open source”
Tymczasem regulaminy narzędzi AI zawierają zapisy:
„Output może zawierać treści generowane na podstawie zewnętrznych źródeł”
„Dostawca nie gwarantuje braku naruszeń praw własności intelektualnej”
„Użytkownik jest odpowiedzialny za weryfikację zgodności z prawem”
Pojawia się więc klasyczny konflikt: z jednej strony obiecujesz klientowi „wolny od roszczeń” kod, z drugiej – akceptujesz regulaminy, które przerzucają całe ryzyko na Ciebie. Jeżeli do tego dochodzą restrykcyjne licencje open source w datasetach, margines błędu robi się niewielki.
Tu zaczyna działać czysta pragmatyka:
albo formalnie ograniczasz użycie AI w projektach objętych ostrymi zobowiązaniami wobec klienta,
albo modyfikujesz wzory umów, wprowadzając zastrzeżenia dotyczące AI, open source i zakresu gwarancji IP.
Współautorstwo: człowiek + AI + open source
W projektach, które mocno korzystają z AI, dużo częściej pojawia się realne współautorstwo w klasycznym sensie: kilka osób redaguje ten sam moduł, część funkcji pochodzi z promptów, część jest przeniesiona z istniejących bibliotek (zgodnie z licencją lub nie), część dopisywana ręcznie.
Współautorstwo pociąga za sobą skutki:
Każdy współautor ma prawa do całości utworu, ale przy eksploatacji (np. licencjonowaniu całości klientowi) w zasadzie trzeba mieć zgodę wszystkich, chyba że umowa mówi inaczej.
Jeśli fragmenty pochodzą z projektów open source, autorzy tych projektów de facto stają się współautorami kodu końcowego – tyle że warunki współautorstwa definiuje licencja (GPL, MIT itd.).
Brak dokumentacji pochodzenia fragmentów kodu utrudnia później rozdzielenie wkładów i naprawę sytuacji (np. „wyrzucamy tylko to, co jest zarażone GPL-em”).
Jeżeli AI generuje fragment niemal identyczny z funkcją z repozytorium MIT, a Ty go tylko kosmetycznie modyfikujesz, rozsądne podejście jest takie: przyjmujesz, że oryginalny autor jest autorem dominującym, Ty dodajesz wkład zależny, a licencja MIT nadal „przechodzi” na Twój projekt, nawet jeżeli model był pośrednikiem.
Typowe scenariusze użycia AI do kodu i ich konsekwencje prawne
AI jako „lint” i narzędzie refaktoryzacji
Wiele zespołów korzysta z AI głównie do:
podpowiadania refaktoryzacji istniejącego kodu,
generowania alternatywnych implementacji,
upraszczania złożonych funkcji.
Ryzyko licencyjne jest tu z reguły niższe niż przy generowaniu nowych modułów od zera, ale nie zerowe. Pojawiają się dwa newralgiczne punkty:
Jeżeli wrzucasz do chatu długie fragmenty kodu objęte NDA lub licencją, która zakazuje ich ujawniania osobom trzecim, możesz naruszyć umowę, niezależnie od tego, że treść jest przetwarzana przez „maszynę”. Dla kontrahenta dostawca AI to po prostu kolejny podmiot zewnętrzny.
Model może zaproponować „ulepszoną” wersję funkcji, która de facto pochodzi z innego źródła (repozytorium OSS, bloga, tutoriala). Jeśli implementacja jest bardzo podobna, wchodzą w grę te same kwestie co przy zwykłym kopiowaniu.
Bezpieczniejszy jest tryb, w którym:
rzadko „wklejasz” pełne pliki produkcyjnego kodu do zewnętrznych modeli (chyba że masz jasną zgodę prawną i biznesową),
traktujesz podpowiedzi refaktoryzacyjne jak inspirację, a nie gotowy kod do wklejenia 1:1,
w krytycznych komponentach utrzymujesz proces code review, który zakłada identyfikację „zbyt znajomo” wyglądających fragmentów.
Szkielety, boilerplate, generatory CRUD
W wielu projektach AI jest wykorzystywane głównie do generowania:
szkieletów kontrolerów, serwisów, modułów,
formularzy CRUD, DTO, mapperów,
powtarzalnych konfiguracji frameworków.
Na pierwszy rzut oka wydaje się, że w tej kategorii „ryzyko licencyjne jest minimalne, bo to tylko powtarzalny kod, który każdy mógłby napisać”. I często tak właśnie jest – boilerplate rzadko osiąga próg oryginalności. Jednak są wyjątki:
Niektóre frameworki mają specyficzne, rozbudowane szablony plików (np. pełne konfiguracje security, nietypowe middleware). Jeśli model skopiuje takie pliki z konkretnego repozytorium, a nie z dokumentacji, może to być już utwór chroniony.
Jeżeli skeleton jest identyczny jak plik startowy z repozytorium GPL/AGPL, to problem pojawia się nawet wtedy, gdy Ty go traktujesz jako „zwykły szablon”.
Rozsądna praktyka to:
utrzymywanie wewnętrznych, własnych szablonów projektów (project templates) i generowanie kodu głównie na ich bazie,
ograniczanie w promptach odwołań wprost do konkretnych projektów typu „wygeneruj serwis identyczny jak w projektX na GitHubie” – to wprost zaprasza do naruszeń,
regularne upraszczanie i unifikacja boilerplate’u, tak by nie polegać na „magicznych” plikach generowanych w całości przez model.
AI jako „pomocnik Stack Overflow”
Model używany jak wyszukiwarka/QA: pytasz o konkretny błąd, prosisz o przykład konfiguracji, snippet regexa, algorytm sortowania. Na poziomie prawnym sytuacja jest podobna do korzystania z blogów i forów, ale z paroma istotnymi różnicami:
Nie widzisz, skąd pochodzi snippet. Na Stack Overflow masz chociaż informację o licencji (CC BY-SA), autora, źródło. W modelu – tylko rezultat.
Model może łączyć kilka źródeł w jeden przykład. To utrudnia stosowanie licencji, które wymagają przypisania autorstwa lub udostępniania zmian.
Snippety bywają powielane w tysiącach miejsc w sieci – trudno więc stwierdzić, czy chodzi o „banalny fragment”, czy o unikalne rozwiązanie, które ktoś może chcieć chronić.
Z praktycznego punktu widzenia:
proste, „encyklopedyczne” fragmenty (np. wzorce regex do walidacji e-maila, klasyczna implementacja quicksorta) rzadko staną się przedmiotem sporu,
im bardziej wyszukany i rozbudowany snippet, tym większa szansa, że pochodzi z konkretnego projektu – szczególnie gdy zawiera charakterystyczne nazwy, komentarze, styl kodowania,
jeśli snippet staje się istotną częścią funkcjonalności biznesowej, dobrze jest przynajmniej spróbować zidentyfikować jego pochodzenie (np. szybkie wyszukiwanie po kilku linijkach kodu).
Budowanie całych produktów „na AI”
Ekstremum to projekty, w których 70–90% kodu powstaje z promptów. Często spotykany przypadek w szybkich MVP, hackathonach, produktach no-code/low-code wzbogaconych o generatywne „silniki”.
Tu kumuluje się kilka problemów:
Brak pełnej świadomości składników – trudno stwierdzić, co jest autorską pracą zespołu, co dosłownym cytatem z datasetu, a co „remiksem”.
Zerwana ścieżka pochodzenia (proweniencja) – jeżeli przez kilka miesięcy rozwijasz produkt, przepuszczając moduły przez różne modele, a do tego kod jest refaktoryzowany ręcznie, odtworzenie pochodzenia fragmentów jest praktycznie niewykonalne.
Ryzyko przy due diligence – przy inwestycji, akwizycji lub dużym kontrakcie B2B pojawi się pytanie „jak kontrolujecie IP w projekcie?”. Odpowiedź „piszemy to z ChatGPT” nie wystarczy.
Z punktu widzenia ryzyka licencyjnego i IP takie projekty mogą wymagać:
zdefiniowania „obszarów krytycznych”, które są przepisywane ręcznie lub tworzone na bazie jasno zidentyfikowanych źródeł (np. oficjalna dokumentacja frameworka),
wprowadzenia minimalnego poziomu dokumentacji: który moduł powstał z pomocą AI, kiedy, w jakim zakresie,
przygotowania się na ewentualną konieczność późniejszego „wyczyszczenia” kluczowych komponentów – czyli przepisania ich od zera przez zespół.
Najczęściej zadawane pytania (FAQ)
Czy mogę legalnie używać Copilota i ChatGPT do pisania kodu w projektach komercyjnych?
Co do zasady tak, bo regulaminy tych narzędzi dopuszczają użycie komercyjne. Problem nie dotyczy samego korzystania z usługi, lecz tego, jaki kod finalnie trafi do Twojego repozytorium i czy nie narusza cudzych praw autorskich lub licencji copyleft (np. GPL, AGPL).
Ryzyko rośnie, gdy AI generuje dłuższe, „dziwnie znajome” fragmenty – np. pełne funkcje, całe klasy, charakterystyczne komentarze. Wtedy może się okazać, że implementacja jest zbyt podobna do istniejącego utworu. Firmy zazwyczaj wymagają w takich sytuacjach dodatkowej weryfikacji kodu i jasnych zasad użycia AI (polityka „AI usage policy”).
Do kogo należy kod wygenerowany przez AI – do mnie, do firmy czy do dostawcy narzędzia?
Większość vendorów (w standardowych regulaminach) zakłada, że użytkownik ma prawa do wygenerowanych treści w zakresie potrzebnym do wykorzystania ich w swojej działalności. Nie oznacza to jednak automatycznie, że kod jest wolny od cudzych praw – jeśli jest faktyczną kopią fragmentów GPL-owego repozytorium, to oryginalny autor nadal ma swoje uprawnienia.
W praktyce: Twoja firma może rozporządzać takim kodem tak jak innym kodem własnym, ale ponosi też ryzyko, że ktoś podniesie zarzut naruszenia licencji lub praw autorskich. Dlatego większe organizacje łączą deklaracje vendorów z wewnętrznymi procedurami przeglądu i audytu kodu generowanego.
Czy kod z AI może „zarazić” mój projekt licencją GPL lub AGPL?
Sam fakt użycia AI nie powoduje „zarażenia” projektu GPL-em. Kłopot pojawia się dopiero wtedy, gdy fragment wygenerowany przez model jest w praktyce kopią lub utworem zależnym względem konkretnego kodu objętego licencją copyleft. Wtedy mogą uruchamiać się typowe obowiązki z tej licencji (np. otwarcie kodu, informacja o autorach, zachowanie not copyright).
Ryzykowne sytuacje to m.in.:
dłuższe, prawie identyczne funkcje lub klasy z popularnych bibliotek GPL/AGPL,
zachowane oryginalne komentarze, nazwy zmiennych, specyficzne konstrukcje,
kod, który po szybkim wyszukaniu w Google czy GitHubie okazuje się 1:1 z jednego repozytorium.
Jeżeli AI generuje ogólną pętlę lub prostą walidację formularza, zwykle nie ma podstaw, by mówić o „zarażeniu” licencyjnym – to za mało twórcze, aby podlegać silnej ochronie.
Jak rozpoznać, czy fragment kodu z AI jest tylko inspiracją, czy już kopiowaniem chronionego utworu?
Granica nie jest ostro wytyczona i często „to zależy” od konkretnego przypadku. Kluczowe kryteria, które zwykle bada prawnik lub biegły, to:
długość i złożoność identycznego fragmentu (kilka linijek vs cała złożona funkcja),
unikalność rozwiązania (generyczny kod, który występuje wszędzie, vs bardzo specyficzny algorytm),
liczba i charakter podobieństw (układ warunków, struktura modułów, komentarze, nazwy),
czy podobny kod można znaleźć masowo, czy praktycznie tylko w jednym źródle.
Jeśli kod jest jedynie funkcjonalnie podobny (realizuje ten sam pomysł, ale innymi środkami), zwykle mówimy o inspiracji. Gdy układ linii, komentarze i struktura są niemal identyczne – rośnie ryzyko, że to już kopiowanie lub utwór zależny.
Czy jako programista odpowiadam osobiście za użycie Copilota/ChatGPT w kodzie klienta?
Umowy B2B i pracownicze często przerzucają odpowiedzialność na firmę jako stronę wobec klienta, ale to nie oznacza pełnej „bezkarnosci” developera. W praktyce:
firma może ponosić odpowiedzialność kontraktową względem klienta za naruszenia licencji,
developer może odpowiadać służbowo lub kontraktowo (np. naruszenie procedur, polityki AI usage policy),
w skrajnych przypadkach możliwe są roszczenia także wobec konkretnej osoby, np. gdy działała rażąco niedbale.
Bezpieczne podejście: stosować się do wytycznych firmy, zgłaszać „podejrzanie znajome” fragmenty i nie akceptować w ciemno długich bloków kodu z AI, zwłaszcza w krytycznych komponentach.
Czy narzędzia typu Copilot są zgodne z licencjami open source, na których były trenowane?
To jedno z głównych pól sporu. Część środowiska twierdzi, że trenowanie modeli na publicznym kodzie (w tym GPL) jest dopuszczalne jako analiza danych lub dozwolony użytek, inni uważają to za naruszenie licencji i praw autorskich. Trwające pozwy zbiorowe przeciw GitHubowi, Microsoftowi i OpenAI pokazują, że temat nie jest rozstrzygnięty.
Dla użytkownika praktyczna konsekwencja jest taka, że:
vendorzy zazwyczaj w regulaminach zastrzegają, że nie gwarantują braku naruszeń,
część oferuje odszkodowanie (indemnification) tylko w drogich planach enterprise i z wieloma wyłączeniami,
typowy użytkownik indywidualny lub mała firma korzysta „na własne ryzyko”.
Dlatego same deklaracje producenta narzędzia nie zastąpią własnych procedur compliance po stronie organizacji.
Jak praktycznie ograniczyć ryzyko licencyjne przy użyciu AI do kodu w firmie?
Najczęściej stosowany zestaw środków to połączenie zasad organizacyjnych i technicznych. W praktyce firmy:
tworzą politykę użycia AI (jakie narzędzia, do jakich zadań, w jakich projektach),
ograniczają użycie AI w krytycznej logice biznesowej lub komponentach narażonych na copyleft,
wymagają code review pod kątem „podejrzanych” fragmentów oraz szybkiego sprawdzania w wyszukiwarkach/GitHubie, skąd może pochodzić kod,
integrują dotychczasowe narzędzia SCA z procesem przeglądu (choć nie wyłapią one wszystkiego),
szkolą developerów z podstaw prawa autorskiego i rozpoznawania ryzykownych wzorców.
To nie usuwa ryzyka do zera, ale znacząco zmniejsza szanse, że do produktu wejdzie dłuższy, nieświadomie skopiowany fragment objęty problematyczną licencją.
Kluczowe Wnioski
Masowe użycie Copilota, ChatGPT i podobnych narzędzi sprawia, że w produkcyjnym kodzie pojawia się coraz więcej fragmentów generowanych przez AI, często bez świadomej decyzji architekta czy działu prawnego, co rodzi realne ryzyka licencyjne.
Dotychczasowe procesy kontroli open source (SCA, przeglądy licencji, wytyczne bibliotek) nie obejmują dobrze kodu generowanego na żądanie – narzędzie może wygenerować coś bardzo zbliżonego do kodu na GPL/AGPL, a systemy SCA tego formalnie „nie widzą”, choć prawnie może to być problem.
Granica między inspiracją a kopiowaniem nie jest jasna: proste konstrukcje (np. pętla po tablicy) są zwykle neutralne, ale złożone funkcje z charakterystycznymi nazwami, komentarzami i strukturą mogą zostać uznane za utwór zależny albo kopiowanie, zwłaszcza gdy są unikalne dla konkretnej biblioteki.
Ryzyko prawne jest w dużej mierze przerzucone na użytkownika – regulaminy narzędzi AI zazwyczaj nie gwarantują braku naruszeń praw autorskich, a jednocześnie nie ujawniają pełnych danych treningowych, więc ocena zgodności licencyjnej opiera się na domysłach i analizie skutków, nie faktów.
Różne grupy interesariuszy podnoszą temat licencji: programiści, którzy rozpoznają „znane” fragmenty kodu, liderzy techniczni broniący jakości i bezpieczeństwa prawnego, działy compliance reagujące na zapisy w umowach oraz klienci wymagający gwarancji, że kod nie jest „zarażony” copyleftem.
Bibliografia i źródła
Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Sejm Rzeczypospolitej Polskiej (1994) – Podstawowa regulacja ochrony programów komputerowych w Polsce
Dyrektywa 2009/24/WE Parlamentu Europejskiego i Rady w sprawie ochrony prawnej programów komputerowych. Parlament Europejski i Rada Unii Europejskiej (2009) – Unijne zasady ochrony programów komputerowych jako utworów
Sprawa C‑406/10 SAS Institute Inc. przeciwko World Programming Ltd. Trybunał Sprawiedliwości Unii Europejskiej (2012) – Orzeczenie TSUE o granicy między ideą a wyrażeniem w programach
