Prawa autorskie do oprogramowania w umowie z wykonawcą

Prawa autorskie do oprogramowania zamówionego u wykonawcy przechodzą na Ciebie tylko wtedy, gdy umowa wyraźnie to przewiduje, na piśmie i z wymienionymi polami eksploatacji. Jeśli tego zabraknie, prawo zakłada, że dostałeś licencję, często węższą, niż myślisz. W tym tekście wyjaśniam z perspektywy szefa software house’u, czym różni się przeniesienie praw od licencji, jakie pola eksploatacji wpisać, co z kodem źródłowym, bibliotekami open source i komponentami, które wykonawca przynosi do projektu. To praktyczne omówienie, a nie porada prawna: konkretną umowę zawsze warto dać do przeczytania prawnikowi.

Prawa autorskie do oprogramowania: co mówi ustawa

Program komputerowy jest chroniony jak utwór literacki, a ochrona obejmuje wszystkie formy jego wyrażenia, w tym kod źródłowy i wynikowy. Nie są natomiast chronione idee i zasady, na których program się opiera.

Tak stanowi art. 74 ustawy o prawie autorskim i prawach pokrewnych, którą cytuję według tekstu jednolitego w Dz.U. 2025 poz. 24. Dla zamawiającego wynika z tego jedna praktyczna rzecz: pomysł na system, procesy i układ ekranów nie są Twoją własnością tylko dlatego, że je opisałeś. Chroniony jest konkretny kod i to do niego trzeba nabyć prawa.

Druga ważna zasada dotyczy łańcucha praw. Według art. 74 ust. 3 prawa majątkowe do programu napisanego przez pracownika w ramach obowiązków przysługują pracodawcy, o ile umowa nie stanowi inaczej. Ten przepis nie obejmuje jednak programistów współpracujących na umowach cywilnych, a w branży IT to częsty model. Wykonawca może przenieść na Ciebie tylko te prawa, które sam skutecznie nabył od swoich ludzi.

Przeniesienie praw czy licencja

Przeniesienie praw autorskich do oprogramowania oznacza, że stajesz się właścicielem praw majątkowych do kodu na wskazanych polach eksploatacji. Licencja daje tylko zgodę na korzystanie w określonym zakresie, a prawa zostają przy wykonawcy.

Kwestia	Przeniesienie praw	Licencja
Kto jest właścicielem praw	zamawiający	wykonawca
Forma umowy	pisemna pod rygorem nieważności (art. 53)	wyłączna: pisemna pod rygorem nieważności (art. 67 ust. 5), niewyłączna: dowolna
Czy wykonawca może sprzedać ten sam kod innym	nie	tak, przy licencji niewyłącznej
Czas trwania	bez ograniczeń	według umowy, a przy braku zapisu reguły z art. 66 i art. 68
Typowe zastosowanie	system tworzony wyłącznie dla zamawiającego	produkt wykonawcy, komponenty używane w wielu projektach

Kluczowy jest art. 65: w braku wyraźnego postanowienia o przeniesieniu prawa uważa się, że twórca udzielił licencji. Zapis w stylu „wykonawca przekazuje system zamawiającemu” bez słowa o przeniesieniu praw może więc oznaczać licencję. Do tego art. 66 mówi, że licencja bez innych ustaleń uprawnia do korzystania przez pięć lat na terytorium państwa siedziby licencjobiorcy, a art. 68 pozwala wypowiedzieć licencję udzieloną na czas nieoznaczony, jeśli umowa nie stanowi inaczej. Dla systemu, na którym opiera się firma, to poważne ryzyko.

Licencja nie jest jednak niczym złym. Przy gotowych produktach i modułach wykonawcy to normalny model. Ważne, żeby była świadomym wyborem z dobrze opisanym zakresem, a nie skutkiem niedopowiedzenia.

Pola eksploatacji: co wpisać przy oprogramowaniu

