Zamówienie strony internetowej, aplikacji mobilnej, sklepu internetowego, integracji API albo indywidualnego systemu informatycznego często wygląda podobnie. Klient opisuje swoje potrzeby, wykonawca przedstawia wycenę, strony uzgadniają zakres prac w wiadomościach e-mail lub komunikatorze, programista wykonuje kod, a następnie wystawia fakturę. Klient płaci wynagrodzenie i zaczyna korzystać z przygotowanego rozwiązania. Przez pewien czas nikt nie zastanawia się nad tym, komu przysługują prawa autorskie do kodu.

Problem pojawia się zazwyczaj dopiero wtedy, gdy klient chce zmienić wykonawcę, sprzedać projekt inwestorowi, udostępnić system spółce powiązanej, wdrożyć oprogramowanie u kolejnych klientów albo zlecić innemu programiście rozwój aplikacji. Dotychczasowy wykonawca może wówczas stwierdzić, że klient zapłacił wyłącznie za wykonanie i korzystanie z oprogramowania, ale nie nabył autorskich praw majątkowych do kodu. Klient odpowiada zwykle, że przecież otrzymał fakturę, opłacił całość prac, odebrał repozytorium i od początku było oczywiste, że zamawiał program dla siebie.

Z perspektywy biznesowej takie stanowisko klienta może wydawać się logiczne. Z perspektywy prawa autorskiego sytuacja jest jednak znacznie bardziej skomplikowana. Sama zapłata za stworzenie programu komputerowego nie oznacza automatycznie nabycia praw autorskich do programu. Również faktura, nawet zawierająca ogólny opis w rodzaju „wykonanie aplikacji wraz z prawami autorskimi”, najczęściej nie zapewnia klientowi takiego poziomu bezpieczeństwa, jaki dawałaby prawidłowo przygotowana umowa.

Kod programu komputerowego jako przedmiot prawa autorskiego

Program komputerowy może być utworem chronionym prawem autorskim. Ochrona obejmuje przede wszystkim sposób wyrażenia programu, a więc między innymi kod źródłowy i kod wynikowy, o ile spełniają one ustawowe przesłanki twórczości i indywidualności. Ochrona może dotyczyć również odpowiednio przygotowanego materiału projektowego, jeżeli pozwala on na stworzenie programu komputerowego.

Prawo autorskie nie chroni natomiast samych pomysłów, zasad działania, funkcjonalności ani koncepcji biznesowych. Klient nie nabywa wyłączności na sam pomysł stworzenia aplikacji do rezerwowania wizyt, systemu do porównywania cen albo modułu do automatycznego generowania raportów. Ochronie może jednak podlegać konkretny sposób realizacji takiego pomysłu, wyrażony w kodzie, strukturze programu i określonych rozwiązaniach programistycznych.

Rozróżnienie to ma duże znaczenie w sporach dotyczących podobieństwa dwóch systemów. Sam fakt, że konkurencyjna aplikacja posiada zbliżone funkcje, nie musi jeszcze oznaczać naruszenia praw autorskich. Konieczne może być wykazanie, że przejęto chronione elementy sposobu wyrażenia programu, na przykład twórcze fragmenty kodu. Sąd Najwyższy zwracał uwagę, że przy ocenie naruszenia praw do oprogramowania istotne może być ustalenie konkretnych fragmentów kodu, ich funkcjonalności, twórczego charakteru oraz tego, czy nie stanowią one rozwiązań powszechnie dostępnych lub standardowych. (Sąd Najwyższy)

Prawo Unii Europejskiej również przyjmuje, że program komputerowy jest chroniony, jeżeli jest oryginalny w tym znaczeniu, że stanowi własną intelektualną twórczość autora. Ochrona dotyczy formy wyrażenia programu, natomiast nie obejmuje koncepcji i zasad, na których opierają się elementy programu, w tym zasad leżących u podstaw interfejsów. (Eur-Lex)

W praktyce nie każdy pojedynczy fragment kodu będzie samodzielnym utworem. Prosta instrukcja, oczywista funkcja techniczna, standardowa konfiguracja albo rozwiązanie wymuszone przez określony język programowania mogą nie posiadać wystarczającego poziomu twórczości. Nie zmienia to jednak faktu, że rozbudowany system, moduł albo całościowo ujęty kod aplikacji bardzo często będzie podlegał ochronie prawnoautorskiej.

Kto pierwotnie nabywa prawa do kodu?

