Czy AI może generować kod bez naruszania licencji? Prawo dogania technologię

Sytuacja wyjściowa: jak naprawdę korzystamy dziś z AI w developmentzie

Programiści i AI: od podpowiedzi po gotowe moduły

W praktycznym projekcie IT narzędzia typu GitHub Copilot, ChatGPT, CodeWhisperer czy inne asystenty AI są używane na kilka powtarzalnych sposobów. Czasem to tylko inteligentny „autocomplete”, który podpowiada kolejną linię kodu, a czasem generator całych modułów, klas czy nawet mikroserwisów. Różnica między tymi scenariuszami jest kluczowa z punktu widzenia licencji i prawa autorskiego, choć na pierwszy rzut oka użytkownik widzi tylko „wstawiony kod”.

W sytuacji, gdy AI uzupełnia pojedyncze linie, deweloper ma poczucie, że to raczej przyspieszenie pisania niż pozyskanie „cudzego kodu”. Im dłuższy fragment generacji – np. cała funkcja z testami – tym bardziej pojawia się pytanie: skąd to się wzięło, czy to wzorzec, czy konkretna implementacja kogoś innego? I czy ten kod może „wnosić” do projektu obowiązki wynikające z licencji open source, o których nikt nie pomyślał na etapie planowania produktu.

Do tego dochodzi presja biznesowa. Zespoły mają skracać time‑to‑market, dowozić nowe funkcjonalności szybciej niż konkurencja, podczas gdy działy prawne i compliance zwracają uwagę na ryzyko licencyjne, reputacyjne i kontraktowe. Programista, który wkleja kod wygenerowany przez AI, porusza się więc często między oczekiwaniem szybkiego efektu a mglistą obawą, że gdzieś w tle mogą istnieć prawa autorskie lub licencje, których firma nie chciała dotykać.

Trzy typowe scenariusze z życia

Zespół produktowy w SaaS i lęk przed „zarażeniem” copyleft

Wyobraźmy sobie zespół rozwijający aplikację SaaS dla klientów biznesowych. Kod jest komercyjny, zamknięty, a w umowach z klientami znajdują się zapisy, że dostawca posiada pełne prawa do oprogramowania i może udzielać licencji bez ograniczeń. CTO decyduje o wdrożeniu asystenta AI w IDE, aby przyspieszyć prace. Po kilku sprintach część developerów zaczyna korzystać z AI do generowania całych handlerów API, warstw serwisowych, a nawet fragmentów logiki biznesowej.

W pewnym momencie na code review ktoś rozpoznaje fragment, który wygląda niemal identycznie jak kod z popularnej biblioteki na licencji GPL. Pojawia się pytanie: czy wklejenie tego fragmentu „wciąga” cały projekt w obowiązki GPL, na przykład konieczność udostępnienia kodu źródłowego? Dla SaaS, który buduje przewagę na zamkniętym kodzie, byłby to poważny problem biznesowy. Nagle temat AI przestaje być tylko technologiczną ciekawostką i trafia na biurko prawnika.

Freelancer z klauzulą odpowiedzialności za naruszenia

Drugi scenariusz: freelancer buduje moduł integracyjny lub komponent frontendowy dla dużego klienta. W umowie ma typową klauzulę, że oświadcza posiadanie praw do przekazywanego kodu i ponosi odpowiedzialność za ewentualne naruszenia praw autorskich osób trzecich, w tym licencji open source. Żeby zdążyć w terminie, chętnie korzysta z AI: generuje szkielety, przykłady integracji, a czasem całe gotowe funkcje.

Po zakończeniu projektu klient przeprowadza audyt bezpieczeństwa i zgodności licencyjnej (code scan). Narzędzie wykrywa, że część kodu jest niemal identyczna z fragmentem projektu open source na licencji AGPL. Klient pyta, dlaczego ten kod znalazł się w rozwiązaniu komercyjnym, skoro nie uzgodniono korzystania z AGPL, i grozi wstrzymaniem płatności albo żąda modyfikacji i oświadczeń. Dla freelancera to realne ryzyko: może stracić zlecenie, reputację i być zmuszony do szybkiej, nerwowej refaktoryzacji.

Korporacyjny zespół i warunki narzucone przez compliance

Trzeci kontekst to duża organizacja, w której istnieją rozbudowane procedury compliance. Zespół developerski chce wdrożyć asystenta AI w całym departamencie IT. Działy prawne i bezpieczeństwa stawiają warunek: narzędzie nie może wysyłać do dostawcy fragmentów poufnego kodu, a wygenerowany kod nie może wprowadzać ryzyka „zakażenia” copyleftem. Dopóki nie zostaną opracowane wewnętrzne zasady korzystania z AI i proces akceptacji kodu, inicjatywa jest blokowana.

W efekcie powstaje napięcie między potrzebą modernizacji workflow developerskiego a wymaganiami formalnymi. Programiści widzą AI jako sposób na mniej nudnej pracy i szybsze rozwiązywanie problemów, prawnicy patrzą na potencjalne spory sądowe, audyty klientów i konsekwencje niezgodności licencyjnych. Rozplątanie tego konfliktu wymaga zrozumienia, gdzie faktycznie w łańcuchu korzystania z AI powstaje ryzyko licencyjne i kto może za nie odpowiadać.

Gdzie w tych scenariuszach pojawia się pytanie o licencje

Miejsca, w których rośnie ryzyko prawne

Ryzyko naruszenia licencji lub praw autorskich przy kodzie generowanym przez AI nie jest równomierne. Szczególnie wrażliwe są:

• Kopiowanie całych funkcji lub klas – im dłuższy i bardziej charakterystyczny fragment, tym większe prawdopodobieństwo, że jest rozpoznawalny jako konkretny utwór lub część biblioteki pod daną licencją.
• Generowanie gotowych modułów – na przykład pełen moduł autoryzacji, obsługi płatności czy integracja z konkretnym API, gdzie struktura i nazwy mogą pokrywać się z projektem open source.
• Specyficzne snippety konfiguracyjne – pliki konfiguracyjne frameworków, CI/CD czy narzędzi, które są często kopiowane z dokumentacji lub repozytoriów i mogą być objęte licencją (choć tu zwykle próg twórczości jest niski).
• Generacja w oparciu o bardzo konkretny prompt – np. „zrób odpowiednik funkcji X z projektu Y” lub wklejenie fragmentu licencjonowanego kodu do promptu z prośbą o jego przerobienie.

Znacznie mniejsze ryzyko pojawia się przy generowaniu ogólnych szablonów, prostych funkcji pomocniczych czy wzorców, które są standardem branżowym. Tam granica między „wzorem” a „konkretnym utworem” jest słabsza, a często w ogóle brak ochrony prawnoautorskiej z uwagi na zbyt małą oryginalność.

Różny apetyt na ryzyko: startup, korporacja, freelancer

Te same fakty techniczne mogą prowadzić do innych decyzji w zależności od profilu organizacji:

