Złudzenie własności kodu. O ryzykach IP w transakcjach M&A

Każda transakcja M&A dotycząca oprogramowania, w której uczestniczyłem – po którejkolwiek stronie stołu – opierała się na założeniu, którego nikt nigdy nie poddał weryfikacji: że nabywany kod musi być czyjąś własnością.

W tym fundamentalnym założeniu tkwiłem do czasu, gdy odkryłem dla siebie vibe coding. Po zachwycie nad możliwościami tworzenia własnych, działających programów, jako prawnik przeszedłem naturalnie do pytania o to, kto i czego jest tutaj właścicielem. Niepokojącą, choć początkowo odrzucaną myślą było, że mój sprawnie działający program komputerowy może nie mieć żadnego właściciela w sensie formalnym.

Przegląd dostępnych źródeł – w tym z wykorzystaniem narzędzi AI, które sam zbudowałem – wraz z analizą orzecznictwa sądów europejskich i polskich oraz poglądami prawników z obu stron Atlantyku utwierdziły mnie w przekonaniu, że problem, jakkolwiek złożony, jest na obecnym etapie interpretowany w kierunku braku jakichkolwiek praw autorskich do kodu generowanego przez modele językowe.

Te rozważania zawiodły mnie w kierunku mojej głównej specjalizacji – doradztwa transakcyjnego. W wielu transakcjach uczestniczyłem, zarówno po stronie kupującej jak i sprzedającej (buy-side i sell-side), gdzie najważniejszym lub przynajmniej bardzo istotnym aktywem było oprogramowanie. Podejście było, z transakcyjnego punktu widzenia, dość proste. Po stronie kupującej badamy klauzule przeniesienia praw autorskich, zakres obowiązków w umowach o pracę, postanowienia umów licencyjnych. Sprawdzamy pola eksploatacji. Sprawdzamy, czy wszystko zostało opłacone. Na końcu odbieramy oświadczenia i zapewnienia, że targetowi przysługują prawa autorskie do oprogramowania lub prawa wynikające z licencji. Po stronie sprzedającej ten proces był zasadniczo analogiczny – sprzedający bez zastanowienia składali zapewnienia dotyczące praw do oprogramowania, bo mieli ku temu podstawę: wytwarzali je wewnętrznie lub nabywali, co potwierdzały stosowne umowy.

I dokładnie w tym momencie zagadnienie zaczyna się komplikować. Na ile powyższy model pozostaje adekwatny dziś?

Vibe coding wszedł do słownika w lutym 2025 roku, gdy Andrej Karpathy – znany badacz AI – przyznał publicznie, że nie pisze już kodu samodzielnie. Nazwał nowy styl pracy: promptujesz, AI koduje, ty weryfikujesz wynik. Dziś pojęcia AI-developera, AI-startupu przedzierają się nie tylko do świadomości, ale i do biznesowej rzeczywistości. Firmy oferujące produkty powstałe dzięki AI są codziennością. Kodujące agenty – oprogramowanie zdolne do generowania całych baz kodu na podstawie poleceń w języku naturalnym – stały się pełnoprawnymi narzędziami pracy programistów.

Według badań opublikowanych przez Sonar ok. 42% oprogramowania jest już tworzone z wykorzystaniem sztucznej inteligencji, a udział ten ma wzrosnąć do 65% w 2027 r. W 2025 r. 73% deweloperów używających AI stosowało ją przy tworzeniu kodu produkcyjnego do zastosowań konsumenckich, a 58% – do zastosowań biznesowych. Jared Friedman, partner zarządzający Y Combinator – jednego z najbardziej renomowanych akceleratorów startupów na świecie – stwierdził, że 25% startupów z naboru YC Winter 2025 miało bazę kodu wygenerowaną w 95% przez AI, przy czym w większości przypadków twórcy ci potrafili kodować samodzielnie – po prostu wybrali AI jako narzędzie pracy.

Mamy więc realne biznesy, z realnie działającymi rozwiązaniami, generujące realne obroty, spełniające wszystkie definicje dobrego celu inwestycyjnego, których jednak dotyczy fundamentalne ryzyko braku własności kodu.

Czy jednak jest to zjawisko nowe? Czy już od co najmniej 10 lat wizja programisty ręcznie piszącego każdą linijkę kodu nie jest bardziej romantyczna niż rzeczywista? Czy narzędzia używane jeszcze przed erą modeli językowych – frameworki, biblioteki, generatory kodu, powielanie fragmentów z serwisów takich jak Stack Overflow – de facto nie prowadziły do tego, że kod był w większej mierze kompilowany niż pisany, co przynajmniej poddaje w wątpliwość jego twórczy charakter wymagany przez prawo autorskie?

