Przeniesienie praw autorskich do kodu na B2B: co musi być w umowie

Prawa autorskie do kodu napisanego na B2B przechodzą na klienta tylko na podstawie umowy o przeniesienie praw zawartej w formie pisemnej, czyli z podpisem własnoręcznym albo kwalifikowanym podpisem elektronicznym. Umowa musi wyraźnie wymieniać pola eksploatacji, a powinna też określać moment przejścia praw, wynagrodzenie, zasady dla open source i kwestię praw osobistych. Automatyczne nabycie praw do programu ustawa przewiduje tylko dla pracodawcy, a nie dla firmy, która współpracuje z programistą na kontrakcie (stan prawny na październik 2026).

Dlaczego na B2B prawa nie przechodzą same

Zgodnie z art. 8 ust. 1 ustawy o prawie autorskim i prawach pokrewnych (tekst jednolity: Dz.U. 2025 poz. 24) prawo autorskie przysługuje twórcy, o ile ustawa nie stanowi inaczej. Wyjątek dla programów komputerowych zawiera art. 74 ust. 3: prawa majątkowe do programu stworzonego przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy należą do pracodawcy, chyba że umowa stanowi inaczej.

Programista na B2B nie jest pracownikiem, tylko przedsiębiorcą, więc ten wyjątek go nie obejmuje. Dopóki nie podpisze ważnej umowy przenoszącej prawa, autorskie prawa majątkowe do kodu zostają przy nim, nawet jeśli klient opłacił wszystkie faktury.

Gdy umowa dotyczy korzystania z kodu, ale nie przenosi praw wyraźnie, uważa się, że twórca udzielił licencji (art. 65). Bez innych ustaleń taka licencja obowiązuje pięć lat i tylko na terytorium państwa, w którym licencjobiorca ma siedzibę albo miejsce zamieszkania (art. 66 ust. 1).

Forma umowy: pisemna pod rygorem nieważności

Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53), podobnie jak licencja wyłączna (art. 67 ust. 5). Licencja niewyłączna takiego wymogu nie ma, ale lepiej ją spisać.

Formę pisemną zachowuje własnoręczny podpis na dokumencie (art. 78 § 1 Kodeksu cywilnego), a równoważna jest forma elektroniczna, czyli oświadczenie z kwalifikowanym podpisem elektronicznym (art. 78¹). Mail z akceptacją, wymiana skanów czy niekwalifikowany podpis w aplikacji to najwyżej forma dokumentowa (art. 77²), która do przeniesienia praw nie wystarczy. Tej samej formy co umowa wymaga aneks, np. rozszerzający przeniesienie na nowe moduły lub pola eksploatacji (art. 77 § 1 KC).

Przeniesienie praw czy licencja

Przy przeniesieniu zamawiający nabywa autorskie prawa majątkowe w zakresie opisanym w umowie i może przenieść je dalej, chyba że umowa stanowi inaczej (art. 41 ust. 1 pkt 2). Przy licencji prawa zostają przy twórcy, a licencjobiorca bez zgody wyrażonej w umowie nie może udzielać sublicencji (art. 67 ust. 3).

Licencja sprawdza się, gdy programista chce zachować prawa do własnych narzędzi. Trzeba jednak pamiętać, że jeśli umowa nie stanowi inaczej, licencję na czas nieoznaczony twórca może wypowiedzieć z zachowaniem terminów umownych, a w ich braku na rok naprzód, na koniec roku kalendarzowego. Licencję na ponad pięć lat po upływie tego okresu uważa się za udzieloną na czas nieoznaczony (art. 68).