Co do zasady autorem programu komputerowego jest osoba fizyczna, która go stworzyła. W przypadku oprogramowania może to być jeden programista albo większy zespół osób odpowiedzialnych za poszczególne moduły. Spółka z ograniczoną odpowiedzialnością, spółka akcyjna albo inna osoba prawna nie jest twórcą w rozumieniu prawa autorskiego, ponieważ twórczość jest rezultatem działalności człowieka.

Firma może jednak nabyć autorskie prawa majątkowe do kodu na podstawie ustawy albo umowy. Szczególna zasada dotyczy programów komputerowych tworzonych przez pracowników. Jeżeli program został stworzony przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy, autorskie prawa majątkowe do takiego programu przysługują pracodawcy, o ile umowa nie stanowi inaczej.

W odniesieniu do programów komputerowych regulacja ta jest korzystniejsza dla pracodawcy niż ogólne zasady dotyczące utworów pracowniczych. Prawa do programu powstają po stronie pracodawcy w zakresie wynikającym z przepisów, bez potrzeby zawierania z pracownikiem odrębnej umowy przenoszącej prawa po zakończeniu każdego zadania.

Nie oznacza to jednak, że każdy kod napisany przez pracownika automatycznie należy do pracodawcy. Konieczne jest ustalenie, czy program został rzeczywiście stworzony w ramach wykonywania obowiązków pracowniczych. Znaczenie może mieć treść umowy o pracę, zakres obowiązków, polecenia przełożonych, cel stworzenia programu, miejsce i czas wykonywania pracy oraz powiązanie kodu z działalnością pracodawcy. Sam fakt napisania programu na komputerze służbowym nie musi przesądzać o nabyciu praw przez firmę, jeżeli program powstał całkowicie poza zakresem obowiązków pracownika.

Sąd Najwyższy rozpatrywał między innymi sprawę programu stworzonego przez pracownika w ramach stosunku pracy. W sprawie tej istotnym problemem był brak dostępu pracodawcy do materiału źródłowego oraz hasła umożliwiającego jego wykorzystanie. Orzeczenie pokazuje, że posiadanie praw do programu i faktyczna możliwość korzystania z kodu źródłowego są ze sobą związane, ale nie są dokładnie tym samym. Można posiadać prawa autorskie, a jednocześnie nie dysponować repozytorium, aktualną dokumentacją lub informacjami dostępowymi potrzebnymi do rozwoju systemu. (Sąd Najwyższy)

Zupełnie inaczej wygląda sytuacja, gdy kod przygotowuje freelancer prowadzący jednoosobową działalność gospodarczą, wspólnik spółki wykonujący prace poza stosunkiem pracy albo zewnętrzny software house. W takim przypadku klient nie nabywa praw tylko dlatego, że zapłacił za usługę. Potrzebna jest właściwa podstawa prawna, którą może być umowa przenosząca autorskie prawa majątkowe albo umowa licencyjna.

Czy zapłata za napisanie programu oznacza zakup praw autorskich?

Wynagrodzenie zapłacone programiście może obejmować różne świadczenia. Może być zapłatą za czas pracy, wykonanie określonych funkcjonalności, wdrożenie systemu, utrzymanie infrastruktury, konfigurację gotowych komponentów, udzielenie licencji albo przeniesienie praw autorskich. O tym, jaki jest rzeczywisty zakres transakcji, nie decyduje sama wysokość wynagrodzenia ani przekonanie jednej ze stron, lecz treść zawartej umowy.

W praktyce klient często zakłada, że skoro sfinansował stworzenie oprogramowania od podstaw, powinien stać się właścicielem wszystkiego, co powstało. Prawo autorskie nie posługuje się jednak prostą zasadą, zgodnie z którą osoba finansująca stworzenie utworu automatycznie nabywa do niego prawa. Finansowanie prac może być istotnym argumentem przy interpretacji uzgodnień stron, ale samo w sobie nie zastępuje skutecznego przeniesienia praw.

Należy też odróżnić własność nośnika, serwera albo plików od praw autorskich. Klient może otrzymać kopię kodu źródłowego, dostęp do repozytorium, pliki aplikacji albo komputer, na którym zainstalowano program, a mimo to nie nabyć autorskich praw majątkowych. Nabycie egzemplarza utworu lub nośnika, na którym go zapisano, co do zasady nie powoduje przejścia praw autorskich do samego utworu.

Analogicznie wykonawca może przekazać klientowi domenę internetową, dostęp do hostingu oraz wszystkie pliki strony, ale nadal zachować prawa do kodu i elementów graficznych, jeżeli nie doszło do ich prawidłowego przeniesienia. Klient może wówczas mieć techniczną możliwość posługiwania się stroną, ale jego uprawnienie do dokonywania zmian, tworzenia kolejnych wersji, sprzedaży rozwiązania albo udzielania sublicencji może być sporne.