• Startup SaaS często świadomie akceptuje umiarkowane ryzyko prawne w zamian za tempo rozwoju produktu. Może pozwolić na szersze użycie AI, ale zwykle i tak będzie unikał świadomego korzystania z kodu na licencjach copyleft.
• Korporacja ma dużo niższą akceptację ryzyka – częściej woli rezygnować z części wygody AI, niż narażać się na spory sądowe czy audyty klientów. Tu liczy się proces: polityki, checklisty, audyty kodu.
• Freelancer teoretycznie ma większą swobodę, ale praktycznie często bierze na siebie osobistą odpowiedzialność kontraktową. Naruszenie może dotknąć go bezpośrednio finansowo, więc „kopiuj–wklej z AI” bywa szczególnie ryzykowne.

To prowadzi do podstawowego pytania: co jest naruszeniem w kontekście kodu generowanego przez AI i kto ponosi konsekwencje? Żeby na to odpowiedzieć, trzeba zrozumieć, skąd model „zna” kod i gdzie w tym wszystkim jest miejsce licencji.

Skąd model „zna” kod: trenowanie na repozytoriach a problem licencji

Trenowanie modeli na kodzie – tylko tyle, ile potrzebne

Dane treningowe vs output modelu

Modele generatywne do kodu są trenowane na ogromnych zbiorach danych: publicznych repozytoriach, dokumentacji, tutorialach, forach dyskusyjnych. Technicznie model nie przechowuje „kopii” plików z GitHuba, tylko parametry pozwalające odtworzyć pewne wzorce. Z perspektywy prawa licencyjnego istotne są dwie fazy:

• Trening – pobieranie i przetwarzanie cudzego kodu przez twórcę modelu.
• Generacja outputu – dostarczanie przez model fragmentów kodu użytkownikowi końcowemu.

Spór prawny może dotyczyć obu etapów, ale z punktu widzenia dewelopera korzystającego z AI najważniejszy jest output: to właśnie on trafia do repozytorium projektu i może stać się źródłem naruszenia licencji.

Zjawisko „memorization” – kiedy model powtarza kod

Kluczowe pojęcie to memorization, czyli sytuacja, w której model generuje treść bardzo zbliżoną lub identyczną do fragmentu, na którym był trenowany. Dzieje się tak częściej, gdy:

• fragment treningowy był bardzo często powtarzany (popularne snippets, biblioteki),
• prompt użytkownika jest bardzo zbliżony do oryginalnego kontekstu,
• użytkownik prosi o długi, specyficzny kawałek kodu, np. „pełną implementację algorytmu X z optymalizacjami Y”.

Z perspektywy licencyjnej to właśnie sytuacje, w których model „odtwarza” konkretny utwór, są najbardziej problematyczne. Gdy generuje ogólny wzorzec lub „nową” kombinację znanych motywów, ryzyko kolizji z konkretną licencją maleje.

Prompt a ryzyko kopiowania

Na poziom ryzyka wpływa także sposób zadawania pytań. Prośby typu:

• „Napisz przykładowy kontroler REST w Spring Boot do CRUD na encji User” – raczej skłaniają model do stworzenia standardowego, generycznego przykładu.
• „Zaimplementuj funkcję calculateOptimalRoute() tak jak w bibliotece Z pod projektem Y” – zwiększają szansę, że output będzie zbliżony do konkretnego licencjonowanego kodu.

W praktyce polityka korzystania z AI powinna odnosić się także do treści promptów, a nie tylko do samego faktu używania narzędzia. To w promptach często ukrywa się proszenie modelu o „rekonstrukcję” cudzego utworu.

Gdzie w tym wszystkim pojawia się licencja

Publiczny kod to nie „no‑license”

To, że kod jest dostępny publicznie na GitHubie, GitLabie czy w innym repozytorium, nie oznacza, że jest wolny od licencji. Przeciwnie – niemal każdy projekt open source jest objęty jakąś licencją, która reguluje:

• czy wolno kopiować i modyfikować kod,
• na jakich warunkach można go rozpowszechniać,
• jakie obowiązki informacyjne lub patentowe wiążą się z użyciem.

Jeżeli model był trenowany na takim kodzie, a następnie wygeneruje fragment identyczny lub bardzo podobny, powstaje pytanie: czy użytkownik modelu, wklejając ten fragment do swojego projektu, jest zobowiązany do przestrzegania tej samej licencji, jakby skopiował kod z repozytorium ręcznie.

Trening a output – dwie różne oceny prawne

Na poziomie dyskusji prawniczej rozróżnia się co najmniej dwa zagadnienia:

• Legalność trenowania na danych objętych licencjami (czy licencja obejmuje proces „uczenia” modelu, czy autor kodu może się temu sprzeciwić).
• Legalność wykorzystania outputu, czyli czy użytkownik może korzystać z wygenerowanego kodu bez naruszenia licencji pierwotnego projektu.

Dla programisty kluczowy jest drugi punkt: nawet jeśli twórca modelu uznaje, że trening był zgodny z prawem, to użytkownik odpowiada za to, co robi z wygenerowanym kodem. W razie sporu to jego produkt będzie analizowany pod kątem podobieństwa do projektu open source, a nie proces trenowania modelu.

Co wiemy, a czego nie wiemy o danych treningowych

Część dostawców narzędzi AI deklaruje, że szkolą modele na danych zgodnie z obowiązującymi przepisami i licencjami, czasem udostępniają opcje wyłączenia prywatnych repozytoriów z treningu. Jednocześnie zazwyczaj nie publikują pełnej, szczegółowej listy źródeł i proporcji danych, co powoduje, że:

• wiemy, że w zbiorach treningowych znajduje się duża ilość publicznego kodu open source,
• nie wiemy dokładnie, który kod mógł wpłynąć na wygenerowany fragment w konkretnym przypadku.

To utrudnia przypisanie konkretnej licencji do konkretnego outputu „od strony modelu”. Z prawnego punktu widzenia analiza zwykle będzie wyglądała tak, jakby kod został po prostu znaleziony w projekcie: porównanie z istniejącymi repozytoriami, ocena podobieństwa, a dopiero potem rozważanie udziału AI jako pośrednika.

Licencje open source w pigułce: co może „przylecieć” w wygenerowanym kodzie

Dwie wielkie grupy: copyleft i licencje permisywne

Copyleft – GPL, AGPL, LGPL i logika „zarażania”

Największy lęk przy korzystaniu z kodu generowanego przez AI budzą licencje typu copyleft, przede wszystkim rodzina GPL (GPL, AGPL, LGPL). Ich ogólna logika polega na tym, że:

• jeśli tworzysz utwór zależny od kodu na GPL (modyfikujesz go lub tworzysz projekt łączący się w określony sposób),
• musisz udostępnić swój kod (lub jego część) na warunkach tej samej licencji.

• „Zarażenie” może nastąpić przez statyczne linkowanie, kopiowanie i modyfikację kodu, a w przypadku AGPL – także przez udostępnianie usługi przez sieć.
• W praktyce oznacza to konieczność otwarcia kodu źródłowego własnej aplikacji (lub jej istotnych części) na tej samej licencji, jeśli spełnione są przesłanki powstania utworu zależnego.

Jeżeli model „odtworzy” fragment kodu objęty copyleft, a deweloper włączy go bezrefleksyjnie do zamkniętego produktu, formalnie powstaje ten sam problem, który pojawiłby się przy ręcznym skopiowaniu pliku z projektu na GPL. Narzędzie AI nie „czyści” licencji – jedynie zmienia sposób, w jaki kod trafił do repozytorium.

