Founderzy często zakładają, że skoro produkt powstał „u nas”, to prawa do produktu też są „nasze”.
Przy pierwszej rozmowie z inwestorem albo klientem enterprise może się jednak okazać, że największym problemem nie jest brak produktu. Problemem jest brak porządku wokół produktu.
I dokładnie to potrafi zaboleć w due diligence.
Przy due diligence nie wystarczy powiedzieć: produkt jest nasz. Trzeba umieć pokazać, kto go stworzył, na jakich zasadach i gdzie są prawa.
Czego dowiesz się z tego tekstu?
- dlaczego chaos wokół IP może być większym problemem niż sam brak dokumentów,
- co inwestor albo klient enterprise będzie chciał zobaczyć przy due diligence,
- dlaczego samo opłacenie freelancera albo software house’u nie zawsze oznacza skuteczne nabycie praw,
- dlaczego forma pisemna umowy o przeniesienie praw autorskich jest tak ważna,
- jak uporządkować kod, design, dokumentację, AI-generated assets, open source i repozytoria,
- jaką checklistę warto przejść przed rozmową inwestorską albo sprzedażą do większego klienta.
Produkt to nie tylko kod
W wielu startupach MVP powstaje w modelu bardzo praktycznym:
- trochę founder,
- trochę freelancer,
- trochę software house,
- trochę AI assistant,
- trochę open source,
- trochę gotowe biblioteki,
- trochę komponenty z poprzednich projektów.
Biznesowo to często działa świetnie. Zespół szybko dowozi pierwszą wersję produktu, testuje rynek, pokazuje demo, zbiera feedback, buduje pierwsze integracje i zaczyna rozmowy z klientami.
Problem pojawia się dopiero wtedy, gdy ktoś zadaje proste pytanie: „Kto właściwie ma prawa do tego produktu?”.
Na początku odpowiedź zwykle brzmi: „My”. Ale gdy zaczyna się due diligence, trzeba pokazać więcej niż przekonanie founderów. Trzeba pokazać dokumenty.
Chaos wokół IP wychodzi dopiero przy due diligence
Przy rozmowie z inwestorem albo klientem enterprise może się okazać, że produkt działa, roadmapa wygląda dobrze, demo robi wrażenie, ale dokumenty nie dowożą.
Typowe problemy wyglądają tak:
- część kodu nie ma poprawnego assignmentu,
- design był robiony „na szybko”,
- grafikę przygotował znajomy bez umowy,
- UI/UX był projektowany na prywatnym koncie narzędzia,
- promptów i AI-generated assets nikt nie kontrolował,
- repozytoria są pomieszane,
- domena jest na osobę prywatną,
- logo nie zostało sprawdzone ani przeniesione,
- freelancer wystawił fakturę, ale nie podpisał umowy przeniesienia praw,
- software house przekazał kod, ale niekoniecznie pełnię praw w zakresie potrzebnym do komercjalizacji,
- umowa mówi ogólnie „prawa przechodzą na zamawiającego”, ale nie wskazuje pól eksploatacji,
- nie ma jasnego rozdzielenia między produktem startupu a uniwersalnymi bibliotekami foundera.
I wtedy problemem nie jest brak IP. Problemem jest chaos wokół IP.
Dlaczego inwestor pyta o IP?
Inwestor nie pyta o prawa do produktu dlatego, że lubi dokumenty. Pyta, bo chce wiedzieć, czy spółka faktycznie ma aktywo, w które inwestuje.
Jeżeli startup sprzedaje produkt cyfrowy, SaaS, aplikację, marketplace, system AI, grę, platformę albo technologię B2B, to prawa do produktu często są jednym z najważniejszych aktywów spółki.
Inwestor chce więc sprawdzić:
- kto stworzył kod,
- kto stworzył architekturę,
- kto stworzył UI/UX,
- kto stworzył dokumentację,
- kto stworzył logo, nazwę, grafikę i materiały marketingowe,
- kto ma prawa do domen,
- czy prawa zostały przeniesione na spółkę,
- czy spółka może komercjalizować produkt,
- czy spółka może udzielać licencji i sublicencji,
- czy spółka może sprzedać produkt albo spółkę,
- czy w produkcie są elementy open source,
- czy użyto AI-generated assets,
- czy ktoś z zewnątrz może później powiedzieć: to jest moje.
To jest bardzo praktyczne pytanie o ryzyko. Jeżeli prawa są nieuporządkowane, inwestor może:
- obniżyć wycenę,
- uzależnić inwestycję od naprawienia dokumentów,
- zażądać dodatkowych oświadczeń i zabezpieczeń,
- przesunąć transakcję,
- albo po prostu zrezygnować.
Samo zapłacenie faktury nie zawsze wystarczy
To jeden z najczęstszych błędów. Startup płaci freelancerowi za logo, makiety, kod albo teksty i zakłada, że skoro zapłacił, to „ma prawa”.
Tymczasem w prawie autorskim trzeba odróżnić kilka rzeczy:
- wykonanie usługi,
- wydanie pliku,
- zapłatę wynagrodzenia,
- udzielenie licencji,
- przeniesienie autorskich praw majątkowych.
To nie jest to samo.
Można zapłacić za stworzenie kodu i nadal nie mieć skutecznie przeniesionych praw. Można dostać pliki źródłowe i nadal mieć tylko ograniczoną licencję. Można używać projektu w MVP, ale nie mieć prawa do jego dalszej komercjalizacji, modyfikacji, sublicencjonowania albo wniesienia do spółki.
Można też mieć umowę, która wygląda dobrze biznesowo, ale prawnie nie przenosi tego, co miała przenieść.
Dlatego w startupie technologicznym trzeba patrzeć nie tylko na to, czy coś zostało dowiezione. Trzeba sprawdzić, czy prawa do tego czegoś zostały poprawnie ułożone.
Forma pisemna umowy o przeniesienie praw autorskich. Dlaczego to jest tak ważne?
To jest punkt, który w startupach nadal bywa lekceważony. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności.
Mówiąc prościej: jeżeli nie ma prawidłowo podpisanej umowy, może nie być skutecznego przeniesienia praw.
Nie wystarczy więc:
- mail z ustaleniami,
- akceptacja oferty w komunikatorze,
- faktura,
- przelew,
- przekazanie plików,
- wpis w Trello,
- komentarz w repozytorium,
- ogólne „dogadaliśmy się”,
- regulamin narzędzia, który nie rozwiązuje konkretnej relacji między stronami.
To może być dowód współpracy, zakresu zlecenia albo rozliczenia. Ale samo w sobie nie musi wystarczyć do przeniesienia autorskich praw majątkowych.
W praktyce oznacza to, że jeżeli freelancer, grafik, designer, copywriter, programista albo zewnętrzny wykonawca tworzy elementy produktu, to trzeba zadbać o podpisaną umowę obejmującą przeniesienie praw albo odpowiednio szeroką licencję.
W startupach często słyszę: „Ale przecież mamy fakturę”. Faktura może potwierdzać, że ktoś wykonał usługę i dostał wynagrodzenie. Nie oznacza automatycznie, że prawa zostały skutecznie przeniesione.
Co powinna zawierać dobra umowa przeniesienia praw?
Sama forma pisemna to dopiero początek. Dobra umowa przeniesienia praw autorskich powinna odpowiadać co najmniej na kilka praktycznych pytań.
Co dokładnie jest przenoszone?
Trzeba opisać utwory albo rezultaty prac.
W startupie mogą to być na przykład:
- kod źródłowy,
- kod wynikowy,
- architektura systemu,
- dokumentacja techniczna,
- dokumentacja produktowa,
- UI/UX,
- makiety,
- grafiki,
- logo,
- teksty,
- bazy danych,
- modele, prompt templates i konfiguracje,
- materiały marketingowe,
- prezentacje,
- elementy audio/wideo,
- fragmenty aplikacji albo moduły.
Im bardziej konkretny opis, tym łatwiej później pokazać, co rzeczywiście przeszło na spółkę.
Na jakich polach eksploatacji?
Umowa o przeniesienie praw albo licencja musi obejmować pola eksploatacji wyraźnie w niej wymienione.
Nie wystarczy więc ogólne zdanie: „wykonawca przenosi wszelkie prawa”.
W kontekście produktu cyfrowego trzeba pomyśleć m.in. o:
- utrwalaniu,
- zwielokrotnianiu,
- wprowadzaniu do obrotu,
- wprowadzaniu do pamięci komputera,
- publicznym udostępnianiu,
- korzystaniu w modelu SaaS,
- udostępnianiu użytkownikom przez internet,
- modyfikowaniu,
- integrowaniu z innym oprogramowaniem,
- tworzeniu wersji rozwojowych,
- wdrażaniu u klientów,
- udzielaniu licencji i sublicencji,
- wykorzystywaniu w materiałach sprzedażowych i inwestorskich.
To trzeba dopasować do konkretnego produktu. Inaczej będą wyglądały pola eksploatacji dla aplikacji SaaS, inaczej dla gry, inaczej dla dokumentacji, inaczej dla logo, a jeszcze inaczej dla treści marketingowych.
Kiedy prawa przechodzą?
Umowa powinna określać moment przejścia praw.
Przykładowo:
- z chwilą zapłaty wynagrodzenia,
- z chwilą odbioru utworu,
- z chwilą podpisania protokołu odbioru,
- z chwilą przekazania konkretnego deliverable,
- z chwilą ustalenia utworu,
- albo według innego mechanizmu ustalonego przez strony.
To ma znaczenie szczególnie wtedy, gdy projekt jest realizowany etapami.
Jeżeli startup płaci za sprinty, zlecenia wykonawcze albo kolejne wersje produktu, warto wiedzieć, czy prawa przechodzą po każdym etapie, po zapłacie, czy dopiero po finalnym odbiorze.
Czy obejmuje prawa zależne?
W produkcie cyfrowym możliwość modyfikowania, rozwijania, łączenia i tworzenia kolejnych wersji jest kluczowa.
Dlatego trzeba zadbać nie tylko o przeniesienie autorskich praw majątkowych, ale także o zgodę na wykonywanie i zezwalanie na wykonywanie praw zależnych, jeżeli jest potrzebna.
Bez tego może pojawić się problem przy dalszym rozwoju produktu, refaktoryzacji, tworzeniu forków, wersji enterprise, white-label, integracji albo nowych modułów.
Czy spółka może udzielać sublicencji i przenosić prawa dalej?
Jeżeli startup planuje sprzedaż produktu, model SaaS, partnerstwa, marketplace, white-label, współpracę z integratorami albo przyszłą transakcję inwestycyjną, warto przewidzieć możliwość:
- udzielania licencji,
- udzielania sublicencji,
- przenoszenia praw na podmioty z grupy,
- przenoszenia praw na następcę prawnego,
- wniesienia praw do spółki,
- sprzedaży praw razem z przedsiębiorstwem albo produktem.
Brak takich postanowień może być problemem przy skalowaniu.
Co z pre-existing IP i bibliotekami foundera?
To bardzo ważne w startupach technologicznych.
Nie wszystko, co znajduje się w repozytorium, musi być własnością spółki. Founder albo wykonawca może mieć własne wcześniejsze biblioteki, frameworki, komponenty, know-how, snippet’y, template’y albo narzędzia wykorzystywane w wielu projektach.
Umowa powinna jasno rozróżniać:
- IP tworzone specjalnie dla startupu,
- IP istniejące wcześniej,
- komponenty open source,
- narzędzia third-party,
- know-how foundera albo software house’u,
- elementy, do których startup dostaje tylko licencję.
To chroni obie strony. Startup wie, co posiada. Founder albo wykonawca nie traci przypadkowo uniwersalnych bibliotek, których używa w innych projektach.
Co z AI-generated assets?
Coraz częściej elementy produktu powstają przy pomocy narzędzi AI.
Może to dotyczyć:
- grafik,
- tekstów,
- ikon,
- fragmentów kodu,
- promptów,
- dokumentacji,
- materiałów marketingowych,
- danych testowych,
- nazw,
- koncepcji UX.
W umowie i procesie warto ustalić:
- jakich narzędzi AI wolno używać,
- czy wolno wprowadzać dane klienta albo kod do modelu,
- kto odpowiada za weryfikację wyników,
- czy output może być komercyjnie wykorzystywany,
- czy trzeba oznaczać użycie AI,
- gdzie dokumentujemy użycie AI,
- czy AI-generated elementy wchodzą do produktu, czy tylko pomagają w pracy.
To nie jest temat „na później”. Przy większym kliencie albo inwestorze pytanie o AI-generated assets może pojawić się szybciej, niż founderzy zakładają.
Co warto uporządkować jak najszybciej?
Najlepiej równolegle z tworzeniem produktu. Podejście „najpierw dowieziemy produkt, papiery ogarniemy później” może ostro namieszać.
Na start warto uporządkować:
- ownership kodu i assetów,
- umowy z founderami,
- umowy z freelancerami i software house’ami,
- zasady korzystania z AI tools,
- repozytoria i dostęp do nich,
- domeny i konta,
- open source i komponenty third-party,
- dokumentację procesu tworzenia produktu,
- rozdzielenie IP produktu od uniwersalnego know-how,
- zasady przeniesienia IP do spółki albo licencji dla spółki.
Nie chodzi o to, żeby od pierwszego dnia tworzyć korporacyjny data room. Chodzi o to, żeby później dało się odpowiedzieć na trzy pytania:
- kto stworzył produkt,
- na jakich zasadach,
- kto realnie ma do niego prawa.
Praktyczna checklista IP przed due diligence
- Czy spółka ma podpisane umowy z wszystkimi osobami, które tworzyły kod, design, dokumentację, treści albo materiały marketingowe?
- Czy umowy przeniesienia praw autorskich mają formę pisemną?
- Czy umowy wskazują konkretne pola eksploatacji?
- Czy wiadomo, kiedy prawa przechodzą na spółkę?
- Czy spółka ma zgodę na modyfikacje i rozwój produktu?
- Czy spółka może udzielać licencji i sublicencji?
- Czy prawa do kodu, repozytoriów, domen i kont są po stronie właściwego podmiotu?
- Czy wiadomo, które elementy są open source albo third-party?
- Czy wiadomo, jakie elementy powstały z użyciem AI?
- Czy founderzy rozdzielili IP produktu od własnych uniwersalnych bibliotek i know-how?
- Czy dokumenty są spójne z umową spółki, founders agreement i dokumentami inwestorskimi?
- Czy da się szybko pokazać inwestorowi albo klientowi, skąd wzięły się prawa do produktu?
Jeżeli odpowiedź na kilka z tych pytań brzmi „nie wiem”, to nie znaczy, że projekt jest zły. To znaczy, że trzeba uporządkować chain of title.
Na koniec
Founderzy powinni dbać o porządek w IP od początku. Nie dlatego, że papiery są ważniejsze niż produkt.
Tylko dlatego, że bez porządku w IP produkt może okazać się trudniejszy do sfinansowania, sprzedaży, wdrożenia u klienta enterprise albo przeniesienia do spółki.
Największym blockerem przy due diligence czasem nie jest technologia. Jest nim brak możliwości pokazania:
- kto stworzył produkt,
- na jakich zasadach,
- i kto realnie ma do niego prawa.
Protip: warto robić to równolegle. Produkt i dokumenty nie powinny żyć w dwóch osobnych światach.
Budujesz produkt i chcesz uporządkować IP przed inwestorem?
Pomagam startupom i software house’om uporządkować prawa do kodu, designu, dokumentacji i umowy z wykonawcami, AI-generated assets, repozytoria oraz domeny. Przygotowuję umowy przeniesienia praw, licencje, IP assignment, NDA i dokumenty potrzebne przed rozmową z inwestorem albo klientem enterprise.