Czy sama faktura przenosi prawa autorskie do kodu?

Najczęściej nie. Faktura jest przede wszystkim dokumentem księgowym potwierdzającym dokonanie określonej sprzedaży lub wykonanie usługi. Może być również dowodem tego, że strony zawarły umowę o określonej treści, ale nie każda faktura spełnia szczególne wymagania przewidziane dla przeniesienia autorskich praw majątkowych.

Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności. Oznacza to, że jeżeli ustawowa forma nie została zachowana, prawa nie przechodzą na klienta, nawet gdy strony ustnie uzgodniły, że klient ma otrzymać pełne prawa, a następnie rozliczyły usługę fakturą.

Zwykła faktura przesłana w pliku PDF nie spełnia automatycznie wymogu formy pisemnej. Forma pisemna wymaga złożenia własnoręcznego podpisu na dokumencie obejmującym oświadczenie woli. Równoważna formie pisemnej jest forma elektroniczna opatrzona kwalifikowanym podpisem elektronicznym. Zwykły skan podpisanego dokumentu, wiadomość e-mail, akceptacja oferty w komunikatorze albo faktura elektroniczna bez kwalifikowanego podpisu zasadniczo nie są równoznaczne z formą pisemną wymaganą dla przeniesienia praw.

Nie oznacza to, że faktura nigdy nie może stanowić elementu umowy przenoszącej prawa. Teoretycznie dokument nazwany fakturą mógłby zawierać odpowiednie oświadczenia stron i zostać podpisany w sposób spełniający wymagania ustawowe. W praktyce faktura jest jednak zazwyczaj wystawiana jednostronnie przez wykonawcę, zawiera jedynie skrótowy opis usługi i nie posiada podpisów obu stron. Dlatego trudno uznać ją za prawidłową umowę przenoszącą prawa autorskie.

Sformułowanie na fakturze „wykonanie programu z przekazaniem praw autorskich” może mieć znaczenie dowodowe. Może wskazywać, jaki był cel współpracy lub zamiar wystawcy dokumentu. Nie usuwa jednak problemu niezachowania wymaganej formy i nie zastępuje precyzyjnego określenia zakresu przenoszonych praw.

Szczególnie ryzykowne są faktury zawierające wyłącznie opisy takie jak „usługi programistyczne”, „wykonanie aplikacji”, „development systemu”, „wdrożenie strony” albo „prace IT zgodnie z ustaleniami”. Z takich opisów nie wynika, czy wynagrodzenie obejmowało przeniesienie praw, udzielenie licencji, czy jedynie wykonanie prac technicznych.

Dlaczego sformułowanie „przeniesienie wszystkich praw autorskich” może być niewystarczające?

Prawo autorskie wymaga, aby umowa określała pola eksploatacji, czyli sposoby korzystania z utworu, na których prawa są przenoszone. Umowa obejmuje tylko te pola eksploatacji, które zostały w niej wyraźnie wymienione.

Ogólne zdanie, zgodnie z którym wykonawca „przenosi wszystkie prawa autorskie”, może zatem nie dawać klientowi pełnego bezpieczeństwa. Klauzula powinna zostać dostosowana do specyfiki programu komputerowego oraz rzeczywistego modelu biznesowego klienta. Innych uprawnień potrzebuje przedsiębiorca zamawiający prosty system wyłącznie na użytek wewnętrzny, innych startup planujący pozyskanie inwestora i sprzedaż spółki, a jeszcze innych firma zamierzająca wdrażać oprogramowanie u wielu swoich klientów.

W odniesieniu do programów komputerowych znaczenie mają w szczególności uprawnienia do trwałego lub czasowego zwielokrotniania programu w całości lub części, dokonywania tłumaczeń, przystosowywania, zmiany układu oraz innych modyfikacji, a także rozpowszechniania programu lub jego kopii. Umowa powinna odpowiadać temu, w jaki sposób klient rzeczywiście zamierza eksploatować kod.

W projektach informatycznych warto szczegółowo uregulować również prawo do rozwijania programu, tworzenia kolejnych wersji, łączenia go z innymi systemami, wdrażania na różnych środowiskach, korzystania z programu przez spółki powiązane, oferowania oprogramowania w modelu SaaS, udostępniania użytkownikom końcowym, sprzedaży przedsiębiorstwa lub projektu oraz powierzania rozwoju kodu innym wykonawcom.

