Prawa autorskie programisty B2B - kto ma prawa do kodu?

Prawa autorskie do kodu napisanego przez programistę współpracującego na B2B należą do programisty - dopóki nie przeniesie ich na klienta w pisemnej umowie. Przepisy, które automatycznie dają pracodawcy prawa do programu, dotyczą wyłącznie pracowników na umowie o pracę. Jeśli więc zlecasz pracę kontraktorowi lub sam nim jesteś, o tym, kto ma prawa do kodu, decyduje treść umowy - a dokładniej to, czy przewiduje przeniesienie praw, na jakich polach eksploatacji i w jakiej formie.

W tym artykule wyjaśniamy, jak działa to w praktyce, czym różni się sytuacja pracownika od kontraktora i co powinno się znaleźć w dobrej umowie B2B z programistą.

Czy kod źródłowy w ogóle jest chroniony prawem autorskim?

Tak. Program komputerowy to utwór w rozumieniu prawa autorskiego i jest chroniony podobnie jak utwór literacki (art. 1 ust. 2 pkt 1 i art. 74 ust. 1 ustawy o prawie autorskim i prawach pokrewnych, dalej: pr. aut.).

Ochrona obejmuje każdą formę wyrażenia programu - kod źródłowy, kod wynikowy (skompilowany), a także dokumentację projektową. Nie są natomiast chronione same idee, algorytmy czy zasady działania programu (art. 74 ust. 2 pr. aut.). Ochrona powstaje automatycznie, z chwilą napisania kodu - bez rejestracji, zastrzeżeń czy znaczka ©.

W praktyce oznacza to, że programista, który pisze kod, od pierwszej linijki jest jego twórcą i - w braku innych regulacji - właścicielem autorskich praw majątkowych.

Utwór pracowniczy a kod programisty B2B - na czym polega różnica?

Utwór pracowniczy to utwór stworzony przez pracownika w wyniku wykonywania obowiązków ze stosunku pracy. Dla programów komputerowych obowiązuje szczególnie korzystna dla pracodawcy reguła: autorskie prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków służbowych przysługują pracodawcy, chyba że umowa stanowi inaczej (art. 74 ust. 3 pr. aut.). Pracodawca nie musi nawet przyjmować utworu - prawa nabywa od razu, z mocy samej ustawy.

Kłopot w tym, że programista na B2B nie jest pracownikiem. Współpracuje na podstawie umowy cywilnoprawnej (zwykle umowy o świadczenie usług lub o dzieło), prowadząc własną działalność gospodarczą. Do takiej współpracy art. 12 i art. 74 ust. 3 pr. aut. nie mają zastosowania.

Co się dzieje, gdy umowa B2B nie wspomina o prawach autorskich?

Krótko: prawa do kodu zostają przy programiście. Klient, który zapłacił za pracę, nie staje się automatycznie właścicielem praw autorskich.

Pomocniczo sąd może uznać, że strony w sposób dorozumiany (wynikający z okoliczności) udzieliły sobie licencji niewyłącznej - czyli zgody na korzystanie z kodu w zakresie, jaki był konieczny do realizacji celu umowy. Zgodnie z art. 65 pr. aut., w braku wyraźnego postanowienia o przeniesieniu prawa uważa się, że twórca udzielił licencji. Taka licencja jest jednak:

• niewyłączna - programista może ten sam kod licencjonować innym, także konkurencji,
• niepewna co do zakresu - nie wiadomo, czy obejmuje np. dalszą sprzedaż, modyfikacje czy udostępnianie w modelu SaaS,
• trudna do wykazania - spór o jej zakres rozstrzyga się dopiero przed sądem.

Pamiętaj też, że samo przekazanie kodu, repozytorium czy nośnika nie przenosi praw autorskich (art. 52 ust. 1 pr. aut.).

Jak skutecznie przenieść prawa do kodu na klienta?

Aby klient nabył prawa do kodu, potrzebna jest pisemna umowa o przeniesienie autorskich praw majątkowych, wskazująca konkretne pola eksploatacji. To trzy kluczowe elementy.