Pola eksploatacji to sposoby korzystania z utworu, na które przechodzą prawa albo których dotyczy licencja. Umowa obejmuje tylko pola wyraźnie w niej wymienione (art. 41 ust. 2) i tylko takie, które są znane w chwili jej zawarcia (art. 41 ust. 4).

Punktem wyjścia jest art. 74 ust. 4, który wymienia uprawnienia do programu komputerowego. W praktyce w umowie dotyczącej systemu warto wymienić co najmniej:

• trwałe lub czasowe zwielokrotnianie programu w całości lub w części, w tym instalowanie, uruchamianie, przechowywanie i tworzenie kopii zapasowych,
• tłumaczenie, przystosowywanie, zmiany układu i wszelkie inne zmiany w programie, także przez osoby trzecie na zlecenie zamawiającego,
• rozpowszechnianie, w tym użyczenie i najem programu lub jego kopii,
• udostępnianie programu użytkownikom przez sieć, w tym w modelu, w którym klienci zamawiającego korzystają z systemu przez przeglądarkę,
• wprowadzanie do pamięci komputerów i serwerów, także u dostawców chmury,
• prawo do dalszego przenoszenia praw i udzielania licencji, jeśli planujesz sprzedaż systemu albo udostępnianie go spółkom z grupy.

Ogólne sformułowania typu „na wszystkich znanych polach eksploatacji” to sygnał ostrzegawczy. Lista ma być konkretna i dopasowana do tego, jak naprawdę zamierzasz korzystać z systemu za kilka lat, a nie tylko w dniu odbioru.

Zgoda na zmiany przez innego wykonawcę

Nawet po przeniesieniu wszystkich praw majątkowych twórca zachowuje prawo zezwalania na wykonywanie zależnego prawa autorskiego, jeśli umowa nie stanowi inaczej (art. 46). Chodzi o korzystanie z opracowań, czyli zmienionych wersji programu.

Dlatego w umowie o prawa autorskie do oprogramowania powinien się znaleźć wyraźny zapis, że zamawiający może wykonywać i zezwalać na wykonywanie zależnych praw autorskich do programu. Bez niego przejście do innego wykonawcy albo rozwijanie systemu własnym zespołem może wymagać dodatkowej zgody. O tym, jak wygląda w praktyce zmiana wykonawcy, piszę w tekście o tym, jak przebiega przejęcie projektu IT od innej firmy.

Warto też ustalić moment przejścia praw. Według art. 64 umowa zobowiązująca do przeniesienia przenosi prawa z chwilą przyjęcia utworu, chyba że postanowiono inaczej. W umowach IT często wiąże się przejście praw z zapłatą za dany etap. To rozsądne dla obu stron, pod warunkiem że każdy etap ma jasno określony zakres i protokół odbioru.

Kod źródłowy: bez niego prawa są teoretyczne

Prawa autorskie do oprogramowania niewiele dają, jeśli nie masz kodu źródłowego. Program w postaci wynikowej da się uruchomić, ale nie da się go sensownie rozwijać ani naprawić bez wykonawcy.

W umowie zapisz obowiązek przekazania kodu i ustal, w jakiej formie to następuje:

• repozytorium kodu na koncie zamawiającego albo stały dostęp do repozytorium wykonawcy z pełną historią zmian,
• przekazanie przy każdym odbiorze etapu, a nie dopiero na koniec projektu,
• instrukcja budowania i wdrażania, konfiguracja serwerów, skrypty bazy danych,
• dokumentacja techniczna w zakresie potrzebnym innemu zespołowi do przejęcia prac.

Przy produktach wykonawcy, gdzie kodu się nie przekazuje, rozwiązaniem bywa depozyt kodu u niezależnego podmiotu (escrow) z opisanymi warunkami wydania, na przykład gdy wykonawca kończy działalność.

Biblioteki open source w Twoim systemie