Ryzyko jest szczególnie odczuwalne w dwóch scenariuszach: gdy model generuje całe pliki lub moduły wysokiego poziomu (np. pełen driver bazy danych, implementację protokołu czy warstwę ORM), oraz gdy output jest wyraźnie związany z konkretnym, znanym projektem na GPL/AGPL. Wtedy nawet częściowa zbieżność może skłonić audytora lub prawnika do głębszego porównania kodu.

Część organizacji przyjmuje więc restrykcyjną zasadę: kod, który „wygląda jak” fragment znanej biblioteki copyleft, jest automatycznie traktowany z podejrzliwością. Taki fragment albo jest przepisywany od zera (na podstawie specyfikacji, nie kodu), albo zastępowany innym rozwiązaniem – nawet kosztem kilku dodatkowych dni pracy.

Licencje permisywne – MIT, BSD, Apache 2.0

Z drugiej strony są licencje permisywne, takie jak MIT, BSD czy Apache 2.0. Dają one szeroką swobodę kopiowania, modyfikowania i używania kodu – także w projektach zamkniętych. W zamian nakładają stosunkowo proste obowiązki: zachowanie informacji o prawach autorskich, dołączenie treści licencji, ewentualnie spełnienie warunków dotyczących patentów (szczególnie w Apache 2.0).

Kiedy model wygeneruje fragment wyraźnie przypominający kod z projektu na MIT czy BSD, główne pytanie brzmi nie tyle „czy wolno z niego korzystać?”, ale „czy w naszym projekcie zostały dochowane minimalne wymogi licencyjne”. W praktyce spór nie będzie dotyczył konieczności otwarcia całego repozytorium, lecz np. braku informacji o autorze lub braku pliku NOTICE.

Dla wielu firm taki typ ryzyka jest bardziej akceptowalny: ewentualna korekta polega na uzupełnieniu nagłówków, dorzuceniu plików licencyjnych lub zastąpieniu pojedynczych fragmentów, a nie na zmianie całego modelu biznesowego. Stąd też w politykach korzystania z AI częściej dopuszcza się inspirację kodem na MIT/Apache niż jakimkolwiek kodem copyleft.

Brak licencji, licencje własne i kody „no‑license”

Osobną kategorię stanowią projekty bez wyraźnie określonej licencji lub z licencjami autorskimi, które nie mieszczą się w typowym katalogu „open source”. Brak licencji nie oznacza „wolnej amerykanki” – co do zasady oznacza to pełną ochronę prawa autorskiego na standardowych zasadach. Wygenerowanie i użycie kodu, który istotnie powiela taki projekt, może być więc traktowane jak naruszenie praw autorskich bez jakiejkolwiek „tarczy” w postaci jasnych warunków open source.

W praktyce, gdy audyt wykryje istotne podobieństwo do projektu „no‑license” albo z bardzo restrykcyjną licencją własną, organizacje często wybierają najprostsze wyjście: usunąć lub przepisać sporny fragment, zamiast próbować negocjować zgodę ex post. W tym obszarze AI niczego nie upraszcza – jeśli model „ściągnie” taki kod, problem jest identyczny jak przy manualnym kopiowaniu.

Jak odróżnić inspirację od kopiowania w praktyce projektu

Spór o to, czy dany fragment kodu jest tylko „typowym rozwiązaniem”, czy już kopią konkretnego projektu open source, rozgrywa się na poziomie szczegółów. Z punktu widzenia programisty i zespołu kilka kryteriów pojawia się w takich analizach najczęściej.

Poziom podobieństwa: algorytm, struktura, konkretne linie

Audytorzy techniczni i prawnicy przyglądają się co najmniej trzem warstwom:

• idei i algorytmowi – ogólny pomysł na rozwiązanie problemu (np. użycie BFS, quicksorta, klasycznego wzorca projektowego); sam pomysł zwykle nie jest chroniony, chronione jest jego konkretne wyrażenie w kodzie,
• strukturze i organizacji – podział na klasy, moduły, nazwy metod, sposób przepływu danych; im bardziej osobliwa i nietypowa struktura, tym łatwiej mówić o przejęciu cudzego utworu,
• konkretnym brzmieniom linii kodu – identyczne lub prawie identyczne sekwencje instrukcji, komentarzy, nazw zmiennych.

W sporach dotyczących kodu generowanego przez AI zwykle bada się, czy zachodzi istotne podobieństwo przynajmniej w dwóch z tych warstw jednocześnie. Prosty, krótki fragment w stylu „pętla po liście i sumowanie wartości” rzadko będzie uznany za przejęcie cudzego utworu, ale już rozbudowana klasa z nietypową logiką i charakterystycznymi nazwami – o wiele częściej.

„Krótkie fragmenty” a realne ryzyko

W dyskusjach pojawia się argument, że „krótkie fragmenty kodu” nie są chronione, bo są banalne lub oczywiste. W rzeczywistości granica nie jest ostra. Zależy od:

• stopnia oryginalności danego fragmentu (czy jest to standardowy idiom języka, czy unikalny trik),
• kontekstu – czy ten fragment tworzy z innymi elementami spójny, indywidualny utwór,
• skali powtórzeń – pojedynczy wiersz będzie oceniany inaczej niż kilkadziesiąt linii w niezmienionej kolejności.

W praktyce przyjmuje się ostrożne podejście: jeśli audyt wykryje ciągi kilkunastu–kilkudziesięciu linii identycznych z projektem open source, zwłaszcza z charakterystycznymi komentarzami lub nazwami, zespół traktuje to jak potencjalne naruszenie, niezależnie od tego, czy kod napisał człowiek, czy AI.

Checklista dla review kodu z AI

Podczas code review sensowne jest wrzucenie kilku prostych pytań kontrolnych dla fragmentów wygenerowanych przez model:

• Czy fragment jest wyjątkowo rozbudowany jak na jedno zapytanie do AI (np. całe API, warstwa persistence, skomplikowany parser)?
• Czy w treści pojawiają się nazwy klas, metod, komentarze, które brzmią, jakby pochodziły z konkretnej biblioteki lub projektu?
• Czy widać nietypowe „smaczki” stylu – dziwne konwencje nazewnicze, żarty w komentarzach, odniesienia do dawnych wersji frameworków?
• Czy prompt zawierał bezpośrednie odniesienie do istniejącego projektu („tak jak w bibliotece X”, „z repozytorium Y”)?

Jeśli na któreś z tych pytań odpowiedź brzmi „tak”, rozsądną reakcją jest dodatkowe sprawdzenie podobieństwa z publicznymi repozytoriami albo decyzja o przepisaniu fragmentu na podstawie czystej specyfikacji.

Odpowiedzialność za naruszenie: kto realnie ryzykuje

Wraz z upowszechnieniem narzędzi AI w developmentzie pojawia się pytanie: kto ponosi konsekwencje, gdy ktoś zgłosi naruszenie licencji – autor modelu, jego użytkownik czy firma, która produkt sprzedaje klientom?

Użytkownik i jego firma jako „ostatni przystanek”

Z punktu widzenia prawa autorskiego i licencji kluczowa jest osoba lub podmiot, który eksploatuje kod: wdraża go w produkcie, sprzedaje, udostępnia w chmurze. W modelu B2B i B2C będzie to z reguły firma, a nie pojedynczy programista.