1. Forma pisemna

Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 pr. aut.). Oznacza to własnoręczny podpis lub kwalifikowany podpis elektroniczny (art. 78 i 781 Kodeksu cywilnego). Mail, akceptacja w systemie do zarządzania projektami czy podpis zwykłym narzędziem do e-podpisu, który nie daje podpisu kwalifikowanego, nie wystarczą. Ta sama forma dotyczy licencji wyłącznej (art. 67 ust. 5 pr. aut.).

2. Wyraźnie wymienione pola eksploatacji

Pole eksploatacji to określony sposób korzystania z utworu, np. kopiowanie, modyfikowanie czy rozpowszechnianie. Umowa obejmuje tylko te pola, które zostały w niej wyraźnie wymienione (art. 41 ust. 2 pr. aut.). Ogólne sformułowanie typu „przenosi wszelkie prawa autorskie na wszystkich polach eksploatacji” jest bardzo ryzykowne i może zostać uznane za nieskuteczne.

Dla programów komputerowych punktem wyjścia jest art. 74 ust. 4 pr. aut., który wymienia uprawnienia twórcy. W umowie warto ująć co najmniej:

• trwałe lub czasowe zwielokrotnianie programu w całości lub w części, jakimikolwiek środkami i w jakiejkolwiek formie, w tym wprowadzanie, wyświetlanie, stosowanie, przekazywanie i przechowywanie,
• tłumaczenie, przystosowywanie, zmianę układu i wszelkie inne zmiany (np. refaktoryzację, rozwój, poprawki),
• rozpowszechnianie, w tym użyczenie lub najem programu lub jego kopii,
• publiczne udostępnianie w taki sposób, aby każdy mógł mieć do niego dostęp w wybranym miejscu i czasie (np. model SaaS, aplikacje mobilne w sklepach),
• wprowadzanie do pamięci komputerów, serwerów i chmury,
• łączenie z innym oprogramowaniem i włączanie do innych utworów,
• udzielanie dalszych licencji i sublicencji oraz zbywanie praw.

3. Zgoda na wykonywanie praw zależnych

Prawo zależne to prawo do korzystania z opracowania cudzego utworu - np. nowej wersji programu powstałej na bazie pierwotnego kodu. Rozporządzanie opracowaniem i korzystanie z niego wymaga zgody twórcy utworu pierwotnego (art. 2 ust. 2 pr. aut.). Jeśli umowa tego nie przewiduje, prawo do zezwalania na wykonywanie praw zależnych zostaje przy twórcy (art. 46 pr. aut.). W umowie z programistą warto więc wprost przenieść to prawo na klienta albo przynajmniej udzielić mu zgody na rozwijanie kodu przez innych programistów.

Co jeszcze powinna zawierać umowa z programistą B2B?

Same pola eksploatacji to nie wszystko. Dobra umowa IP (dotycząca własności intelektualnej) z kontraktorem reguluje też kilka praktycznych kwestii:

1. Moment przejścia praw - np. z chwilą przekazania kodu, odbioru etapu albo zapłaty wynagrodzenia. Programiści często chcą, by prawa przechodziły dopiero po zapłacie; klient woli moment wydania kodu.
2. Wynagrodzenie - wskaż, że wynagrodzenie za usługi obejmuje także przeniesienie praw na wszystkich polach eksploatacji. Bez tego twórca może domagać się osobnej zapłaty za każde pole (art. 45 pr. aut.).
3. Kod źródłowy i dokumentacja - obowiązek przekazania kodu źródłowego (np. przez repozytorium klienta) wraz z dokumentacją.
4. Komponenty open source i biblioteki zewnętrzne - programista nie może przenieść praw do cudzego kodu. Umowa powinna wymagać informowania o użytych licencjach (np. GPL, MIT, Apache) i zakazywać licencji „zaraźliwych”, jeśli mogłyby zmusić klienta do otwarcia własnego kodu.
5. Kod generowany z pomocą AI - fragmenty wygenerowane przez narzędzia AI bez twórczego wkładu człowieka mogą w ogóle nie być utworem, a więc nie da się do nich przenieść praw. Warto zobowiązać programistę do informowania o takim użyciu i do przestrzegania zasad klienta w tym zakresie. To obszar, w którym orzecznictwo i przepisy wciąż się kształtują - dobrze śledzić zmiany.
6. Oświadczenia i gwarancje - że kod nie narusza praw osób trzecich, a w razie roszczeń programista zwolni klienta z odpowiedzialności.
7. Autorskie prawa osobiste - zobowiązanie twórcy do niewykonywania ich w sposób utrudniający korzystanie z kodu, np. do nieżądania oznaczania autorstwa.