Znaczenie precyzyjnego określenia praw do systemu i kodu źródłowego pokazują sprawy dotyczące rozbudowanych wdrożeń informatycznych. W jednym z postępowań analizowanych przez Sąd Najwyższy umowa wyraźnie obejmowała między innymi przeniesienie praw do systemu, udzielenie możliwości korzystania na nielimitowanej liczbie stanowisk, modyfikowanie systemu, jego rozbudowę oraz przekazanie kodów źródłowych. Takie postanowienia znacznie dokładniej określają sytuację zamawiającego niż ogólne zdanie umieszczone na fakturze. (Sąd Najwyższy)

Czy brak umowy oznacza, że klient w ogóle nie może używać programu?

Brak skutecznego przeniesienia autorskich praw majątkowych nie zawsze oznacza, że klient korzysta z programu całkowicie bezprawnie. W określonych okolicznościach można rozważać, czy strony zawarły umowę licencyjną.

Licencja nie powoduje przejścia praw autorskich na klienta. Wykonawca nadal pozostaje podmiotem uprawnionym, natomiast klient uzyskuje zgodę na korzystanie z programu w określonym zakresie. Licencja może być wyłączna albo niewyłączna.

Licencja wyłączna oznacza, że licencjodawca zobowiązuje się nie udzielać licencji innym osobom w zakresie objętym umową. Taka umowa, podobnie jak przeniesienie praw, wymaga formy pisemnej. Licencja niewyłączna nie wymaga natomiast co do zasady tej samej szczególnej formy. Może więc zostać udzielona również przez zachowanie stron, wiadomości e-mail, zaakceptowaną ofertę albo inne okoliczności wskazujące na zgodę wykonawcy na korzystanie z programu.

Jeżeli klient zamówił system, zapłacił za niego, otrzymał dostęp i rozpoczął korzystanie za wiedzą wykonawcy, trudno zwykle twierdzić, że nie uzyskał żadnego uprawnienia do używania oprogramowania. Zakres takiej dorozumianej licencji może być jednak znacznie węższy, niż zakłada klient.

Możliwe jest na przykład przyjęcie, że klient uzyskał prawo używania aplikacji we własnej działalności, ale nie prawo do jej sprzedaży, udostępniania innym podmiotom, tworzenia konkurencyjnych produktów albo dowolnego przekazywania kodu zewnętrznym programistom. Ustalenie zakresu licencji wymaga analizy celu umowy, korespondencji, specyfikacji projektu, sposobu rozliczenia, dotychczasowej praktyki stron oraz charakteru stworzonego rozwiązania.

W sporze sądowym rezultat takiej analizy może być trudny do przewidzenia. Klient może wykazywać, że celem zamówienia było stworzenie produktu, który miał być rozwijany i komercjalizowany. Wykonawca może z kolei twierdzić, że wynagrodzenie obejmowało tylko wykonanie określonego wdrożenia, a szersze prawa miały być przedmiotem osobnej umowy lub dodatkowej opłaty.

Dlatego opieranie wartościowego projektu technologicznego na dorozumianej licencji jest rozwiązaniem ryzykownym. Dorozumiana licencja może umożliwić dalsze podstawowe korzystanie z programu, ale nie zapewnia takiej pewności jak prawidłowo skonstruowana umowa.

Przeniesienie praw czy licencja — co powinien wybrać klient?

Nie w każdym projekcie konieczne jest przenoszenie pełnych praw autorskich. Wybór między przeniesieniem praw a licencją powinien wynikać z charakteru rozwiązania i interesów stron.

Przeniesienie praw jest zwykle uzasadnione, gdy wykonawca tworzy dla klienta indywidualne oprogramowanie, które ma stanowić istotny składnik przedsiębiorstwa klienta. Dotyczy to zwłaszcza startupów technologicznych, platform internetowych, aplikacji oferowanych użytkownikom, systemów przeznaczonych do dalszej odsprzedaży oraz rozwiązań, których wartość zależy od możliwości swobodnego rozwoju przez różnych wykonawców.

Inwestor przeprowadzający badanie prawne startupu będzie zazwyczaj oczekiwał wykazania, że spółka posiada prawa do kodu tworzącego jej produkt. Faktury od programistów nie muszą zostać uznane za wystarczające. Brak umów może obniżyć wycenę spółki, opóźnić transakcję albo prowadzić do żądania zawarcia dodatkowych umów z twórcami przed finalizacją inwestycji.

Licencja może być odpowiednia, gdy klient korzysta ze standardowego produktu wykonawcy albo gdy system opiera się na rozwiązaniu rozwijanym przez dostawcę dla wielu odbiorców. Przeniesienie pełnych praw do całej platformy byłoby w takim przypadku nieproporcjonalne lub wręcz niemożliwe z punktu widzenia modelu biznesowego wykonawcy.