Jeżeli fragment kodu wygenerowany przez AI zostanie wprost przejęty do produktu i narusza licencję lub cudze prawa autorskie, roszczenia kierowane są najpierw do podmiotu oferującego produkt. Narzędzie AI jest w tym scenariuszu traktowane jak każde inne narzędzie programistyczne: nie zwalnia z odpowiedzialności za finalny kształt kodu.

Dostawca narzędzia: zapisy w regulaminach i klauzule indemnifikacyjne

Dostawcy narzędzi wprowadzają własne zasady gry w regulaminach i umowach. Widać kilka powtarzających się rozwiązań:

• ograniczenie odpowiedzialności – zastrzeżenie, że narzędzie działa „as is”, a użytkownik sam ocenia zgodność z licencjami,
• wyłączenia dla określonych zastosowań – np. zakaz używania modelu do replikowania konkretnych bibliotek,
• częściowa ochrona prawna (indemnity) w wyższych planach – dostawca zobowiązuje się do obrony klienta w razie roszczeń dotyczących outputu, ale pod warunkiem spełnienia określonych procedur i ograniczeń.

Co istotne, taka ochrona często obejmuje spory o naruszenie patentów lub praw autorskich przez sam mechanizm generowania, a niekoniecznie klasyczne naruszenia licencji open source, w których użytkownik włączył do produktu wprost fragment znanego projektu.

Programista jako osoba fizyczna

W typowym układzie pracowniczym to firma jest adresatem roszczeń, ale zachowanie konkretnego dewelopera może mieć znaczenie wewnętrzne:

• jeśli pracownik świadomie ominął procedury (np. skopiował output AI żywcem mimo jasnego zakazu), firma może dochodzić roszczeń regresowych,
• w kontraktach B2B (freelancer–klient) częste są klauzule, że wykonawca gwarantuje „wolność od obciążeń prawnych” dostarczonego kodu – w takim układzie to on pierwszy zmierzy się z pretensjami klienta.

Z praktycznego punktu widzenia dla dewelopera ważniejsze jest więc to, co mówi umowa z pracodawcą lub klientem, niż szczegółowa konstrukcja przepisów prawa autorskiego.

Procedury w zespole: jak wbudować AI w proces, żeby nie paraliżować pracy

Wprowadzenie narzędzi AI do developmentu zwykle wymusza ułożenie kilku prostych, ale konsekwentnie stosowanych zasad. Ich celem jest nie tyle wyeliminowanie ryzyka (to nierealne), co przesunięcie go na akceptowalny poziom.

Polityka korzystania z AI – o co zadbać

Nawet krótka, jednokartkowa polityka może uporządkować praktykę. Często obejmuje ona m.in.:

• dozwolone obszary użycia – np. prototypowanie, testy, generowanie boilerplate’u, ale nie kluczowa logika biznesowa czy unikalne algorytmy firmy,
• zakaz proszenia modelu o odtwarzanie konkretnych projektów – brak promptów w stylu „zrób tak jak w bibliotece X”,
• wymóg oznaczania fragmentów generowanych w commitach lub PR-ach (choćby krótkim komentarzem w opisie),
• obowiązek code review dla wszystkich istotnych fragmentów wygenerowanych przez AI, z uwzględnieniem ryzyka licencyjnego.

Polityka nie rozwiąże każdego przypadku, ale pozwala menedżerom i prawnikom zorientować się, które miejsca w kodzie potencjalnie niosą większe ryzyko i jak je monitorować.

Code review z „radarem licencyjnym”

W wielu zespołach review dotyczy głównie jakości technicznej. W kontekście AI dochodzi jeszcze szybka ocena zgodności z licencjami. Praktyczny kompromis to:

• oznaczanie w PR-ach plików, gdzie wykorzystano AI,
• obowiązkowe review takich fragmentów przez osobę z podstawową wiedzą o licencjach (niekoniecznie prawnika),
• stosowanie automatycznych narzędzi do wykrywania podobieństw kodu z publicznymi repozytoriami w krytycznych modułach.

Dla małego startupu może to być po prostu „osoba ds. open source” w zespole; w większych organizacjach – dedykowany zespół compliance technicznego.

Trzy typowe scenariusze organizacyjne

Na poziomie decyzji biznesowych często powtarzają się trzy scenariusze:

• Mały zespół produktowy / startup SaaS – AI jest używane intensywnie do prototypowania i boilerplate’u, ale unika się generowania kluczowej logiki. Ryzyko licencyjne zarządza się głównie zdrowym rozsądkiem i podstawową polityką.
• Średnia firma software house – narzędzia AI są wykorzystywane, lecz każde wdrożenie do projektu klienta przechodzi formalny code review i skan podobieństw. Umowy z klientami zawierają zapisy o sposobie korzystania z AI w projekcie.
• Duża organizacja / korporacja – AI jest często ograniczone do środowisk wewnętrznych lub własnych modeli, a procesy licencyjne są zbliżone do klasycznego zarządzania open source (rejestr komponentów, zatwierdzanie wyjątków, okresowe audyty).

Decyzja, który model przyjąć, zależy od wagi produktu, profilu klienta i apetytu na ryzyko, a nie od samej technologii generatywnej.

Co robić, gdy pojawi się zarzut naruszenia licencji przez kod z AI

Nawet przy ostrożnym podejściu mogą zdarzyć się sytuacje, w których ktoś zgłasza, że fragment kodu w produkcie narusza jego licencję lub prawa autorskie. Reakcja „gasimy pożar, jak się da” bywa zrozumiała, ale nie zawsze optymalna.

Pierwszy krok: techniczne porównanie i zabezpieczenie dowodów

Na początku przydaje się chłodna, techniczna analiza:

• porównanie spornego fragmentu z repozytorium wskazanym przez zgłaszającego (narzędzia typu diff, porównanie historii zmian, stylu),
• sprawdzenie historii commitów i opisów PR – czy widać tam ślady użycia AI, czy raczej ręczne kopiowanie,
• zabezpieczenie aktualnej wersji repozytorium i logów, aby w razie sporu móc odtworzyć, jak powstawał kod.

Na tym etapie nie przesądza się jeszcze, czy doszło do naruszenia – celem jest ustalenie faktów, zanim projekt zostanie posprzątany lub przepisany.

Decyzje biznesowe: przepisać, usunąć, negocjować

Po wstępnej analizie zwykle pojawiają się trzy ścieżki działania:

• przepisanie lub usunięcie fragmentu – wybierane, gdy fragment jest mało istotny, a podobieństwo znaczne; to najprostszy sposób na szybkie obniżenie ryzyka,
• dostosowanie się do licencji – np. dodanie plików licencyjnych, informacji o autorze, zmian w komunikatach; dotyczy głównie licencji permisywnych,
• negocjacje lub spór – gdy zarzut dotyczy kluczowego elementu produktu albo pojawia się w kontekście szerszego konfliktu biznesowego.

To, że kod wygenerowała AI, ma w takich sytuacjach znaczenie wtórne. Z punktu widzenia drugiej strony liczy się, że w produkcie znalazł się fragment zbyt bliski jej projektowi, a nie to, czy trafił tam z GitHuba, czy z modelu językowego.

Włączenie AI do istniejących procedur compliance

