Open source i własność intelektualna w Tech Due Diligence: ukryte ryzyka prawne, które ujawniają się dopiero po transakcji

W skrócie Większość technicznych badań due diligence koncentruje się na architekturze, jakości kodu, bezpieczeństwie i zespole. Własność intelektualna do oprogramowania często schodzi na dalszy plan, ponieważ leży na styku części technicznej i prawnej, a żadna z nich nie czuje się za nią w pełni odpowiedzialna. Tymczasem problemy z IP należą do najdroższych niespodzianek po zamknięciu transakcji: licencja copyleft w kluczowym module, kod napisany przez współpracowników B2B bez skutecznego przeniesienia praw czy rosnący udział kodu wygenerowanego przez AI o niejasnym statusie prawnym. W tym artykule pokazujemy, gdzie zwykle kryją się te ryzyka, jak je zbadać w trakcie due diligence i jak przełożyć ustalenia na warunki umowy, zamiast odkrywać je dopiero przy integracji.

Dlaczego ryzyka IP wymagają osobnego obszaru badania

W typowej transakcji prawnicy analizują umowy, znaki towarowe i patenty, a zespół techniczny ocenia kod. Oprogramowanie jako przedmiot własności intelektualnej wypada dokładnie w lukę między tymi dwoma obszarami. Prawnicy rzadko analizują drzewa zależności, a inżynierowie rzadko czytają umowy o pracę czy kontrakty ze współpracownikami.

Ustalenia dotyczące IP różnią się od większości kwestii technicznych przede wszystkim momentem, w którym wychodzą na jaw, i skalą skutków. Dług technologiczny spowalnia realizację roadmapy, natomiast wada prawna może podważyć wartość aktywa, za które inwestor właśnie zapłacił. Typowe konsekwencje to:

• konieczność udostępnienia zastrzeżonego kodu źródłowego na zasadach licencji copyleft,
• kosztowna przebudowa, ponieważ danego komponentu nie wolno używać komercyjnie,
• spory z byłymi współpracownikami lub założycielami o prawa do kodu,
• naruszenie oświadczeń i zapewnień z umowy sprzedaży, które prowadzi do roszczeń długo po zapłacie ceny.

Takie problemy rzadko pojawiają się w pierwszych tygodniach po closingu. Zwykle wychodzą na jaw wtedy, gdy nabywca chce zrobić coś nowego: pozyskać klienta korporacyjnego z rygorystycznym procesem zakupowym, przygotować kolejne wyjście z inwestycji albo zintegrować produkt z większą platformą.

Nie każda licencja open source oznacza to samo

Niemal każdy współczesny produkt cyfrowy w dużej mierze opiera się na open source. Samo w sobie nie jest to problemem. Poziom ryzyka zależy od tego, jakie licencje są wykorzystywane, w jaki sposób używany jest kod i jak produkt trafia do klientów.

W praktyce dwie kwestie są szczególnie często źle rozumiane.

Po pierwsze, tzw. „luka SaaS” nie obejmuje wszystkiego. Wiele zespołów zakłada, że obowiązki wynikające z GPL nigdy ich nie dotyczą, ponieważ nie dystrybuują oprogramowania. W przypadku GPL i czystego modelu SaaS jest to w dużej mierze prawda, ale nie w przypadku AGPL. Nie dotyczy to też komponentów dostarczanych klientom, takich jak instalacje on-premise, aplikacje mobilne, klienty desktopowe, SDK czy oprogramowanie wbudowane w urządzenia.

Po drugie, licencje zmieniają się w czasie. W ostatnich latach kilka popularnych projektów infrastrukturalnych przeszło z licencji open source na bardziej restrykcyjne licencje typu source-available. Dobrze znanym przykładem jest przejście HashiCorp na Business Source License w 2023 roku. Zależność, która w chwili jej dodania nie budziła zastrzeżeń, w aktualnej wersji może podlegać zupełnie innym warunkom.

Gdzie naprawdę kryją się ryzyka

Uporządkowana lista bezpośrednich zależności nie oznacza jeszcze uporządkowanego kodu. Z naszego doświadczenia wynika, że najistotniejsze ustalenia pochodzą zwykle z mniej oczywistych miejsc.