Na to pytanie nie odpowiem. Ale zadam je głośno. Bo z perspektywy transakcyjnej nie ma znaczenia czy kiedyś jakiś sąd udzieli na nie odpowiedzi – liczy się to, że odpowiedź mogłaby brzmieć „nie” i mieć wpływ na całą dekadę zamkniętych już transakcji M&A dotyczących oprogramowania.

Pozostaje pytanie, co z tą świadomością ryzyk prawnych – wyrosłą na gruncie własnego korzystania z narzędzi AI – zrobić ma prawnik transakcyjny siedzący przy europejskim stole negocjacyjnym? Uważam, że na pewno nie powinien zagadnienia ignorować.

Badanie tematu prowadzi do wniosku, że biznes ze Stanów Zjednoczonych ma łatwiejsze, choć wcale niełatwe zadanie. Prawo amerykańskie dopuszcza ochronę patentową rozwiązań programistycznych, o ile spełniają wymogi nowości i technicznej istotności. Zagadnienie jest złożone – orzeczenie Sądu Najwyższego w sprawie Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), istotnie zawęziło zakres tej ochrony, wymagając, aby wynalazek zawierał element inwencji wykraczający poza abstrakcyjną ideę. Precyzyjny zakres dostępnej ochrony pozostaje sporny. Niemniej – instrument istnieje.

Europejski biznes stoi w znacznie trudniejszej sytuacji. Europejska Konwencja Patentowa wyklucza programy komputerowe jako takie z zakresu zdolności patentowej. Europejski Urząd Patentowy wypracował co prawda doktrynę „charakteru technicznego” i „dalszego efektu technicznego”, która w wąskich przypadkach dopuszcza ochronę patentową rozwiązań programistycznych. W praktyce jednak ochrona ta jest niedostępna dla zdecydowanej większości europejskich firm – w szczególności dla tych, których produkty powstają z wykorzystaniem narzędzi AI.

Tym samym wyłączenie ochrony prawnoautorskiej generowanego kodu pociąga za sobą w praktyce brak prawa, które mogłoby być przedmiotem obrotu. Powstaje paradoks działającego biznesu generującego obroty i zyski, lecz nieposiadającego substratu, który byłby zbywalny. Brak ochrony prawnoautorskiej kodu powoduje, że każdy może go skopiować w całości i używać dokładnie tak samo jak pierwotny użytkownik.

Większość znanych mi umów na wytworzenie oprogramowania to umowy o dzieło, których celem jest stworzenie kodu o określonych właściwościach i przeniesienie majątkowych praw autorskich do tego kodu na zamawiającego. Wynagrodzenie dewelopera jest najczęściej ryczałtowe – obejmuje zarówno pracę programistyczną, jak i przeniesienie praw autorskich, przy czym element wynagrodzenia za przeniesienie praw rzadko bywa wyodrębniony kwotowo. Najczęstsza formuła brzmi: „wynagrodzenie z tytułu przeniesienia praw autorskich zawiera się w wynagrodzeniu opisanym w niniejszej umowie”. W Polsce zaawansowane umowy koncentrują się na przenoszeniu praw majątkowych na nowych polach eksploatacji, zakazie wykonywania autorskich praw osobistych, prawach pokrewnych i zależnych. Cała architektura kontraktowa kręci się wokół praw autorskich i nieweryfikowanego założenia, że kod jest unikalnym utworem będącym wytworem ludzkiej twórczości.

A co, jeśli deweloper wygenerował kod lub jego fragment przy użyciu agenta AI i nie jest on utworem, a więc nie jest przedmiotem żadnych praw autorskich? Co, jeśli konkretny pracownik – nawet bez wiedzy pracodawcy, w ramach tzw. shadow AI, czyli korzystania z narzędzi AI bez autoryzacji pracodawcy – stworzył fragment kodu przy użyciu takiego agenta? Wreszcie co, jeśli cały kod został skompilowany, a nie napisany?

Większość systemów europejskich, w tym prawo polskie, inkorporuje ogólną regułę wywodzącą się z cywilnego prawa rzymskiego: nemo plus iuris in alium transferre potest, quam ipse habet – nikt nie może przenieść na drugiego więcej praw niż sam posiada.

Zasada ta oznacza, że sam fakt zawarcia umowy o przeniesienie praw – nawet spełniającej wszystkie kryteria ważności – nie gwarantuje przeniesienia tych praw, jeśli zbywca ich nie posiadał. Tym bardziej jeśli prawa te nigdy nie powstały.

Istnienie umowy o przeniesienie praw autorskich majątkowych do oprogramowania nie gwarantuje zatem – w dzisiejszym stanie techniki – że prawa te zostały w istocie przeniesione. Najlepsze oświadczenia i zapewnienia zbywcy nic tu nie zmienią.