W firmach, które już wcześniej korzystały z komponentów open source, proces reagowania na zarzuty naruszeń często jest gotowy. Najczęściej:

• zespół prawny i techniczny wspólnie ocenia ryzyko i koszty działań,
• produkt może otrzymać tymczasowe ograniczenia wdrożeń (np. brak nowych klientów na czas wyjaśnienia sprawy),
• klienci kluczowi są informowani o sytuacji, jeśli istnieje ryzyko wpływu na SLA lub funkcjonalność.

AI nie wymusza całkowicie nowych procedur – raczej poszerza zakres, w którym trzeba je stosować. Kod generowany przez model staje się jednym z wielu potencjalnych źródeł komponentów o niejasnym pochodzeniu.

Jak świadomie korzystać z AI: generator kodu czy asystent inżyniera?

W praktyce większość zespołów dochodzi do punktu, w którym trzeba odpowiedzieć na konkretne pytanie: czy traktować AI jako źródło gotowego kodu produkcyjnego, czy raczej jako narzędzie pomocnicze przy pracy człowieka. Ta decyzja wprost przekłada się na ryzyko licencyjne i oczekiwania wobec procesu review.

Dwa modele użycia AI w projekcie

Widać dwa przeciwstawne podejścia do roli AI w developmentzie:

• AI jako dostawca gotowego kodu – deweloper wkleja większe fragmenty outputu bez głębokiej ingerencji, szczególnie przy powtarzalnych zadaniach (API, CRUD, testy). Szybkość jest maksymalna, ale rośnie ryzyko, że do repozytorium trafi dłuższy fragment podobny do cudzego projektu.
• AI jako asystent inżyniera – model podpowiada szkic rozwiązania, a programista przebudowuje go, łączy z istniejącą architekturą, zmienia nazwy, struktury danych, czasem jedynie inspiruje się logiką. Tu ryzyko naruszenia licencji jest wyraźnie niższe, bo ostateczna forma kodu powstaje w wyniku świadomej pracy twórczej.

Spór prawny rzadziej dotyczy krótkich, wielokrotnie przepisanych fragmentów, częściej – niemal identycznych modułów czy klas. To praktyczny argument za traktowaniem AI bardziej jako szkicownika niż maszyny kopiującej.

Kiedy generować, a kiedy pisać ręcznie

Jedna z prostszych metod zarządzania ryzykiem to rozdzielenie kodu na kategorie według wagi biznesowej i prawnej. W codziennej pracy może wyglądać to tak:

• Boilerplate, glue code, testy – AI może być używane szeroko, o ile zespół zachowa review i minimalną przeróbkę wygenerowanych fragmentów.
• Logika biznesowa (unikalne algorytmy, nietypowe reguły): AI raczej jako źródło pomysłów i szkiców, kod ostateczny pisany lub mocno przebudowany przez człowieka.
• Fragmenty o wysokiej wrażliwości prawnej (np. implementacja zbliżona do znanych bibliotek, standardów branżowych): albo bez AI, albo z obowiązkowym, pogłębionym porównaniem z istniejącymi projektami open source.

Decyzja, do której kategorii trafi dany moduł, bywa bardziej biznesowa niż techniczna. Kluczowe pytania to: jak łatwo przepisać ten fragment, gdyby pojawiło się ryzyko, oraz jak duże byłyby skutki jego czasowego wyłączenia.

Checklist dla menedżera: jak ustawić granice

Przy ustalaniu roli AI pomocne bywa kilka prostych kryteriów, zadanych wprost zespołowi:

• czy chcemy, by AI tworzyła kluczowe elementy produktu, czy raczej przyspieszała codzienne zadania,
• czy mamy zasoby, żeby audytować newralgiczne moduły pod kątem podobieństwa do open source,
• jak zareagujemy, jeśli za rok pojawi się poważny zarzut licencyjny: uleczalne przepisywanie czy paraliż produktu.

Te pytania często prowadzą do wniosku, że największą część zysków produktywności daje używanie AI tam, gdzie ewentualny błąd licencyjny jest najłatwiejszy do naprawienia.

Niewiadome i sporne obszary: czego prawo jeszcze nie poukładało

Choć część ryzyk można oswoić poprzez procesy, pozostają kwestie, w których brak jeszcze stabilnej praktyki sądowej. To one budzą najwięcej emocji w dyskusji o kodzie generowanym przez AI.

Status prawny kodu wygenerowanego przez AI

Na poziomie przepisów większość jurysdykcji chroni utwory stworzone przez człowieka. Kod powstały w pełni automatycznie ma niejasny status: czy można mówić o „autorze”, jeśli człowiek jedynie zaakceptował wynik modelu?

W praktyce stosuje się kilka interpretacji:

• jeśli programista aktywnie kształtuje wynik (prompt, modyfikacje, refaktoryzacja), uznaje się, że finalny kod ma wkład twórczy człowieka i może podlegać ochronie jak zwykłe oprogramowanie,
• przy prostym skopiowaniu dłuższego fragmentu outputu bez zmian pojawia się pytanie, czy w ogóle powstał „utwór” po stronie użytkownika, co komplikuje np. przeniesienie praw na klienta.

Co wiemy na pewno? Umowy w branży IT nadal zakładają, że wykonawca dostarcza kod, do którego może przenieść lub udzielić praw. Czego nie wiemy? Jak sądy będą traktować przypadki, w których większość treści pochodzi z modelu, a udział człowieka jest minimalny.

Trenowanie modeli na kodzie a licencje open source

Drugi sporny obszar dotyczy samego etapu treningu modeli na publicznych repozytoriach. Pojawiają się pytania, czy masowe przetwarzanie kodu objętego GPL, MIT czy innymi licencjami wymaga osobnych zgód lub podlega wyjątkom typu dozwolony użytek techniczny.

Obecny stan jest niejednoznaczny:

• część ekspertów uznaje trening za formę analizy danych, która nie skutkuje powstaniem utworu zależnego i jest dopuszczalna przy zachowaniu określonych zasad,
• inni wskazują, że jeśli model potrafi odtworzyć dłuższe fragmenty kodu, granica między „analizą” a „replikacją” zostaje przekroczona.

To spór głównie między autorami popularnych projektów open source a twórcami dużych modeli. Dla użytkownika końcowego oznacza to tyle, że część konfliktów może rozgrywać się ponad jego głową, ale skutki (np. zmiany warunków korzystania z narzędzi) będą odczuwalne w codziennej pracy.

Granica dozwolonej inspiracji

W tradycyjnych sporach o prawo autorskie sądy od lat rozstrzygają, gdzie kończy się inspiracja, a zaczyna kopiowanie. W przypadku AI dochodzi jeszcze jedna warstwa: brak przejrzystości co do ścieżki, którą model doszedł do konkretnego rozwiązania.

Typowy dylemat: AI proponuje algorytm, który przypomina istniejącą bibliotekę open source, ale nie ma w nim identycznych linii. Czy to już naruszenie? Część prawników odpowie: najczęściej nie, o ile nie skopiowano struktury plików, komentarzy czy unikalnych fragmentów. Inni zwrócą uwagę na możliwość „ukrytego” odwzorowania architektury.

Bez ugruntowanej praktyki orzeczniczej ryzyko pozostaje ocenne. Stąd nacisk na pragmatykę: im bardziej unikalny i strategiczny moduł, tym większy sens, by tworzyć go w sposób maksymalnie odseparowany od automatycznych podpowiedzi.

