Przeniesienie autorskich praw majątkowych czy licencja? Jak rozliczać kod w umowie B2B

Kto właściwie jest właścicielem kodu, za który zapłaciłeś? Gdy zamawiasz oprogramowanie od programisty prowadzącego jednoosobową działalność gospodarczą lub gdy sam dostarczasz kod jako kontraktor B2B, naturalnym założeniem wydaje się, że opłacenie faktury zamyka sprawę. W rzeczywistości prawo autorskie działa zupełnie inaczej. Przelew bankowy bez odpowiednio sformułowanej umowy nie sprawi, że prawa do stworzonego oprogramowania przejdą na klienta.

W relacjach biznesowych (B2B) kluczową decyzją jest wybór między trwałym przeniesieniem autorskich praw majątkowych a udzieleniem licencji. Każde z tych rozwiązań niesie za sobą odmienne konsekwencje prawne, podatkowe oraz biznesowe dla obu stron. Zrozumienie różnic między nimi oraz poprawne sformułowanie zapisów umownych pozwala uniknąć kosztownych sporów o prawa do kodu źródłowego, a także ułatwia ewentualną sprzedaż projektu lub pozyskanie inwestorów w przyszłości.

Kod w umowie B2B: dlaczego sama faktura nie rozstrzyga praw do programu

Usługa programistyczna, utwór i program komputerowy – trzy pojęcia, które łatwo pomylić

Wielu przedsiębiorców utożsamia wykonanie usługi programistycznej z nabyciem praw do jej efektów

utworów. To jednak dwa różne porządki. Usługa oznacza wykonanie określonych prac, na przykład zaprogramowanie modułu płatności lub usunięcie błędów. Utworem jest natomiast rezultat twórczej pracy, jeżeli ma indywidualny charakter. Kod źródłowy programu komputerowego co do zasady podlega ochronie prawa autorskiego, ale ochroną nie są objęte same pomysły, funkcje biznesowe ani ogólne zasady działania aplikacji.

Faktura potwierdza przede wszystkim, że wykonawca rozliczył usługę lub dostarczył rezultat prac. Nie przenosi automatycznie autorskich praw majątkowych, nawet jeśli w opisie widnieje „wykonanie oprogramowania” albo „sprzedaż kodu”. Również przekazanie klientowi dostępu do repozytorium, plików źródłowych czy serwera nie przesądza jeszcze, że może on dowolnie kod zmieniać, rozpowszechniać albo odsprzedawać.

W modelu B2B programista nie działa jak pracownik zatrudniony na etacie. Przepis, który w określonych warunkach przyznaje pracodawcy prawa do programu stworzonego przez pracownika, nie rozciąga się automatycznie na współpracę między dwoma przedsiębiorcami. Jeżeli umowa milczy na temat praw autorskich, twórca kodu zwykle zachowuje autorskie prawa majątkowe, a klient może co najwyżej powoływać się na zakres używania wynikający z celu i okoliczności współpracy. Taka sytuacja bywa szczególnie ryzykowna przy wdrożeniu dla inwestora, sprzedaży spółki lub zmianie wykonawcy.

Jasne rozdzielenie zapłaty za pracę od zasad korzystania z kodu chroni obie strony. Klient wie, czy nabywa prawa na stałe, czy jedynie otrzymuje zgodę na używanie programu, a wykonawca nie musi później spierać się o to, czy przekazał więcej, niż rzeczywiście zamierzał.

Dwa podstawowe warianty: przeniesienie praw majątkowych albo licencja

W obrocie gospodarczym B2B regulacja kwestii praw autorskich do kodu sprowadza się zazwyczaj do wyboru jednego z dwóch modeli prawnych. Pierwszym jest trwałe przeniesienie autorskich praw majątkowych, drugim – udzielenie licencji (która może przybrać formę wyłączną lub niewyłączną). Wybór ten determinuje, kto ostatecznie pozostaje „właścicielem” kodu, a kto jedynie uzyskuje prawo do korzystania z niego na określonych zasadach.