Jest i dobra wiadomość: nabywca korzystający z generowanego kodu, do którego praw autorskich nie nabył, bo prawa te nigdy nie powstały, nie narusza cudzych praw autorskich – bo takich praw po prostu nie ma. Może więc z takiego kodu korzystać. Nie posiada jednak istotnego atrybutu, jakim jest ochrona kodu względem wszystkich (erga omnes) – czyli możliwości zakazania innym czynienia tego samego.

Nie oznacza to jednak, że zbywca nie ponosi w tej sytuacji żadnej odpowiedzialności. Zobowiązał się przenieść prawa, które nie istniały, i poniesie konsekwencje niewykonania umowy. Ale ta odpowiedzialność jest słabą pociechą dla nabywcy, który nie stał się właścicielem aktywa, które miało być dla niego kluczową wartością.

Los prawny takich umów jest również niepewny z innego powodu. Europejskie systemy prawne powszechnie inkorporują koncepcję kauzalności czynności prawnych – zasadę, że ważność umowy zależy od istnienia prawnie doniosłej przyczyny jej zawarcia, tzw. iusta causa. Mówiąc prościej: jeśli prawną przyczyną zawarcia umowy było nabycie czegoś, co nie istnieje, sama umowa może okazać się nieważna.

Skoro umowy o wytworzenie oprogramowania koncentrują się na przeniesieniu praw autorskich, to prawnie doniosłą przyczyną ich zawarcia było oczekiwanie, że w ich wykonaniu zostaną wytworzone utwory objęte ochroną prawnoautorską. Jeśli kod nie jest takim utworem – bo ze względu na metodę jego wytworzenia ochrona ta jest konstrukcyjnie wykluczona – pada pytanie o ważność całej umowy. Dramatycznie rozciąga to ryzyka dewelopera: nie tylko odpowie on odszkodowawczo za nieprzeniesienie praw, ale może zostać całkowicie pozbawiony wynagrodzenia za pracę, którą rzeczywiście wykonał.

Skoro bowiem umowa jest nieważna, strony powinny zwrócić sobie wzajemnie to, co świadczyły. Co dokładnie? Odpowiedź wydaje się oczywista: nabywca zwraca nośnik, dane dostępowe do repozytorium, dokumentację. Tu jednak ujawnia się paradoks – skoro prawa autorskie nigdy nie powstały, nabywca może zatrzymać pełną kopię kodu i nadal z niego korzystać, nie naruszając niczyich praw. Zwraca opakowanie. Zachowuje treść. Deweloper tymczasem zwraca wynagrodzenie – w całości – za pracę, która została rzeczywiście wykonana.

Ryzyka są zatem zasadnicze. Transakcyjnie mogą prowadzić do zablokowania transakcji, uruchomienia klauzul odszkodowawczych, ustanowienia depozytu escrow, a nawet do obniżenia wyceny – wszędzie tam, gdzie wartość targetu opiera się nie tylko na wskaźnikach finansowych, ale na perspektywach związanych z oprogramowaniem.

Czy to jest luka w prawie? Raczej nie. Prawo dość precyzyjnie odpowiada i klasyfikuje opisany stan. Odrębną kwestią jest, czy powinno go regulować inaczej. De lege ferenda sytuacja wymaga interwencji ustawodawczej lub jasnego kierunku orzecznictwa korygującego interpretację przepisów poprzez dostosowanie jej do bieżącego stanu techniki. Niestety instrumenty takie jak unijny AI Act nie dotykają tej kwestii w żadnej mierze.

Warto zapytać, czy ochrona prawnoautorska jest w ogóle właściwym instrumentem dla oprogramowania. Vibe coding – ale i wcześniejsze praktyki – w dużej mierze odwartościowały kod jako utwór. Jego wartość leży dziś w procesie, który automatyzuje, w rozwiązaniu, które dostarcza, i w architekturze, którą optymalizuje. Nie w tym, jak został napisany – w tym, co robi.

Jeśli powszechnie sugerowanym promptem na platformach do vibe codingu jest „odtwórz popularną platformę społecznościową”, oznacza to, że wartość tej platformy nie tkwi już w sposobie zapisu kodu – te same funkcje można odtworzyć na wiele sposobów, w różnych językach, różnymi narzędziami. Wartość ta tkwi bardziej w ekosystemie biznesowym: jaką usługę oferuje, komu i jaki przychód z tego generuje. Rzeczywista przewaga konkurencyjna to know-how i pozycja rynkowa – nie sposób wyrażenia kodu.

Praw autorskich nie należy zatem fetyszyzować jako jedynego narzędzia ochrony oprogramowania. Były wygodne – dawały ochronę powszechną, również dla kodu ujawnionego publicznie. Chronią jednak wyłącznie określony sposób wyrażenia, nie zaś rozwiązania i idee, które kod ucieleśnia.

