Open source w Twoim produkcie. Jak uporządkować licencje, zanim zrobi to inwestor.

Twój kod to najcenniejsze aktywo spółki. Prawdopodobnie nie wiesz jednak, z czego w większości się składa — ani na jakich warunkach masz prawo go używać. Dowiesz się tego dokładnie w tygodniu, w którym inwestor otworzy data room albo klient enterprise przyśle kwestionariusz dotyczący własności intelektualnej. Wtedy jest najdroższy moment na odkrywanie, że biblioteka na licencji copyleft siedzi w sercu produktu.

Licencje open source to nie techniczny detal. To źródło zobowiązań prawnych ciążących na Twojej spółce i jej produkcie. Każda z nich nakłada własny zestaw obowiązków — od atrybucji twórców, przez udostępnienie kodu źródłowego, po klauzule patentowe. Naruszenie tych warunków może skutkować utratą tytułu prawnego do komponentu, roszczeniami z tytułu praw autorskich i — co najczęściej boli najbardziej — zablokowaniem rundy inwestycyjnej lub kontraktu enterprise.

W tym artykule przejdę przez konkretne ryzyka, które open source w produkcie generuje dla spółek technologicznych, i pokażę, jak je uporządkować — bez zatrzymywania roadmapy produktowej i bez wykładu o copyleft.

Podstawowe pojęcia, zanim przejdziemy dalej

Zanim zajmiemy się ryzykami i rekomendacjami, warto uporządkować kilka terminów, które będą się pojawiać w całym artykule.

Program komputerowy podlega ochronie prawnoautorskiej na podstawie ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych oraz dyrektywy 2009/24/WE. Licencja open source nie jest zrzeczeniem się praw — to instrument udzielający upoważnienia do korzystania z praw wyłącznych na określonych warunkach.

Dlaczego open source w produkcie to ryzyko transakcyjne

96% organizacji zwiększyło lub utrzymało skalę korzystania z oprogramowania open source w 2024 roku, a 53% respondentów wskazało redukcję kosztów jako główny powód wyboru OSS. Pytanie nie brzmi więc „czy masz open source w produkcie”, lecz „czy wiesz, na jakich warunkach z niego korzystasz”.

Problem w tym, że większość spółek technologicznych nie posiada inwentaryzacji komponentów. Brak widoczności oznacza brak kontroli — organizacja nie jest w stanie ocenić skali ryzyka ani udowodnić zgodności licencyjnej.

Temat jest ignorowany do momentu, gdy staje się realnym problemem. A materializuje się w trzech sytuacjach:

1. Runda inwestycyjna lub exit — inwestor otwiera data room i pyta o listę komponentów, licencje i chain of title
2. Sprzedaż do klienta enterprise — klient wymaga oświadczeń i gwarancji dotyczących IP oraz zgodności licencyjnej
3. Zmiana modelu dystrybucji — przejście z SaaS na on-premise lub odwrotnie zmienia zakres obowiązków licencyjnych

W każdym z tych scenariuszy brak uporządkowanej dokumentacji oznacza opóźnienie, obniżoną wycenę lub utratę kontraktu.

Mapa licencji — co wolno, czego nie

Nie każda licencja open source niesie takie samo ryzyko. Poniższa tabela pokazuje praktyczne różnice między najpopularniejszymi rodzinami licencji.

Licencje permisywne (MIT, BSD, Apache 2.0) pozwalają na włączenie komponentu do zamkniętego kodu komercyjnego. Obowiązki ograniczają się do zamieszczenia informacji o posłużeniu się komponentem i atrybucji twórców. Apache 2.0 nie jest równoważna MIT — zawiera dodatkowe postanowienia dotyczące udzielenia licencji patentowej i wymóg oznaczenia modyfikacji w kodzie źródłowym.

Licencje copyleft (GPL, AGPL) działają inaczej. Stosowanie GPL oznacza obowiązek udzielenia licencji nieodpłatnie oraz zapewnienia użytkownikom nieodpłatnego dostępu do kompletnego kodu źródłowego. Naruszenie tych warunków skutkuje warunkową lub trwałą utratą uprawnień do wykorzystanego komponentu — a w konsekwencji ryzykiem roszczeń z tytułu korzystania z kodu bez podstawy prawnej.