Prawie każdy współczesny system korzysta z bibliotek open source. Wykonawca nie może przenieść na Ciebie praw autorskich do oprogramowania napisanego przez innych, może jedynie zapewnić, że korzysta z niego zgodnie z licencją.

Licencje open source różnią się obowiązkami. Część wymaga tylko zachowania informacji o autorach, inne przy rozpowszechnianiu zmienionego programu wymagają udostępnienia kodu na tych samych zasadach. Dla systemu używanego wewnątrz firmy zwykle nie stanowi to problemu, ale przy produkcie, który zamierzasz sprzedawać lub instalować u klientów, ma znaczenie.

Poproś w umowie o trzy rzeczy: listę użytych komponentów z ich licencjami (aktualizowaną przy każdym odbiorze), oświadczenie wykonawcy, że korzysta z nich zgodnie z licencjami, oraz zgodę na użycie komponentów o licencjach wymagających udostępnienia kodu tylko po Twojej akceptacji.

Komponenty wykonawcy i kod pisany z pomocą narzędzi AI

Wykonawcy często budują systemy na własnych modułach używanych w wielu projektach. Przeniesienie praw do nich nie ma sensu dla żadnej strony, ale zamawiający potrzebuje pewności, że będzie mógł z nich korzystać bez końca.

Rozsądny zapis to licencja niewyłączna, bezterminowa, bez prawa wypowiedzenia przez wykonawcę, obejmująca także modyfikacje i korzystanie przez kolejnych wykonawców. Komponenty te powinny być wymienione w umowie, żeby nie było sporu, co jest systemem zamawiającego, a co produktem wykonawcy.

Nowym tematem jest kod tworzony z pomocą narzędzi AI. Ochrona prawnoautorska dotyczy przejawów działalności twórczej (art. 1 ust. 1), co w polskim prawie łączy się z pracą człowieka, więc status fragmentów wygenerowanych w całości przez narzędzie bywa niejasny. Zapytaj wykonawcę, jak używa takich narzędzi, czy programista przegląda i odpowiada za każdy fragment kodu oraz czy narzędzie nie przesyła Twojego kodu do dostawcy w sposób sprzeczny z umową o poufności.

Lista kontrolna przed podpisaniem umowy

Zanim podpiszesz umowę z wykonawcą, sprawdź, czy w sprawie praw autorskich do oprogramowania odpowiada na poniższe pytania. Każda odpowiedź „nie wiadomo” to temat do rozmowy przed podpisem, a nie po odbiorze.

1. Czy umowa wyraźnie przenosi prawa majątkowe, na piśmie, a nie tylko „przekazuje system”?
2. Czy pola eksploatacji są wymienione konkretnie i obejmują rozwój, udostępnianie przez sieć i dalsze przenoszenie?
3. Czy jest zgoda na wykonywanie zależnych praw autorskich przez zamawiającego i osoby trzecie?
4. Kiedy przechodzą prawa i czy jest to powiązane z odbiorem oraz zapłatą?
5. Czy kod źródłowy, dokumentacja i dostęp do repozytorium są przekazywane przy każdym etapie?
6. Czy jest lista komponentów open source i komponentów wykonawcy wraz z zasadami licencji?
7. Czy wykonawca oświadcza, że nabył prawa od wszystkich osób, które pisały kod?

Te pytania dobrze połączyć z wyborem modelu rozliczeń, bo zapisy o odbiorach i płatnościach wpływają na moment przejścia praw. Szerzej o tym piszę w tekstach o tym, jak wybrać model umowy oraz jak wybrać software house.

Jeśli masz przed sobą umowę wdrożeniową, przejdź ją z listą powyżej i zaznacz miejsca, w których prawa autorskie do oprogramowania nie są opisane wprost. Z tymi punktami idź do prawnika, a jeśli chcesz porozmawiać o tym, jak wygląda to od strony wykonawcy, napisz do mnie przed podpisem.