Po co w ogóle porządkować licencje w startupie technologicznym
Licencje a wycena i możliwość pozyskania inwestycji
Dla inwestora technologia bez jasnych praw to tykająca bomba. Nawet najlepszy produkt SaaS, świetne MRR i dynamiczny wzrost nie przykryją faktu, że spółka może nie mieć prawa legalnie sprzedawać tego, na czym opiera się jej biznes. W praktyce due diligence prawno-technologiczne coraz częściej zaczyna się od pytania: „kto tak naprawdę ma prawa do kodu i na jakich licencjach stoi produkt?”.
Jeżeli dokumenty licencyjne i umowy IP (prawa własności intelektualnej) są w porządku, wycena spółki może być obroniona, ryzyko dyskonta spada, a negocjacje skupiają się na modelu skalowania. Jeśli natomiast kod jest „sklejony” z niejasnych komponentów, bez ścieżki ich pochodzenia, inwestor dolicza ryzyko prawne – albo wprost odmawia wejścia w rundę, bo koszt posprzątania sytuacji jest nieprzewidywalny.
Typowe czerwone flagi podczas due diligence
Podczas audytu licencyjnego w startupie technologicznym zwykle wypływa kilka powtarzalnych problemów:
brak jasnych umów z założycielami i kluczowymi developerami – kod powstał „na gębę”, bez cesji praw,
brak inwentarza licencji (brak listy bibliotek OSS, narzędzi SaaS, licencji komercyjnych),
użycie bibliotek na licencjach copyleft (np. GPL, AGPL) w rdzeniu produktu bez świadomości konsekwencji,
oparcie backendu o bazę lub komponent objęty licencją quasi-open-source (np. SSPL) niezgodnie z jej warunkami,
niespójne dokumenty: regulamin usługi (ToS), EULA, umowy z klientami B2B – każdy mówi coś innego o prawach i ograniczeniach,
brak rozdziału między eksperymentami R&D a kodem produkcyjnym – do produkcji trafił „tymczasowy” kawałek kodu z wątpliwą licencją.
Dla inwestora to oznaka, że założyciele nie kontrolują ryzyk prawnych. Pojawia się obawa, że w momencie wejścia na większy rynek lub przy większym kliencie pojawi się spór, który zablokuje sprzedaż albo wymusi kosztowny refactoring całego stacku.
„Działa teraz” kontra „da się to legalnie skalować globalnie”
W pierwszych miesiącach startupu liczy się jedno: żeby produkt w ogóle działał. Zespół korzysta z tego, co ma pod ręką – wtyczki, skrypty z GitHuba, gotowe integracje. Problem w tym, że licencje mało kto wtedy czyta. Kod trafia do produkcji, a po roku nikt już nie pamięta, skąd wzięła się dana biblioteka i co właściwie można z nią zrobić.
Model „byle teraz poszło” zderza się z rzeczywistością, gdy:
wchodzi większy klient B2B, którego prawnik pyta o pochodzenie komponentów,
inwestor prosi o listę licencji open source w produkcie i potwierdzenie ich zgodności,
dodajecie nowy kanał dystrybucji (np. marketplace partnera), który wymaga gwarancji, że nie naruszacie licencji osób trzecich.
W tej perspektywie dobór licencji oprogramowania w startupie technologicznym to nie „papierologia”, tylko część architektury skalowalności – tak samo istotna jak wybór chmury czy bazy danych.
Przykład blokady rundy przez chaos licencyjny
Scenariusz z praktyki: startup rozwijał produkt SaaS do analityki danych. CTO na etapie MVP sięgnął po kilka bibliotek na licencji AGPL, bo „były wygodne”. Nikt nie przeanalizował, co AGPL oznacza dla aplikacji webowej. Po dwóch latach produkt miał kilkudziesięciu klientów B2B. Podczas due diligence inwestor zatrudnił kancelarię, która przepuściła repo przez skaner OSS. Wykryto AGPL w backendzie. Wniosek: istnieje ryzyko, że cała aplikacja webowa powinna być dostępna w kodzie źródłowym dla użytkowników.
Inwestor zażądał:
refactoringu i usunięcia komponentów AGPL z kluczowych ścieżek,
uzyskania alternatywnej licencji komercyjnej lub podpisania porozumień z autorami bibliotek,
aktualizacji dokumentacji licencyjnej i polityki OSS.
Runda opóźniła się o kilka miesięcy, część warunków inwestora stała się ostrzejsza, a zespół musiał w trybie awaryjnym przepisać kawał produktu. Wszystko dlatego, że nikt nie połączył wyborów technologicznych z konsekwencjami licencyjnymi.
Źródło: Pexels | Autor: cottonbro studio
Podstawy prawa autorskiego, które musi rozumieć założyciel
Utwór i kod jako przedmiot prawa autorskiego
Kod źródłowy to utwór w rozumieniu prawa autorskiego, o ile ma element twórczy (czyli nie jest czystym odtworzeniem czegoś oczywistego). Ochrona powstaje automatycznie z chwilą stworzenia utworu – nie trzeba żadnej rejestracji. Oznacza to, że osoba, która napisała kod, z automatu ma do niego prawa, chyba że zostały one skutecznie przeniesione lub udzielono licencji.
W startupie na miano utworu mogą zasługiwać nie tylko pliki .js czy .py, ale także:
architektura systemu (diagramy, opisy),
skrypty konfiguracyjne (np. złożone pliki Terraform, Ansible),
modele UX/UI (makiety, design system),
modele uczenia maszynowego (jako kombinacja kodu, parametrów i struktury),
dokumentacja techniczna i produktowa.
Każdy z tych elementów może mieć swojego autora lub współautorów, a prawa do nich nie „przechodzą magicznie” na spółkę tylko dlatego, że plik wisi w repozytorium organizacji.
Autorskie prawa osobiste i majątkowe
Prawo autorskie w Polsce dzieli się na:
autorskie prawa osobiste – niezbywalne, np. prawo do autorstwa, oznaczania utworu imieniem i nazwiskiem, nietykalności treści; nie można ich sprzedać, ale można ograniczyć sposób wykonywania (np. zobowiązanie do niewykonywania niektórych uprawnień),
autorskie prawa majątkowe – „ekonomiczne”, pozwalają zarabiać na utworze i rozporządzać nim; te mogą być przenoszone (cesja) lub licencjonowane.
W kontekście startupu technologicznego kluczowe jest, aby spółka miała pełne autorskie prawa majątkowe do kodu, z którego buduje produkt, albo przynajmniej licencję, która pozwala legalnie go eksploatować w modelu biznesowym spółki (SaaS, on-premise, OEM itd.).
Pola eksploatacji, terytorium i czas
Każda licencja lub umowa przeniesienia praw powinna dokładnie określać:
pola eksploatacji – w jaki sposób utwór może być wykorzystywany (np. utrwalanie, zwielokrotnianie, rozpowszechnianie w sieci, wprowadzanie do obrotu, używanie w SaaS),
terytorium – na jakim obszarze licencja działa (Polska, Europa, cały świat),
czas – okres obowiązywania (czas określony vs bezterminowo).
Jeśli w umowie z programistą B2B wpisano tylko „przenosi prawa na klienta”, bez doprecyzowania pól eksploatacji, terytorium i czasu, pojawia się ryzyko, że przeniesienie praw jest nieważne albo węższe, niż sądzicie. W due diligence takie luki wychodzą natychmiast.
Licencja, przeniesienie praw, sublicencja, NDA
Kilka pojęć, które w praktyce są nagminnie mylone:
przeniesienie praw (cesja) – autor (lub dotychczasowy właściciel) oddaje autorskie prawa majątkowe do utworu; po prawidłowej cesji to spółka staje się właścicielem kodu i może nim dalej rozporządzać,
licencja – zgoda na korzystanie z utworu w określony sposób; autor nadal pozostaje właścicielem, ale pozwala korzystać z utworu w określonym zakresie,
sublicencja – dalsza licencja udzielona przez licencjobiorcę (np. spółka ma licencję i daje sublicencję klientowi); możliwa, jeśli umowa bazowa na to pozwala,
NDA (non-disclosure agreement) – umowa o poufności; nie reguluje praw autorskich, tylko zakazuje ujawniania informacji.
Błąd, który pojawia się często: CTO podpisuje z freelancerem samo NDA i umowę o dzieło „na wykonanie modułu”, bez klauzul IP. Freelancer pisze kluczową część backendu. W papierach: brak cesji, brak porządnej licencji. Formalnie spółka nie ma do tego kodu żadnego prawa poza domyślnymi zasadami użycia z kodeksu cywilnego. Przy wejściu inwestora – duży problem.
Co tworzy „własność intelektualną” startupu
Własność intelektualna w startupie technologicznym to nie tylko „kod aplikacji”. To zwykle cały pakiet:
repozytoria kodu (aplikacje, mikroserwisy, skrypty, narzędzia wewnętrzne),
infrastruktura jako kod (IaC) – pliki konfiguracyjne, pipeline’y CI/CD, szablony deploymentu,
dane szkoleniowe i same modele ML, jeśli startup działa w obszarze AI,
elementy frontendu i design system (komponenty UI, ikony, ilustracje),
dokumentacja, specyfikacje, user stories, procedury operacyjne,
produkty pochodne – SDK, pluginy, integracje z systemami klientów.
To wszystko trzeba ogarnąć licencyjnie: kto stworzył, na jakiej podstawie, jakie są ograniczenia, jak rozkładają się prawa. Hasło „kod w repo spółki” nie daje żadnej gwarancji, że spółka jest właścicielem tego kodu. O tym decydują wyłącznie umowy i licencje.
Jakie typy licencji oprogramowania spotkasz w startupie
Oprogramowanie własne, open source, komercyjne i no-code
W przeciętnym startupie technologicznym funkcjonuje jednocześnie kilka typów licencji:
oprogramowanie własne – kod napisany przez zespół (pracownicy, współzałożyciele, kontraktorzy) na rzecz spółki,
licencje open source – biblioteki, frameworki, narzędzia wbudowane w produkt lub używane w procesie developmentu,
licencje komercyjne / SaaS – narzędzia typu CRM, monitoring, analityka, CI/CD, które są używane jako usługi w modelu subskrypcyjnym,
komponenty no-code/low-code – platformy, gdzie logika biznesowa budowana jest z klocków dostarczonych przez zewnętrznego dostawcę.
Każda z tych grup rządzi się innymi regułami. Kod własny to obszar, gdzie spółka ma największy wpływ: może dowolnie licencjonować i zmieniać model. Open source narzuca zewnętrzne warunki (np. obowiązek udostępnienia modyfikacji). Komercyjne SaaS to zwykle licencje, których nie da się negocjować poza większym enterprise. No-code bywa szczególnie zdradliwe, bo część „produktowej logiki” jest zamknięta w platformie, do której spółka ma jedynie licencję, a nie prawa własności.
On-premise vs SaaS, subskrypcja vs licencja jednorazowa
Z punktu widzenia dobierania licencji dla własnego produktu trzeba rozróżnić dwa światy:
on-premise – klient dostaje oprogramowanie do instalacji u siebie; tu funkcjonują klasyczne licencje:
per user / per seat (na użytkownika lub stanowisko),
per instancja (na konkretną instalację lub serwer),
per core/CPU (na zasoby sprzętowe),
licencja czasowa (np. roczna) lub bezterminowa z opłatą maintenance.
SaaS – klient uzyskuje dostęp do usługi w chmurze; tu licencja jest zwykle „opakowana” w regulamin usługi (Terms of Service) i EULA, a model rozliczeń jest subskrypcyjny (miesięcznie, rocznie, usage-based).
Dobór modelu wpływa na to, jak pisać licencje: w on-premise trzeba dokładnie określić zasady instalacji, kopii zapasowych, przejścia licencji na inny podmiot. W SaaS licencja często sprowadza się do pozwolenia na korzystanie z interfejsu i API w określonym zakresie, bez przekazania jakiejkolwiek kopii kodu.
Rola EULA, Terms of Service i DPA w modelu SaaS
W produkcie SaaS kluczowe dokumenty licencyjne to:
EULA (End-User License Agreement) – umowa licencyjna z użytkownikiem końcowym; określa, co wolno użytkownikowi zrobić z usługą, jakie są ograniczenia, zakazy (np. reverse engineering), odpowiedzialność,
ToS (Terms of Service) – ogólne warunki świadczenia usługi; zawierają element licencyjny, ale też kwestie płatności, supportu, SLA, rozwiązywania umowy,
Licencje na komponenty firm trzecich i API
Poza klasycznymi bibliotekami i narzędziami deweloperskimi w produktach SaaS bardzo często pojawiają się komponenty firm trzecich: bramki płatnicze, systemy mailingowe, usługi typu search, rekomendacje, feature flagi, a także gotowe widgety embedowane poprzez <script> lub <iframe>. Każdy z nich ma własne warunki licencyjne, które wpływają na to, co możesz obiecać swoim klientom.
Kilka elementów, które trzeba czytać nie tylko „technicznie”, ale i licencyjnie:
API Terms – warunki korzystania z API; regulują m.in. limity zapytań, typy dozwolonych zastosowań (np. zakaz użycia w aplikacjach konkurencyjnych),
restrykcje terytorialne – zakaz użycia API na określonych rynkach lub w konkretnych sektorach (healthcare, finanse),
data ownership – kto jest właścicielem danych przechodzących przez API i danych pochodnych (np. model scoringowy budowany na podstawie danych klienta),
white-label / branding – czy możesz „ukryć” dostawcę pod własnym brandem, czy musisz eksponować logo / informację „powered by X”,
sub-licencjonowanie – czy masz prawo udostępniać funkcjonalność zbudowaną na cudzym API jako element swojej usługi klientom B2B lub partnerom (multi-tenant),
zmiany regulaminu – jak często dostawca może zmieniać warunki i z jakim wyprzedzeniem, co się dzieje, gdy przestaniesz je akceptować.
Przykład z życia: startup fintech buduje kluczowy moduł scoringu kredytowego w oparciu o zewnętrzne API. W regulaminie API jest zakaz świadczenia usług oceny zdolności kredytowej na rzecz podmiotów z tej samej branży, co sam dostawca. Z perspektywy technicznej wszystko działa idealnie, ale model biznesowy jest sprzeczny z licencją. Efekt: wymiana komponentu w ogniu wdrożeń enterprise.
Tip: załóż w repo osobny plik (np. THIRD_PARTY_LICENSES.md), gdzie spisujesz wszystkie kluczowe komponenty firm trzecich z linkami do licencji i krótkim opisem ograniczeń. To świetna baza wyjściowa na due diligence i sanity check przy projektowaniu nowych feature’ów.
Źródło: Pexels | Autor: Ivan S
Licencje open source – praktyczna analiza i typowe pułapki
Najważniejsze dla CTO i product ownera jest zrozumienie różnic między trzema rodzinami licencji open source:
permissive (liberalne) – np. MIT, BSD, Apache 2.0; pozwalają praktycznie na dowolne wykorzystanie, także komercyjne i zamknięte, pod warunkiem zachowania informacji o autorach i licencji,
copyleft – np. GPL, LGPL; narzucają obowiązek udostępniania kodu źródłowego pochodnych utworów przy jego dystrybucji („efekt wirusowy”),
network copyleft – np. AGPL; rozszerzają copyleft na sytuację, gdy oprogramowanie jest udostępniane jako usługa w sieci (SaaS), nie tylko w formie binariów do pobrania.
Permissive są „bezpieczniejsze” dla startupu, bo dają dużą elastyczność przy zamknięciu kodu produktu. Copyleft i AGPL wymagają dokładnej analizy architektury: gdzie kończy się „użycie biblioteki”, a zaczyna „utwór zależny” (derivative work).
Czytanie licencji: na co patrzeć w praktyce
Przy ocenie biblioteki open source nie trzeba rozumieć całego tekstu prawnego. Kluczowe pytania, które warto sobie zadać:
Czy licencja wymaga udostępnienia pełnego kodu źródłowego produktu lub jego części? W jakich sytuacjach (dystrybucja binariów, hostowanie jako SaaS)?
Czy są zakazy dotyczące pól eksploatacji, np. zakaz użycia w rozwiązaniach militarnych, finansowych albo w konkurencyjnych produktach?
Czy dopuszczone jest łączenie z zamkniętym kodem i na jakich warunkach (dynamiczne vs statyczne linkowanie, mikroserwisy, pluginy)?
Czy licencja wymaga oznaczeń w UI, dokumentacji, oprogramowaniu (attribution), a jeśli tak – w jakiej formie?
Czy są zapisy patentowe (Apache 2.0, GPLv3) – np. czy licencja zawiera patent grant, czy grozi utrata licencji przy sporze patentowym?
Na poziomie procesu dobrze działa prosty workflow: przy dodawaniu nowej zależności do projektu (dependency) developer w PR opisuje typ licencji, a osoba odpowiedzialna za compliance (często CTO lub lead dev) akceptuje ją zgodnie z polityką spółki.
Efekt wirusowy copyleft i AGPL w architekturze mikroserwisów
Najwięcej nieporozumień pojawia się przy próbie odpowiedzi na pytanie: kiedy kod naszego produktu staje się „dziełem zależnym” w rozumieniu licencji copyleft. Prawo autorskie nie daje tu twardych, binarnych granic, ale można przyjąć kilka praktycznych reguł:
statyczne linkowanie (włączanie kodu biblioteki do binarium) prawie zawsze jest traktowane jako utwór zależny – GPL może rozlać się na całość,
dynamiczne linkowanie jest bardziej dyskusyjne, ale wiele interpretacji i rekomendacji FSF traktuje je podobnie do statycznego,
komunikacja przez sieć/protokół (HTTP, gRPC, REST) między odrębnymi serwisami często jest uznawana za połączenie „na poziomie systemu”, a nie utworu zależnego – co osłabia efekt wirusowy,
w AGPL udostępnianie usługi przez sieć może uruchamiać obowiązek udostępnienia kodu również wtedy, gdy nigdzie nie publikujesz binariów do pobrania.
Dlatego przy krytycznych komponentach (search, storage, messaging) objętych copyleft/AGPL często stosuje się izolację:
wydzielony serwis z wyraźnym API (SOA/mikroserwis),
brak miksowania kodu copyleft i kodu własnego w jednym binarium,
dystans na poziomie procesu buildu (osobne repo, osobny artefakt).
To nie jest srebrna kula, ale w praktyce znacząco redukuje ryzyko, że ktoś nazwie cały produkt dziełem zależnym podlegającym obowiązkom GPL/AGPL.
Forki, modyfikacje i kontrybucje do open source
Startupy coraz częściej nie tylko konsumują open source, ale również:
tworzą forki – własne rozwidlenia repozytoriów,
wprowadzają modyfikacje do używanych bibliotek,
oddają kontrybucje (pull requests) do projektów zewnętrznych.
To generuje dodatkowe wątki licencyjne:
fork podlega tej samej licencji co oryginał (chyba że licencja pozwala na relicencjonowanie, a autorzy projektu wyraźnie to dopuszczają),
jeśli developer pracujący w startupie kontrybuuje do projektu open source w czasie pracy i na sprzęcie firmowym, spółka może być współwłaścicielem praw – to musi być spójne z polityką IP w umowach,
commitując kod do cudzego projektu, często akceptujesz Contributor License Agreement (CLA) lub DCO – warto sprawdzić, czy nie oddajesz w ten sposób zbyt szerokich praw, które mogą kolidować z interesem spółki.
Bez prostej polityki „kto, kiedy i na jakich zasadach kontrybuuje do open source” łatwo o sytuację, w której kluczowy algorytm, budowany wewnątrz przez kilka miesięcy, ląduje w publicznym repo na licencji MIT, bo developer wykorzystał go w zewnętrznej kontrybucji.
Budowa produktu a konsekwencje licencyjne – scenariusze techniczne
Monolit vs mikroserwisy a segmentacja ryzyka
Architektura systemu wpływa bezpośrednio na to, jak rozchodzi się ryzyko licencyjne:
monolit – wszystkie moduły kompilowane i dystrybuowane jako jeden artefakt; wciągnięcie jednej biblioteki GPL może „zainfekować” całość,
mikroserwisy – każdy serwis ma własny cykl release’ów i zależności; naruszenie licencji może dotyczyć jednego komponentu, łatwiej też go wymienić.
Izolacja na poziomie repozytoriów i pipeline’ów CI/CD ułatwia panowanie nad tym, kto i jakich zależności używa. W dużych setupach powstają wewnętrzne „approved lists” – zbiory dopuszczonych licencji i bibliotek, które można stosować w konkretnej domenie (frontend, backend, ML).
SDK, pluginy i marketplace – kto do kogo ma licencję
Jeśli produkt oferuje SDK lub mechanizm pluginów, pojawia się ciekawy układ licencji:
ty udzielasz licencji na SDK (np. klientowi lub partnerowi),
partner tworzy plugin lub integrację, do którego jest właścicielem praw,
plugin działa wewnątrz twojego produktu (czasem jako kod wstrzykiwany, czasem przez API).
Trzeba wtedy ustalić kilka zasad:
czy możesz hostować pluginy (np. w marketplace) i w jakim zakresie – hosting to też pole eksploatacji,
czy wolno ci dokonywać modyfikacji pluginów (np. fixes, security patch) i na jakiej podstawie,
czy możesz używać pluginu w demo dla innych klientów,
kto odpowiada za naruszenia praw autorskich lub licencji osób trzecich w pluginie.
W praktyce przydaje się standardowa umowa dla partnerów marketplace, która:
przenosi na ciebie lub licencjonuje odpowiednio prawa niezbędne do hostowania i promowania pluginu,
wymusza, by partner miał pełne prawa do kodu i komponentów, których używa,
pozwala ci odciąć plugin w razie roszczeń (tzw. takedown) i przerzuca część odpowiedzialności regresowo na partnera.
Feature flags i A/B testy a kwestie licencyjne
Przy dynamicznym rozwoju produktu sporo funkcji jest „schowanych” za feature flagami lub odpalanych tylko części użytkowników (A/B testing). Z punktu widzenia licencji wcale nie ma znaczenia, ilu użytkowników korzysta z funkcji – liczy się:
czy funkcja jest dystrybuowana (np. w aplikacji desktop/mobile),
czy jest udostępniana publicznie jako część usługi (SaaS).
Jeśli testujesz nową funkcję opartą na bibliotece z restrykcyjną licencją, nie traktuj tego jako „eksperymentu poza prawem”. Już pierwszy rollout do produkcji może uruchomić obowiązki wynikające z licencji (np. AGPL). Dlatego eksperymenty najlepiej ograniczać do komponentów o znanym i akceptowalnym profilu licencyjnym.
ML, dane treningowe i modele – kto ma prawa do czego
W startupach AI sytuacja komplikuje się jeszcze bardziej, bo w grze są:
dane treningowe – teksty, obrazy, logi, dane telemetryczne,
feature engineering – pipeline’y przetwarzania danych (kod + konfiguracje),
same modele – w formie wag, architektury i hyperparametrów.
Przy budowaniu modeli w oparciu o cudze dane lub zewnętrzne API trzeba rozpoznać co najmniej:
czy posiadasz licencję na wykorzystanie danych w celach treningowych (text and data mining),
czy dostawca API nie zakazuje trenowania modeli na swoich odpowiedziach,
czy możliwe jest reidentyfikowanie osób na podstawie modelu (problem RODO/Privacy, ale i własności danych),
kto ma prawa do powstałego modelu – ty, klient (w modelu enterprise), czy współwłasność.
Scenariusz, który często pojawia się w negocjacjach z klientami enterprise: klient żąda przeniesienia praw do modelu wytrenowanego na jego danych. Z perspektywy licencyjnej prowadzi to do:
konieczności rozdzielenia modeli „shared” (trenujących się na wielu klientach) od modeli „dedykowanych”,
innego traktowania kodu (który pozostaje twój) i wag modelu (które mogą przejść na klienta lub być licencjonowane ograniczenie).
Źródło: Pexels | Autor: Christina Morillo
Prawa do kodu w zespole – umowy i praktyka
Założyciele a IP sprzed rejestracji spółki
Spora część kodu powstaje zanim formalnie powołacie spółkę – w ramach projektu „po godzinach” lub freelancingu. Z perspektywy prawnej:
autorem kodu jest ta osoba, która faktycznie go stworzyła,
jeśli występowała jako freelancer dla innego podmiotu, tamta firma może mieć do kodu prawa.
Dlatego na etapie zakładania spółki sensownym krokiem jest:
przegląd repozytoriów, z których kod trafi do spółki,
Wkład rzeczowy (aport) kodu do spółki
Jeżeli część kluczowego IP powstała przed rejestracją spółki, często sensownym ruchem jest wniesienie go jako aportu (wkładu niepieniężnego) w zamian za udziały. Z punktu widzenia kontroli nad licencjami to bardziej przewidywalne niż luźne “używamy kodu założyciela na zasadzie dogadania”.
Taki aport powinien być opisany konkretnie:
jakie repozytoria są wnoszone (linki, snapshot commitów),
jaki jest zakres praw, które przechodzą na spółkę (przeniesienie majątkowych praw autorskich vs licencja wyłączna/niewyłączna),
czy założyciel zachowuje prawo do re-użycia tego kodu w innych projektach (i w jakich granicach),
jak radzić sobie z zależnościami open source w tym kodzie – aport dotyczy tylko części autorskiej, nie bibliotek stron trzecich.
Dobrze, żeby w umowie założycielskiej pojawiło się oświadczenie, że:
wnoszony kod nie narusza praw osób trzecich (np. byłego pracodawcy, klienta),
założyciel nie ograniczył swobody dysponowania kodem innymi umowami (NDA, non-compete, kontrakt B2B),
ewentualne roszczenia osób trzecich pokrywa ten, kto kod wniósł (regres).
Tip: przy większych projektach architektonicznie opłaca się odseparować elementy „sporne” (np. komponent stworzony u byłego pracodawcy) i przepisać je od zera pod pełną kontrolą spółki.
Umowy z pracownikami – kto jest właścicielem kodu
W klasycznym zatrudnieniu etatowym (umowa o pracę) większość jurysdykcji przewiduje, że majątkowe prawa autorskie do utworów pracowniczych przechodzą na pracodawcę w granicach celu umowy. To jednak nie załatwia wszystkiego:
trzeba zdefiniować, co jest „utworem pracowniczym” – kod napisany w godzinach pracy, na sprzęcie firmowym, w ramach obowiązków służbowych,
określić zakres pól eksploatacji, na których spółka nabywa prawa (SaaS, on‑premise, sublicencje, white‑label),
dodać jasne zasady dot. side‑projectów – kiedy są prywatne, a kiedy należą do spółki.
Bez tego łatwo o konflikt typu: developer twierdzi, że napisał fragment silnika rekomendacji „po godzinach”, a ty uważasz, że to kluczowy komponent produktu. Pomaga minimalistyczna, ale precyzyjna polityka:
pracownik musi zgłosić projekty rozwijane w tej samej domenie biznesowej co startup,
projekty niezwiązane z działalnością spółki (np. gra indie, open source spoza waszej branży) pozostają jego,
wszelkie IP powstałe w ramach zadań służbowych przechodzi na spółkę niezależnie od miejsca i czasu tworzenia.
Uwaga: w części krajów (np. w UE) nie można skutecznie zrzec się osobistych praw autorskich (np. autorstwa). Da się natomiast umownie uregulować prawo do wykonywania tych praw (np. decyzje o modyfikacjach, publikacji).
Kontrakty B2B i freelancerzy – IP bez „ustawy o pracowniczych”
Przy umowach B2B (kontraktorzy, agencje) nie działa domyślny mechanizm przejścia praw jak przy pracowniku. Jeżeli w umowie nie ma jasnego przeniesienia praw lub licencji, domyślnie twórcą i właścicielem kodu jest kontraktor.
Bezpieczny szkielet klauzuli IP w umowie B2B zazwyczaj zakłada, że:
wykonawca przenosi na spółkę majątkowe prawa autorskie do utworów powstałych w ramach kontraktu, w najszerszym dopuszczalnym prawem zakresie,
przeniesienie następuje z chwilą zapłaty wynagrodzenia lub przyjęcia dzieła (jasny moment),
wykonawca może wykorzystywać własne „know‑how” i narzędzia w kolejnych projektach, ale bez kopiowania kodu kluczowego dla produktu,
wszelkie komponenty open source użyte w projekcie zostaną zidentyfikowane i opisane wraz z licencjami.
Dobrze sprawdza się prosty mechanizm „IP exception list”: wykonawca przed startem projektu listuje komponenty, do których zachowuje prawa (np. swój framework), a które tylko licencjonuje spółce. Wszystko inne przechodzi na startup.
Kontrybucje pracowników do open source w czasie pracy
Jeżeli zespół mocno kontrybuuje do OSS, trzeba rozstrzygnąć, kto jest stroną tych kontrybucji – osoba prywatna czy spółka. To ma znaczenie, gdy projekt wymaga podpisania CLA lub udzielenia szerokiej licencji maintainerom.
Najczęstsze modele:
kontrybucje „firmowe” – pracownicy commitują jako reprezentanci spółki, spółka akceptuje CLA i jest formalnym licencjodawcą,
kontrybucje „osobiste” – developerzy działają jako osoby fizyczne, a spółka pozwala na to w określonym wymiarze czasowym i domenowym,
mix: do projektów krytycznych dla waszej infrastruktury kontrybucje są „firmowe”, a do pozostałych – osobiste.
Dobrze, jeżeli polityka OSS:
określa, kiedy wymagana jest zgoda (np. przed pierwszym większym PR do projektu używanego w core’owym produkcie),
reguluje, kto może podpisywać CLA w imieniu spółki,
zabrania wynoszenia do projektów zewnętrznych kodu, który jest kluczowy dla przewagi konkurencyjnej startupu.
Shadow IT i prywatne repozytoria
W wielu zespołach część kodu ląduje w prywatnych repo deweloperów (osobiste GitHub’y, Gist’y, pastebiny). Z perspektywy licencji i ochrony IP to proszenie się o kłopoty: trudniej potem wykazać, co zostało napisane w ramach stosunku pracy i kiedy.
Dobrym kompromisem jest:
prostą zasadą: kod produktu nie może być trzymany w prywatnych repozytoriach,
osobnymi, firmowymi kontami w serwisach typu GitHub/GitLab dla projektów open source rozwijanych przez zespół,
krótkim szkoleniem z tego, co może trafić do publicznego Gist’a, a co nie (np. fragment algorytmu vs genericzny snippet konfiguracyjny).
Dobór licencji dla własnego produktu – projektowanie modelu biznesowego
Mapa zależności: co możesz w ogóle zaoferować klientom
Zanim wybierzesz licencję dla własnego produktu, trzeba znać ograniczenia narzucane przez komponenty, na których stoisz. Chodzi nie tylko o biblioteki, ale też:
bazy danych (np. licencje „source available”, SSPL),
silniki wyszukiwania, message brokery, feature store’y,
modele ML (często licencje z zakazem re‑treningu lub komercyjnego wykorzystania).
Dobrą praktyką jest zrobienie licencyjnego inventory:
lista komponentów z wersjami,
typ licencji (MIT, Apache 2.0, GPLv3, AGPL, BSD, własna komercyjna),
krótka notatka, czy licencja jest kompatybilna z komercyjną dystrybucją w wybranym modelu (SaaS, on‑prem, embedded),
link do pełnego brzmienia licencji.
Dopiero na tej podstawie da się sensownie zaprojektować własny model licencjonowania bez wchodzenia w konflikt z upstreamem.
SaaS vs on‑premise vs embedded – trzy różne reżimy
To, jak sprzedajesz produkt, bardzo mocno wpływa na sensowny wybór licencji:
SaaS – zazwyczaj nie „dystrybuujesz” binariów, tylko świadczysz usługę. Tu duża część restrykcji copyleft (GPL) aktywuje się tylko, gdy publikuje się binaria. Wyjątkiem jest AGPL, która celuje właśnie w usługi sieciowe.
On‑premise – klient dostaje binaria (czasem też kod źródłowy). Wtedy licencja musi precyzyjnie regulować prawo do instalacji, modyfikacji, audytu bezpieczeństwa, a także możliwość dalszego udostępniania (np. w spółkach z grupy kapitałowej).
Embedded / OEM – twój kod jest częścią większego produktu klienta (np. urządzenia IoT, aplikacji white‑label). Tutaj trzeba przewidzieć sublicencjonowanie dalej do klientów końcowych oraz ograniczyć możliwość „wyjęcia” komponentu i użycia go poza uzgodnionym kontekstem.
Komercyjna licencja własna + open source – dual licensing
Popularny model to dual licensing: udostępniasz projekt w wersji open source (często z licencją przyjazną dla developerów), a jednocześnie oferujesz wersję komercyjną z dodatkowymi funkcjami / wsparciem.
Typowe konfiguracje:
core MIT/Apache, dodatki komercyjne – podstawowa funkcjonalność dostępna na przyjaznej licencji, ale funkcje enterprise (SAML, multi‑tenant, audyt, HA) tylko w wersji płatnej,
„copyleft jako dźwignia sprzedaży” – core pod GPL/AGPL, a klientom, którzy nie chcą się otwierać, sprzedajesz komercyjną licencję pozwalającą na closed‑source użycie,
source‑available – kod jest dostępny, ale licencja zabrania tworzenia konkurencyjnego SaaS / komercyjnego hostingu (np. modele „SSPL‑like”).
Dual licensing wymaga konsekwentnego pilnowania, żeby:
wszystkie kontrybucje do części, którą chcesz relicencjonować komercyjnie, były objęte przeniesieniem praw lub odpowiednim CLA,
linie między „core OSS” a „enterprise features” były technicznie do obrony (osobne moduły, feature gates, wyraźny podział w repo).
Licencje przyjazne społeczności vs kontrola nad komercjalizacją
Jeżeli zależy ci na dynamicznej społeczności devów, licencje typu MIT, BSD lub Apache 2.0 minimalizują tarcie. Pozwalają firmom używać kodu w zamkniętych produktach bez większych obaw. Z drugiej strony, utrudniają monetyzację w modelu „głęboko open source, płatny tylko support”.
Dylemat jest prosty:
im bardziej permistywna licencja, tym łatwiej o adopcję, ale trudniej o budowanie „moatu” wyłącznie na kodzie,
im bardziej restrykcyjna (copyleft, non‑compete hosting), tym bardziej chronisz się przed konkurencyjnym SaaS, ale część developerów będzie omijać projekt.
W praktyce często lepiej, by „magia” produktu leżała w:
a nie w samym kodzie licencjonowanym maksymalnie agresywnie.
Klauzule w licencjach własnych, które warto przemyśleć
Pisząc własną licencję (lub modyfikując standardową EULA), lepiej unikać „kopiuj‑wklej” z losowego projektu. Kilka punktów, nad którymi trzeba usiąść:
zakres dozwolonego użycia – czy klient może używać produktu tylko na własne potrzeby, czy też w ramach świadczenia usług na rzecz swoich klientów (model MSP, white‑label),
audyty i reverse engineering – czy całkowicie zakazujesz inżynierii wstecznej, czy dopuszczasz ją na potrzeby bezpieczeństwa / interoperability (i w jakich ramach),
liczba instancji / użytkowników – czy licencja jest per user, per core, per instancja, per środowisko (dev/test/prod),
aktualizacje – czy klient musi aktualizować do najnowszej wersji (argument bezpieczeństwa) i jak to wpływa na support,
prawo do benchmarków i publikacji wyników – część vendorów zakazuje publikowania benchmarków bez zgody, ale w community może to być źle przyjęte.
Tip: dopasuj język licencji do tego, jak realnie rozmawiasz z klientami. Jeżeli sprzedajesz rozwiązanie developerom, zbyt agresywne zakazy benchamrków i porównań zaczną wracać w feedbacku sprzedażowym.
Współwłasność IP z klientem – custom features i joint development
Przy dużych klientach często pojawia się wątek wspólnego rozwijania funkcji (joint development). Klient finansuje budowę funkcji X, ty ją implementujesz, a potem wszyscy zastanawiają się, kto ma prawa do kodu.
Kilka modeli:
Najczęściej zadawane pytania (FAQ)
Jak brak uregulowanych licencji wpływa na wycenę startupu i rundę inwestycyjną?
Nieuporządkowane licencje działają jak „ukryty dług” – inwestor musi założyć, że część produktu być może nie może być legalnie sprzedawana lub będzie wymagała przepisywania. To zwykle kończy się dyskontem na wycenie, ostrzejszymi warunkami lub w skrajnym przypadku odrzuceniem inwestycji.
Podczas due diligence kancelaria inwestora zaczyna od pytania, kto faktycznie ma prawa do kodu i na jakich licencjach stoi produkt. Jeśli nie ma jasnych umów z założycielami i developerami, brak inwentarza licencji OSS, a w repo są „mocne” licencje typu GPL/AGPL czy SSPL, inwestor zakłada podwyższone ryzyko prawne. To może zablokować rundę lub ją mocno opóźnić.
Jakie umowy z programistami są konieczne, żeby spółka faktycznie miała prawa do kodu?
Minimalny zestaw to: umowa regulująca przeniesienie autorskich praw majątkowych (cesję) albo licencję na kod oraz NDA (poufność). NDA samo w sobie nie daje żadnych praw do korzystania z oprogramowania – ogranicza tylko ujawnianie informacji. Kluczowe jest, żeby w umowie IP były opisane konkretne pola eksploatacji, terytorium oraz czas.
Przy cesji spółka staje się właścicielem kodu i może nim swobodnie rozporządzać (w tym udzielać sublicencji klientom). Przy licencji spółka „tylko” uzyskuje prawo używania utworu w określony sposób – trzeba sprawdzić, czy to wystarczy do przyjętego modelu biznesowego (np. SaaS, on‑premise, OEM). Uwaga: kod w repozytorium spółki nie oznacza automatycznie, że spółka ma do niego prawa.
Czym różni się licencja open source typu MIT/BSD od copyleft (GPL, AGPL) dla startupu SaaS?
Licencje typu MIT/BSD są „permisywne” – pozwalają używać kodu w projektach komercyjnych, zamkniętych, zwykle z minimalnymi obowiązkami (np. zachowanie informacji o autorach). Nie wymuszają otwierania całego kodu aplikacji opartej na tej bibliotece.
Licencje copyleft (GPL, AGPL) działają bardziej „zaraźliwie”. Jeśli komponent na GPL/AGPL jest zintegrowany z kluczową logiką aplikacji, może pojawić się obowiązek udostępnienia szerszej części kodu na tej samej licencji. AGPL dodatkowo obejmuje udostępnianie przez sieć (ważne przy SaaS) – użytkownikowi może przysługiwać prawo do wglądu w kod serwera. Dla startupu SaaS to często nieakceptowalne ryzyko.
Jak praktycznie ogarnąć inwentarz licencji w młodym startupie?
Na start wystarczy prosty rejestr: tabela (np. w Notion, Confluence, Google Sheets) z listą bibliotek, ich wersjami, typem licencji, źródłem (repo, vendor) i informacją, w którym module produktu są używane. Później można to zautomatyzować skanerami OSS (np. narzędzia SBOM – Software Bill of Materials) podpinanymi do CI/CD.
Tip: rozdziel kod eksperymentalny od produkcyjnego (osobne repozytoria lub katalogi R&D). To ogranicza ryzyko, że „tymczasowa” biblioteka na problematycznej licencji niechcący trafi na produkcję i do klienta. Przy każdym merge do main/master warto mieć checklistę: czy nowa zależność jest opisana w inwentarzu i czy jej licencja jest akceptowalna.
Kiedy faktycznie muszę skonsultować wybór licencji z prawnikiem, a kiedy wystarczy zdrowy rozsądek?
Zdrowy rozsądek i dokumentacja licencji wystarczą przy prostym użyciu popularnych bibliotek na dobrze opisanych licencjach (MIT, Apache 2.0, BSD) oraz typowych narzędziach SaaS z jasnymi regulaminami. W wielu przypadkach wystarczy, że CTO lub dev lead przeczyta warunki i sprawdzi podstawowe ograniczenia.
Prawnika warto włączyć, gdy:
używasz komponentów na GPL/AGPL/SSPL lub innych quasi‑open‑source w rdzeniu produktu,
tworzysz własną licencję produktu (np. EULA, ToS) albo model OEM/whitelabel,
planujesz duży kontrakt B2B z ostrym SLA i gwarancjami IP,
inwestor sygnalizuje, że będzie robił szczegółowe due diligence licencyjne.
W tych sytuacjach koszt błędu jest na tyle wysoki, że konsultacja jest tańsza niż późniejszy refactoring i renegocjacje z klientami.
Co zrobić, jeśli w produkcie już jest biblioteka na AGPL lub innej „trudnej” licencji?
Najpierw trzeba ustalić, w jakim zakresie ta biblioteka jest zintegrowana z produktem i czy sposób użycia faktycznie aktywuje ostre obowiązki licencji (np. konieczność udostępnienia całości kodu). Tu często przydaje się kombinacja: analiza architektury przez CTO i interpretacja licencji przez prawnika technologicznego.
Typowe ścieżki wyjścia to:
refactoring i zastąpienie komponentu inną biblioteką lub własnym kodem,
zakup komercyjnej licencji od autora projektu (jeśli oferuje dual‑licensing),
ograniczenie użycia komponentu do obszaru, w którym nie „zaraża” reszty aplikacji.
Im wcześniej problem zostanie wykryty (np. przed dużą rundą lub wejściem kluczowego klienta), tym mniej bolesne i tańsze będą konsekwencje.
Czy wystarczy, że w regulaminie SaaS (ToS) napiszę, że „wszystkie prawa do oprogramowania należą do spółki”?
ToS/EULA opisują relację z użytkownikiem końcowym, a nie przenoszą na spółkę praw od developerów, freelancerów czy dostawców zewnętrznych komponentów. Jeśli spółka nie ma poprawnie uregulowanych praw „w górę” (umowy z twórcami kodu, licencje na użyte komponenty), to zapis w regulaminie jest tylko deklaracją bez pokrycia.
Najpierw trzeba zadbać o mocne podstawy: cesje lub licencje z osobami i firmami, które tworzą lub dostarczają kod. Dopiero na tej bazie można sensownie kształtować ToS/EULA, w których definiujesz, co i w jakim zakresie licencjonujesz użytkownikom czy klientom B2B. Inwestorzy szybko wychwytują niespójności między „papierami wewnętrznymi” a dokumentami dla klientów.
Opracowano na podstawie
Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Sejm Rzeczypospolitej Polskiej (1994) – Podstawowe regulacje dot. utworu, praw autorskich i pól eksploatacji
Directive 2009/24/EC of the European Parliament and of the Council on the legal protection of computer programs. European Union (2009) – Ochrona prawna programów komputerowych w prawie UE
Open Source Software: Managing Legal and Business Risks. Oxford University Press (2004) – Ryzyka prawne i biznesowe przy korzystaniu z licencji open source