W praktyce często stosuje się model mieszany. Wykonawca zachowuje prawa do wcześniej istniejących bibliotek, frameworków, narzędzi i modułów ogólnego przeznaczenia, natomiast przenosi na klienta prawa do kodu przygotowanego specjalnie na potrzeby danego projektu. Klient otrzymuje jednocześnie odpowiednio szeroką licencję na elementy wykonawcy, które są niezbędne do korzystania z systemu.

Taki podział powinien być wyraźny. W przeciwnym razie po zakończeniu współpracy może powstać spór o to, które elementy były wcześniej istniejącym know-how wykonawcy, a które powstały w ramach opłaconego projektu klienta.

Kod źródłowy nie zawsze należy w całości do wykonawcy

Software house wystawiający klientowi fakturę nie zawsze jest automatycznie uprawniony do przeniesienia wszystkich praw do kodu. Firma wykonawcza musi wcześniej skutecznie nabyć prawa od osób, które uczestniczyły w realizacji projektu.

Jeżeli kod stworzyli pracownicy software house’u w ramach obowiązków pracowniczych, prawa majątkowe do programów komputerowych mogą przysługiwać pracodawcy na podstawie ustawy. Jeżeli jednak prace wykonywali podwykonawcy prowadzący działalność gospodarczą, osoby zatrudnione na podstawie umów zlecenia albo kontraktorzy B2B, potrzebne mogą być odpowiednie postanowienia umowne.

Umowa B2B nie jest umową o pracę. Samo to, że programista regularnie współpracuje z firmą, używa jej sprzętu, uczestniczy w spotkaniach zespołu i wystawia comiesięczne faktury, nie powoduje automatycznego nabycia praw przez software house. Jeżeli kontrakt z programistą nie zawiera skutecznej klauzuli przenoszącej prawa, wykonawca może nie dysponować pełnią praw, które obiecał następnie przenieść na klienta.

Powstaje wówczas problem tak zwanego łańcucha praw. Klient zawiera umowę z software house’em, software house korzysta z kilku kontraktorów, część kodu powstaje jeszcze u kolejnego podwykonawcy, a w systemie wykorzystywane są zewnętrzne komponenty. Aby klient rzeczywiście nabył uzgodnione prawa, każdy etap tego łańcucha musi być prawidłowo uregulowany.

Umowa klienta z wykonawcą powinna przewidywać nie tylko oświadczenie o posiadaniu praw, ale również odpowiedzialność wykonawcy za roszczenia osób trzecich. Warto uregulować obowiązek zapewnienia praw od pracowników i podwykonawców, zasady obrony klienta przed roszczeniami, zwrot kosztów oraz odpowiedzialność za wykorzystanie komponentów bez wymaganej licencji.

Biblioteki open source i kod osób trzecich

Nawet bardzo indywidualny projekt informatyczny prawie nigdy nie powstaje w całkowitym oderwaniu od zewnętrznych komponentów. Programiści korzystają z bibliotek open source, frameworków, gotowych pakietów, fragmentów kodu, narzędzi, usług chmurowych, interfejsów API i komercyjnego oprogramowania innych dostawców.

Wykonawca nie może przenieść na klienta praw, których sam nie posiada. Jeżeli biblioteka jest udostępniana na licencji open source, klient otrzymuje możliwość korzystania z niej na zasadach tej licencji, a nie pełne prawa autorskie. Umowa powinna więc rozróżniać kod tworzony dla klienta od komponentów osób trzecich.

Samo określenie „open source” nie oznacza, że z kodu można korzystać bez żadnych warunków. Poszczególne licencje różnią się zakresem obowiązków. Niektóre są stosunkowo liberalne i wymagają głównie zachowania informacji o autorach oraz treści licencji. Inne mogą nakładać dalej idące obowiązki związane z udostępnianiem kodu źródłowego albo licencjonowaniem zmodyfikowanej wersji.

Dla klienta rozwijającego komercyjny produkt szczególnie istotna jest wiedza o tym, jakie komponenty zostały użyte i na jakich zasadach. Wykonawca powinien prowadzić wykaz zależności, informować o zastosowanych licencjach oraz nie wprowadzać do projektu komponentów, które mogłyby uniemożliwić zakładany sposób komercjalizacji.

Faktura nie zawiera zazwyczaj żadnej informacji na ten temat. Nawet gdy widnieje na niej adnotacja o przeniesieniu praw autorskich, nie odpowiada ona na pytanie, które elementy są rzeczywiście własnym kodem wykonawcy, a które pochodzą od osób trzecich.