Prawo nie pozostawia tej kwestii bez odpowiedzi. Tyle że odpowiedź jest inna, niż przez lata zakładała praktyka transakcyjna i wymaga innego podejścia. Szukać jej należy w ochronie know-how, nie w prawie autorskim.

Ochrona know-how bazuje głównie na tajemnicy przedsiębiorstwa. Istnieje dopóty, dopóki know-how jest chronione i nie stanie się publicznie znane. Nawet generowany kod może korzystać z tej ochrony – o ile jest odpowiednio zabezpieczony. Ochrona tajemnicy przedsiębiorstwa powstaje z mocy prawa, ale wymaga aktywnego jej utrzymywania: zarówno środkami prawnymi, jak i technicznymi. Ujawnienie przedmiotu tajemnicy – nawet wskutek działania nielegalnego – powoduje utratę ochrony.

Ochrona generowanego kodu jako know-how nie jest rozwiązaniem idealnym, ale de lege lata daje określoną i powszechnie akceptowaną ochronę prawną temu, co w praktyce może stanowić istotną część substancji biznesowej będącej przedmiotem transakcji M&A.

Powyższe konstatacje wymagają przeformatowania myślenia o IP w transakcjach M&A. Tradycyjne podejście do kodu jako przedmiotu praw autorskich pozostaje zasadne – duża jego część, zwłaszcza powstała wcześniej, może w pełni korzystać z tej ochrony. Nie powinno to być jednak jedyne podejście.

Praktyka transakcyjna musi nadążyć za technologią. Poniżej kilka konkretnych wskazówek.

Po stronie sprzedającego

Zadbaj po pierwsze o to, aby regulamin korzystania z narzędzi do generowania kodu (T&C) zawierał postanowienia, z których wynika, że dostawca nie rości sobie żadnych praw do wygenerowanych treści. Po drugie – by pracownicy korzystali wyłącznie z narzędzi przez ciebie autoryzowanych. Po trzecie – by pracownicy i współpracownicy podpisali klauzule o nieroszczeniu sobie praw do generowanego kodu. Ta ostatnia kwestia jest istotna: w prawie polskim i wielu innych porządkach kod będący przedmiotem praw autorskich, powstały w ramach stosunku pracy, automatycznie przechodzi na pracodawcę. Reguła ta nie dotyczy jednak kodu generowanego.

Zadbaj o ochronę swoich tajemnic: miej podpisane umowy o zachowaniu poufności (NDA), wdrożone polityki dostępu i techniczne zabezpieczenia. Samo prywatne repozytorium nie wystarczy, jeśli ktoś może uzyskać do niego dostęp – legalnie lub nie – albo jeśli dane z niego wyciekną. Prowadź rejestr: kiedy dany kod został wygenerowany, przez kogo, jakim narzędziem, na jakich warunkach, gdzie jest przechowywany. Chroń przede wszystkim know-how – opisy procesów, rozwiązań, metodologie korzystania z narzędzi. To jest twój prawdziwy wyróżnik.

Po stronie kupującego

Miej świadomość, że duża część nabywanego oprogramowania może nie być przedmiotem ochrony prawnoautorskiej – i nie wpadaj z tego powodu w panikę. Zweryfikuj, czy sprzedający zadbał o powyższe, sprawdź, czy nie doszło do ujawnienia know-how. Oceń technicznie, w jakim zakresie unikalne i istotne biznesowo procesy są ujawniane poprzez sam sposób działania oprogramowania, publicznie dostępny kod lub interfejs użytkownika. Odbierz oświadczenia i zapewnienia adekwatne do sytuacji i rozważ klauzule dotyczące narzędzi AI, zgodności z regulaminami, utrzymania tajemnicy przedsiębiorstwa oraz zakresu ewentualnych praw autorskich.

Podsumowanie

Czy taki due diligence zabezpieczy cię w 100% przed ryzykiem? Na pewno nie. Ale da ci dokładnie to, czym due diligence jest: standard należytej staranności pozwalający w możliwie największym stopniu zidentyfikować i zarządzić ryzykiem prawnym dla twojej inwestycji.

Czy opisana sytuacja zmienia paradygmat transakcyjny, gdy istotnym aktywem jest oprogramowanie? Nie nazwałbym tego zmianą paradygmatu. Prawo działa tu precyzyjnie – po prostu inaczej, niż przez lata zakładaliśmy. Wektor ochrony musi się przesunąć: z praw autorskich w kierunku know-how, z kodu w kierunku procesów i metodologii, które go wytworzyły. Transakcyjna dokumentacja musi za tym nadążyć. A pytanie „kto jest właścicielem tego kodu?” powinno paść przy każdym stole negocjacyjnym – zanim transakcja się zamknie, nie po.