Wariant A: Przeniesienie autorskich praw majątkowych

Przeniesienie praw majątkowych to transakcja o charakterze definitywnym. W jej wyniku programista (twórca) całkowicie i bezpowrotnie wyzbywa się autorskich praw majątkowych do stworzonego kodu na rzecz klienta. Od momentu skutecznego przeniesienia to klient staje się wyłącznym dysponentem oprogramowania.

Może on wówczas swobodnie modyfikować kod, odsprzedawać go innym podmiotom, udostępniać jako open source czy komercjalizować w dowolny sposób. Programista traci prawo do dalszego licencjonowania tego konkretnego kodu innym klientom, chyba że w umowie wprost zastrzeżono określone wyjątki (np. prawo do korzystania z uniwersalnych bibliotek pomocniczych).

Wariant B: Licencja na korzystanie z oprogramowania

Licencja nie powoduje przejścia praw autorskich. Programista pozostaje jedynym właścicielem kodu, a klient otrzymuje jedynie uprawnienie (zgodę) do korzystania z niego w zakresie ściśle określonym w umowie. W praktyce B2B wyróżnia się dwa główne typy licencji:

• Licencja niewyłączna – najemca (klient) może korzystać z kodu, ale programista zachowuje prawo do udzielania identycznych licencji dowolnej liczbie innych podmiotów. To standardowy model przy oprogramowaniu typu SaaS, gotowych komponentach czy powtarzalnych modułach.
• Licencja wyłączna – programista zobowiązuje się, że w danym okresie i na określonym terytorium nie udzieli licencji nikomu innemu ani sam nie będzie korzystał z kodu w zakresie objętym wyłącznością. Taki model daje klientowi większe bezpieczeństwo rynkowe, zbliżone do przeniesienia praw, jednak nadal bez pełnego prawa własności.

Porównanie modeli: co dokładnie zmienia się dla klienta i wykonawcy

Wybór między przeniesieniem praw a licencją wpływa bezpośrednio na swobodę biznesową, wycenę projektu oraz bezpieczeństwo prawne obu stron transakcji. Poniższe zestawienie przedstawia kluczowe różnice między tymi dwoma podejściami.

Zalety i wady przeniesienia praw

Dla klienta głównym plusem jest pełna niezależność. Posiadanie praw majątkowych eliminuje ryzyko, że wykonawca zablokuje rozwój projektu lub zażąda dodatkowych opłat za rozbudowę systemu. Jest to warunek konieczny przy budowaniu systemów dedykowanych, które stanowią rdzeń biznesu (core IP) lub są przygotowywane pod kątem sprzedaży firmy inwestorowi. Minusem jest wyższa cena oraz konieczność precyzyjnego uregulowania kwestii tzw. bibliotek zewnętrznych i kodu wielokrotnego użytku.

Dla programisty przeniesienie praw oznacza konieczność dokładnego wyeliminowania z przenoszonego zakresu swoich własnych narzędzi i uniwersalnych fragmentów kodu (tzw. developer components), których używa w codziennej pracy dla różnych klientów. Brak takich wyłączeń może zablokować jego dalszą działalność zawodową.

Zalety i wady licencji

Licencja to optymalne rozwiązanie dla klientów, którzy potrzebują gotowego narzędzia do wsparcia biznesu (np. systemu CRM, silnika sklepu), ale nie zamierzają go odsprzedawać ani traktować jako swojego głównego aktywa. Pozwala to na znaczne obniżenie kosztów początkowych. Wadą jest uzależnienie od licencjodawcy w kwestii poprawek, aktualizacji oraz ograniczone możliwości samodzielnego dostosowywania kodu.

Dla programisty licencjonowanie kodu to najlepszy sposób na budowanie pasywnego dochodu i skalowanie biznesu. Może on raz stworzony moduł sprzedawać wielokrotnie, zachowując nad nim pełną kontrolę autorską.