Czy przekazanie repozytorium oznacza przekazanie praw?

Dostęp do repozytorium jest niezwykle ważny, ale nie zastępuje umowy prawnoautorskiej. Repozytorium zawiera techniczną historię projektu, pliki źródłowe, informacje o zmianach oraz dane dotyczące autorów poszczególnych fragmentów. Przekazanie klientowi konta administratora albo przeniesienie repozytorium do organizacji klienta zapewnia mu faktyczną kontrolę nad kodem, lecz samo w sobie nie przesądza o prawach autorskich.

Możliwa jest również sytuacja odwrotna. Klient może skutecznie nabyć prawa autorskie do programu, ale nie otrzymać aktualnego kodu źródłowego. Będzie wtedy podmiotem praw, lecz rozwój systemu może być faktycznie niemożliwy albo bardzo kosztowny.

Dobra umowa powinna osobno regulować przeniesienie praw i obowiązki związane z wydaniem rezultatów prac. Należy określić sposób prowadzenia repozytorium, częstotliwość przekazywania kodu, zakres dokumentacji, zasady wydawania danych dostępowych, konfiguracji środowisk, plików wdrożeniowych oraz informacji potrzebnych do uruchomienia systemu.

Warto również ustalić, czy klient otrzyma historię zmian, skrypty migracyjne, konfigurację procesów CI/CD, dokumentację API, modele baz danych, instrukcje wdrożenia oraz inne elementy potrzebne do przejęcia projektu przez nowy zespół.

Kiedy prawa do kodu powinny przechodzić na klienta?

Umowa powinna jasno określać moment przejścia autorskich praw majątkowych. Możliwe jest powiązanie go z odbiorem danego etapu, przekazaniem kodu, stworzeniem utworu albo zapłatą wynagrodzenia.

Wykonawcy często oczekują, że prawa przejdą dopiero po uregulowaniu całej należności. Chroni ich to przed sytuacją, w której klient otrzyma kod i prawa, ale nie zapłaci faktury. Klient powinien z kolei zadbać, aby mechanizm nie powodował utraty praw do wszystkich rezultatów w razie sporu dotyczącego niewielkiej części wynagrodzenia.

Przy projektach rozliczanych etapami można przewidzieć sukcesywne przechodzenie praw do poszczególnych odebranych i opłaconych modułów. Takie rozwiązanie ogranicza ryzyko, że po wielu miesiącach prac klient pozostanie bez praw do całego systemu tylko dlatego, że współpraca zakończyła się przed wdrożeniem ostatniego etapu.

Sąd Najwyższy analizował sprawę, w której strony przewidziały sukcesywne przenoszenie praw do wykonywanych modułów systemu wraz z kodem źródłowym. Konstrukcja umowy miała znaczenie dla oceny, czy zamawiający zachował prawa do części oprogramowania wykonanej przed zakończeniem współpracy. (Sąd Najwyższy)

Moment przejścia praw powinien być skoordynowany z odbiorem prac oraz płatnością. Należy unikać sytuacji, w której faktura została zapłacona, lecz nie wiadomo, czy nastąpił odbiór, albo odbiór został podpisany, ale wykonawca twierdzi, że prawa miały przejść dopiero po spełnieniu dodatkowego warunku.

Wynagrodzenie za stworzenie kodu a wynagrodzenie za prawa autorskie

Umowa powinna określać, czy ustalone wynagrodzenie obejmuje również przeniesienie praw albo udzielenie licencji. Brak takiego postanowienia może prowadzić do sporu, czy wykonawca ma prawo żądać dodatkowej zapłaty za umożliwienie klientowi szerszego korzystania z programu.

W praktyce można ustalić jedną łączną kwotę obejmującą wykonanie oprogramowania, przeniesienie praw i wydanie kodu. Możliwe jest też wyodrębnienie części wynagrodzenia przypadającej na prawa autorskie. Najważniejsze, aby z umowy jasno wynikało, za co klient płaci i jakie uprawnienia otrzymuje.

Samo opłacenie wysokiej faktury nie przesądza o zakresie nabytych praw. Cena może przemawiać za określoną interpretacją zamiaru stron, ale nie naprawia nieważności przeniesienia praw wynikającej z niezachowania wymaganej formy.

Autorskie prawa osobiste programisty

Przeniesienie autorskich praw majątkowych nie oznacza przeniesienia autorskich praw osobistych. Prawa osobiste pozostają związane z twórcą i co do zasady nie podlegają zrzeczeniu się ani zbyciu.