Software house współpracujący z programistami na kontraktach przeniesie na klienta tylko prawa, które sam od nich nabył, więc umowy w łańcuchu muszą do siebie pasować (więcej w dziale Software house'y).

Pola eksploatacji programu komputerowego

Umowa o przeniesienie praw i licencja obejmują tylko pola eksploatacji wyraźnie w nich wymienione (art. 41 ust. 2) i mogą dotyczyć wyłącznie pól znanych w chwili zawarcia umowy (art. 41 ust. 4). Ogólna formuła „na wszystkich polach eksploatacji” bez wyliczenia jest więc dla zamawiającego ryzykowna.

Punktem odniesienia jest art. 74 ust. 4, opisujący zakres praw do programu, oraz przykładowy katalog z art. 50. Lista pól może obejmować:

trwałe lub czasowe zwielokrotnianie programu w całości lub w części, dowolnymi środkami i w dowolnej formie;
tłumaczenie, przystosowywanie, zmianę układu i wszelkie inne zmiany w programie;
rozpowszechnianie programu lub jego kopii, w tym użyczenie i najem;
wprowadzanie do obrotu oryginału albo egzemplarzy;
publiczne udostępnianie programu w taki sposób, aby każdy mógł mieć do niego dostęp w miejscu i czasie przez siebie wybranym.

Pola trzeba dopasować do modelu biznesowego, np. opisać wprost udostępnianie w modelu SaaS albo dystrybucję przez sklepy z aplikacjami. Na sposób korzystania, który pojawi się dopiero po podpisaniu umowy, potrzebna będzie nowa umowa lub aneks.

Kiedy prawa przechodzą na zamawiającego

Jeśli umowa nie stanowi inaczej, prawa przechodzą na nabywcę z chwilą przyjęcia utworu (art. 64). Gdy zamawiający w ciągu sześciu miesięcy od dostarczenia nie zawiadomi twórcy o przyjęciu, nieprzyjęciu albo uzależnieniu przyjęcia od zmian, uważa się, że przyjął utwór bez zastrzeżeń. Strony mogą ustalić inny termin (art. 55 ust. 4).

Moment przejścia praw można powiązać m.in. z:

wydaniem kodu, np. przekazaniem do repozytorium klienta;
odbiorem potwierdzonym protokołem;
zapłatą wynagrodzenia, dzięki czemu programista nie traci praw przed otrzymaniem pieniędzy;
końcem okresu rozliczeniowego, np. co miesiąc dla kodu z danego miesiąca.

Jeśli prawa mają przejść dopiero po zapłacie, umowa powinna dawać zamawiającemu licencję na okres przejściowy.

Wynagrodzenie za przeniesienie praw

Od 20 września 2024 r., po nowelizacji z 26 lipca 2024 r., art. 77 ust. 1 wyłącza w przypadku programów komputerowych m.in. art. 43 i 44. Do kodu nie stosuje się więc reguły o godziwym wynagrodzeniu należnym twórcy, gdy umowa nie przewiduje nieodpłatności, ani możliwości żądania przed sądem podwyższenia wynagrodzenia niewspółmiernie niskiego wobec korzyści nabywcy.

Stosuje się natomiast art. 45: jeśli umowa nie stanowi inaczej, twórcy należy się odrębne wynagrodzenie za korzystanie z utworu na każdym odrębnym polu eksploatacji. Umowa powinna więc jasno mówić, czy wynagrodzenie za prawa na wszystkich polach mieści się w stawce za usługi.

Ma to też znaczenie podatkowe. W uldze IP Box kwalifikowany dochód z kwalifikowanych praw własności intelektualnej jest opodatkowany stawką 5 proc. (art. 30ca ustawy o PIT, stan na październik 2026). Do takich praw należy autorskie prawo do programu komputerowego wytworzonego, rozwiniętego lub ulepszonego przez podatnika w ramach jego działalności badawczo-rozwojowej, a dochód może pochodzić m.in. ze sprzedaży prawa lub z opłat licencyjnych. Ulga wymaga wyodrębnienia każdego takiego prawa w księgach lub ewidencji (art. 30cb), więc zapisy umowy najlepiej uzgodnić z doradcą podatkowym.

Utwory przyszłe, kod źródłowy i prawa zależne

Umowa jest nieważna w części dotyczącej wszystkich utworów albo wszystkich utworów określonego rodzaju tego samego twórcy, które mają powstać w przyszłości (art. 41 ust. 3). Bezpieczniej powiązać przeniesienie z konkretnym projektem, zamówieniem lub specyfikacją, a kolejne partie kodu potwierdzać protokołami odbioru.

Ochrona obejmuje wszystkie formy wyrażenia programu, ale nie idee i zasady, na których się opiera (art. 74 ust. 2), dlatego przeniesienie dobrze odnieść zarówno do kodu źródłowego, jak i wynikowego. Jeśli umowa nie stanowi inaczej, przejście praw nie przenosi na nabywcę własności egzemplarza utworu (art. 52 ust. 2). Umowa powinna więc wymieniać, co programista przekazuje, np. repozytorium, dokumentację i dostępy.

Trzeba też zadbać o prawa zależne, czyli zgodę na rozporządzanie i korzystanie z opracowań utworu (art. 2 ust. 2). Według art. 46 twórca, jeśli umowa nie stanowi inaczej, zachowuje wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego, nawet gdy przeniósł całość praw majątkowych. Art. 77 nie wyłącza tego przepisu dla programów, więc umowa powinna przenosić także to uprawnienie.

Open source i biblioteki własne programisty

Programista nie przeniesie praw do kodu, którego nie stworzył. Z komponentów open source klient korzysta na zasadach ich licencji, dlatego umowa powinna przewidywać listę bibliotek zewnętrznych wraz z licencjami.

Licencje różnią się obowiązkami. Licencja MIT wymaga zachowania informacji o prawach autorskich i treści licencji we wszystkich kopiach lub istotnych częściach oprogramowania. GNU GPL v3 przy rozpowszechnianiu programu opartego na takim kodzie wymaga objęcia całości tą samą licencją i udostępnienia kodu źródłowego. Zamawiający może zastrzec, że komponenty z licencjami typu copyleft wymagają jego zgody.

Własne biblioteki, generatory czy szablony programisty powinny być w umowie wyłączone z przeniesienia, najlepiej konkretną listą repozytoriów lub modułów, i objęte licencją dla klienta, np. niewyłączną, bez ograniczeń terytorialnych i z jasnymi warunkami wypowiedzenia.

Autorskie prawa osobiste

Autorskie prawa osobiste nie podlegają zrzeczeniu się ani zbyciu (art. 16). Przy programach komputerowych ich zakres jest węższy, bo art. 77 ust. 1 wyłącza art. 16 pkt 3–5, czyli prawo do nienaruszalności treści i formy utworu oraz jego rzetelnego wykorzystania, do decydowania o pierwszym udostępnieniu publiczności i do nadzoru nad sposobem korzystania. Zostaje przede wszystkim prawo do autorstwa oraz do oznaczenia kodu nazwiskiem lub pseudonimem albo udostępniania go anonimowo.

W umowach stosuje się więc zobowiązanie twórcy do niewykonywania tych praw wobec zamawiającego i jego następców prawnych albo upoważnienie zamawiającego do decydowania o oznaczaniu autorstwa. Ustawa nie reguluje takich klauzul wprost, więc ich zakres trzeba opisać precyzyjnie.

Checklista dla programisty

Forma pisemna lub kwalifikowany podpis elektroniczny i dokładne wskazanie kodu, którego dotyczy przeniesienie.
Przejście praw po zapłacie lub odbiorze, a wcześniej licencja dla klienta.
Jasny zapis, czy wynagrodzenie za prawa mieści się w stawce.
Własne biblioteki wyłączone z przeniesienia i objęte licencją.
Lista komponentów open source.
Przy IP Box: zapisy uzgodnione z doradcą podatkowym.

Checklista dla zamawiającego

Pola eksploatacji wymienione wprost, w tym zmiany w kodzie i udostępnianie online.
Przeniesienie prawa do zezwalania na wykonywanie praw zależnych (art. 46).
Brak zakazu dalszego przenoszenia praw, a przy licencji zgoda na sublicencje.
Obowiązek wydania kodu źródłowego, dokumentacji i dostępów.
Oświadczenie, że kod nie narusza praw osób trzecich; gdy utwór ma wady prawne, zamawiający może odstąpić od umowy i żądać naprawienia szkody (art. 55 ust. 2).
Potwierdzenie, że wykonawca nabył prawa od swoich pracowników i podwykonawców, oraz zasady użycia komponentów typu copyleft.

Każdy projekt wymaga innych zapisów, dlatego przy dużym kontrakcie lub sporze o kod dobrze jest skonsultować umowę z prawnikiem. Więcej o pracy na kontraktach znajdziesz w dziale Praca w IT, a o rejestracji działalności w poradniku o kodach PKD dla programisty.

Najczęściej zadawane pytania

Do kogo należą prawa autorskie do kodu pisanego na B2B?

Do programisty jako twórcy, dopóki nie przeniesie ich umową zawartą w formie pisemnej. Automatyczne nabycie praw do programu przez zatrudniającego dotyczy tylko pracowników (art. 74 ust. 3).

Czy umowę o przeniesienie praw autorskich można zawrzeć mailowo?

Nie, mail to najwyżej forma dokumentowa, a ustawa wymaga formy pisemnej pod rygorem nieważności. Wystarczy podpis własnoręczny albo kwalifikowany podpis elektroniczny.

Jakie pola eksploatacji wpisać dla programu komputerowego?

Podstawą są zwielokrotnianie, zmiany i rozpowszechnianie programu (art. 74 ust. 4), a w razie potrzeby także publiczne udostępnianie online, np. w modelu SaaS. Każde pole musi być wymienione wprost.

Czy można przenieść autorskie prawa osobiste do kodu?

Nie, prawa osobiste są niezbywalne. Przy programach chodzi głównie o prawo do autorstwa i oznaczenia utworu, a w umowach stosuje się zobowiązanie do ich niewykonywania.