O ostatnim punkcie piszemy szerzej w artykule Jak zabezpieczyć się przed roszczeniami twórcy z tytułu osobistych praw autorskich?. Warto wiedzieć, że przy programach komputerowych prawa osobiste są węższe niż przy innych utworach - twórcy nie przysługuje m.in. prawo do nienaruszalności treści i formy utworu ani do nadzoru nad sposobem korzystania z niego (art. 77 ust. 1 w zw. z art. 16 pkt 3-5 pr. aut.). Prawo do autorstwa pozostaje jednak przy programiście i nie da się go przenieść.

Przeniesienie praw czy licencja - co wybrać?

Przeniesienie praw oznacza, że klient staje się właścicielem autorskich praw majątkowych do kodu, a licencja to jedynie zgoda na korzystanie z niego w określonym zakresie. Dla kodu tworzonego na zamówienie, który ma być rdzeniem produktu klienta, standardem jest przeniesienie praw.

Licencja sprawdza się, gdy programista lub software house dostarcza własne, gotowe narzędzia i biblioteki, z których korzysta u wielu klientów. Wtedy często stosuje się model mieszany: prawa do kodu dedykowanego przechodzą na klienta, a do komponentów „bazowych” wykonawca udziela licencji - najlepiej niewyłącznej, bezterminowej i nieodwołalnej.

Czy umowa B2B może zostać uznana za umowę o pracę?

Jeśli współpraca w praktyce ma wszystkie cechy stosunku pracy - praca pod kierownictwem, w miejscu i czasie wyznaczonym przez zleceniodawcę, za wynagrodzeniem - to zgodnie z art. 22 § 11 Kodeksu pracy nie ma znaczenia nazwa umowy. Teoretycznie mogłoby to otworzyć dyskusję o zastosowaniu art. 74 ust. 3 pr. aut., ale opieranie się na takim scenariuszu byłoby bardzo ryzykowne i rodzi inne poważne konsekwencje (składki, prawa pracownicze). Bezpieczniej zawsze zakładać, że prawa przechodzą wyłącznie na podstawie umowy. O wyborze formy prowadzenia działalności przeczytasz w artykule Spółka z o.o. czy JDG - co bardziej opłaca się przedsiębiorcy w 2026 roku?.

Umowy IP z programistami, audyty praw do oprogramowania przed inwestycją oraz porządkowanie praw do kodu to sprawy, którymi zajmuje się m.in. APM Poniatowska-Maj Kancelaria Prawna sp. k. - jeśli potrzebujesz wsparcia, możesz napisać na biuro@apmkancelaria.pl.

Lista kontrolna - prawa do kodu programisty B2B

Zanim podpiszesz umowę z programistą na B2B (lub jako programista - zanim ją zaakceptujesz), sprawdź, czy:

• umowa zawiera wyraźne postanowienie o przeniesieniu autorskich praw majątkowych lub udzieleniu licencji,
• jest zawarta w formie pisemnej lub z kwalifikowanym podpisem elektronicznym,
• wymienia konkretne pola eksploatacji dopasowane do oprogramowania (zwielokrotnianie, modyfikacje, rozpowszechnianie, udostępnianie online, sublicencjonowanie),
• przenosi prawo do zezwalania na wykonywanie praw zależnych,
• określa moment przejścia praw i to, że wynagrodzenie obejmuje wszystkie pola eksploatacji,
• reguluje przekazanie kodu źródłowego i dokumentacji,
• zawiera zasady korzystania z open source i narzędzi AI,
• zawiera oświadczenia o braku naruszeń praw osób trzecich oraz zobowiązanie dotyczące wykonywania praw osobistych,
• w przypadku dotychczasowej współpracy bez takich zapisów - masz plan zawarcia umów „naprawczych”.