GPL nie zabrania komercyjnego wykorzystania oprogramowania. Możliwe są modele biznesowe oparte na płatnych usługach wdrożeniowych czy utrzymaniowych. Ograniczenie dotyczy obowiązku udostępniania kodu źródłowego i nieodpłatnego licencjonowania — co wymaga świadomego zarządzania architekturą i modelem dystrybucji.

Pułapka SaaS i rola AGPL

Wiele spółek SaaS żyje w przekonaniu, że licencje copyleft ich nie dotyczą. Logika jest prosta: „nie dystrybuujemy binarki, więc GPL nas nie obowiązuje”. To przekonanie jest częściowo uzasadnione — ale niebezpieczne.

W większości licencji z rodziny GPL efekt copyleft nie występuje w modelu SaaS, ponieważ obowiązek udostępnienia kodu powstaje jedynie przy „przekazaniu” (convey) programu. Udostępnianie funkcji użytkownikom przez sieć nie spełnia tej przesłanki — co potwierdza zarówno powszechnie przyjęta interpretacja, jak i stanowisko Free Software Foundation.

Wyjątkiem jest licencja AGPL (GNU Affero GPL), stworzona właśnie w odpowiedzi na tę lukę. AGPL nakłada obowiązek stosowania zasad GPL również w zastosowaniach SaaS — jeśli użytkownicy wchodzą w interakcję z programem przez sieć, musisz udostępnić im kod źródłowy.

Dyrektywa 2009/24/WE nie nakłada na dostawcę SaaS obowiązku publikowania kodu źródłowego — obowiązek taki wynika wyłącznie z warunków konkretnej licencji. AGPL występuje w obrocie rzadziej niż GPL, ale wystarczy jeden komponent na tej licencji w sercu produktu, żeby zmienić sytuację całej spółki.

Co sprawdzić:

1. Czy w Twoich zależnościach są komponenty na licencji AGPL
2. Jak są zintegrowane z kodem własnym — linkowanie, forki, modyfikacje
3. Czy zmiana modelu dystrybucji (np. dodanie wersji on-premise) nie uruchomi obowiązków, które w modelu SaaS nie istniały

Co inwestor sprawdza w due diligence technologicznym

Due diligence następuje po term sheecie, przed dokumentami transakcyjnymi, i obejmuje weryfikację IP, zobowiązań i podatków (PARP — jak sprzedać startup). Dla spółki technologicznej kod to główne aktywo — i to właśnie na nim koncentruje się technologiczna część DD.

Dokumenty, których inwestor oczekuje

Typowe pytania inwestora

1. Czy spółka ma pełny tytuł do kodu — od każdego pracownika i kontraktora?
2. Czy w produkcie są komponenty na licencji GPL lub AGPL? Jeśli tak — jak są zintegrowane?
3. Czy chain of title od kontraktorów B2B jest udokumentowany pisemnymi umowami z wyraźnymi polami eksploatacji?
4. Czy były incydenty bezpieczeństwa lub roszczenia dotyczące IP?
5. Czy umowy z klientami zawierają klauzule change-of-control?

Urząd Patentowy RP w Przewodniku dla startupów (2024) wskazuje potrzebę ustalenia, kto jest uprawniony do poszczególnych praw IP, czy rozwiązania stworzyli założyciele, pracownicy lub wykonawcy, oraz czy istnieją umowy regulujące te prawa.

Skutki w umowie transakcyjnej

Nieuporządkowane licencje i niekompletny chain of title od kontraktorów B2B są najczęściej identyfikowanymi lukami w IP due diligence. W umowie transakcyjnej (SPA) przekładają się na:

1. Oświadczenia i gwarancje (R&W) dotyczące tytułu IP i zgodności licencyjnej — jeśli nie możesz ich złożyć, transakcja się komplikuje
2. Escrow lub retencja ceny przy zidentyfikowanym ryzyku licencyjnym lub niejasnych prawach kontraktorów
3. Earn-out powiązany z mierzalnymi wskaźnikami technologicznymi — zamiast pełnej ceny przy zamknięciu