Zależności przechodnie. Biblioteka na licencji permisywnej może pociągać za sobą komponenty na znacznie bardziej restrykcyjnych warunkach. Bez analizy pełnego drzewa zależności pozostają one niewidoczne.

Skopiowane fragmenty kodu. Kod przeniesiony z publicznych repozytoriów, forów czy poradników nie pojawia się w żadnym manifeście pakietów. Aby go wykryć, trzeba skanować kod na poziomie fragmentów, a nie tylko analizować manifesty.

Biblioteki wkopiowane do repozytorium i forki. Biblioteki skopiowane bezpośrednio do repozytorium, często zmodyfikowane wiele lat temu, tracą widoczny związek z projektem źródłowym i jego licencją.

Komponenty komercyjne. Płatne biblioteki, SDK, fonty i zbiory danych mają własne warunki licencyjne. Niektóre są przypisane do konkretnego podmiotu, liczby użytkowników lub modelu wdrożenia i mogą nie przetrwać zmiany kontroli nad spółką bez renegocjacji.

Brakujące informacje licencyjne. Nawet licencje permisywne wymagają oznaczenia autorstwa. Braki w plikach z informacjami licencyjnymi zwykle łatwo uzupełnić, ale wiele mówią o dojrzałości procesów compliance w firmie.

Do kogo naprawdę należy kod?

Open source to tylko połowa obrazu. Druga połowa to pytanie, czy spółka rzeczywiście dysponuje prawami do kodu, który sama wytworzyła. Luki w łańcuchu praw są częste w szybko rosnących firmach, zwłaszcza tych, które korzystały z freelancerów, software house’ów lub z pracy założycieli jeszcze przed założeniem spółki.

W polskich realiach szczególnie ważne jest rozróżnienie form współpracy.

Pracownicy etatowi. Zgodnie z art. 74 ust. 3 ustawy o prawie autorskim i prawach pokrewnych autorskie prawa majątkowe do programu komputerowego stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej. Warto jednak sprawdzić, czy kod rzeczywiście powstał w ramach obowiązków pracowniczych i czy umowy nie zawierają odmiennych postanowień.

Współpracownicy B2B, umowy cywilnoprawne i software house’y. Tu żadne automatyczne nabycie praw nie następuje. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53) i obejmuje wyłącznie pola eksploatacji w niej wyraźnie wymienione (art. 41 ust. 2). Ogólnikowe sformułowania typu „wszelkie prawa do rezultatów prac” to jedna z najczęstszych przyczyn wadliwego łańcucha praw. Warto też zweryfikować postanowienia dotyczące utworów zależnych oraz możliwości dalszego przeniesienia praw na nabywcę.

Założyciele. Czy kod powstały przed rejestracją spółki został do niej skutecznie wniesiony lub przeniesiony?

Projekty grantowe i współpraca z uczelniami. Czy istnieją umowy, które zapewniają podmiotom trzecim prawa do części technologii?

Ma to duże znaczenie w kontekście rynku polskiego, gdzie model B2B jest w branży IT powszechny. Dla inwestora oznacza to, że sama lista osób zatrudnionych w spółce nie wystarczy: trzeba sprawdzić, na jakiej podstawie każda z nich współtworzyła kod. Kwestia ta jest równie istotna dla zagranicznych nabywców, zwłaszcza z Niemiec i Austrii, gdzie przepisy są zbudowane inaczej, a różnice w podejściu do przeniesienia praw nie zawsze są oczywiste dla zespołu prowadzącego transakcję.

Kod generowany przez AI: nowa kategoria ryzyk

W 2026 roku trudno znaleźć zespół programistyczny, który nie korzysta z asystentów AI. Pojawiają się więc pytania, których jeszcze kilka lat temu nie było w żadnej liście kontrolnej due diligence.