W przypadku programów komputerowych zakres stosowania części uprawnień osobistych jest uregulowany szczególnie. Mimo to umowa powinna odnosić się do kwestii oznaczenia autorstwa, dokonywania zmian, korzystania z kodu bez wskazywania nazwiska twórcy oraz wykonywania określonych uprawnień przez klienta.

W praktyce stosuje się zobowiązanie wykonawcy, że twórcy nie będą wykonywać praw osobistych w sposób utrudniający korzystanie z programu, oraz upoważnienie klienta do wykonywania określonych uprawnień w imieniu twórców, w zakresie dopuszczalnym przez prawo. Warto też zadbać, aby analogiczne zobowiązania zostały uzyskane od faktycznych programistów, a nie tylko od spółki będącej stroną umowy.

Co powinien zrobić klient, który ma tylko faktury?

Brak prawidłowej umowy nie oznacza, że sytuacji nie można uporządkować. Pierwszym krokiem powinno być ustalenie, kto faktycznie stworzył kod oraz jakie dokumenty istnieją. Należy przeanalizować faktury, zamówienia, oferty, korespondencję, regulaminy współpracy, protokoły odbioru, dostęp do repozytorium i umowy z podwykonawcami.

Następnie warto zawrzeć odrębną umowę potwierdzającą przeniesienie autorskich praw majątkowych albo odpowiednio szeroką licencję. Umowa może objąć rezultaty powstałe wcześniej, pod warunkiem prawidłowego określenia utworów, pól eksploatacji, wynagrodzenia i pozostałych warunków.

Nie należy ograniczać się do podpisania jednostronicowego oświadczenia, że wykonawca „przekazuje wszystkie prawa”. Dokument powinien identyfikować projekt, repozytoria, moduły i inne rezultaty, określać zakres praw oraz potwierdzać, że wykonawca jest uprawniony do ich rozporządzania.

Trzeba też sprawdzić, czy wykonawca korzystał z podwykonawców. Jeżeli prawa nadal przysługują poszczególnym programistom, oświadczenie samego software house’u może nie wystarczyć. Konieczne może być uzupełnienie braków w całym łańcuchu praw.

W startupie przygotowującym się do inwestycji lub sprzedaży audyt powinien obejmować wszystkich dotychczasowych twórców produktu. Szczególnej uwagi wymagają pierwsze wersje systemu, które często powstają przed założeniem spółki, w ramach nieformalnej współpracy założycieli albo na podstawie prostych zamówień kierowanych do freelancerów.

Jak powinna wyglądać bezpieczna umowa dotycząca kodu?

Bezpieczna umowa powinna przede wszystkim jednoznacznie wskazywać, czy klient nabywa autorskie prawa majątkowe, czy otrzymuje licencję. Powinna identyfikować utwory objęte umową, określać pola eksploatacji, moment przejścia praw, wynagrodzenie oraz zasady wydania kodu i dokumentacji.

Należy uregulować uprawnienie do modyfikacji, rozwijania i łączenia programu z innymi rozwiązaniami. W przypadku produktu komercyjnego potrzebne może być także prawo do oferowania systemu klientom końcowym, udostępniania go w chmurze, przenoszenia praw w ramach sprzedaży przedsiębiorstwa oraz korzystania przez podmioty powiązane.

Umowa powinna rozdzielać kod dedykowany, wcześniejsze komponenty wykonawcy oraz elementy osób trzecich. W odniesieniu do każdej kategorii trzeba określić właściwy tytuł prawny. Klient powinien otrzymać informacje o bibliotekach open source i warunkach ich licencji.

Istotne są oświadczenia wykonawcy dotyczące autorstwa i braku naruszeń praw osób trzecich. Wykonawca powinien potwierdzić, że posiada prawa pozwalające na zawarcie umowy, a osoby uczestniczące w projekcie zostały odpowiednio związane postanowieniami dotyczącymi praw autorskich i poufności.

Należy również uregulować odpowiedzialność za naruszenia, obowiązek współpracy w razie roszczeń, zasady usuwania wad prawnych oraz możliwość zastąpienia zakwestionowanego komponentu rozwiązaniem, z którego klient będzie mógł legalnie korzystać.

Warto pamiętać o wymaganej formie. Umowa przenosząca autorskie prawa majątkowe powinna zostać podpisana własnoręcznie albo kwalifikowanymi podpisami elektronicznymi. Podpisanie dokumentu profilem zaufanym, zwykłym podpisem elektronicznym lub poprzez popularny system akceptacji dokumentów nie zawsze będzie spełniało wymagania formy pisemnej. Należy sprawdzić, jaki dokładnie rodzaj podpisu został użyty.