Każdy z tych mechanizmów oznacza dla foundera mniej pieniędzy, później i z większą niepewnością.

Prawa do kodu od kontraktorów B2B — najczęstsza luka

Art. 74 ust. 3 ustawy o prawie autorskim przewiduje ustawowe nabycie praw do programu przez pracodawcę — ale wyłącznie w ramach stosunku pracy. Przy współpracy B2B ta reguła nie działa.

Żeby spółka miała prawa do kodu napisanego przez kontraktora, potrzebna jest pisemna umowa przenosząca autorskie prawa majątkowe (art. 53 ustawy — forma pisemna pod rygorem nieważności). Umowa musi wyraźnie wymieniać pola eksploatacji (art. 41 ust. 2) — ogólna klauzula „wszelkich praw” bez ich identyfikacji jest niewystarczająca.

Właściwe pola eksploatacji dla programu komputerowego to (art. 74 ust. 4):

1. Zwielokrotnianie programu
2. Modyfikacja programu (w tym tłumaczenie, przystosowywanie, zmiany układu)
3. Rozpowszechnianie programu (w tym użyczenie, najem)

Sama faktura lub dostęp do repozytorium nie zastępuje pisemnej umowy przenoszącej prawa. Chain of title jest gotowy do DD dopiero gdy istnieje nieprzerwany łańcuch nabycia praw od każdej osoby fizycznej uczestniczącej w tworzeniu kodu — łącznie z dalszymi podwykonawcami kontraktora.

Sprawdź:

1. Czy masz pisemne umowy z każdym kontraktorem, który pisał kod
2. Czy umowy wymieniają pola eksploatacji z art. 74 ust. 4
3. Czy moment przejścia praw jest powiązany z przyjęciem konkretnego rezultatu (commit, protokół odbioru)
4. Czy kontraktor nie korzystał z podwykonawców — a jeśli tak, czy masz umowy również z nimi

Asystenci AI w kodowaniu — nowe źródło ryzyka

Narzędzia takie jak GitHub Copilot generują fragmenty kodu, które mogą być identyczne lub istotnie podobne do kodu objętego licencją open source. Jeżeli taki fragment trafi do Twojego repozytorium, mogą powstać trzy odrębne problemy:

1. Konieczność przestrzegania warunków licencji tego komponentu (notices, udostępnienie kodu)
2. Ryzyko zarzutu naruszenia autorskich praw majątkowych
3. Niemożność wykazania pochodzenia kodu w due diligence

Art. 1 ust. 1 i art. 74 ust. 1 ustawy o prawie autorskim stanowią, że program podlega ochronie, jeżeli stanowi własną twórczość intelektualną. Sam fakt wygenerowania kodu przez AI nie rozstrzyga ani o jego twórczym charakterze, ani o tym, kto posiada prawa do jego użycia. Brak polskiego orzeczenia ani stanowiska organu publicznego w tej kwestii.

Minimalny proces kontrolny:

1. Przegląd wygenerowanego kodu przed commitem
2. Skanowanie podobieństwa do publicznych repozytoriów
3. Rejestrowanie źródła i licencji komponentów
4. Zakaz wprowadzania poufnego kodu spółki do promptów bez podstawy prawnej

Nadchodzące regulacje — CRA i obowiązek prowadzenia SBOM

Rozporządzenie CRA (UE) 2024/2847 wprowadza obowiązek prowadzenia wykazu komponentów (SBOM) dla produktów z elementami cyfrowymi. Terminy wejścia w życie:

Producent włączający komponent open source do produktu z elementami cyfrowymi odpowiada jako producent produktu końcowego i powinien posiadać aktualny SBOM. CRA nie wskazuje obowiązkowego formatu — ale w zamówieniach publicznych (np. Centrum e-Zdrowia) stosowane są już formaty CycloneDX i SPDX (Centrum e-Zdrowia — opis przedmiotu zamówienia).

Dyrektywa NIS2 (2022/2555), art. 21 ust. 2 lit. d i e, nakłada na podmioty kluczowe i ważne obowiązki w zakresie bezpieczeństwa łańcucha dostaw i zarządzania podatnościami. NIS2 nie nakazuje wprost prowadzenia SBOM, ale SBOM może być proporcjonalnym środkiem realizacji tych obowiązków.

