Ochrona pomysłu na aplikację w praktyce
W dzisiejszej lekcji chcę na początek opowiedzieć Ci o wydarzeniach związanych z powstaniem Snapchata. Aplikacja umożliwiająca wysyłanie zdjęć, które znikają po kilku sekundach, została założona przez Evana Spiegela, Bobby'ego Murphy'ego i Reggie'ego Browna.
Reggie Brown, będący współlokatorem i kolegą z klasy Spiegela, rzekomo wpadł na pomysł aplikacji umożliwiającej wysyłanie znikających zdjęć i podzielił się nim ze Spiegelem. Wszyscy trzej zaczęli wspólnie pracować nad wczesną wersją aplikacji, znaną wtedy jako "Picaboo".
Ale jak to bywa w relacjach gdzie stawką jest pieniądz, Spiegel i Murphy postanowili wyrzucić Browna ze startupu. Twierdzili, że nie przyczynił się wystarczająco do rozwoju produktu. Weszli w spór. Brown twierdził, że skoro był pomysłodawcą koncepcji to jego wkład był kluczowy dla stworzenia aplikacji. Sprawa skończyła się w sądzie - Brown pozwał Spiegela i Murphy'ego, domagając się uznania jego udziału w założeniu firmy i odszkodowania. Ostatecznie strony doszły do ugody, której szczegóły nie zostały ujawnione, ale Brown został oficjalnie uznany za jednego z założycieli Snapchata.
Wniosek płynący z powyższej historii jest taki, że skoro istnieje zagrożenie dla pomysłu, gdy budujesz aplikację w grupie bliskich znajomych, to tym bardziej, gdy rozwijasz produkt:
a) z innymi specjalistami poznanymi na wydarzeniu branżowym
b) z wykorzystaniem usług software house’u
czy
c) udzielasz dostępu do MVP testerom
d) prowadzisz rozmowy z inwestorami
- powinieneś zadbać o ochronę pomysłu, który realizujesz bądź będziesz realizował w ramach tych współprac.
Jak to zrobić?
I. Founders Agreement
Pierwszym krokiem w dobrym kierunku pod kątem ochrony pomysłu jest podpisanie umowy założycielskiej, inaczej Founders Agreement. Lekcję i kompletny tutorial sporządzenia tego dokumentu znajdziesz tu. Polecam Ci zapoznanie się z tym podrozdziałem handbooka, a teraz zanurzmy się w temacie ochrony pomysłu głębiej.
II. Czy do pomysłu zastosujemy ochronę z przepisów prawa autorskiego?
Zacznijmy od tego, czym właściwie jest pomysł na aplikację.
Jeśli mamy nowatorską myśl lub plan dotyczący tego, co można by zrobić lub jak coś zrobić inaczej niż było to robione dotychczas - mamy pomysł. Z perspektywy prawa jednak, dopóki koncepcja aplikacji nie została w jakiś sposób wyrażona - czy to w dokumentacji czy w formie choćby nieukończonego kodu źródłowego - nie podlega ochronie tzw. prawnoautorskiej. Innymi słowy, po przeciwnej stronie naszego miasta czy kraju, ktoś inny może mieć całkiem zbliżoną myśl, i dopóki my czy nasz potencjalny konkurent pomysłu nie „ustalimy”, z perspektywy prawa autorskiego nic się nie stało. Dopiero kiedy pomysł zostanie „ustalony”, tj. uzewnętrzniony w postaci np. kodu źródłowego - prawo autorskie wskoczy na swoje miejsce i obejmie ochroną ten kod źródłowy.
Skoro jednak ochroną będzie objęty kod źródłowy, to czy nasz konkurent może pomysł na identyczną funkcję aplikacji wyrazić innym kodem źródłowym i uzyskać ochroną prawnoautorską? W tym cały szkopuł, że tak. Prawo autorskie nie chroni więc pomysłu, lecz efekty naszej pracy.
Jakie ma to znaczenie dla startupu? Jeśli prezentuje inwestorowi materiały, które już są chronione prawem autorskim, takie jak oprogramowanie, dodatkowa umowa w tym zakresie (o której za moment sobie opowiemy) może być niepotrzebna. Dzieje się tak, ponieważ prawo autorskie automatycznie zabezpiecza te utwory, nie wymagając od twórców żadnych dodatkowych działań formalnych. W takiej sytuacji, bez wyraźnej zgody w formie licencji lub przeniesienia praw autorskich, inwestor nie ma prawa wykorzystywać dzieła zaprezentowanego w ramach pitchu przez startup, na przykład aplikacji, dla własnych potrzeb.
Jednakże takie sytuacje zdarzają się rzadko. W większości przypadków, oprócz utworów chronionych prawem autorskim, inwestor ma dostęp do różnorodnych materiałów nieobjętych taką ochroną. Mowa tutaj o elementach takich jak właśnie pomysły i koncepcje, strategie biznesowe, informacje finansowe, szczegółowa wiedza specjalistyczna dotycząca określonego sektora rynku, w tym na przykład cen i marż, profil klientów, czy unikalna wiedza techniczna.
Co zatem zrobić, aby wykonawca (np. software house) lub inwestor, nie eksploatowali naszego pomysłu?
III. Umowa o zachowaniu poufności
Z pomocą przychodzi nam umowa o zachowaniu poufności, tzw. NDA (ang. Non-disclosure agreement) albo inaczej CDA (ang. Confidential disclosure agreement).
NDA jest niezawodnym sposobem zabezpieczenia nie tylko pomysłów, lecz również innych tajemnic, które przekazujemy partnerom biznesowym, a które mogą mieć wartość gospodarczą, np. know-how czy informacji finansowych. Dzięki jej zapisom, w szczególności karom umownym, którymi obwarowuje niedochowanie poufności, zwiększamy prawdopodobieństwo, że nasz pomysł nie wycieknie.
Pamiętaj, że NDA są standardem rynkowym w relacjach z software house’ami. Troszkę inaczej jest z sektorem VC w Polsce. Inwestorzy zazwyczaj unikają podpisania NDA ze startupami, ale to niekoniecznie oznacza złe intencje z ich strony. Jaki zatem jest powód? Większość inwestorów to fundusze VC, które koncentrują się na inwestowaniu w młode firmy i mają do rozpatrzenia setki projektów. Dla nich podpisywanie NDA oznaczałoby ograniczenie elastyczności inwestycyjnej i ryzyko ponoszenia kar umownych. Na przykład, jeśli ktoś opracuje (lub ma pomysł na) aplikację do zarządzania efektywnością energetyczną w budynkach, możliwe, że do konkretnego VC zgłosi się wiele podobnych projektów. Dlatego VC chętniej podpisze NDA, jeśli zamierzamy zaprezentować mu nie tylko pomysł, lecz także np. projekt techniczny i inne twardsze dane. Jednak, gdy inwestor zdecyduje się na inwestycję i rozpoczynają się rozmowy na temat szczegółów inwestycji, w tym omawianie term sheet oraz przeprowadzanie audytu due diligence, zawarcie NDA staje się absolutnie niezbędne.
IV. NDA w praktyce
Przeanalizujmy teraz jak powinno wyglądać NDA na etapie rozmów z software house’m lub partnerem biznesowym (np. inwestorem).