W skrócie: Umowa B2B z programistą powinna określać zakres usług, sposób rozliczenia, przeniesienie autorskich praw majątkowych do kodu na wymienionych polach eksploatacji (forma pisemna, art. 53 prawa autorskiego), poufność, zakaz konkurencji, SLA, limit odpowiedzialności i wypowiedzenie. Kontraktor nie jest pracownikiem, więc bez umowy prawa do kodu zostają przy nim. Jeśli programista pracuje pod kierownictwem, w miejscu i czasie wyznaczonym przez firmę, to bez względu na nazwę umowy jest to stosunek pracy (art. 22 § 1¹ KP), a od 8 lipca 2026 r. może to stwierdzić decyzją okręgowy inspektor pracy. Stan prawny: 25 października 2026.
Umowa B2B z programistą musi przede wszystkim przenieść na firmę prawa do kodu, zabezpieczyć poufność i opisać model współpracy tak, żeby nie przypominał etatu. Programista na kontrakcie nie jest pracownikiem, więc nie działa wobec niego zasada, że prawa do programu stworzonego w ramach obowiązków służbowych przysługują pracodawcy (art. 74 ust. 3 prawa autorskiego). Bez dobrze napisanej umowy firma płaci za kod, którego formalnie nie jest właścicielem.
Poniżej omawiamy elementy, które powinna zawierać każda umowa B2B w IT, zarówno z perspektywy software house’u lub startupu, jak i samego programisty.
Czym jest umowa B2B z programistą
Umowa B2B z programistą to umowa o świadczenie usług między dwoma przedsiębiorcami, do której stosuje się odpowiednio przepisy o zleceniu (art. 750 KC). Programista prowadzi jednoosobową działalność, wystawia faktury i sam opłaca podatek oraz składki. Strony mogą ułożyć umowę dowolnie w granicach swobody umów (art. 353¹ KC), ale to, czego nie uregulują, rozstrzygną przepisy o zleceniu, w tym prawo każdej strony do wypowiedzenia umowy w każdym czasie (art. 746 KC).
Często spotyka się też umowę mieszaną: część usługową (rozwój i utrzymanie oprogramowania) i część o dzieło (konkretny moduł z odbiorem). Taka konstrukcja jest dopuszczalna, ale wymaga precyzyjnego opisania, które obowiązki mają charakter rezultatu, a które starannego działania.
Elementy umowy B2B z programistą
Dobra umowa B2B w IT ma kilkanaście stałych elementów, które odpowiadają na pytania: co, za ile, na jakich zasadach i co po zakończeniu. Lista kontrolna:
- Strony – dane z CEIDG lub KRS, NIP, adresy do doręczeń, adresy e-mail do komunikacji.
- Przedmiot i zakres usług – technologie, rodzaj prac (rozwój, utrzymanie, code review, konsultacje), sposób zlecania zadań (np. przez system zgłoszeń).
- Model rozliczenia – stawka godzinowa, dzienna, ryczałt miesięczny albo wynagrodzenie za etapy; sposób raportowania czasu.
- Płatności – termin zapłaty faktury, waluta, zasady akceptacji raportu.
- Prawa autorskie – przeniesienie praw do kodu i dokumentacji, pola eksploatacji, moment przejścia praw, prawa zależne, open source.
- Poufność – definicja informacji poufnych, okres obowiązywania, zwrot materiałów.
- Zakaz konkurencji i zakaz podkupywania – zakres, czas, ewentualne wynagrodzenie.
- SLA – przy utrzymaniu systemów: czasy reakcji i usunięcia błędów.
- Odpowiedzialność – limit, wyłączenia, kary umowne.
- Dane osobowe – umowa powierzenia, jeśli programista ma dostęp do danych.
- Okres umowy i wypowiedzenie – czas nieokreślony lub określony, okres wypowiedzenia, rozwiązanie ze skutkiem natychmiastowym.
- Przekazanie po zakończeniu – kod, repozytoria, dostępy, dokumentacja.
Przeniesienie praw autorskich do kodu
Prawa do kodu przechodzą na firmę tylko wtedy, gdy umowa na piśmie wyraźnie je przenosi i wymienia pola eksploatacji. Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 prawa autorskiego), a umowa obejmuje tylko pola eksploatacji wyraźnie w niej wymienione (art. 41 ust. 2). Forma pisemna oznacza własnoręczny podpis albo kwalifikowany podpis elektroniczny; akceptacja w mailu czy podpis zwykłym narzędziem do e-podpisów nie wystarczy.
Pola eksploatacji dla programu komputerowego
Dla programów komputerowych ustawa wymienia szczególne uprawnienia (art. 74 ust. 4): zwielokrotnianie programu w całości lub części, tłumaczenie, przystosowywanie i inne zmiany oraz rozpowszechnianie, w tym użyczenie i najem. W umowie warto rozpisać je szczegółowo i dodać pola typowe dla IT:
- trwałe i czasowe zwielokrotnianie kodu źródłowego i wynikowego jakimikolwiek środkami,
- wprowadzanie do pamięci komputerów i serwerów, w tym w modelu chmurowym i SaaS,
- modyfikowanie, tłumaczenie, przystosowywanie, rozwijanie i łączenie z innymi programami,
- rozpowszechnianie, w tym udzielanie licencji i sublicencji osobom trzecim,
- publiczne udostępnianie programu tak, aby każdy mógł mieć do niego dostęp w miejscu i czasie przez siebie wybranym.
Moment przejścia praw i prawa zależne
Ustal, kiedy prawa przechodzą: z chwilą przekazania kodu (np. wypchnięcia do repozytorium firmy), z chwilą odbioru albo z chwilą zapłaty. Przy stałej współpracy praktyczne jest przejście praw z chwilą przekazania każdego fragmentu, w ramach wynagrodzenia za dany okres. Dodaj też zgodę na wykonywanie praw zależnych i prawo firmy do zezwalania na to innym, bo bez takiego zapisu twórca zachowuje wyłączne prawo zezwalania na opracowania (art. 46).
Biblioteki open source i narzędzia AI
Programista nie może przenieść praw, których nie ma. Umowa powinna zobowiązywać go do informowania o użytych bibliotekach open source i ich licencjach oraz do niewykorzystywania komponentów na licencjach, które firma wyklucza. Warto też uregulować korzystanie z asystentów AI do generowania kodu: czy jest dozwolone i na jakich zasadach. O prawnej ochronie treści generowanych przez AI piszemy w artykule prawa autorskie do grafik, zdjęć i treści z AI.
Szczegółowo o polach eksploatacji, licencji i przykładowych klauzulach przeczytasz w tekście przeniesienie autorskich praw majątkowych i pola eksploatacji.
Poufność i tajemnica przedsiębiorstwa
Klauzula poufności w umowie B2B z programistą chroni kod, architekturę systemu, dane klientów i plany produktowe także po zakończeniu współpracy. Powinna zawierać definicję informacji poufnych, wyłączenia (informacje publiczne, znane wcześniej, ujawniane na żądanie organu), czas trwania po zakończeniu umowy, obowiązek zwrotu lub usunięcia materiałów i karę umowną. Jeśli współpraca zaczyna się od rozmów i dostępu do repozytorium przed podpisaniem umowy głównej, podpisz najpierw osobne NDA; co powinno zawierać, opisaliśmy w artykule umowa NDA: co musi zawierać.
Zakaz konkurencji w umowie B2B
W umowie B2B zakaz konkurencji ustala się swobodnie, bo przepisy Kodeksu pracy o zakazie konkurencji i obowiązkowym odszkodowaniu dotyczą tylko pracowników. Zakaz musi jednak być rozsądny: obejmować konkretnych konkurentów lub branżę, trwać określony czas i nie odbierać programiście możliwości wykonywania zawodu. Bardzo szeroki zakaz bez żadnego wynagrodzenia łatwo zakwestionować jako sprzeczny z zasadami współżycia społecznego (art. 58 § 2 KC).
W praktyce w IT lepiej działają węższe klauzule:
- zakaz bezpośredniej współpracy z klientem końcowym, do którego programista został skierowany, przez 6–12 miesięcy,
- zakaz podkupywania (non-solicitation) innych współpracowników,
- zakaz konkurencji w trakcie współpracy, z jasną definicją działalności konkurencyjnej.
Jeżeli zakaz ma obowiązywać po zakończeniu umowy i dotyczy szerokiego rynku, rozważ miesięczne wynagrodzenie za powstrzymanie się od konkurencji. Więcej o zasadach dla pracowników przeczytasz w artykule zakaz konkurencji po ustaniu stosunku pracy, a gotowy dokument znajdziesz we wzorze umowy o zakazie konkurencji (pracownik i B2B).
SLA, odbiory i jakość pracy
SLA (service level agreement) określa, jak szybko programista reaguje na zgłoszenia i usuwa błędy, i ma sens głównie przy utrzymaniu systemów. Typowa tabela SLA dzieli błędy na kategorie:
| Kategoria błędu | Przykład | Czas reakcji | Czas obejścia lub naprawy |
|---|---|---|---|
| krytyczny | system nie działa, brak możliwości składania zamówień | do 2 godzin roboczych | do 1 dnia roboczego |
| poważny | kluczowa funkcja działa wadliwie | do 8 godzin roboczych | do 3 dni roboczych |
| drobny | błąd wizualny, literówka | do 2 dni roboczych | w kolejnym wydaniu |
Wartości w tabeli to przykład do negocjacji, a nie standard rynkowy. Przy jednoosobowym kontraktorze ustal też, co dzieje się w czasie jego niedostępności (urlop, choroba): kto przejmuje zgłoszenia i czy SLA jest wtedy zawieszone. Przy pracach rozwojowych zamiast SLA lepiej opisać proces odbioru: kryteria akceptacji, termin na zgłoszenie uwag i skutki braku uwag w terminie.
Odpowiedzialność i kary umowne
Zasadą w umowie B2B jest pełna odpowiedzialność za szkodę wynikłą z niewykonania lub nienależytego wykonania umowy (art. 471 KC), dlatego strony zwykle ją ograniczają. Najczęściej spotykane rozwiązania:
- limit odpowiedzialności programisty do wynagrodzenia z ostatnich 3, 6 lub 12 miesięcy,
- wyłączenie odpowiedzialności za utracone korzyści,
- wyłączenie limitu dla szkód wyrządzonych umyślnie, naruszenia poufności i naruszenia praw autorskich osób trzecich.
Pamiętaj, że nie można z góry wyłączyć odpowiedzialności za szkodę wyrządzoną umyślnie (art. 473 § 2 KC). Kary umowne można zastrzec za naruszenie poufności, zakazu konkurencji czy opóźnienie w oddaniu etapu, ale nie za opóźnienie w zapłacie faktury, bo to zobowiązanie pieniężne (art. 483 § 1 KC). Jak dobrać wysokość kary, opisujemy w artykule kary umowne: ile można zastrzec.
Okres umowy i wypowiedzenie
Umowę B2B z programistą zawiera się najczęściej na czas nieokreślony z okresem wypowiedzenia od 1 do 3 miesięcy dla obu stron. Bez takiego zapisu zastosowanie znajdzie art. 746 KC: każda strona może wypowiedzieć umowę w każdym czasie, a przy wypowiedzeniu bez ważnego powodu odpowiada za szkodę. Prawa do wypowiedzenia z ważnych powodów nie można się zrzec (art. 746 § 3 KC), więc umowa powinna przykładowo wskazać, co jest ważnym powodem: rażące naruszenie poufności, zaległość w płatnościach powyżej określonego czasu, powtarzające się naruszenia SLA.
Zapisz też obowiązki po zakończeniu: przekazanie kodu i dokumentacji, zwrot sprzętu i dostępów, usunięcie danych oraz wsparcie przy przekazaniu projektu następcy, najlepiej za wynagrodzeniem według stawki godzinowej.
Ryzyko uznania B2B za stosunek pracy
Umowa B2B z programistą zostanie potraktowana jak umowa o pracę, jeśli w praktyce programista pracuje pod kierownictwem, w miejscu i czasie wyznaczonym przez firmę, za wynagrodzeniem. Kodeks pracy mówi wprost, że takie zatrudnienie jest stosunkiem pracy bez względu na nazwę umowy (art. 22 § 1¹ KP), a zastąpienie umowy o pracę umową cywilnoprawną przy zachowaniu tych warunków jest niedopuszczalne (art. 22 § 1² KP).
Od 8 lipca 2026 r. obowiązuje nowelizacja ustawy o PIP. Inspektor pracy może polecić zmianę sposobu wykonywania umowy albo zawarcie umowy o pracę, a gdy polecenie nie zostanie wykonane, okręgowy inspektor pracy może wydać decyzję stwierdzającą istnienie stosunku pracy. Według informacji rządowych do 8 lipca 2027 r. trwa okres przejściowy na dobrowolne uporządkowanie umów zawartych przed nowelizacją. Za zawarcie umowy cywilnoprawnej zamiast umowy o pracę grozi grzywna od 2000 zł do 60 000 zł (art. 281 § 1 pkt 1 KP).
Sygnały ryzyka w IT to: stałe godziny pracy narzucone przez firmę, obowiązek pracy z biura, wnioski urlopowe wymagające akceptacji, podporządkowanie team leaderowi jak przełożonemu, brak możliwości korzystania z podwykonawców i praca wyłącznie na sprzęcie firmy bez ryzyka gospodarczego po stronie programisty. Te same okoliczności mają znaczenie podatkowe, bo ustawa o PIT nie uznaje za działalność gospodarczą czynności wykonywanych pod kierownictwem i w miejscu oraz czasie wyznaczonych przez zlecającego, gdy wykonawca nie ponosi ryzyka gospodarczego (art. 5b ust. 1).
Umowa powinna opisywać rzeczywisty, niezależny model pracy: zadania i terminy zamiast godzin, uzgadnianie dostępności zamiast wniosków urlopowych, odpowiedzialność za rezultat. Ważniejsza od zapisów jest jednak praktyka. Przegląd innych ryzyk znajdziesz w przewodniku umowy B2B i freelance.
IP Box a umowa B2B
Programista na B2B może w niektórych przypadkach skorzystać z IP Box, czyli stawki 5% podatku od kwalifikowanego dochodu z kwalifikowanych praw własności intelektualnej (art. 30ca ustawy o PIT). Wśród tych praw ustawa wymienia autorskie prawo do programu komputerowego, ale tylko takiego, który został wytworzony, rozwinięty lub ulepszony w ramach działalności badawczo-rozwojowej prowadzonej przez podatnika. Ulga wymaga prowadzenia osobnej ewidencji i spełnienia kilku warunków, a ocena, czy praca programisty jest działalnością B+R, bywa sporna.
Dla umowy oznacza to tyle, że wynagrodzenie warto rozdzielić na część za przeniesienie praw do programu i część za pozostałe usługi, a zapisy o prawach autorskich muszą być precyzyjne. O zastosowaniu IP Box w konkretnej sytuacji decyduj z doradcą podatkowym lub na podstawie indywidualnej interpretacji.
Dane osobowe i dostęp do systemów
Jeśli programista ma dostęp do produkcyjnej bazy danych, panelu sklepu albo CRM, przetwarza dane osobowe w imieniu firmy i potrzebna jest umowa powierzenia (art. 28 RODO). Umowa powinna też określać zasady bezpieczeństwa: logowanie przez konta imienne, uwierzytelnianie dwuskładnikowe, zakaz kopiowania danych na prywatne urządzenia i zgłaszanie incydentów. Szczegóły w artykule umowa powierzenia przetwarzania danych.
Kiedy skonsultować się z prawnikiem
Przy dużych projektach, współpracy z zagranicznym klientem, planach korzystania z IP Box lub kontroli PIP dotyczącej kontraktów B2B skorzystaj z porady prawnej online.
Najczęściej zadawane pytania
Czy firma ma prawa do kodu napisanego przez programistę na B2B?
Tylko jeśli umowa na piśmie przenosi autorskie prawa majątkowe i wymienia pola eksploatacji. Zasada, że prawa do programu przysługują pracodawcy, dotyczy wyłącznie pracowników, a nie kontraktorów B2B.
Czy umowę B2B z programistą można podpisać elektronicznie?
Tak, ale część dotycząca przeniesienia autorskich praw majątkowych wymaga formy pisemnej, czyli podpisu własnoręcznego albo kwalifikowanego podpisu elektronicznego. Zwykły podpis w aplikacji lub akceptacja mailem nie spełnia tego wymogu.
Czy zakaz konkurencji w umowie B2B musi być płatny?
Przepisy tego nie wymagają, bo obowiązkowe odszkodowanie dotyczy tylko pracowników. Bardzo szeroki i długi zakaz bez wynagrodzenia może jednak zostać uznany za nieważny jako sprzeczny z zasadami współżycia społecznego.
Jaki okres wypowiedzenia wpisać w umowie B2B z programistą?
Najczęściej od 1 do 3 miesięcy dla obu stron. Bez zapisu każda strona może wypowiedzieć umowę w każdym czasie na podstawie art. 746 KC, odpowiadając za szkodę, jeśli robi to bez ważnego powodu.
Kiedy umowa B2B z programistą zostanie uznana za etat?
Gdy programista pracuje pod kierownictwem, w miejscu i czasie wyznaczonym przez firmę, za wynagrodzeniem. Od 8 lipca 2026 r. okręgowy inspektor pracy może w takiej sytuacji wydać decyzję stwierdzającą istnienie stosunku pracy.
Czy programista na B2B może korzystać z IP Box?
Może, jeśli tworzy, rozwija lub ulepsza program komputerowy w ramach działalności badawczo-rozwojowej i prowadzi wymaganą ewidencję. Stawka wynosi 5% kwalifikowanego dochodu, a warunki warto potwierdzić z doradcą podatkowym.
Podstawa prawna
- Ustawa z dnia 23 kwietnia 1964 r. – Kodeks cywilny (Dz.U. 2026 poz. 795 t.j.): art. 58 § 2, 353¹, 471, 473 § 2, 483 § 1, 746, 750
- Ustawa z dnia 26 czerwca 1974 r. – Kodeks pracy (Dz.U. 2026 poz. 1245 t.j.): art. 22 § 1–1², art. 281 § 1 pkt 1
- Ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz.U. 2025 poz. 24 t.j.): art. 41 ust. 2, 46, 53, 74
- Ustawa z dnia 26 lipca 1991 r. o podatku dochodowym od osób fizycznych (Dz.U. 2026 poz. 592 t.j.): art. 5b ust. 1, art. 30ca
- Ustawa z dnia 11 marca 2026 r. o zmianie ustawy o Państwowej Inspekcji Pracy, ustawy – Kodeks pracy oraz niektórych innych ustaw
- Rozporządzenie (UE) 2016/679 (RODO): art. 28