Dobrym uzupełnieniem tego tematu jest także poradnik: Kiedy kod staje się utworem chronionym prawem autorskim?.

Rekomendacja: Jak wybrać właściwy model?

Wybór nie powinien być dziełem przypadku. Można posłużyć się prostym podziałem opartym na celu biznesowym realizowanego projektu:

• Wybierz przeniesienie praw majątkowych, gdy: tworzysz unikalne oprogramowanie od zera, które ma stanowić kluczową wartość Twojego przedsiębiorstwa, planujesz pozyskanie funduszy VC, sprzedaż startupu lub chcesz mieć pełną swobodę w wyborze kolejnych software house’ów do rozwoju systemu.
• Wybierz licencję, gdy: korzystasz z gotowego rozwiązania, które wykonawca jedynie konfiguruje lub dostosowuje do Twoich potrzeb, budżet projektu jest ograniczony, bądź oprogramowanie pełni jedynie funkcję pomocniczą i nie stanowi o Twojej przewadze konkurencyjnej.

Jak opisać zakres praw do kodu, żeby umowa działała w praktyce

Samo zdecydowanie się na przeniesienie praw lub licencję to dopiero połowa sukcesu. Aby zapisy w umowie B2B były skuteczne i nie budziły wątpliwości interpretacyjnych, muszą precyzyjnie określać parametry techniczne i prawne tej transakcji.

Pola eksploatacji – klucz do skutecznej umowy

Zarówno przy przeniesieniu praw, jak i przy licencji, umowa musi wskazywać tzw. pola eksploatacji, czyli konkretne sposoby korzystania z utworu. Polskie prawo autorskie w art. 50 (oraz art. 74 dla programów komputerowych) wprost wymaga ich wymienienia. Zapis typu „przenosi wszelkie prawa na wszelkich polach” może zostać uznany za nieważny lub nieskuteczny.

W umowie B2B dotyczącej oprogramowania należy wyraźnie wymienić przynajmniej takie pola eksploatacji jak: trwałe lub czasowe zwielokrotnienie programu komputerowego w całości lub w części, wprowadzanie do pamięci komputerów, uruchamianie, przechowywanie, wyświetlanie, a także tłumaczenie, przystosowywanie, zmiany układu lub jakiekolwiek inne modyfikacje w kodzie źródłowym (prawo do wykonywania i zezwalania na wykonywanie autorskich praw zależnych).

Forma pisemna jako warunek konieczny

Zgodnie z ustawą o prawie autorskim i prawach pokrewnych, umowa o przeniesienie autorskich praw majątkowych oraz umowa o licencję wyłączną wymagają zachowania formy pisemnej pod rygorem nieważności. Oznacza to, że ustalenia przesłane w wiadomości e-mail, na komunikatorze Slack, a nawet podpisane zwykłym podpisem elektronicznym (bez certyfikatu kwalifikowanego, np. zwykły skan dokumentu) nie wywołają skutku prawnego w postaci przejścia praw. Do skutecznego zawarcia takiej umowy niezbędne są tradycyjne podpisy własnoręczne na papierze lub kwalifikowane podpisy elektroniczne (np. mSzafir, Autenti z weryfikacją tożsamości).

Moment przejścia praw i powiązanie z wynagrodzeniem

Częstym błędem jest brak powiązania momentu przejścia praw z zapłatą wynagrodzenia. Z punktu widzenia wykonawcy (programisty) najbezpieczniejszym zapisem jest wskazanie, że autorskie prawa majątkowe przechodzą na klienta (lub licencja zostaje udzielona) z chwilą zapłaty całości wynagrodzenia wynikającego z wystawionej faktury. Chroni to twórcę przed sytuacją, w której klient przejmuje kod, zaczyna go używać, ale odmawia uregulowania należności.

Z kolei z perspektywy klienta istotne jest, aby prawa przechodziły sukcesywnie – np. z chwilą akceptacji danego etapu prac i opłacenia faktury częściowej – co zapobiega paraliżowi projektu w przypadku nagłego zakończenia współpracy w trakcie wdrożenia.

