10 gru Najdroższy błąd początkujących w SaaS: Dlaczego zapłacona faktura nie daje Ci praw do “kupionego” kodu?
Błąd, który może kosztować Cię firmę (dosłownie)
Wyobraź sobie taką sytuację: zatrudniony na zlecenie programista (np. freelancer) dostarcza Ci kluczowy element na którym opiera się Twój nowy produkt i Twoja aplikacja wreszcie działa. Fakturę płacisz w terminie i myślisz sobie, że jest po sprawie, prawda?
Następnie wchodzisz w rundę inwestycyjną. Inwestor robi due diligence (audyt prawny) przedsięwzięcia. W trakcie audytu pyta o umowy z programistami, a Ty pokazujesz mu faktury. Później pada zdanie, które mrozi Ci krew w żyłach, każdego początkującego przedsiębiorcy: „Przykro mi, ale Twoja spółka nie jest właścicielem tego kodu. Właścicielem nadal jest programista Piotrek”.
Zastanawiasz się: Jak to możliwe? Przecież zapłaciłaś/zapłaciłeś!
Niestety, w świetle prawa autorskiego w tej sytuacji „zapłaciłam” nie oznacza „kupiłam” i jest to jeden z kosztowniejszych i najczęstszych błędów, jakie widzę u startupów technologicznych.
Faktura to nie umowa (a przelew to nie przeniesienie praw)
Większość founderów działa intuicyjnie: skoro płacę za stworzenie czegoś (kodu, grafiki, tekstu), to logiczne jest, że to należy do mnie. Gdy robisz zakupy płacisz, to towar jest Twój. Problem polega na tym, że kod to nie towar. Kod to utwór.
A jak utwór to wkraczamy na pole prawa autorskiego, które posługuje się zasadą ochrony twórcy. Jeżeli nie masz pisemnej umowy, z której jasno wynika, że Kowalski-programista przenosi autorskie prawa majątkowe na Twoją firmę, to zgodnie z zasadami prawa autorskiego uznaje się, że Kowalski udzielił Ci tylko i wyłącznie licencji do swojego kodu.
Zgodnie z art. 53 prawa autorskiego: przeniesienie autorskich praw majątkowych do jakiegokolwiek utworu wymaga umowy pisemnej pod rygorem nieważności. Co powoduje, że przy braku umowy pisemnej do żadnego przeniesienia praw nie dochodzi i zostajesz tylko licencjobiorcą.
Czym licencja różni się od przeniesienia autorskich praw majątkowych?
Wyobraź sobie różnicę między kupnem mieszkania a jego wynajmem.
Przeniesienie praw (Kupno): Z mieszkaniem (teoretycznie) możesz robić co chcesz. Wyburzyć ścianę, pomalować na różowo, a przede wszystkim – sprzedać je komuś innemu.
Licencja (Wynajem): Możesz tam mieszkać, ale nie możesz go przebudować ani sprzedać. Na przemalowanie potrzebujesz zgody właściciela, a właściciel i tak może w każdej chwili wypowiedzieć Ci umowę lub… „wynająć” albo co gorsze sprzedać ten sam kod Twojej konkurencji.
Dla startupu SaaS, który planuje globalną ekspansję lub exit (sprzedaż), w tym sensie licencja jest bezwartościowa. Inwestor nie kupi choćby fragmentu firmy (nie dokona inwestycji), która „wynajmuje” swój własny produkt.
Bez przeniesienia praw nie możesz:
1) Modyfikować kodu, a tym samym rozwijać produktu.
2) Licencjonować go dalej swoim klientom B2B.
3) Wycenić go jako aktywa spółki.
4) Zabronić programiście sprzedania tego samego modułu komuś innemu.
„Ale my mamy do siebie zaufanie”
Wierzę. Naprawdę. Tylko jakoś tak się składa, że większość katastrof prawnych zaczyna się od wielkiej przyjaźni, wielkich słów i podejścia „jakoś się dogadamy”.
Problemy pojawiają się najwcześniej wtedy, gdy:
> Zatrudniony programista dostaje lepszą ofertę i odchodzi, zabierając swoją wiedzę (i prawa do kodu).
> Twój startup odnosi sukces i nagle programista uświadamia sobie, że ten kawałek kodu, który kiedyś napisał za 3000 zł, jest teraz wart miliony.
> Pojawia się konflikt wspólników i finalnie ktoś odchodzi zabierając swoje „zabawki”.
Wtedy brak tej jednej umowy może zablokować Cię na wiele miesięcy. Ponadto jego „zdobycie” na tym etapie może być baaardzo kosztowne.
Co robić i jak to naprawić? (Zanim będzie za późno)
Dobra wiadomość jest taka, że dopóki masz kontakt z twórcami, możesz to naprawić. Zawsze lepiej jednak zapobiegać niż leczyć, dlatego potrzebujesz „Tarczy IP” – solidnej umowy lub w przypadku ratowania sytuacji aneksu do umowy.
Co musi się w niej znaleźć, żebyś mogła spać spokojnie?
1) Forma pisemna pod rygorem nieważności. E-mail nie wystarczy. PDF podpisany bez kwalifikowanego podpisu elektronicznego też może być podważony w sądzie.
2) Słowa-klucze: „Przeniesienie autorskich prawa majątkowych”. Unikaj słów „udostępnienie”, „korzystanie”. Musi być jasno napisane, że autorskie prawa majątkowe są przenoszone na spółkę.
3) Wynagrodzenie za przeniesienie autorskich praw majątkowych, w umowie musi znaleźć się rozstrzygnięcie tych kwestii najlepiej, gdyby kwota wynagrodzenia uzgodnionego za stworzenie kodu obejmuje również wynagrodzenie należne z tytułu przeniesienia autorskich praw majątkowych.
4) Moment przejścia praw. Najlepiej z chwilą ustalenia/utrwalenia utworu (czyli w momencie napisania kodu), a nie dopiero z chwilą zapłaty całej faktury.
5) Pola eksploatacji. To już stricte prawnicze określenie na to, co w ramach przysługujących Ci jako nabywcy praw możesz zrobić z tym kodem (kopiować, drukować, modyfikować, sprzedawać, wrzucać do chmury). Muszą być wymienione konkretnie. Podstawowy katalog takich pól został wymieniony wprost w ustawie (art. 50)
Sprawdź swoje fundamenty
Nie pozwól, by „papierologia” a właściwie jej brak zniszczyła to, co budujesz miesiącami albo nawet latami. Twoja własność intelektualna jest tym co odróżnia Cię od konkurencji. Zadbaj o to, aby te często najcenniejsze dla biznesu prawa należały do Ciebie, a nie do podwykonawców, byłych pracowników czy byłych wspólników.
Nie jesteś pewna/pewny, co masz w umowach ze swoim software housem lub programistami freelancerami?
Nie czekaj na audyt inwestora. Napisz do mnie albo od razu umów się na konsultację podczas, której rzucę okiem na Twoje dokumenty i powiem Ci, czy kod Twojej aplikacji lub inne rozwiązania programistyczne są naprawdę Twoje.
