Przy umowie B2B autorskie prawa majątkowe do kodu, grafik czy dokumentacji należą na start do wykonawcy, a nie do zleceniodawcy. Klient nabywa je dopiero wtedy, gdy umowa w formie pisemnej wyraźnie przewiduje przeniesienie praw i wymienia pola eksploatacji. Jeśli takiego zapisu brak, ustawa zakłada, że twórca udzielił jedynie licencji.
Dlaczego B2B działa inaczej niż etat
Ustawa o prawie autorskim i prawach pokrewnych zawiera szczególną regułę dla pracowników: prawa majątkowe do programu komputerowego stworzonego w ramach obowiązków ze stosunku pracy przysługują pracodawcy, o ile umowa nie stanowi inaczej (art. 74 ust. 3). Przedsiębiorca prowadzący działalność i rozliczający się fakturą nie jest pracownikiem, więc ta reguła go nie obejmuje. Ani wystawienie faktury, ani przekazanie repozytorium, ani wdrożenie aplikacji na serwer klienta same w sobie niczego nie przenoszą.
Ma to znaczenie dla obu stron. Zleceniodawca, który zapłacił za oprogramowanie bez porządnej klauzuli, może mieć problem z jego sprzedażą, z pozyskaniem inwestora czy przejściem badania prawnego spółki. Wykonawca z kolei, który nie zadba o zapisy, może nieświadomie oddać prawa do własnych narzędzi wykorzystywanych w wielu projektach.
Trzy przepisy, które rozstrzygają o przejściu praw
- Forma pisemna pod rygorem nieważności (art. 53). Umowa przenosząca autorskie prawa majątkowe zawarta wyłącznie mailowo, przez akceptację regulaminu czy kliknięcie w systemie jest nieważna w tej części. Formę pisemną zachowuje własnoręczny podpis albo kwalifikowany podpis elektroniczny.
- Pola eksploatacji wymienione wprost (art. 41 ust. 2). Przeniesienie obejmuje tylko te sposoby korzystania, które wskazano w umowie. Ogólnik „wszystkie znane pola” bywa podważany. Umowa nie może też dotyczyć pól nieznanych w chwili jej zawarcia (art. 41 ust. 4).
- Domniemanie licencji (art. 65). Gdy nie ma wyraźnego postanowienia o przeniesieniu, przyjmuje się, że twórca udzielił licencji — a licencja bez określonych warunków jest niewyłączna, ograniczona do 5 lat i terytorium kraju licencjobiorcy (art. 66–67).
Dodatkowo nieważna jest umowa dotycząca wszystkich przyszłych utworów danego twórcy (art. 41 ust. 3). Klauzula w stylu „wykonawca przenosi prawa do wszystkiego, co kiedykolwiek stworzy” nie zadziała; przedmiot przeniesienia trzeba powiązać z konkretnym zleceniem, projektem lub zamówieniem.
Kiedy dokładnie prawa przechodzą na klienta
Jeżeli umowa nie wskazuje innego momentu, prawa przechodzą z chwilą przyjęcia utworu (art. 64). W praktyce strony wybierają jeden z modeli:
| Moment przejścia | Dla kogo korzystny | Na co uważać |
|---|---|---|
| Przyjęcie (odbiór) utworu | neutralny, zgodny z ustawą | trzeba opisać, jak wygląda odbiór przy pracy ciągłej, np. w sprintach |
| Zapłata wynagrodzenia za dany okres | wykonawca | klient przez pewien czas korzysta z kodu bez praw — umowa powinna przewidywać licencję przejściową |
| Chwila powstania (ustalenia) kodu | zleceniodawca | wykonawca traci kontrolę nad prawami nawet przy nieopłaconych fakturach |
Przy rozliczeniu miesięcznym wygodnym rozwiązaniem jest przeniesienie praw do wszystkiego, co powstało w danym miesiącu, z chwilą zapłaty faktury za ten miesiąc, oraz udzielenie licencji na czas między wydaniem kodu a zapłatą.
Elementy dobrej klauzuli dla wykonawcy B2B
- Przedmiot — co jest utworem: kod źródłowy i wynikowy, dokumentacja, testy, schematy baz danych, projekty interfejsów.
- Pola eksploatacji — dopasowane do programu: zwielokrotnianie, modyfikacja i tłumaczenie kodu, rozpowszechnianie, udostępnianie w sieci, w tym w modelu subskrypcyjnym, łączenie z innym oprogramowaniem.
- Prawo zależne — zgoda na tworzenie i rozporządzanie opracowaniami. Bez niej twórca zachowuje wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego, nawet przy przeniesieniu całości praw (art. 46).
- Moment przejścia i licencja przejściowa — patrz tabela wyżej.
- Wynagrodzenie — informacja, że stawka obejmuje przeniesienie praw, a w razie potrzeby wyodrębniona kwota za prawa (istotna np. przy uldze IP Box).
- Elementy wyłączone — własne biblioteki, szablony i narzędzia wykonawcy oraz komponenty o otwartym kodzie, na które klient dostaje licencję, a nie prawa.
- Prawa osobiste — zobowiązanie do niewykonywania niektórych uprawnień, np. oznaczania autorstwa. Praw osobistych nie da się zbyć (art. 16).
Warto wiedzieć, że przepisy o wynagrodzeniu twórcy, w tym prawo do „godziwego” wynagrodzenia i dodatkowego wynagrodzenia przy rażącej dysproporcji (art. 43–44), w ogóle nie dotyczą programów komputerowych (art. 77 ust. 1). Wysokość zapłaty za prawa do kodu zależy więc wyłącznie od negocjacji.
Licencja czy przeniesienie — co wybrać
Przeniesienie praw ma sens, gdy klient buduje własny produkt, chce go sprzedawać, licencjonować dalej lub pozyskać finansowanie. Licencja wystarcza, gdy oprogramowanie służy wewnętrznym potrzebom klienta albo gdy wykonawca dostarcza rozwiązanie, które sprzedaje również innym. Licencja wyłączna wymaga formy pisemnej pod rygorem nieważności, podobnie jak przeniesienie. Licencja niewyłączna może być zawarta w dowolnej formie, ale bez zapisu o okresie wygasa po 5 latach — co w projektach wieloletnich bywa zaskoczeniem.
Przykład: aplikacja dla sieci sklepów
Pan Marek, programista na JDG, przez 8 miesięcy rozwijał system rezerwacji dla klienta. Umowa ramowa została zaakceptowana mailowo i zawierała zdanie: „prawa autorskie należą do zamawiającego”. Gdy klient zaczął rozmowy o sprzedaży spółki, audytor wskazał, że przeniesienie jest nieważne z braku formy pisemnej, a pola eksploatacji nie zostały wymienione. W efekcie klient miał jedynie licencję niewyłączną. Rozwiązaniem było podpisanie aneksu kwalifikowanym podpisem elektronicznym, z listą pól eksploatacji, zgodą na opracowania i wyłączeniem biblioteki, którą Pan Marek stosuje u innych klientów. Aneks przenosi prawa od dnia podpisania; za okres wcześniejszy strony potwierdziły w nim licencję.
Najczęstsze błędy
- Brak umowy na piśmie i poleganie na korespondencji lub zamówieniach w systemie zakupowym.
- Jedno zdanie o „przeniesieniu wszelkich praw” bez listy pól eksploatacji.
- Brak zgody na opracowania, przez co klient formalnie nie może modyfikować kodu.
- Przeniesienie praw do narzędzi, z których wykonawca korzysta u kolejnych klientów.
- Kary umowne i zakazy konkurencji nieproporcjonalne do stawki, a do tego zapisy upodabniające współpracę do etatu — więcej w artykule o tym, kiedy umowa B2B może zostać uznana za stosunek pracy.
Treść ustawy w aktualnym brzmieniu (tekst jednolity Dz.U. 2025 poz. 24) jest dostępna w Internetowym Systemie Aktów Prawnych.
Jak pomaga Good Balance
Przygotowujemy i weryfikujemy umowy B2B, w tym klauzule o przeniesieniu praw autorskich, licencjach i wyłączeniach własnych narzędzi wykonawcy. Szczegóły w usłudze przygotowanie umów. Jeśli umowa ma także umożliwić rozliczenie ulgi IP Box, uwzględniamy to od razu w zapisach — więcej o samej uldze w poradniku IP Box dla programistów. W sprawach spornych można umówić się na konsultację prawną.