Kwestia komponentów Open Source i praw zależnych

Współczesne oprogramowanie rzadko powstaje w 100% od zera. Programiści powszechnie korzystają z bibliotek open source, frameworków oraz gotowych szablonów. Przy konstrukcji umowy B2B należy wprost określić, że:

1. Przeniesienie praw dotyczy wyłącznie kodu stworzonego bezpośrednio przez wykonawcę.
2. W zakresie komponentów otwartego oprogramowania (open source) wykonawca gwarantuje, że zostały one użyte zgodnie z ich licencjami (np. MIT, Apache, GPL) i nie naruszają praw osób trzecich ani nie nakładają na klienta obowiązku upubliczniania jego własnego kodu handlowego.
3. Wykonawca przenosi na klienta prawo do zezwalania na wykonywanie zależnego prawa autorskiego, co umożliwia dokonywanie modyfikacji kodu przez innych programistów w przyszłości.

Autorskie prawa osobiste a swoboda refaktoryzacji kodu

Nawet całkowite przeniesienie autorskich praw majątkowych nie pozbawia programisty jego autorskich praw osobistych – te są niezbywalne i trwale związane z twórcą. W środowisku IT rodzi to konkretne ryzyka operacyjne, m.in. prawo do nienaruszalności treści i formy utworu (co teoretycznie mogłoby blokować usuwanie błędów czy refaktoryzację kodu przez innego programistę) oraz prawo do oznaczania utworu nazwiskiem twórcy.

Prawidłowo skonstruowana umowa B2B musi zawierać klauzulę, w której wykonawca:

• zobowiązuje się do niewykonywania przysługujących mu autorskich praw osobistych wobec klienta oraz jego następców prawnych,
• upoważnia klienta do decydowania o pierwszym publicznym udostępnieniu oprogramowania oraz o sposobie oznaczania (lub braku oznaczania) autorstwa kodu,
• zezwala na dokonywanie wszelkich przeróbek, modyfikacji, integracji i zmian w strukturze kodu bez konieczności uzyskiwania każdorazowej zgody pierwotnego autora.

Procedura odbioru i precyzyjne wskazanie przekazywanego kodu

W modelu zwinnego wytwarzania oprogramowania (np. Scrum, Kanban) kod powstaje iteracyjnie, a granice między poszczególnymi funkcjonalnościami zacierają się w kolejnych commitach. Aby uniknąć sporów dotyczących tego, które dokładnie fragmenty repozytorium objęte są daną płatnością i dyspozycją praw, warto wdrożyć przejrzysty mechanizm odbiorczy:

• Identyfikacja wersji w protokole odbioru: powiązanie faktury i przeniesienia praw z konkretnym stanem repozytorium (np. poprzez wskazanie unikalnego identyfikatora commit hash, numeru wersji tag w systemie Git lub linku do zaakceptowanego pull requesta).
• Wydzielenie środowiska: wyraźne zdefiniowanie w umowie, czy prawa obejmują wyłącznie kod źródłowy aplikacji docelowej, czy także skrypty konfiguracyjne (CI/CD, Dockerfile, Terraform), testy automatyczne oraz dokumentację techniczną.
• Tryb akceptacji prac: określenie terminu, w jakim klient ma prawo zgłosić uwagi techniczne, oraz zasady, że brak zastrzeżeń w wyznaczonym czasie (tzw. milczący odbiór) jest równoznaczny z przyjęciem etapu i skutkuje rozliczeniem praw zgodnie z przyjętym modelem.

Dostęp do repozytorium to nie to samo co nabycie praw

Przekazanie klientowi dostępu do GitHuba, GitLaba czy serwera z plikami nie przesądza jeszcze o sytuacji prawnej kodu. Klient może fizycznie skopiować repozytorium, a mimo to nie mieć prawa do jego dalszego rozwijania, udostępniania innemu wykonawcy albo wykorzystania w kolejnym produkcie. Dostęp techniczny i uprawnienie prawne to dwie odrębne kwestie, które powinny zostać uregulowane równolegle.

