Typowy scenariusz wygląda tak. Aplikacja powstaje od ponad roku, jest dostępna dla użytkowników i zaczyna zarabiać. Za development zapłacono już kilkaset tysięcy złotych. Współpraca z software house’em przestaje się jednak układać, więc founder szuka nowego zespołu. Nowy wykonawca prosi o dostęp do repozytorium, dokumentację techniczną i umowę, żeby sprawdzić, co wolno mu zrobić z kodem. Wtedy okazuje się, że repozytorium jest na koncie dotychczasowego wykonawcy, dokumentacja w praktyce nie istnieje, a umowa mówi o „licencji na korzystanie z aplikacji”.
Aplikacja działa, ale pytanie „czy mogę ją legalnie i technicznie rozwijać z kimś innym?” nie ma już prostej odpowiedzi. Prawa autorskie do aplikacji mobilnej to nie jedno zdanie w umowie. To kilka odrębnych kwestii: jakie prawa uzyskujesz, od kiedy, do czego, co możesz z nimi zrobić i czy masz faktyczny dostęp do tego, co jest potrzebne do dalszego rozwoju.
Ogólny przegląd tego, co warto sprawdzić przed podpisaniem umowy z wykonawcą, znajdziesz w artykule Umowa na stworzenie aplikacji mobilnej – na co zwrócić uwagę przed podpisaniem?. Tutaj skupiam się wyłącznie na prawach do aplikacji i kodu.
„Zapłaciłem za aplikację, więc jest moja” – dlaczego to założenie może być błędne?
Zlecając stworzenie aplikacji, kupujesz tak naprawdę dwie różne rzeczy, choć rzadko się je rozdziela. Pierwsza to praca wykonawcy i jej rezultat: działające oprogramowanie. Druga to prawa, które pozwolą Ci z tego oprogramowania korzystać, zmieniać je i na nim zarabiać.
Program komputerowy jest w polskim prawie chroniony jak utwór literacki (ustawa o prawie autorskim i prawach pokrewnych). Warto jednak pamiętać, że aplikacja to nie tylko kod programu komputerowego. W ramach projektu mogą powstawać również inne elementy, np. grafiki, interfejs, teksty, dokumentacja czy baza danych, których status prawny może wymagać odrębnej oceny. Dlatego postanowienia dotyczące praw powinny uwzględniać to, jakie elementy rzeczywiście powstają w ramach konkretnego projektu.
Autorskie prawa majątkowe do programu przysługują co do zasady twórcy, a w przypadku programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy – pracodawcy, o ile umowa nie stanowi inaczej. Samo zamówienie aplikacji i zapłata wynagrodzenia nie przenoszą tych praw na zamawiającego. Potrzebna jest odpowiednia podstawa umowna.
Jeżeli umowa nie zawiera wyraźnego postanowienia o przeniesieniu praw, ustawa nakazuje przyjąć, że twórca udzielił licencji. A licencja, której zakresu strony odpowiednio nie określiły, może okazać się znacznie węższa, niż zakładał zamawiający.
Przeniesienie praw czy licencja?
Przy przeniesieniu autorskich praw majątkowych prawa w określonym zakresie przechodzą na Ciebie. Stajesz się uprawnionym z autorskich praw majątkowych w zakresie określonym w umowie i co do zasady możesz nimi dalej rozporządzać, np. sprzedać je razem z produktem albo wnieść do spółki.
Przy licencji prawa zostają przy wykonawcy, a Ty otrzymujesz zgodę na korzystanie z oprogramowania w granicach umowy. Kilka zasad ustawowych ma tu duże znaczenie praktyczne:
- jeżeli umowa nie określa czasu i terytorium, licencja uprawnia do korzystania przez pięć lat na terytorium państwa, w którym licencjobiorca ma siedzibę, a po upływie tego okresu wygasa,
- licencjobiorca nie może upoważnić innej osoby do korzystania z utworu (udzielić sublicencji), chyba że umowa na to pozwala,
- licencja wyłączna wymaga formy pisemnej pod rygorem nieważności. Licencja niewyłączna takiego wymogu nie ma.
Licencja nie jest z definicji gorszym rozwiązaniem. Jeśli korzystasz z gotowej platformy, którą software house rozwija dla wielu klientów i tylko konfiguruje pod Ciebie, przeniesienie praw często nie będzie realne ani potrzebne. Szeroka licencja może być wtedy rozsądnym kompromisem, pod warunkiem, że obejmuje wszystko, czego produkt potrzebuje, pozwala na rozwój przez innych wykonawców, a jej czas trwania i zasady wypowiedzenia zapewniają ciągłość korzystania z produktu.
Samo określenie „bezterminowa” tego nie gwarantuje. Licencję udzieloną na czas nieoznaczony można co do zasady wypowiedzieć, jeżeli umowa nie stanowi inaczej. Z kolei licencję udzieloną na czas oznaczony dłuższy niż pięć lat po upływie pięciu lat uważa się za udzieloną na czas nieoznaczony. Dlatego umowa powinna wprost przesądzać, czy i na jakich warunkach licencjodawca może licencję wypowiedzieć.
Inaczej jest, gdy aplikacja jest istotą Twojego biznesu i planujesz pozyskać inwestora. Wtedy z reguły lepiej, żeby prawa do kodu stworzonego na Twoje zamówienie były po Twojej stronie. Właściwy wybór zależy od modelu biznesowego, a nie od jednej uniwersalnej zasady.
Co właściwie obejmuje przeniesienie praw autorskich do oprogramowania?
W umowach często pojawia się zdanie: „wykonawca przenosi na zamawiającego wszelkie prawa do aplikacji”. Brzmi to kompleksowo, ale prawnie może być niewystarczające. Umowa o przeniesienie praw obejmuje tylko te pola eksploatacji, które zostały w niej wyraźnie wymienione. Umowa o przeniesienie praw obejmuje tylko pola eksploatacji wyraźnie w niej wymienione. Prawa w zakresie niewymienionych pól nie przechodzą na zamawiającego.
Zakres praw warto projektować, wychodząc od tego, co chcesz biznesowo robić z aplikacją, na przykład:
- udostępniać użytkownikom, czyli publikować, rozpowszechniać, udostępniać online, także w modelu subskrypcyjnym,
- rozwijać i modyfikować, czyli wprowadzać zmiany, tworzyć nowe wersje, łączyć z innym oprogramowaniem,
- komercjalizować, czyli udzielać licencji dalej, sprzedawać produkt, wnosić go do spółki,
- powierzyć rozwój innemu wykonawcy, czyli umożliwić osobom trzecim wykonywanie tych działań na Twoją rzecz.
Te cele biznesowe nie są jeszcze gotową listą pól eksploatacji. Trzeba je przełożyć na precyzyjne postanowienia umowy. Przy programach komputerowych punktem odniesienia jest ustawowy katalog uprawnień, obejmujący m.in. zwielokrotnianie programu, wprowadzanie w nim zmian i jego rozpowszechnianie.
Szczególnie ważne jest prawo do wprowadzania zmian i korzystania ze zmienionych wersji. Ustawa pozwala osobie, która legalnie weszła w posiadanie programu, dokonywać niektórych czynności, w tym zmian, bez zgody uprawnionego. Warunki są dwa: umowa nie może stanowić inaczej, a czynności muszą być niezbędne do korzystania z programu zgodnie z jego przeznaczeniem, np. do poprawiania błędów. To jednak nie to samo co swoboda rozwijania produktu o nowe funkcje przez dowolny zespół. Jeśli taki rozwój jest dla Ciebie ważny, warto uregulować go w umowie wprost.
Forma umowy i moment przejścia praw
Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. To wymóg ustawowy, a nie dobra praktyka. Oznacza to, że ustalenia w mailach, akceptacja oferty w wiadomości czy kliknięcie „akceptuję” nie przeniosą praw. Formę pisemną spełnia dokument podpisany własnoręcznie albo opatrzony kwalifikowanym podpisem elektronicznym. Zwykły podpis w popularnych narzędziach do e-podpisu nie zawsze jest podpisem kwalifikowanym, więc warto to sprawdzić przed podpisaniem umowy.
Drugą kluczową kwestią jest moment przejścia praw. Umowy wiążą go zwykle z odbiorem, zapłatą albo przekazaniem kolejnych części oprogramowania. Każde z tych rozwiązań jest dopuszczalne, ale ma inne konsekwencje, gdy projekt nie dojdzie do końca.
Przykład: umowa przewiduje, że prawa przechodzą z chwilą zapłaty za odbiór końcowy. Po ośmiu miesiącach i opłaceniu kilku etapów współpraca się kończy. Do odbioru końcowego nie doszło, więc zamawiający może nie mieć praw do kodu, za którego stworzenie już zapłacił. Dlatego warto, żeby prawa przechodziły etapami, np. wraz z zapłatą za dany etap. Warto też przewidzieć licencję na okres przejściowy, do chwili przeniesienia praw.
Prawa do kodu a dostęp do kodu
To jedna z najczęściej pomijanych kwestii. Nabycie praw autorskich i faktyczne otrzymanie kodu źródłowego to dwie różne rzeczy. Sam transfer praw autorskich nie zastępuje umownego obowiązku wydania kodu źródłowego, dokumentacji i dostępów. Możesz mieć pełnię praw do aplikacji i jednocześnie nie mieć ani jednej linii jej kodu.
Dla dalszego rozwoju produktu kluczowe są zwykle:
- kod źródłowy aplikacji w aktualnej wersji, z historią zmian,
- dostęp do repozytorium, najlepiej na koncie zamawiającego, a nie wykonawcy,
- dokumentacja techniczna, która pozwoli nowemu zespołowi zrozumieć architekturę,
- dane dostępowe do serwerów, baz danych, paneli administracyjnych,
- środowiska (deweloperskie, testowe, produkcyjne) i sposób ich konfiguracji,
- klucze API i certyfikaty, w tym klucze do podpisywania aplikacji,
- konta związane z produktem, np. w usługach chmurowych czy narzędziach analitycznych.
Founder, który ma w umowie poprawnie przeniesione prawa, ale nie ma repozytorium, dokumentacji ani dostępu do infrastruktury, formalnie może zmienić wykonawcę, ale w praktyce nowy zespół musi zaczynać od odtwarzania projektu. Umowa powinna więc określać nie tylko prawa, ale też co, kiedy i w jakiej formie jest przekazywane. Rozwiązanie, które najlepiej chroni zamawiającego, to bieżący dostęp do repozytorium przez cały czas trwania projektu, a nie jednorazowe przekazanie kodu na koniec.
Jeżeli model współpracy opiera się na licencji i wykonawca nie chce wydać kodu, można rozważyć depozyt kodu źródłowego (escrow), który zostaje wydany zamawiającemu w określonych sytuacjach, np. gdy wykonawca zaprzestanie działalności.
Zmiana software house’u – czy nowy wykonawca może przejąć projekt?
Dobrym testem umowy jest pytanie: jeśli jutro zechcesz zmienić wykonawcę, czy nowy software house będzie mógł legalnie i technicznie kontynuować rozwój aplikacji?
Żeby odpowiedź brzmiała „tak”, zwykle muszą być spełnione jednocześnie cztery warunki:
- Masz prawo modyfikować aplikację i powierzać to osobom trzecim. Jeżeli korzystasz z aplikacji na podstawie licencji, jej zakres powinien pozwalać Ci powierzyć modyfikację i rozwój oprogramowania innemu wykonawcy, na zasadach odpowiednio określonych w umowie.
- Przy licencji: jej czas trwania i zasady wypowiedzenia nie pozwalają wykonawcy zakończyć jej razem ze współpracą.
- Masz kod, repozytorium, dokumentację i dostępy, bez których nowy zespół nie ruszy.
- Umowa zobowiązuje dotychczasowego wykonawcę do przekazania projektu, a najlepiej także do współpracy przy tym przekazaniu przez określony czas.
Brak któregokolwiek z tych elementów nie musi przekreślać zmiany wykonawcy, ale sprawia, że staje się ona przedmiotem negocjacji, a nie realizacją umowy. Zasady samego wypowiedzenia lub odstąpienia od umowy omówię w osobnym artykule.
Open source, third-party i komponenty własne software house’u
Nie każda linia kodu Twojej aplikacji zostanie napisana specjalnie dla Ciebie. Aplikacje mobilne korzystają z bibliotek open source, frameworków, zewnętrznych SDK (np. do płatności czy analityki) i usług dostawców zewnętrznych. Software house często używa też własnych, wcześniej stworzonych komponentów, które wykorzystuje w wielu projektach.
Wykonawca nie może przenieść na Ciebie praw, których sam nie ma. Z bibliotek open source korzystasz zwykle na zasadach licencji, na których zostały udostępnione. Przy komponentach i usługach third-party zakres Twoich uprawnień zależy od tego, jak zostały pozyskane i na jakich warunkach dostawca je udostępnia. Czasem licencję zawierasz bezpośrednio z dostawcą, a czasem korzystasz z niej za pośrednictwem wykonawcy.
Niektóre licencje open source typu copyleft mogą, po spełnieniu określonych przesłanek, np. przy dystrybucji oprogramowania, nakładać obowiązki dotyczące udostępnienia kodu źródłowego objętego ich warunkami. Nie oznacza to automatycznie obowiązku ujawnienia całego kodu aplikacji, ale wymaga świadomego doboru komponentów.
Przy własnych komponentach wykonawcy rozsądnym rozwiązaniem jest zwykle licencja niewyłączna, obejmująca prawo do modyfikacji i do korzystania przez przyszłych wykonawców, z czasem trwania i zasadami wypowiedzenia dopasowanymi do cyklu życia produktu. Warto też, żeby umowa zobowiązywała wykonawcę do wskazania, jakie komponenty zewnętrzne i własne zostały użyte i na jakich zasadach. Szczegółowo temat licencji open source omówię w kolejnym tekście.
Czy software house ma prawa, które chce przenieść?
Software house może przenieść tylko te prawa, które sam skutecznie nabył. W praktyce mówi się o tzw. chain of title, czyli nieprzerwanym łańcuchu praw od osób, które faktycznie pisały kod, do Ciebie.
Zasady nabycia praw nie są jednakowe dla wszystkich członków zespołu:
- przy pracownikach prawa majątkowe do programu stworzonego w ramach obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej. Dotyczy to jednak tylko programów tworzonych w wykonaniu tych obowiązków,
- przy współpracownikach B2B, freelancerach i podwykonawcach ta zasada nie działa. Zakres praw software house’u zależy od umów, które z nimi zawarł. Jeżeli wykonawca ma przenieść prawa na Ciebie, sam musi je wcześniej skutecznie nabyć, a przeniesienie praw wymaga formy pisemnej pod rygorem nieważności. Jeżeli model współpracy opiera się na licencji, wystarczy, że software house ma tytuł licencyjny na tyle szeroki, by mógł udzielać dalszych licencji. Forma pisemna jest wtedy wymagana przy licencji wyłącznej, ale nie przy niewyłącznej.
Nie sprawdzisz sam umów wykonawcy z jego programistami. Możesz natomiast zadbać, żeby wykonawca zapewnił w umowie, że dysponuje prawami, które przenosi lub licencjonuje, i żeby odpowiadał wobec Ciebie, jeśli ktoś zgłosi roszczenia do kodu.
Kiedy prawa autorskie do aplikacji mobilnej stają się szczególnie ważne?
Przez większość czasu nikt nie zagląda do tych postanowień. Wracają one w momentach, w których stawka jest najwyższa:
- zmiana software house’u, gdy trzeba przekazać projekt nowemu zespołowi,
- pozyskanie inwestora, który będzie chciał wiedzieć, czy spółka rzeczywiście ma prawa do swojego kluczowego aktywa,
- due diligence przy rundzie finansowania, gdzie luki w łańcuchu praw mogą wpłynąć na wycenę albo warunki transakcji,
- sprzedaż spółki lub produktu, bo trudno sprzedać coś, do czego nie ma się udokumentowanych praw,
- skalowanie i wejście na nowe rynki, gdy okazuje się, że licencja jest ograniczona terytorialnie lub nie obejmuje nowych modeli dystrybucji.
Uzupełnianie braków w dokumentacji prawnej po fakcie może być trudniejsze i kosztowniejsze niż prawidłowe uregulowanie tych kwestii na początku współpracy.
Prawa autorskie do aplikacji mobilnej – podsumowanie
Zapłata za stworzenie aplikacji nie jest tym samym co nabycie praw do niej. Pytanie „czy mam prawa do aplikacji?” rozkłada się na kilka pytań szczegółowych: jakie prawa otrzymujesz, od kiedy, do których elementów, czy możesz aplikację modyfikować i powierzyć jej rozwój innemu wykonawcy, oraz czy masz faktyczny dostęp do kodu i infrastruktury. Dobra umowa odpowiada na każde z nich.
Masz przed sobą umowę z software house’em?
Jeśli otrzymałeś projekt umowy i nie masz pewności, jakie prawa do aplikacji i kodu uzyskasz po zakończeniu projektu, kancelaria Prawnik dla IT może przeanalizować postanowienia dotyczące praw autorskich, licencji i przekazania kodu przed podpisaniem. Wskażemy, co warto zmienić i jak to uzasadnić w rozmowie z wykonawcą. Skontaktuj się z nami.