Wiele startupów buduje MVP w bardzo praktycznym modelu:
trochę founder, trochę freelancer, trochę software house, trochę AI i trochę open source.
Biznesowo może to działać świetnie. Produkt powstaje szybko, MVP zaczyna działać, można je testować, pokazywać pierwszym klientom i sprawdzać, czy cały pomysł ma sens.
Schody zaczynają się wtedy, gdy inwestor albo klient enterprise pyta: „Okej, a kto właściwie ma prawa do tego produktu?”.
Pierwsza odpowiedź zazwyczaj brzmi: „No jak to kto? My!”.
Potem zaczynamy trochę grzebać i okazuje się, że do części kodu nikt skutecznie nie przeniósł praw, design powstał bez porządnej umowy, w produkcie znajdują się komponenty open source na niesprawdzonych licencjach, a część grafik i treści została wygenerowana przez AI bez żadnych zasad dokumentowania tego procesu.
Do tego repozytorium znajduje się na prywatnym koncie byłego wykonawcy, domenę zarejestrował founder jako osoba fizyczna, a dostęp do infrastruktury ma ktoś, kto nie współpracuje z projektem od roku.
Produkt działa. Dokumenty i dostępy już niekoniecznie.
Produkt to znacznie więcej niż kod
Gdy rozmawiamy o prawach do produktu technologicznego, łatwo skupić się wyłącznie na kodzie źródłowym. Tymczasem cały produkt może składać się z wielu elementów:
- kodu źródłowego i wynikowego;
- architektury systemu;
- dokumentacji technicznej i produktowej;
- interfejsu, makiet oraz designu;
- logo, nazwy i identyfikacji wizualnej;
- treści, grafik, animacji, audio i materiałów marketingowych;
- baz danych i ich struktury;
- domen, repozytoriów, kont oraz konfiguracji środowisk;
- bibliotek, frameworków i innych komponentów zewnętrznych;
- elementów powstałych z wykorzystaniem narzędzi AI.
Każdy z tych składników mógł zostać stworzony przez inną osobę, na podstawie innej umowy i z wykorzystaniem innych materiałów.
Dlatego pytanie „czy mamy prawa do kodu?” może być za wąskie. Trzeba raczej zapytać: czy spółka ma prawa, licencje oraz dostępy potrzebne do rozwijania, oferowania, modyfikowania i sprzedaży całego produktu?
Dlaczego inwestor pyta o IP?
Inwestor nie pyta o prawa do produktu dlatego, że szczególnie lubi papierologię. Chce sprawdzić, czy spółka rzeczywiście ma aktywo, w które ma zainwestować.
Jeżeli startup buduje SaaS, aplikację, grę, marketplace, system AI albo inną technologię, prawa do produktu mogą być jednym z jego najważniejszych składników majątkowych.
Podczas due diligence inwestor może więc sprawdzić:
- kto stworzył poszczególne elementy produktu;
- na jakiej podstawie spółka z nich korzysta;
- czy prawa zostały skutecznie przeniesione albo udzielono odpowiedniej licencji;
- czy spółka może modyfikować i dalej rozwijać produkt;
- czy może udzielać licencji klientom i partnerom;
- czy w produkcie znajdują się komponenty open source albo inne elementy zewnętrzne;
- czy wykorzystano narzędzia AI i jak wyglądał ten proces;
- czy były wykonawca albo founder może później zgłosić prawa do części produktu;
- czy spółka kontroluje repozytoria, domeny, konta i infrastrukturę;
- czy prawa będzie można przenieść przy sprzedaży produktu albo całej spółki.
Nieporządek w IP może opóźnić inwestycję, wpłynąć na wycenę albo spowodować, że inwestor uzależni transakcję od uzupełnienia dokumentów. Podobne pytania może zadać klient enterprise, szczególnie gdy produkt ma zostać wdrożony w jego organizacji albo jest dla niego biznesowo istotny.
Zapłacona faktura nie oznacza automatycznie przejścia praw
To jeden z najczęstszych błędów przy tworzeniu produktów cyfrowych.
Startup zamawia kod, logo albo projekt interfejsu. Wykonawca realizuje zlecenie, przekazuje pliki i wystawia fakturę. Startup płaci, więc zakłada, że wszystko należy już do niego.
Tymczasem wykonanie usługi, przekazanie plików, zapłata wynagrodzenia, udzielenie licencji i przeniesienie autorskich praw majątkowych to różne rzeczy.
Można zapłacić za kod i nie nabyć do niego autorskich praw majątkowych. Można otrzymać pliki źródłowe, ale mieć jedynie ograniczone prawo korzystania z nich. Można też legalnie używać elementu w MVP, lecz nie mieć prawa do jego dalszej modyfikacji, udzielania sublicencji, wdrażania u klientów albo przeniesienia do nowo utworzonej spółki.
Inaczej może wyglądać sytuacja programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy, a inaczej kodu przygotowanego przez freelancera prowadzącego działalność gospodarczą. Sam fakt, że programista otrzymał wynagrodzenie w modelu B2B, nie tworzy automatycznie takiego samego skutku jak regulacja dotycząca programu pracowniczego.
Dlatego przy każdym twórcy trzeba sprawdzić konkretną podstawę współpracy i treść jego umowy.
Forma pisemna może zdecydować o wszystkim
Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności.
W praktyce oznacza to, że niewystarczające mogą okazać się:
- ustalenia mailowe;
- wiadomości na komunikatorze;
- zaakceptowana oferta;
- wystawiona i opłacona faktura;
- protokół przekazania plików;
- dostęp do repozytorium;
- ogólne stwierdzenie, że „wszystko należy do zamawiającego”.
Takie materiały mogą potwierdzać zakres współpracy, sposób wykonania zlecenia albo dokonanie zapłaty. Nie zastąpią jednak wymaganej formy umowy przenoszącej prawa.
Forma pisemna nie musi oznaczać wyłącznie kartki podpisanej długopisem. Może zostać zachowana również przez opatrzenie dokumentu kwalifikowanym podpisem elektronicznym. Zwykły skan podpisanej umowy albo akceptacja dokumentu przez e-mail nie są jednak tym samym co forma pisemna.
To szczególnie ważne, gdy twórcami są freelancerzy, founderzy albo osoby pracujące w modelu B2B. Szukanie wykonawcy po dwóch latach i proszenie go o podpisanie brakującej umowy w chwili, gdy inwestor czeka już na dokumenty, nie jest komfortową pozycją negocjacyjną.
Co powinna regulować umowa z wykonawcą?
Samo wpisanie jednego zdania o przeniesieniu praw może nadal nie wystarczyć. Umowa powinna pasować do produktu i sposobu jego dalszej komercjalizacji.
Warto uregulować przede wszystkim:
- jakie elementy i rezultaty prac obejmuje umowa;
- czy prawa są przenoszone, czy wykonawca udziela licencji;
- na jakich polach eksploatacji można korzystać z utworów;
- kiedy następuje przeniesienie praw;
- czy wynagrodzenie obejmuje również przeniesienie praw;
- czy spółka może modyfikować i rozwijać otrzymane elementy;
- czy może zezwalać innym osobom na wykonywanie praw zależnych;
- czy może udzielać licencji i sublicencji;
- czy może przenieść prawa na inną spółkę, inwestora albo nabywcę produktu;
- jakie elementy powstały wcześniej i nie przechodzą na startup;
- czy wykonawca korzystał z open source, narzędzi AI albo materiałów osób trzecich;
- jakie oświadczenia i zasady odpowiedzialności obowiązują przy naruszeniu cudzych praw.
Trzeba też odróżnić IP tworzone specjalnie dla startupu od uniwersalnych bibliotek, frameworków i know-how wykonawcy. Startup powinien wiedzieć, co rzeczywiście nabywa, a wykonawca nie powinien przypadkowo przenosić praw do narzędzi wykorzystywanych wcześniej w wielu projektach.
Open source nie oznacza „można robić wszystko”
Korzystanie z open source jest normalnym elementem tworzenia oprogramowania. Problemem nie jest samo używanie takich komponentów, lecz brak wiedzy o tym, co znajduje się w produkcie i na jakich zasadach można z tego korzystać.
Licencje open source mają różne warunki. Niektóre pozwalają na szerokie wykorzystanie komercyjne przy zachowaniu informacji o autorze i licencji. Inne mogą nakładać dalej idące obowiązki, zależnie od sposobu wykorzystania, modyfikacji i dystrybucji komponentu.
Dlatego startup powinien wiedzieć:
- jakie komponenty zewnętrzne znajdują się w produkcie;
- na jakich licencjach są udostępniane;
- czy licencje są zgodne z modelem dystrybucji produktu;
- jakie informacje i dokumenty trzeba przekazywać użytkownikom;
- kto zatwierdza dodawanie nowych zależności;
- kto monitoruje podatności i aktualizacje.
Przy większym produkcie pomocne mogą być rejestr komponentów, podstawowa polityka open source i narzędzia pozwalające analizować zależności. Nie trzeba od pierwszego dnia tworzyć korporacyjnej procedury na kilkadziesiąt stron. Trzeba jednak umieć ustalić, co znajduje się w produkcie.
Co z elementami wygenerowanymi przez AI?
Tutaj prosta odpowiedź „skoro wygenerowaliśmy, to jest nasze” może być zbyt odważna.
W produkcie mogą pojawić się wygenerowane grafiki, teksty, ikony, fragmenty kodu, dokumentacja, muzyka albo inne assety. Trzeba wtedy rozdzielić kilka kwestii.
Po pierwsze, należy sprawdzić regulamin konkretnego narzędzia i warunki komercyjnego korzystania z wyników.
Po drugie, sam regulamin dostawcy nie przesądza, że każdy wygenerowany materiał jest utworem chronionym prawem autorskim ani że użytkownikowi powstają do niego wyłączne prawa. Znaczenie może mieć zakres twórczego wkładu człowieka, sposób opracowania wyniku i dalsze modyfikacje.
Po trzecie, trzeba ocenić ryzyko podobieństwa wyniku do materiałów osób trzecich, znaków towarowych, postaci albo innych chronionych elementów.
Po czwarte, należy sprawdzić, jakie dane, kod i materiały zespół wprowadza do narzędzia. Problem może dotyczyć nie tylko praw do wyniku, ale też poufności, danych osobowych i tajemnicy przedsiębiorstwa.
W praktyce startup powinien ustalić:
- z jakich narzędzi AI można korzystać;
- jakie informacje wolno do nich wprowadzać;
- do czego można wykorzystywać wygenerowane wyniki;
- kto sprawdza wynik przed włączeniem go do produktu;
- jak dokumentowane są istotne elementy powstałe z użyciem AI;
- czy dany asset powinien być dalej opracowany przez człowieka;
- czy przy kluczowych elementach marki albo produktu lepiej skorzystać z pracy twórcy i klasycznej umowy.
Nie każdy element wygenerowany przez AI oznacza automatycznie niedopuszczalne ryzyko. Trzeba jednak wiedzieć, gdzie takie elementy znajdują się w produkcie i na jakiej podstawie startup z nich korzysta.
Prawa bez dostępu mogą być mało użyteczne
Porządek w IP obejmuje również techniczną kontrolę nad produktem.
Spółka może mieć dobrą umowę z wykonawcą, ale nadal być uzależniona od jego prywatnego konta, jeżeli:
- repozytorium znajduje się wyłącznie na koncie wykonawcy;
- domena jest zarejestrowana na foundera jako osobę prywatną;
- tylko jedna osoba ma dostęp administratora do chmury;
- klucze API i dane uwierzytelniające są przechowywane na prywatnym urządzeniu;
- konta w sklepach z aplikacjami należą do byłego członka zespołu;
- nie istnieje aktualna lista osób i poziomów dostępu.
Prawa do kodu i faktyczna możliwość korzystania z produktu to dwa różne elementy, ale oba będą miały znaczenie dla inwestora, klienta i samej spółki.
Co sprawdzić przed due diligence?
Przed rozmową z inwestorem albo klientem enterprise przeszedłbym przynajmniej przez następującą listę:
- kto stworzył kod, design, dokumentację i pozostałe assety;
- czy z każdą z tych osób zawarto właściwą umowę;
- czy przeniesienie praw zachowuje wymaganą formę;
- czy umowy wskazują odpowiednie pola eksploatacji;
- czy spółka może modyfikować, rozwijać i komercjalizować produkt;
- czy prawa można przenieść lub udzielać dalszych licencji;
- które elementy stanowią wcześniejsze IP founderów albo wykonawców;
- jakie komponenty open source i zewnętrzne znajdują się w produkcie;
- które elementy powstały z wykorzystaniem AI;
- kto kontroluje repozytoria, domeny, konta oraz infrastrukturę;
- czy da się odtworzyć i udokumentować proces tworzenia produktu;
- czy wszystkie dokumenty są przypisane do właściwej osoby albo spółki.
Jeżeli przy kilku punktach odpowiedź brzmi „nie wiem”, nie oznacza to jeszcze, że produkt nie nadaje się do inwestycji. Oznacza natomiast, że chain of title, czyli łańcuch praw do produktu, wymaga uporządkowania.
Podejście „najpierw dowieziemy produkt, a papiery ogarniemy później” jest kuszące. Tylko że późniejsze porządkowanie może oznaczać szukanie freelancera sprzed dwóch lat i proszenie go o podpisanie umowy wtedy, gdy inwestor czeka już na komplet dokumentów.
Produkt i porządek w IP najlepiej budować równolegle. Naprawdę wychodzi szybciej, taniej i z mniejszą liczbą niespodzianek.
Bo nawet świetny produkt może się wyłożyć przy due diligence na czymś znacznie mniej efektownym niż technologia: na papierach.