Wymogi klientów enterprise mogą wyprzedzać obowiązki ustawowe — są to wówczas obowiązki kontraktowe. Jeśli Twój klient wymaga SBOM w 2026 roku, regulacja CRA jest drugorzędna wobec postanowień umowy.

Co zrobić — checklista dla CTO i foundera

Uporządkowanie licencji open source to projekt, który da się zaplanować i przeprowadzić bez zatrzymywania roadmapy. Poniżej konkretne kroki, uporządkowane od pilnych do uzupełniających.

Działania priorytetowe

1. Wygeneruj listę zależności (SBOM) dla każdego repozytorium i buildu. Bez inwentaryzacji nie masz czym zarządzać. Użyj narzędzi SCA (Software Composition Analysis) do automatycznego skanowania — ale pamiętaj, że narzędzie identyfikuje komponenty, a ocena prawna wymaga osobnej analizy.
2. Zaklasyfikuj wykryte licencje na trzy koszyki: dozwolone bez ograniczeń (MIT, BSD), dozwolone warunkowo (Apache 2.0, LGPL, MPL), zakazane w produkcie komercyjnym bez zmian architektonicznych (GPL, AGPL). Przypisz do każdej konkretne obowiązki.
3. Zweryfikuj punkty styku kodu własnego z komponentami copyleft. Sprawdź linkowanie, forki, modyfikacje. Wskaż miejsca wymagające wymiany komponentu lub zmiany architektury.
4. Przyjmij wewnętrzną politykę open source. Ustal: kto zatwierdza nową bibliotekę, jak dokumentuje się decyzję, co jest zakazane, jak wygląda ścieżka wyjątku. Polityka powinna być krótka i zrozumiała dla developera — nie dla prawnika.

Działania uzupełniające

5. Wbuduj kontrolę licencji w pipeline CI/CD — automatyczne skanowanie zależności i blokada niedozwolonych licencji. Żaden przepis tego nie nakazuje, ale jest to racjonalny sposób na egzekwowanie polityki bez ręcznego nadzoru.
6. Przygotuj pakiet dokumentów na DD i kwestionariusze enterprise: zestawienie komponentów, plik NOTICE/atrybucje, polityka OSS, rejestr wyjątków.
7. Przeszkol zespół developerski na konkretnych przykładach: które licencje są bezpieczne, co oznacza copyleft przy SaaS, dlaczego nie wkleja się kodu ze Stack Overflow do repozytorium produkcyjnego, jak postępować z kodem wygenerowanym przez AI.
8. Przejrzyj oświadczenia, gwarancje i klauzule indemnity dotyczące IP w aktualnych umowach z klientami — sprawdź, czy jesteś w stanie je faktycznie spełnić.
9. Ustaw cykliczny przegląd (np. kwartalny) listy zależności i rejestru wyjątków. Audyt to nie jednorazowe wydarzenie — zależności zmieniają się z każdym sprintem.

Napisz do nas

Jak możemy Ci w tym pomóc

Dobrze przygotowane umowy regulują zasady korzystania z komponentów open source w ramach realizacji projektu, w tym prowadzenie ich ewidencji oraz weryfikację i akceptację. Postanowienia dotyczące odpowiedzialności obejmują specyficzne reguły powiązane z obowiązkiem wdrożenia rozwiązań zastępczych oraz odpowiedzialność za koszty poniesione w związku z roszczeniami osób trzecich spowodowanymi naruszeniem licencji.

Wspieramy spółki technologiczne w trzech obszarach:

Przychodzimy przed transakcją, nie w jej trakcie. Cel to uporządkowanie — nie ograniczanie pracy developerów. Zmiany w kodzie rekomendujemy tylko tam, gdzie istnieje realne ryzyko.

Uporządkuj licencje, zanim zrobi to inwestor

Open source w produkcie nie jest problemem sam w sobie — problemem jest brak wiedzy o tym, co masz w zależnościach i na jakich warunkach z tego korzystasz. Uporządkowanie licencji z wyprzedzeniem to przewidywalny projekt. Remediacja pod presją transakcji to koszt alternatywny w postaci obniżonej wyceny, escrow i nieplanowanej pracy inżynierskiej.