Praktyczne strategie dla różnych ról w organizacji

Perspektywa na AI w kodzie jest inna dla osoby zarządzającej produktem, inna dla prawnika, a jeszcze inna dla programisty przy klawiaturze. Spójność podejścia wymaga dopasowania oczekiwań do roli.

Deweloper: jak „bezpiecznie” używać AI na co dzień

W codziennej pracy kluczowe stają się proste nawyki, które nie spowalniają developmentu, a ograniczają najbardziej oczywiste ryzyka:

• traktowanie AI jako pierwszej wersji rozwiązania, nie jako finalnej – każdy większy fragment przechodzi przez etap świadomej modyfikacji,
• unikanie promptów wprost proszących o odtworzenie konkretnych projektów lub bibliotek,
• oznakowanie w PR-ach miejsc, gdzie użyto AI, tak aby recenzent wiedział, na co zwrócić większą uwagę.

W praktyce zmniejsza to zarówno ryzyko licencyjne, jak i czysto techniczne błędy, bo wymusza minimalną refleksję nad proponowanym kodem.

Menedżer produktu / CTO: decyzje na poziomie procesu

Osoba odpowiedzialna za produkt rzadko ma czas wchodzić w szczegóły licencji, ale wpływa na to, jak często zespół będzie stykał się z problemami prawnymi. Typowe decyzje obejmują:

• określenie, w których projektach AI jest domyślnie dozwolone, a gdzie wymaga zgody (np. systemy dla sektora regulowanego),
• zdefiniowanie minimalnego standardu dokumentowania użycia AI – tak, aby w razie sporu dało się odtworzyć historię powstawania kodu,
• wybór narzędzi: czy korzystać z publicznych modeli, czy inwestować w bardziej kontrolowane środowiska (np. modele trenowane na wewnętrznym kodzie).

Te decyzje nie eliminują ryzyka, ale przesuwają je na poziom, który jest świadomie zaakceptowany w strategii produktu.

Prawnik / compliance: ramy, nie pojedyncze commity

Z kolei zespoły prawne najlepiej sprawdzają się tam, gdzie mogą ustawić ramy, a nie oceniać każdy fragment kodu. Najczęściej chodzi o:

• opracowanie prostych wytycznych licencyjnych dla deweloperów, z przykładami „tak / nie” dla najczęstszych sytuacji,
• analizę regulaminów dostawców narzędzi AI i wskazanie, gdzie są realne luki w ochronie użytkownika,
• włączenie kwestii AI do istniejących procesów due diligence przy audytach kodu przed inwestycją, sprzedażą spółki czy dużym wdrożeniem.

W ten sposób odpowiedzialność nie spada wyłącznie na pojedynczych programistów, a organizacja ma spójny, przewidywalny sposób reagowania na pojawiające się wątpliwości.

Najważniejsza myśl i kolejny krok dla zespołu

Kod generowany przez AI nie jest osobną kategorią z punktu widzenia licencji – prędzej kolejnym źródłem fragmentów, których pochodzenia trzeba być świadomym. Różnica polega na skali i tempie: to, co wcześniej kopiowano ręcznie z bloga czy Gista, dziś powstaje jednym promptem.

Realistyczny kolejny krok dla większości zespołów to nie rezygnacja z narzędzi, lecz uporządkowanie ich miejsca w procesie: określenie, gdzie są używane, jak są znakowane w kodzie, kto i kiedy dokonuje przeglądu pod kątem licencji. Dopiero na takim fundamencie sens ma dyskusja o bardziej zaawansowanych zabezpieczeniach technicznych czy negocjacjach z dostawcami modeli.

Reagowanie na zarzut naruszenia licencji przez kod z AI

Prędzej czy później w wielu zespołach pojawia się sytuacja alarmowa: ktoś zgłasza, że fragment kodu w repozytorium wygląda jak przepisany z jego projektu open source. Dla menedżera i programisty kluczowe jest, aby wiedzieć, co zrobić w pierwszych godzinach, zamiast improwizować.

Pierwsza reakcja: zatrzymanie szkody i zebranie faktów

Na początku liczy się nie emocja, lecz procedura. Typowy „bezpieczny” ciąg kroków wygląda tak:

• zamrożenie spornego fragmentu – wstrzymanie nowych wdrożeń z tym kodem, ewentualnie szybki hotfix wyłączający podejrzany moduł z produkcji, jeśli to możliwe bez paraliżu systemu,
• zabezpieczenie historii – pobranie logów z repozytorium, historii PR-ów, komentarzy, dat; chodzi o odtworzenie, skąd konkretny kod się wziął,
• wstępne porównanie techniczne – diff między zakwestionowanym kodem a wskazanym projektem open source: linijka po linijce, z uwzględnieniem struktury plików, nazw, komentarzy.

Na tym etapie nadal nie rozstrzyga się, czy doszło do naruszenia. Celem jest zbudowanie obrazu sytuacji, który później może przeanalizować osoba odpowiedzialna prawnie.

Rola dewelopera w wyjaśnianiu pochodzenia kodu

Deweloper, który wprowadził sporny fragment, nie musi znać wszystkich niuansów licencyjnych, ale może dostarczyć kluczowych informacji faktograficznych:

• czy i w jakim zakresie korzystał z narzędzia AI przy powstawaniu tego fragmentu,
• jak wyglądał proces: prompt, kolejne wersje kodu, manualne poprawki,
• czy w tym samym czasie przeglądał konkretny projekt open source, którego dotyczy zarzut.

Jeżeli zespół wcześniej przyjął zasadę oznaczania miejsc generowanych przez AI, łatwiej dziś udokumentować, co było efektem automatycznej podpowiedzi, a co samodzielnej pracy. To nie tylko kwestia zaufania, ale także materiału do rozmowy z prawnikiem i drugą stroną sporu.

Analiza ryzyka: kiedy przepisać, a kiedy walczyć

Po wstępnym zebraniu danych pytanie brzmi: co dalej – szybkie „przepisanie i zapomnienie” czy spór o zakres ochrony? Decyzja zależy zwykle od kilku czynników:

• Znaczenie fragmentu – jeśli to marginalny helper, często tańsze jest jego przepisanie niż długie spory o to, czy 10 linijek było twórcze.
• Krytyczność modułu – przy kluczowym algorytmie, który trudno zastąpić, firma może być bardziej skłonna bronić się merytorycznie i korzystać z opinii eksperckich.
• Jasność podobieństwa – przy niemal identycznym kodzie i komentarzach linia obrony jest słabsza niż przy ogólnym podobieństwie koncepcji.

Od strony compliance często przyjmuje się zasadę: jeżeli koszt techniczny przepisanego rozwiązania jest niski, a spór prawny niepewny – priorytetem staje się redukcja ryzyka, nawet kosztem odrobiny pracy do wykonania.

Komunikacja z autorem projektu open source

Jeżeli zgłoszenie pochodzi od konkretnego autora lub maintainera projektu, sposób komunikacji może przesądzić o dalszym przebiegu sprawy. W praktyce:

