Łańcuch praw: dlaczego rundy wywracają się na własności kodu
Zanim term sheet zamieni się w przelew, prawnik funduszu poprosi o jedno: pokażcie, jak prawa do każdego elementu produktu przeszły od osób, które go stworzyły, na spółkę. Ten ślad to łańcuch praw. Dziury w nim opóźniają rundy częściej niż słabe metryki, bo jeden brakujący podpis może oznaczać, że spółka nigdy nie nabyła swojego głównego aktywa.
O co inwestor pyta naprawdę
„Czy macie IP” pada w każdej checkliście i każdy founder odpowiada „tak”. Praca zaczyna się przy kolejnym pytaniu: kto napisał pierwszą wersję silnika, na jakiej umowie i gdzie jest dokument przenoszący te prawa na spółkę? Wyobraźcie sobie ekran udostępniony podczas due diligence: associate otwiera historię repozytorium i wskazuje setki commitów z prywatnego adresu e-mail, datowanych rok przed rejestracją spółki. Jeżeli ich autorem jest współzałożyciel, prawa do tego kodu nadal są przy nim osobiście. Samo zawiązanie spółki niczego nie przeniosło. Ogólny zapis w umowie wspólników, że „całe IP należy do spółki”, zwykle też nie działa, bo nie spełnia wymagań umowy przenoszącej autorskie prawa majątkowe.
Cztery miejsca, w których łańcuch się rwie
Te same cztery dziury wracają w większości spółek technologicznych. Po pierwsze, kod founderów sprzed zawiązania spółki. Po drugie, kontraktorzy. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych). Faktura z wątkiem mailowym niczego nie przenosi. Pracownicy to osobny przypadek: art. 12 daje pracodawcy prawa do utworów stworzonych w ramach obowiązków ze stosunku pracy i tylko w tych granicach, więc aplikacja pisana przy poprzednim projekcie zostaje poza spółką. Po trzecie, open source. Kod zależy od setek pakietów, a licencji nikt nie ewidencjonował; komponent copyleft w rdzeniu produktu wypływa w każdym poważnym przeglądzie. Po czwarte, materiały z narzędzi AI: logo, teksty marketingowe, fragmenty kodu. Czy czysto maszynowy wytwór w ogóle korzysta z ochrony prawnoautorskiej, pozostaje niepewne, a o komercyjnym użyciu rozstrzyga regulamin narzędzia. Jeśli nie umiecie wskazać, który materiał pochodzi z którego narzędzia, nie odpowiecie na pytanie funduszu.
Sprzątanie trwa tygodniami, więc zacznijcie przed rundą
Żadna z tych dziur nie kończy transakcji, jeśli znajdziecie ją pierwsi. Zacznijcie od mapy twórców: każda osoba, która commitowała kod, projektowała grafiki albo pisała treści, ze statusem prawnym w chwili tworzenia (founder, pracownik, kontraktor, agencja). Do każdej pozycji dopasujcie podpisaną umowę przenoszącą prawa. Tam, gdzie jej brakuje, podpiszcie teraz umowę potwierdzającą przeniesienie: na piśmie, z wymienionymi polami eksploatacji, z podpisem rzeczywistego autora. To potrafi się ciągnąć, gdy kontraktor zniknął albo oczekuje dopłaty, więc róbcie to przed rundą, bez presji term sheetu. Potem przeskanujcie zależności pod kątem licencji i prowadźcie wynik jako żywą ewidencję open source. Na końcu ułóżcie wszystko w folderze data roomu, zanim ktokolwiek zapyta: mapa twórców, umowy, aneksy, ewidencja licencji, rejestr materiałów z AI.
Co rekomendujemy teraz
Pięć kroków mieści się w najbliższych dwóch tygodniach:
- Wyciągnijcie pełną historię commitów i zasobów i zróbcie listę autorów ze statusem umownym w chwili tworzenia. Wystarczy jeden arkusz.
- Sprawdźcie każdą teczkę kontraktora: czy jest pisemna umowa z polami eksploatacji. Gdzie jej brakuje, przygotujcie umowy potwierdzające i zacznijcie zbierać podpisy, od najtrudniej osiągalnych autorów.
- Przeskanujcie licencje zależności, zachowajcie wynik i zdecydujcie, co zrobić z ewentualnym copyleftem w rdzeniu produktu.
- Spiszcie jednostronicową zasadę dla materiałów z AI: jakie narzędzia są dozwolone, co logujecie, które zasoby wymagają ludzkiej przeróbki albo wymiany.
- Załóżcie folder IP przyszłego data roomu i jeszcze w tym miesiącu włóżcie do niego wszystko powyższe.
Źródła: Ustawa o prawie autorskim i prawach pokrewnych (ISAP)