Umowa powinna określać, kiedy klient otrzymuje dostęp administracyjny do repozytorium, kto jest właścicielem organizacji w systemie kontroli wersji oraz jakie elementy infrastruktury zostają przekazane po zakończeniu współpracy. Dotyczy to zwłaszcza kluczy dostępowych, kont w usługach chmurowych, konfiguracji domen, certyfikatów, sekretów używanych w procesie wdrożenia i kont w sklepach z aplikacjami. Kod bez możliwości bezpiecznego uruchomienia bywa dla klienta znacznie mniej użyteczny, nawet jeśli prawa do niego zostały przeniesione skutecznie.

Licencja: zakres, czas i możliwość dalszego przekazania

Przy licencji największe znaczenie ma odpowiedź na pytanie: co klient może zrobić z programem bez pytania wykonawcy o kolejną zgodę? Ogólne sformułowanie „licencja na korzystanie z aplikacji” pozostawia zbyt duże pole do sporu. W praktyce trzeba opisać przynajmniej sposób korzystania, liczbę lub rodzaj użytkowników, zakres terytorialny, czas obowiązywania oraz to, czy klient może powierzyć obsługę systemu innemu podmiotowi.

Warto przeczytać również powiązany artykuł: Umowy IT – co musi zawierać każda dobra umowa wdrożeniowa?.

Szczególnej uwagi wymaga prawo do udzielania sublicencji. Jeżeli klient prowadzi grupę spółek, korzysta z podwykonawców albo chce udostępnić system swoim klientom, brak wyraźnego uprawnienia może utrudnić zwykłe działanie biznesu. Nie zawsze potrzebna jest pełna swoboda sublicencjonowania. Często wystarcza zapis pozwalający udostępniać program spółkom powiązanym, pracownikom, współpracownikom oraz dostawcom usług IT działającym na rzecz klienta.

Trzeba też rozstrzygnąć los licencji po zakończeniu umowy. Licencja terminowa może wygasnąć po upływie oznaczonego okresu, natomiast licencja udzielona na czas nieoznaczony może zostać wypowiedziana zgodnie z zasadami wynikającymi z umowy i przepisów. Dla systemu, na którym opiera się codzienna działalność firmy, nagłe wygaśnięcie możliwości korzystania z programu jest ryzykiem porównywalnym z utratą dostępu do kluczowego narzędzia.

Kod istniejący wcześniej i elementy wielokrotnego użycia

Wykonawca rzadko zaczyna każdy projekt od pustego pliku. Może wykorzystywać własne narzędzia, fragmenty infrastruktury, szablony, komponenty interfejsu, procedury wdrożeniowe albo moduły stworzone przed rozpoczęciem współpracy. Takie elementy bywają potrzebne klientowi do działania całego rozwiązania, ale nie muszą być sprzedawane wraz z kodem dedykowanym.

Najczytelniejszy model polega na rozdzieleniu obu kategorii. Kod stworzony specjalnie dla klienta może zostać objęty przeniesieniem praw, a komponenty wcześniejsze lub uniwersalne – licencją wystarczającą do korzystania z gotowego systemu. Umowa powinna możliwie konkretnie wskazywać, które elementy należą do każdej z tych grup. Nie musi to oznaczać wyliczenia każdego pojedynczego pliku, lecz opis powinien pozwalać odróżnić moduł dedykowany od narzędzia wykorzystywanego w wielu projektach.

Dobrym rozwiązaniem jest załącznik techniczny aktualizowany przy kolejnych odbiorach. Można w nim wskazać nazwę komponentu, jego przeznaczenie, rodzaj licencji oraz informację, czy kod pochodzi od wykonawcy, z projektu open source czy od zewnętrznego dostawcy. Dzięki temu późniejsza zmiana zespołu programistycznego nie zamienia się w analizę historii każdego commita.