Ochrona prawnoautorska może być ograniczona. Prawo polskie, podobnie jak prawo innych państw UE, chroni przejawy działalności twórczej o indywidualnym charakterze, a za twórcę uznaje się człowieka. Treści wygenerowane wyłącznie przez AI co do zasady nie są więc chronione, natomiast wkład człowieka, taki jak dobór, układ czy istotne przetworzenie, może już taką ochronę uzasadniać. W większości produktów nie stanowi to pilnego problemu, ponieważ programiści weryfikują, modyfikują i integrują propozycje AI. Ryzyko rośnie tam, gdzie większe, zamknięte moduły powstały niemal bez twórczego udziału człowieka. To, co nie jest chronione, może bowiem wykorzystać także konkurencja.

Podpowiedzi mogą powielać kod objęty licencją. Narzędzia AI czasami generują kod bardzo zbliżony do danych treningowych, w tym kod na licencjach copyleft. Wiele narzędzi w wersjach korporacyjnych oferuje filtry blokujące podpowiedzi zgodne z publicznym kodem, ale działają one tylko wtedy, gdy są włączone.

Warunki korzystania i przetwarzania danych bywają różne. Wersje konsumenckie narzędzi AI często mają inne zasady dotyczące praw do wygenerowanych treści i wykorzystania wprowadzanych danych niż plany korporacyjne. Jeżeli programiści wklejali zastrzeżony kod lub dane klientów do niezatwierdzonych narzędzi, może to dodatkowo rodzić pytania o ochronę tajemnicy przedsiębiorstwa i zgodność z RODO.

Przy ocenie spółki kluczowe nie jest więc pytanie, czy zespół korzysta z AI, lecz czy korzysta z niej w sposób kontrolowany i udokumentowany. Warto sprawdzić, czy spółka ma:

• listę zatwierdzonych narzędzi AI objętych warunkami korporacyjnymi,
• włączone filtry wykrywające zgodność z publicznym kodem,
• pisemną politykę określającą, jaki kod i jakie dane można udostępniać narzędziom AI,
• standardy code review, które obejmują w równym stopniu kod pisany ręcznie i kod tworzony z pomocą AI.

Zespół, który pewnie odpowiada na te pytania, zwykle ma też dojrzałą kulturę inżynierską w ogóle. Zespół, który nie potrafi na nie odpowiedzieć, często ma podobne luki także w innych obszarach. Jak wdrożyć takie zasady w praktyce, opisujemy na stronie poświęconej wykorzystaniu AI w pracy zespołów programistycznych.

Jak zbadać ryzyka IP w trakcie due diligence

Skuteczna ocena IP łączy analizę automatyczną z przeglądem dokumentów i ukierunkowanymi rozmowami z zespołem. W praktyce sprawdza się następujące podejście.

1. Przygotowanie wykazu komponentów oprogramowania (SBOM). Narzędzia do analizy składu oprogramowania (SCA) pozwalają stworzyć pełny spis zależności bezpośrednich i przechodnich wraz z informacją o licencjach. Standardowe formaty, takie jak SPDX czy CycloneDX, ułatwiają ponowne wykorzystanie wyników. Wkrótce będzie to istotne nie tylko przy transakcjach: unijny akt o cyberodporności (Cyber Resilience Act) wprowadza obowiązki związane z SBOM dla produktów z elementami cyfrowymi, a większość z nich zacznie obowiązywać od grudnia 2027 roku. Firmy, które na stałe włączyły skanowanie licencji i generowanie SBOM do procesów CI/CD i utrzymania środowisk chmurowych, są znacznie lepiej przygotowane zarówno na transakcję, jak i na nowe regulacje.

2. Skanowanie kluczowych repozytoriów na poziomie fragmentów kodu. Warto skoncentrować się na produkcie podstawowym, a nie na każdym wewnętrznym narzędziu. Celem jest wykrycie skopiowanego kodu bez informacji o licencji.

3. Zestawienie licencji z modelem dystrybucji. Ta sama licencja może być bez znaczenia w usłudze backendowej i bardzo problematyczna w aplikacji mobilnej lub instalacji on-premise. Ustalenia zawsze trzeba oceniać w kontekście.

4. Weryfikacja dokumentów potwierdzających łańcuch praw. Historię commitów należy porównać z listą pracowników i współpracowników, z którymi zawarto skuteczne umowy przenoszące prawa. Osoby widoczne w kodzie, ale nieobecne w dokumentacji umownej, to natychmiastowy sygnał ostrzegawczy.

