Koszty, wycena i brief
Prawa autorskie do kodu: co musi zawierać umowa z wykonawcą
Część poradnika: Ile kosztuje aplikacja mobilna: jak rozłożyć wycenę na czynniki
Prawa autorskie do kodu nie przechodzą na zamawiającego ani przez zapłatę faktury, ani przez odbiór aplikacji. Przechodzą wyłącznie na podstawie pisemnej umowy, która wymienia z nazwy konkretne pola eksploatacji — i tylko wtedy, gdy firma podpisująca tę umowę sama wcześniej nabyła te prawa od osób, które fizycznie napisały kod. Ten trzeci warunek pęka najczęściej, bo w polskich zespołach programistycznych duża część ludzi pracuje na kontraktach B2B, a nie na etacie. Poniższy materiał ma charakter informacyjny i nie jest poradą prawną.
Trzy warunki, bez których prawa autorskie do kodu nie przechodzą na Ciebie
Prawa majątkowe do kodu przechodzą na zamawiającego tylko wtedy, gdy trzy warunki są spełnione łącznie: umowa ma formę pisemną, wyraźnie wymienia pola eksploatacji, a wykonawca dysponuje nieprzerwanym łańcuchem przeniesień od wszystkich autorów kodu. Brak któregokolwiek z nich oznacza, że płacisz za coś, czego prawnie nie otrzymujesz.
| Warunek | Podstawa w ustawie z 4 lutego 1994 r. | Co sprawdzić w umowie |
|---|---|---|
| Forma pisemna | Art. 53 | Czy przeniesienie praw znalazło się w podpisanym dokumencie, a nie tylko w mailu z akceptacją oferty. |
| Wymienione pola eksploatacji | Art. 41 ust. 2 | Czy umowa wylicza pola z nazwy — pola niewymienione zostają przy twórcy. |
| Tylko pola znane dziś | Art. 41 ust. 4 | Czy zapis nie próbuje obejmować pól nieznanych w chwili zawarcia umowy. |
| Nieprzerwany łańcuch autorów | Art. 74 ust. 3 obejmuje wyłącznie stosunek pracy | Czy wykonawca oświadcza, że nabył prawa od pracowników, współpracowników B2B i podwykonawców. |
Art. 53 ustawy o prawie autorskim i prawach pokrewnych brzmi: „Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności”. Rygor nieważności to najostrzejszy skutek, jaki zna prawo cywilne — bez zachowania tej formy przeniesienie po prostu nie następuje, niezależnie od tego, co strony sobie obiecały.
Art. 41 ust. 2 dodaje drugi filtr: „Umowa o przeniesienie autorskich praw majątkowych lub licencja obejmują pola eksploatacji wyraźnie w nich wymienione”. Wszystko, czego umowa nie wymienia, zostaje przy twórcy. Art. 41 ust. 4 domyka temat: umowa może dotyczyć tylko pól eksploatacji znanych w chwili jej zawarcia, więc klauzula rozciągająca prawa na przyszłe, jeszcze nieistniejące sposoby korzystania nic nie wnosi.
Dlaczego art. 74 ust. 3 nie zadziała, gdy zespół pracuje na kontraktach B2B
Art. 74 ust. 3 przyznaje prawa majątkowe do programu komputerowego pracodawcy tylko wtedy, gdy program powstał w wyniku wykonywania przez pracownika obowiązków ze stosunku pracy — i tylko o ile umowa nie stanowi inaczej. To wszystko, co robi ten przepis. Nie obejmuje umów zlecenia, umów o dzieło ani współpracy z jednoosobową działalnością gospodarczą.
Konsekwencja jest bardzo praktyczna. Jeżeli Twoją aplikację pisze pięcioro programistów, z których dwoje jest na etacie, a troje rozlicza się fakturą, to software house z automatu ma prawa tylko do części kodu. Pozostała część zostaje przy autorach, dopóki każdy z nich nie przeniesie praw osobną pisemną umową — z wymienionymi polami eksploatacji, bo art. 53 i art. 41 ust. 2 obowiązują na każdym ogniwie łańcucha, nie tylko na ostatnim. Ta sama zasada dotyczy podwykonawców, którym wykonawca zlecił moduł czy warstwę front-endu.
Zapytaj wprost, jak wygląda struktura zespołu i co podpisali jego członkowie. To jedno z pytań, które rozstrzygają, jak wybrać software house, bo wymijająca odpowiedź o skład zespołu zwykle zapowiada wymijającą odpowiedź o prawa do kodu. Zamiast dyskutować o przepisach, zażądaj jednego oświadczenia w umowie.
„Wykonawca oświadcza, że przysługują mu autorskie prawa majątkowe do całości Oprogramowania powstałego w ramach Umowy, w tym że nabył je w formie pisemnej od wszystkich osób biorących udział w jego tworzeniu — niezależnie od podstawy współpracy z tymi osobami (stosunek pracy, umowa cywilnoprawna, współpraca w ramach działalności gospodarczej) — oraz od podwykonawców. Wykonawca zobowiązuje się przedstawić Zamawiającemu potwierdzenie nabycia tych praw na jego żądanie."
To jest pytanie na etap zapytania ofertowego, nie na etap odbioru; obok zakresu i budżetu powinno znaleźć się w dokumencie, który opisuje poradnik o tym, jak napisać brief dla software house. Jeśli wolisz nie zaczynać od pustej strony, przez te same punkty przeprowadza w sześciu krokach kreator briefu.
Jakie pola eksploatacji wpisać do umowy na oprogramowanie
Przy programie komputerowym nie musisz niczego wymyślać: art. 74 ust. 4 ustawy o prawie autorskim sam wylicza autorskie prawa majątkowe do programu, a ta lista działa jak gotowy katalog pól eksploatacji do przeklejenia do umowy. Obejmuje trzy pozycje: zwielokrotnianie, wprowadzanie zmian i rozpowszechnianie.
„Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do Oprogramowania na następujących polach eksploatacji: 1) trwałe lub czasowe zwielokrotnienie programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie; 2) tłumaczenie, przystosowanie, zmiana układu lub jakiekolwiek inne zmiany w programie komputerowym; 3) rozpowszechnianie, w tym użyczenie lub najem programu komputerowego albo jego kopii."
Punkt drugi jest dla zamawiającego najważniejszy, choć wygląda najbardziej technicznie. To on decyduje o tym, czy możesz zlecić rozwój aplikacji komukolwiek innemu niż jej autor. Bez prawa do wprowadzania zmian masz kod, którego nie wolno Ci poprawić.
Zapis po lewej wygląda mocniej, a jest słabszy: art. 41 ust. 2 wymaga wyraźnego wymienienia pól, a art. 41 ust. 4 wyklucza pola nieznane w chwili zawarcia umowy. Wyliczenie z ustawy zajmuje trzy linijki i nie zostawia miejsca na spór o to, co strony miały na myśli.
Co obejmuje ochrona: kod tak, pomysł nie
Art. 74 ust. 1 daje programom komputerowym ochronę taką jak utworom literackim, a ust. 2 rozciąga ją na wszystkie formy wyrażenia programu, ale wprost wyłącza z niej idee i zasady leżące u jego podstaw. Kupujesz więc konkretny zapis, a nie monopol na pomysł.
Ma to dwa skutki. Po pierwsze, przeniesienie praw nie blokuje wykonawcy przed zbudowaniem podobnie działającego rozwiązania od nowa — jeśli zależy Ci na wyłączności w Twojej branży, musi ona wynikać z osobnego zapisu umownego. Po drugie, spór o „skopiowanie funkcjonalności” jest znacznie trudniejszy niż spór o skopiowany kod, więc realną ochroną jest tu przede wszystkim własność repozytorium i lista tego, co wykonawca ma prawo ponownie wykorzystać.
Przeniesienie praw czy licencja — kiedy licencja wystarczy
Przeniesienie praw oznacza, że autorskie prawa majątkowe przechodzą na Ciebie i to Ty decydujesz o dalszym losie kodu. Licencja to zgoda na korzystanie z kodu na warunkach ustalonych przez uprawnionego, u którego prawa pozostają. Art. 41 ust. 2 dotyczy obu tych umów tak samo — jedna i druga obejmują wyłącznie pola eksploatacji wyraźnie w nich wymienione.
W praktyce prawie każdy projekt jest mieszanką i tak też powinna wyglądać umowa:
- Przeniesienie praw — kod dedykowany, napisany specjalnie dla Ciebie: logika biznesowa, integracje, interfejs, schemat bazy danych.
- Licencja — biblioteki open source, gotowe komponenty, silnik lub platforma wykonawcy, oprogramowanie sprzedawane w abonamencie.
Licencja wystarczy, dopóki płacisz za korzystanie z gotowego produktu i nie planujesz go rozwijać własnymi siłami. Przestaje wystarczać, gdy chcesz zmienić wykonawcę, sprzedać firmę lub produkt, pozyskać inwestora albo przejąć rozwój do własnego zespołu. Zażądaj listy komponentów zewnętrznych wraz z ich licencjami — to również pozycja, która ma wpływ na koszt utrzymania i na to, ile kosztuje aplikacja mobilna w kolejnych latach.
Sam model rozliczenia niczego tu nie przesądza: prawa przenosi umowa, a nie sposób fakturowania, choć różnice między modelem fixed price a time and material wpływają na to, kiedy odbierasz kolejne części kodu.
Co odebrać poza kodem: repozytorium, dokumentacja i dostępy
Prawa do kodu bez dostępu do kodu są bezużyteczne, więc obok przeniesienia praw zapisz w umowie, co dokładnie i w jakiej formie dostajesz przy odbiorze. Odbiór to ostatni etap procesu, który w całości opisuje poradnik o tym, jak stworzyć aplikację mobilną.
- Kod źródłowy z historią repozytorium. Nie paczka ZIP na koniec projektu, tylko repozytorium należące do Twojej organizacji od pierwszego dnia, do którego wykonawca ma dostęp jako członek zespołu.
- Dokumentacja. Specyfikacje oraz dokumentacja użytkownika i deweloperska — ta ostatnia decyduje o tym, czy nowy zespół uruchomi projekt lokalnie w jeden dzień, czy w dwa tygodnie.
- Dostępy i konta. Hosting, domena, usługi zewnętrzne, klucze API i konta w sklepach z aplikacjami mają należeć do Twojej firmy, a nie do wykonawcy. Konto założone na prywatny adres programisty jest realnym punktem awarii.
- Exit plan i zasady podwykonawstwa. Typowa umowa wdrożeniowa zawiera oba te elementy: pierwszy opisuje tryb przekazania projektu, drugi przesądza, czy wykonawca może dopuścić podwykonawcę bez Twojej zgody.
Najtańszy moment na ustalenie tych punktów to etap zapytania ofertowego, a najdroższy — dzień, w którym chcesz zmienić wykonawcę.
Checklista
Sprawdź, czy przeniesienie praw jest w podpisanym dokumencie — art. 53 wymaga formy pisemnej pod rygorem nieważności.
Wypisz w umowie pola eksploatacji z art. 74 ust. 4 zamiast ogólnika o wszystkich polach eksploatacji.
Zapytaj wykonawcę, ilu autorów kodu pracuje na etacie, a ilu na kontraktach B2B i po stronie podwykonawców.
Zażądaj oświadczenia wykonawcy, że nabył prawa od wszystkich autorów niezależnie od formy współpracy.
Rozdziel w umowie kod dedykowany od komponentów zewnętrznych i poproś o listę użytych licencji.
Ustal, że repozytorium, hosting, domena i konta w usługach zewnętrznych należą do Twojej firmy.
Zapisz zakres odbioru: kod źródłowy, specyfikacje oraz dokumentacja użytkownika i deweloperska.
Sprawdź, czy umowa zawiera exit plan i zasady dopuszczania podwykonawców.
Najczęstsze pytania
- Czy jak zapłacę za aplikację, to automatycznie mam prawa do kodu
- Nie. Zapłata faktury nie przenosi autorskich praw majątkowych do programu komputerowego. Potrzebna jest osobna umowa o przeniesienie praw, która zgodnie z art. 53 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych wymaga formy pisemnej pod rygorem nieważności, a zgodnie z art. 41 ust. 2 obejmuje wyłącznie pola eksploatacji wyraźnie w niej wymienione. Bez takiej umowy płacisz za wykonanie usługi, a prawa zostają przy twórcy. Ten opis ma charakter informacyjny i nie jest poradą prawną.
- Co z prawami do kodu, jeśli programiści pracują na B2B, a nie na etacie
- Art. 74 ust. 3 ustawy o prawie autorskim przyznaje prawa majątkowe do programu pracodawcy tylko wtedy, gdy program powstał w wyniku wykonywania przez pracownika obowiązków ze stosunku pracy, i tylko o ile umowa nie stanowi inaczej. Współpracownik na kontrakcie B2B nie jest pracownikiem, więc ten przepis go nie obejmuje — prawa zostają przy nim, dopóki nie przeniesie ich osobną pisemną umową. Dlatego żądaj od wykonawcy oświadczenia, że nabył prawa od wszystkich autorów kodu niezależnie od formy współpracy.
- Co to są pola eksploatacji i które wymienić przy oprogramowaniu
- Pola eksploatacji to sposoby korzystania z utworu, które umowa musi wyliczyć z nazwy — zgodnie z art. 41 ust. 2 ustawy o prawie autorskim pola niewymienione zostają przy twórcy. Dla programu komputerowego gotową listę daje art. 74 ust. 4: trwałe lub czasowe zwielokrotnienie programu w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie; tłumaczenie, przystosowanie, zmiana układu lub jakiekolwiek inne zmiany w programie; rozpowszechnianie, w tym użyczenie lub najem programu albo jego kopii.
- Czy software house może wykorzystać mój kod u innego klienta
- Rozstrzyga o tym umowa. Art. 74 ust. 2 ustawy o prawie autorskim stanowi, że ochrona obejmuje wszystkie formy wyrażenia programu, ale nie idee i zasady leżące u jego podstaw. Jeśli prawa majątkowe do konkretnego kodu przeszły na Ciebie, wykonawca nie dysponuje nim swobodnie poza tym, na co pozwala umowa. Zbudowanie podobnego rozwiązania od nowa to już inna sytuacja — jeżeli zależy Ci na wyłączności rynkowej, musi ona wynikać z zapisów umownych, a nie z samej ustawy.
- Czy dostanę kod źródłowy i dokumentację po zakończeniu współpracy
- Tylko wtedy, gdy umowa to przewiduje: przeniesienie praw autorskich i wydanie materiałów to dwie różne rzeczy. Wpisz do umowy, że przy odbiorze otrzymujesz kod źródłowy wraz z historią repozytorium, specyfikacje oraz dokumentację użytkownika i deweloperską, a także dostępy do hostingu, domeny i usług zewnętrznych. Typowa umowa wdrożeniowa zawiera też exit plan i zasady podwykonawstwa, które opisują tryb przekazania projektu po zakończeniu współpracy.
- Kto powinien być właścicielem repozytorium w trakcie projektu
- Repozytorium powinno należeć do organizacji zamawiającego, a wykonawca powinien mieć w nim dostęp jako członek zespołu. Wtedy historia zmian, konfiguracja i kod są u Ciebie od pierwszego dnia, a zakończenie współpracy sprowadza się do odebrania uprawnień, a nie do negocjacji o wydanie plików. Tak samo ustaw konta hostingu, domeny i usług zewnętrznych: właścicielem jest Twoja firma, a wykonawca dostaje dostęp na czas projektu.
Źródła i metodologia
Linki prowadzą do źródeł pierwotnych oraz zasad, według których przygotowujemy i aktualizujemy materiały.