Odpowiedzialność za prawa osób trzecich

Klient oczekuje zwykle zapewnienia, że otrzymany kod nie narusza cudzych praw. Wykonawca powinien z kolei zadbać, aby odpowiedzialność dotyczyła tylko elementów, nad którymi rzeczywiście ma kontrolę. Inaczej wygląda sytuacja, gdy programista sam kopiuje nieuprawniony fragment kodu, a inaczej, gdy klient przekazuje własne materiały, specyfikację, bibliotekę kupioną na własnym koncie lub wymaga zastosowania określonego rozwiązania.

Przejrzysta klauzula określa, kto odpowiada za roszczenia osób trzecich, jak wygląda procedura zgłoszenia problemu i jakie działania są możliwe w razie naruszenia. Może to być zastąpienie spornego komponentu, uzyskanie odpowiedniej licencji albo modyfikacja programu. Istotne jest także zobowiązanie klienta do niezwłocznego poinformowania wykonawcy o otrzymanym wezwaniu lub pozwie, zanim sam podejmie działania, które utrudnią obronę.

Zapisy, które wymagają zgodności z modelem rozliczeń

Przy rozliczeniu ryczałtowym łatwiej powiązać przeniesienie praw z odbiorem całego projektu albo konkretnego etapu. Przy stałej współpracy godzinowej lepiej ustalić cykl miesięczny: protokół lub zestawienie prac identyfikuje utwory powstałe w danym okresie, a zapłata za fakturę uruchamia skutek wskazany w umowie. Sama pozycja „usługi programistyczne” na fakturze nie zastąpi jednak postanowień o prawach autorskich.

Nie należy też mieszać odpłatności za wykonanie usługi z odpłatnością za przeniesienie praw w sposób niejasny. Umowa może wskazywać, że wynagrodzenie obejmuje oba elementy, ale powinno to wynikać wprost z jej treści. W razie sporu taki zapis ułatwia wykazanie, za co strony faktycznie się umówiły.

Krótka kontrola przed podpisaniem umowy

Przed rozpoczęciem prac dobrze jest zestawić treść umowy z realnym sposobem tworzenia i używania systemu. Pomocne są zwłaszcza cztery pytania:

• czy klient ma dostać kod na własność, czy tylko prawo do korzystania z niego,
• czy będzie mógł samodzielnie zmieniać program i zlecać jego rozwój innym osobom,
• które części rozwiązania są kodem dedykowanym, a które pozostają własnością wykonawcy lub osób trzecich,
• czy opis praw, odbioru i wynagrodzenia da się powiązać z konkretną wersją repozytorium.

Dobrze opisana umowa B2B nie polega na wpisaniu możliwie najszerszej formuły o „wszystkich prawach”. Jej zadaniem jest dopasowanie prawnego modelu do tego, jak oprogramowanie ma działać po zakończeniu współpracy. Gdy zakres kodu, sposób korzystania, moment przejścia praw i zasady użycia komponentów zewnętrznych są jasne, klient zyskuje bezpieczeństwo rozwoju produktu, a wykonawca wie, co sprzedaje i co może zachować do dalszej pracy.

Co warto zapamiętać

• Sama faktura ani przekazanie plików nie przenoszą automatycznie autorskich praw majątkowych do kodu.
• Przeniesienie praw daje klientowi trwałą i szeroką kontrolę nad oprogramowaniem, ale zwykle wiąże się z wyższym kosztem.
• Licencja pozwala korzystać z kodu bez nabywania praw, a jej zakres zależy od postanowień umowy.
• Umowa powinna jasno określać pola eksploatacji, zakres uprawnień, zasady modyfikacji oraz możliwość dalszego udostępniania kodu.
• Przy przeniesieniu praw warto wyłączyć z zakresu uniwersalne biblioteki, narzędzia i komponenty wielokrotnego użytku wykonawcy.