5. Przegląd licencji komercyjnych pod kątem klauzul change of control. Należy zidentyfikować komponenty, których licencja wygasa w razie przejęcia spółki albo wymaga wówczas zgody licencjodawcy.

6. Ocena wykorzystania AI i zasad nadzoru nad nim. Warto porozmawiać z osobami odpowiedzialnymi za technologię, sprawdzić konfigurację narzędzi i ustalić, czy polityka dotycząca AI istnieje i czy jest rzeczywiście stosowana.

Od ustaleń do warunków transakcji

Nie każde ustalenie przekreśla transakcję. Celem due diligence w obszarze IP nie jest idealny kod, lecz adekwatna cena i skuteczne zabezpieczenie nabywcy. Ustalenia można zwykle podzielić na trzy grupy.

Niska waga: do naprawy po closingu. Brakujące informacje licencyjne, nieaktualne pliki licencyjne i drobne luki związane z licencjami permisywnymi. Te kwestie powinny trafić do planu pierwszych 100 dni.

Średnia waga: do naprawy przed closingiem lub do uwzględnienia w cenie. Komponenty na licencjach słabego copyleftu, których sposób użycia może rodzić obowiązki, licencje komercyjne wymagające renegocjacji lub brak umów przenoszących prawa z kilkoma byłymi współpracownikami. Typowe instrumenty to warunki zawieszające closing, szczególne klauzule indemnifikacyjne oraz uwzględnienie szacowanych kosztów naprawy w wycenie.

Wysoka waga: dotyczy samej tezy inwestycyjnej. Kod na licencji silnego lub sieciowego copyleftu w kluczowych, zastrzeżonych modułach dystrybuowanego produktu albo istotne części kodu o nieuregulowanym statusie prawnym. Takie ustalenia mogą uzasadniać znaczącą korektę ceny, rachunek escrow, rozszerzone oświadczenia i zapewnienia, a w skrajnych przypadkach rezygnację z transakcji. Warto pamiętać, że ubezpieczyciele W&I zazwyczaj wyłączają z ochrony ryzyka znane z due diligence, dlatego tym ważniejsze są szczególne klauzule indemnifikacyjne.

Kluczowe jest oszacowanie kosztu naprawy: ile tygodni pracy zespołu zajmie zastąpienie problematycznego komponentu, ponowna implementacja modułu czy uzyskanie brakujących umów przenoszących prawa? Taka wycena zamienia abstrakcyjne ryzyko prawne w liczbę, o której obie strony mogą rzeczowo negocjować. Jeżeli naprawa wymaga przebudowy większej części produktu, AI Refactoring Assessment pozwala realnie oszacować jej zakres jeszcze przed podpisaniem umowy, a samą przebudowę można zaplanować w ramach rozwoju produktów i aplikacji, bez zatrzymywania bieżącej roadmapy.

Uporządkowane prawa są częścią przedmiotu transakcji

Nabywca płaci za oprogramowanie, ponieważ zakłada, że będzie mógł swobodnie z niego korzystać i je rozwijać. Jeżeli status prawny kodu jest niejasny albo licencje ograniczają przyszłe plany, część tej wartości po prostu nie istnieje. Dobra wiadomość jest taka, że większość problemów z IP da się wykryć przed podpisaniem umowy, a wiele z nich można tanio naprawić, jeśli zostaną zidentyfikowane odpowiednio wcześnie.

Najskuteczniejsze podejście traktuje IP jako wspólny obszar badania technicznego i prawnego, oparty na automatycznym skanowaniu, przeglądzie umów i rzetelnej ocenie tego, jak zespół korzysta z AI. Dla sprzedających to samo badanie jest jednym z najprostszych sposobów, aby ochronić wycenę, zanim rozpocznie się due diligence po stronie kupującego. Jeśli przygotowujesz transakcję lub wyjście z inwestycji, porozmawiajmy o tym, jak w praktyce wygląda nasze techniczne due diligence.

Artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej. Kwestie licencyjne oraz dotyczące praw do oprogramowania należy zawsze konsultować z wykwalifikowanym doradcą prawnym właściwym dla danej jurysdykcji.

‍