Jeśli przygotowujesz się do rundy, planujesz sprzedaż do enterprise lub po prostu chcesz wiedzieć, na czym stoisz — napisz do nas. Przeprowadzimy audyt komponentów, pomożemy wdrożyć politykę licencyjną i przygotujemy dokumentację, której oczekuje inwestor lub klient.

Najczęściej zadawane pytania

Od czego zacząć, jeśli mamy kilkadziesiąt repozytoriów i nikt nie wie, co jest w zależnościach?

Od inwentaryzacji. Wygeneruj SBOM (wykaz komponentów) dla każdego repozytorium i buildu — narzędzia SCA robią to automatycznie. Bez listy nie masz czym zarządzać. Następnie zaklasyfikuj wykryte licencje na trzy koszyki: dozwolone, dozwolone warunkowo i zakazane w produkcie komercyjnym. Dopiero po tym etapie wiadomo, gdzie jest realne ryzyko i czy wymaga zmian w kodzie, czy wystarczy uzupełnić dokumentację.

Czy w modelu SaaS licencje copyleft w ogóle mnie dotyczą?

W większości przypadków GPL nie uruchamia obowiązku udostępnienia kodu w modelu SaaS, ponieważ nie dochodzi do „przekazania” programu. Wyjątkiem jest licencja AGPL, stworzona właśnie w odpowiedzi na tę lukę — nakłada obowiązek udostępnienia kodu źródłowego również przy interakcji użytkowników z programem przez sieć. Wystarczy jeden komponent AGPL w produkcie, żeby zmienić sytuację całej spółki. Sprawdź swoje zależności.

Czego dokładnie szukają inwestorzy w due diligence technologicznym?

Pełnego tytułu do kodu (chain of title od każdego pracownika i kontraktora), listy komponentów z licencjami (SBOM), braku komponentów copyleft zintegrowanych z kodem własnym bez świadomej decyzji, pisemnych umów z kontraktorami B2B z wyraźnymi polami eksploatacji oraz polityki zarządzania open source. Brak tych dokumentów nie kończy transakcji automatycznie, ale przekłada się na mechanizmy ochronne: escrow, retencję ceny lub earn-out — czyli mniej pieniędzy, później i z większą niepewnością.

Czy narzędzia do skanowania zależności wystarczą, czy potrzebna jest ocena prawna?

Narzędzia SCA identyfikują komponenty i przypisują im licencje. To niezbędny punkt wyjścia. Ale kwalifikacja, czy doszło do powstania „utworu pochodnego” w rozumieniu konkretnej licencji, zależy od sposobu integracji — linkowania, modyfikacji, architektury. To wymaga oceny prawnej. Narzędzie powie Ci, że masz komponent na GPL. Prawnik powie Ci, czy sposób, w jaki go używasz, uruchamia obowiązek udostępnienia kodu.

Co z kodem napisanym przez kontraktorów B2B — czy mamy do niego prawa?

Nie automatycznie. Ustawowe nabycie praw przez pracodawcę dotyczy wyłącznie stosunku pracy (art. 74 ust. 3 ustawy o prawie autorskim). Przy współpracy B2B potrzebujesz pisemnej umowy przenoszącej autorskie prawa majątkowe z wyraźnym wymienieniem pól eksploatacji. Sama faktura lub dostęp do repozytorium nie wystarczą. Sprawdź też, czy kontraktor nie korzystał z podwykonawców — bo wtedy potrzebujesz umów również z nimi.

Czy asystenci kodowania AI (Copilot) dodają nowe ryzyko licencyjne?

Tak. Wygenerowany kod może być identyczny lub podobny do kodu objętego licencją open source. Jeśli taki fragment trafi do repozytorium, możesz naruszyć warunki licencji, narazić się na roszczenia z tytułu praw autorskich i nie być w stanie wykazać pochodzenia kodu w DD. Wprowadź minimalny proces: przegląd wygenerowanego kodu przed commitem, skanowanie podobieństwa i zakaz wprowadzania poufnego kodu spółki do promptów.