• przydaje się krótkie, rzeczowe potwierdzenie otrzymania zgłoszenia i informacja, że sprawa jest weryfikowana,
• po wstępnej analizie technicznej można przedstawić kroki naprawcze: usunięcie lub modyfikacja fragmentu, ewentualnie dostosowanie się do warunków licencji (np. dołączenie informacji o autorach, licencji w dokumentacji),
• w razie rozbieżności co do oceny dobrze jest, by rozmowę dalej prowadziła osoba z przygotowaniem prawnym, a nie sam deweloper.

Część takich sytuacji kończy się polubownie, zwłaszcza gdy druga strona widzi, że firma nie ignoruje licencji i podejmuje sensowne kroki naprawcze.

Świadome korzystanie z AI: kiedy generować kod, a kiedy tylko się inspirować

W codziennej pracy z AI w tle największym wyzwaniem bywa nie samo narzędzie, lecz brak jasnej odpowiedzi na proste pytanie: „czy w tym konkretnym zadaniu wypuścić model na pełne generowanie, czy raczej użyć go jako doradcy?”.

Kryteria wyboru trybu pracy z AI w zależności od zadania

Uproszczony podział, który wielu zespołom ułatwia życie, to odróżnienie trzech poziomów ryzyka:

• Niskie ryzyko – testy jednostkowe, skrypty migracyjne, proste integracje z API, powtarzalny kod glue. Tu AI może generować większe fragmenty, a review skupia się na poprawności technicznej.
• Średnie ryzyko – moduły biznesowe, które są istotne dla produktu, ale nie stanowią jego unikalnego „sekretu”. AI bywa pomocna, ale programista świadomie modyfikuje strukturę i zapis, tak aby wynik był w praktyce nowym utworem.
• Wysokie ryzyko – kluczowe algorytmy, logika przewagi konkurencyjnej, elementy głęboko związane z regulacjami. Najczęściej stosuje się tu AI do eksperymentowania z koncepcjami (pseudokod, warianty architektury), a finalna implementacja powstaje ręcznie.

Ten podział nie wynika z przepisów, lecz z doświadczeń zespołów, które chcą godzić tempo z kontrolą nad tym, co stanie się z kodem za kilka lat – przy audycie, sprzedaży spółki lub wejściu na nowy rynek.

Scenariusze dla różnych typów organizacji

W praktyce inne ustawienie suwaka „ile AI” przyjmie jednoosobowy freelancer, a inne duży zespół w środowisku regulowanym. Różnice widać szczególnie w trzech typowych scenariuszach.

Mały zespół produktowy (np. SaaS)
Często priorytetem jest czas wejścia na rynek. AI staje się wtedy naturalnym wsparciem przy frontendzie, integracjach czy toolingach wewnętrznych. Jednocześnie newralgiczne fragmenty związane z unikalną logiką produktu są od początku oznaczane jako „manual only” – bez generowania długich bloków przez modele.

Zespół w dużej organizacji
Tu w grę wchodzi większa liczba interesariuszy: bezpieczeństwo, compliance, audyt wewnętrzny. Często przyjmuje się bardziej konserwatywne zasady: AI szeroko w prototypowaniu, mniej w kodzie produkcyjnym, chyba że narzędzie jest wdrożone w kontrolowanym środowisku (np. model on‑premise, trenowany wyłącznie na kodzie firmy).

Freelancer lub mała firma wykonawcza dla klienta
Tutaj ryzyko ma szczególny wymiar kontraktowy. Jeżeli umowa przewiduje pełne przeniesienie praw i gwarancję „braku obciążeń”, wykonawca może narzucić sobie wyższy standard ostrożności, bo to on będzie pierwszym adresatem ewentualnych roszczeń. AI jest częściej używana jako pomoc w analizie problemu, generowaniu przykładów testów, refaktoryzacji, a mniej do tworzenia całych modułów „od zera jednym promptem”.

Prosty zestaw pytań kontrolnych przed użyciem AI do kluczowego kodu

Zanim model wygeneruje krytyczny fragment, pomocne bywa zatrzymanie się na chwilę przy kilku pytaniach:

• czy ten kod będzie przedmiotem formalnych audytów (np. przed inwestycją, certyfikacją, wejściem na nowy rynek),
• czy jego ujawnienie lub konieczność otwarcia na zasadach licencji copyleft zaszkodziłaby przewadze konkurencyjnej,
• czy w razie problemów jesteśmy w stanie go przepisać w rozsądnym czasie, bez naruszenia kluczowych terminów.

Jeśli przy dwóch z trzech pytań odpowiedź brzmi „tak, byłby to duży problem”, AI lepiej potraktować w tej części systemu jako doradcę, a nie wykonawcę.

Najczęściej zadawane pytania (FAQ)

Czy mogę legalnie używać kodu wygenerowanego przez AI w komercyjnym projekcie?

Sam fakt, że kod wygenerowała AI, nie czyni go automatycznie nielegalnym ani „wolnym od licencji”. Kluczowe jest to, czy wygenerowany fragment jest na tyle podobny do istniejącego utworu (np. biblioteki na GPL/AGPL), że można mówić o naruszeniu praw autorskich lub warunków licencji. Im dłuższy i bardziej charakterystyczny snippet (cała funkcja, moduł, nietypowy algorytm), tym większe ryzyko.

W praktyce firmy uznają za względnie bezpieczne: krótkie, ogólne fragmenty (pętle, proste helpery, typowe kontrolery CRUD) oraz kod, który i tak jest standardem branżowym. Większą ostrożność stosuje się przy „magicznie” kompletnych modułach (np. autoryzacja, integracja z konkretnym API), bo tam kolizje z open source są bardziej prawdopodobne i łatwiejsze do wykrycia podczas audytu.

Czy kod wygenerowany przez AI może „zarazić” mój projekt licencją GPL lub AGPL?

Ryzyko „zarażenia” dotyczy nie tyle samego użycia AI, co faktycznego skopiowania fragmentów objętych copyleft (GPL, AGPL, czasem LGPL). Jeśli model wygeneruje kod praktycznie identyczny z biblioteką na GPL i włączysz go do swojego repozytorium, możesz w efekcie wprowadzić do projektu obowiązki tej licencji, np. konieczność udostępnienia kodu źródłowego.

W projektach komercyjnych stosuje się więc kilka bezpieczników: zakaz proszenia AI o „sklonowanie” konkretnego projektu open source, code review pod kątem rozpoznawalnych fragmentów, a w większych firmach – regularne skany licencyjne (SCA). Jeśli coś wygląda jak kopia popularnej biblioteki na GPL/AGPL, zwykle lepiej to przepisać lub zastąpić innym rozwiązaniem.

Kto odpowiada prawnie za naruszenia licencji, jeśli używam AI do generowania kodu?

Z perspektywy klienta czy sądu adresatem roszczeń jest ten, kto dostarczył gotowe oprogramowanie. Dla freelancera będzie to on sam (często z mocy umowy i oświadczeń o posiadaniu praw), dla software house’u – spółka, dla zespołu in-house – pracodawca. Dostawca narzędzia AI zazwyczaj ogranicza swoją odpowiedzialność w regulaminie i nie „przejmuje” ryzyka za sposób użycia wygenerowanego kodu.