Czy faktura może pomóc w sporze?

Faktura nie jest bez znaczenia. Może potwierdzać istnienie współpracy, zakres wykonanych usług, wysokość wynagrodzenia, datę realizacji oraz sposób opisywania świadczeń przez wykonawcę. Razem z korespondencją i innymi dokumentami może pomóc ustalić cel umowy i zakres dorozumianej licencji.

Jeżeli wykonawca przez lata akceptował rozwijanie systemu przez innych programistów, przekazał pełne repozytorium i zapewniał klienta, że może on swobodnie dysponować rozwiązaniem, okoliczności te mogą przemawiać na korzyść klienta. Nie muszą jednak wystarczyć do wykazania skutecznego przeniesienia praw, jeżeli nie zachowano formy wymaganej przez ustawę.

W praktyce faktura jest więc ważnym dowodem, ale słabym substytutem umowy. Im większa wartość projektu i znaczenie oprogramowania dla działalności klienta, tym mniej rozsądne jest opieranie sytuacji prawnej wyłącznie na fakturach.

Najczęstszy błąd: utożsamianie zapłaty z własnością kodu

Najczęstszy błąd popełniany przez zamawiających polega na założeniu, że zapłata za development jest równoznaczna z zakupem kodu i praw. Tymczasem klient może jednocześnie posiadać pliki, używać systemu i opłacić wszystkie faktury, ale nadal nie mieć możliwości swobodnego rozporządzania programem.

Z drugiej strony również wykonawca nie powinien zakładać, że brak formalnej umowy zawsze pozwala mu zablokować klientowi dalsze korzystanie z programu. Jeżeli celem współpracy było stworzenie systemu dla klienta, a wykonawca świadomie przekazał mu program do używania, klient może posiadać co najmniej licencję wynikającą z okoliczności zawarcia umowy.

Brak dokumentacji powoduje jednak, że obie strony wchodzą w obszar niepewności. Zamiast opierać się na jasnych postanowieniach, muszą rekonstruować zamiar stron na podstawie wiadomości, faktur, zachowania uczestników projektu i celu gospodarczego współpracy.

Prawa do kodu warto uregulować przed rozpoczęciem projektu

Najlepszym momentem na ustalenie zasad dotyczących praw autorskich jest etap zawierania umowy, zanim rozpoczną się prace. Wtedy strony mogą świadomie zdecydować, czy cena obejmuje przeniesienie praw, czy licencję, jakie elementy pozostają własnością wykonawcy i w jaki sposób klient otrzyma kod.

Odkładanie tych kwestii do zakończenia projektu osłabia pozycję klienta. Gdy system jest już wdrożony, wykonawca może uzależnić przeniesienie praw od dodatkowego wynagrodzenia. Jeżeli współpraca zakończyła się konfliktem, uzyskanie podpisu programisty może być szczególnie trudne.

Wykonawca również korzysta na jasnym uregulowaniu praw. Może zachować swoje uniwersalne biblioteki, know-how i komponenty wielokrotnego użytku, a jednocześnie uniknąć zarzutów, że klient nie otrzymał tego, za co zapłacił.

Podsumowanie

Sama faktura za wykonanie programu komputerowego najczęściej nie wystarcza, aby klient nabył autorskie prawa majątkowe do kodu. Zapłata za usługę, odebranie aplikacji, dostęp do serwera oraz przekazanie repozytorium nie są równoznaczne z przeniesieniem praw autorskich.

Skuteczne przeniesienie praw wymaga umowy zawartej w odpowiedniej formie oraz określenia pól eksploatacji. Zwykła faktura elektroniczna, korespondencja e-mail lub ustne zapewnienie wykonawcy zazwyczaj nie spełniają tych wymagań.

W braku skutecznego przeniesienia praw klient może posiadać licencję, w szczególności gdy z celu współpracy i zachowania stron wynika zgoda na korzystanie z programu. Zakres takiej licencji może być jednak trudny do ustalenia i nie musi obejmować sprzedaży, dalszego licencjonowania, komercjalizacji ani dowolnego rozwoju przez osoby trzecie.

Bezpieczeństwo projektu wymaga nie tylko prawidłowej umowy z software house’em, ale także sprawdzenia całego łańcucha praw, umów z programistami i podwykonawcami oraz licencji na komponenty zewnętrzne. W przypadku oprogramowania stanowiącego istotny składnik przedsiębiorstwa kwestie te powinny zostać objęte audytem prawnym przed inwestycją, sprzedażą projektu albo zmianą wykonawcy.