W praktyce oznacza to, że to Ty (lub Twoja firma) musisz mieć proces: świadome zasady korzystania z AI, code review, ew. skanowanie licencyjne. Dopiero gdy szkoda już powstała, można rozważać dochodzenie roszczeń wobec dostawcy AI, ale to osobna, trudniejsza ścieżka, a nie realne zabezpieczenie na co dzień.

Czy mogę wkleić do promptu fragment cudzego kodu (np. na GPL) i poprosić AI o jego przerobienie?

Technicznie narzędzie zwykle na to pozwoli, ale prawnie wchodzisz w strefę podwyższonego ryzyka. Wklejenie licencjonowanego fragmentu i proszenie o „zmiany” czy „lepszą wersję” może prowadzić do powstania utworu zależnego, który wciąż podlega pierwotnej licencji (np. GPL/AGPL). Sama „przemielona” wersja nie staje się automatycznie wolna od ograniczeń.

Bezpieczniejsza praktyka to: opisywać problem na poziomie funkcjonalnym („potrzebuję funkcji walidującej X w taki sposób”), a nie kopiować gotowe implementacje z projektów, których licencji nie chcesz dotykać. Jeśli musisz pracować na istniejącym kodzie objętym copyleft, rób to świadomie w ramach zasad tej licencji, a nie „na skróty” przez AI.

Czy trening modeli AI na publicznych repozytoriach GitHuba jest legalny i czy ma to wpływ na mój projekt?

Spór o legalność trenowania modeli na kodzie z publicznych repozytoriów dopiero się kształtuje – toczy się kilka głośnych spraw sądowych. Dotyczy to głównie relacji: autorzy open source vs. dostawcy modeli. Użytkownik końcowy (programista, firma) zazwyczaj nie jest stroną tego sporu, chyba że output modelu narusza czyjeś prawa w sposób oczywisty.

Co wiemy praktycznie? Nawet jeżeli trening odbył się na bazie repozytoriów z ograniczającymi licencjami, nie oznacza to automatycznie, że każdy output jest naruszeniem. Twój realny problem zaczyna się w momencie, gdy wygenerowany kod jest rozpoznawalny jako kopia konkretnego projektu objętego licencją, której nie akceptujesz w swoim produkcie.

Jak ograniczyć ryzyko prawne przy korzystaniu z GitHub Copilot, ChatGPT czy innych asystentów AI?

W codziennym developmentcie stosuje się kilka prostych zasad: nie prosić AI o kopiowanie konkretnych projektów („zrób klon biblioteki X”), nie akceptować bezrefleksyjnie dużych bloków kodu, szczególnie dla złożonych modułów, oraz unikać wklejania poufnego lub licencjonowanego kodu do promptów, jeśli regulamin narzędzia na to nie pozwala.

W firmach dochodzą do tego środki organizacyjne: polityka użycia AI (co wolno, czego nie), obowiązkowe code review, w większych organizacjach – narzędzia SCA i ograniczenia techniczne (np. wtyczki AI wyłączone w repozytoriach z kodem krytycznym). Prosty test kontrolny dla programisty: czy byłbyś w stanie w razie kontroli wyjaśnić pochodzenie danego fragmentu i warunki jego użycia?

Czy krótkie snippet’y i „boilerplate” z AI też mogą naruszać licencje?

Krótkie, schematyczne fragmenty (np. pętla, prosty handler, typowy plik konfiguracyjny) zwykle nie spełniają progu twórczości, by korzystały z pełnej ochrony prawnoautorskiej. W takich przypadkach ryzyko licencyjne jest niskie, a podobieństwo między projektami wynika z natury standardów branżowych, a nie z kopiowania konkretnego utworu.

Problem pojawia się, gdy snippet przestaje być „boilerplate’em”, a staje się rozpoznawalną implementacją czegoś nietypowego, np. charakterystycznego algorytmu czy pełnego modułu złożonej integracji. Wtedy warto zadać sobie dwa pytania: czy da się wskazać konkretny projekt, z którego to pochodzi, oraz czy ten projekt ma licencję, której nie chcesz w swoim kodzie. Jeśli odpowiedź na oba brzmi „tak”, lepszą drogą jest samodzielne przepisanie funkcjonalności w oparciu o wymagania, a nie o gotowy kod.

Najważniejsze punkty

• Ryzyko licencyjne rośnie wraz z długością i „charakterystycznością” generowanego kodu – pojedyncze linie są zwykle mniej problematyczne niż całe funkcje, klasy czy moduły przypominające konkretne biblioteki open source.
• Asystenci AI mogą nieświadomie „przynieść” do projektu obowiązki licencji copyleft (np. GPL, AGPL), co w skrajnym przypadku może wymagać udostępnienia kodu źródłowego komercyjnej aplikacji lub zmian w modelu biznesowym.
• Najbardziej wrażliwe są scenariusze: kopiowanie całych funkcji/klas, generowanie gotowych modułów (autoryzacja, płatności, integracje), używanie specyficznych snippetów konfiguracyjnych oraz proszenie AI o „odtworzenie” funkcji z konkretnego projektu.
• Freelancerzy i małe zespoły, które w umowach przejmują pełną odpowiedzialność za ewentualne naruszenia licencji, są szczególnie narażeni – audyt klienta może wykryć podobieństwo do kodu na licencji copyleft i zablokować płatność lub wymusić kosztowną refaktoryzację.
• W dużych organizacjach konflikt interesów jest wyraźny: IT chce przyspieszyć development dzięki AI, a działy prawne i compliance blokują wdrożenie, dopóki nie powstaną jasne zasady użycia AI, w tym ograniczenia dotyczące przesyłania kodu i akceptowalnych licencji.
• Mniejsze ryzyko dotyczy ogólnych szablonów i standardowych wzorców (np. typowa pętla, prosty helper), gdzie trudno mówić o „utworze” konkretnego autora; kluczowe jest więc rozróżnienie między kodem generycznym a kodem odwzorowującym znaną implementację.

Źródła

• Directive 2009/24/EC on the legal protection of computer programs. European Union (2009) – Podstawy ochrony programów komputerowych w prawie UE
• Directive 2001/29/EC on the harmonisation of certain aspects of copyright. European Union (2001) – Ogólne zasady prawa autorskiego w środowisku cyfrowym
• Opinion 1/09 of the Copyright Office on AI and Copyright. U.S. Copyright Office (2023) – Stanowisko urzędu USA o ochronie utworów generowanych przez AI
• Berne Convention for the Protection of Literary and Artistic Works. World Intellectual Property Organization – Międzynarodowe minimum ochrony prawnoautorskiej
• GitHub Copilot FAQ and Terms for Business. GitHub – Warunki korzystania z Copilot, odpowiedzialność i kwestie licencyjne
• OpenAI Policies and Terms of Use for API and ChatGPT. OpenAI – Zasady użycia modeli, prawa do wygenerowanych treści
• Amazon CodeWhisperer User Guide and Licensing FAQ. Amazon Web Services – Opis działania CodeWhisperer i informacji o licencjach kodu
• The Open Source Definition. Open Source Initiative – Definicja open source i podstawowe kryteria licencyjne
• GPL-3.0 License Text. Free Software Foundation (2007) – Pełna treść licencji GPLv3, obowiązki copyleft
• OSSRA – Open Source Security and Risk Analysis Report. Synopsys – Raport o ryzykach licencyjnych i audytach kodu w projektach komercyjnych