Umowa B2B dla programisty — 12 zapisów, które trzeba sprawdzić przed podpisaniem

Umowa B2B to nie formalność. To dokument, który decyduje o Twoim bezpieczeństwie

W branży IT współpraca w modelu B2B od kilku lat stała się standardem. Zarówno software house’y, startupy, jak i duże korporacje bardzo często oczekują, że programista będzie świadczył usługi jako przedsiębiorca. Dla wielu specjalistów jest to korzystne rozwiązanie podatkowo i organizacyjnie, ale jednocześnie oznacza rezygnację z ochrony wynikającej z Kodeksu pracy. To właśnie dlatego umowa B2B staje się podstawowym dokumentem określającym prawa i obowiązki stron.

W praktyce wielu programistów skupia się niemal wyłącznie na wysokości stawki godzinowej lub miesięcznego wynagrodzenia. Tymczasem zdarza się, że zapis o karze umownej na kilkaset tysięcy złotych, niekorzystnym przeniesieniu praw autorskich albo bardzo szeroko sformułowanym zakazie konkurencji ma dla wykonawcy znacznie większe znaczenie niż różnica kilku lub kilkunastu procent w wynagrodzeniu.

Nie jest również prawdą, że wzór umowy stosowany przez dużą spółkę musi być dokumentem zrównoważonym. Wręcz przeciwnie – większość kontraktów przygotowywana jest przede wszystkim w interesie zamawiającego. Nie oznacza to oczywiście, że są one nieważne. Oznacza jedynie, że przed podpisaniem warto dokładnie zrozumieć skutki poszczególnych postanowień i – jeśli to możliwe – wynegocjować ich zmianę.

Szczególnie ostrożnie należy podchodzić do umów zawieranych z zagranicznymi kontrahentami. W takich przypadkach często pojawiają się postanowienia odwołujące się do prawa obcego, właściwości sądów zagranicznych, arbitrażu albo odpowiedzialności znacznie wykraczającej poza standardy znane z polskiego obrotu gospodarczego. Programista podpisujący taki kontrakt często nie zdaje sobie sprawy, że ewentualny spór będzie musiał prowadzić przed sądem w Londynie, Talinie czy w stanie Delaware w USA.

Dobrze przygotowana umowa B2B nie powinna być postrzegana jako dokument ograniczający wykonawcę. Przeciwnie – powinna jasno określać zasady współpracy i minimalizować ryzyko konfliktów. Im bardziej precyzyjne są postanowienia dotyczące zakresu usług, wynagrodzenia czy praw autorskich, tym mniejsze prawdopodobieństwo, że po kilku miesiącach współpracy pojawi się spór o to, co strony rzeczywiście uzgodniły.

Dlaczego w umowach B2B nie obowiązuje taka ochrona jak przy umowie o pracę?

Jednym z najczęściej powtarzanych błędów jest założenie, że skoro dana klauzula byłaby niedopuszczalna wobec pracownika, to nie może znaleźć się również w kontrakcie B2B. Takie myślenie jest błędne.

Relacje pomiędzy przedsiębiorcami opierają się przede wszystkim na zasadzie swobody umów określonej w art. 353¹ Kodeksu cywilnego. Oznacza to, że strony mogą bardzo szeroko kształtować wzajemne prawa i obowiązki, o ile nie naruszają właściwości stosunku prawnego, ustawy ani zasad współżycia społecznego.

W praktyce powoduje to, że w kontraktach B2B spotyka się rozwiązania, które nigdy nie mogłyby znaleźć się w umowie o pracę. Dotyczy to między innymi bardzo wysokich kar umownych, szerokich obowiązków zachowania poufności, odpowiedzialności za utracone korzyści kontrahenta czy obowiązku posiadania ubezpieczenia OC o wysokiej sumie gwarancyjnej.

Nie oznacza to jednak, że przedsiębiorca jest całkowicie pozbawiony ochrony. Nadal zastosowanie znajdują przepisy Kodeksu cywilnego dotyczące nieważności czynności prawnych, nadużycia prawa podmiotowego czy możliwości miarkowania kary umownej. Problem polega jednak na tym, że dochodzenie swoich racji przed sądem jest zwykle znacznie bardziej skomplikowane (i droższe!) niż zapobieżenie problemowi na etapie negocjowania umowy.

Dlatego analiza kontraktu przed podpisaniem jest niemal zawsze tańsza niż prowadzenie wieloletniego sporu sądowego po zakończeniu współpracy.

1. Zakres usług powinien być opisany precyzyjnie

Pierwszym elementem, który należy sprawdzić, jest opis usług. Wiele umów zawiera bardzo ogólne sformułowania, takie jak „świadczenie usług programistycznych zgodnie z bieżącymi potrzebami klienta” albo „wykonywanie wszelkich czynności związanych z rozwojem oprogramowania”.

Na pierwszy rzut oka takie postanowienia wydają się wygodne. W praktyce mogą jednak prowadzić do sytuacji, w której kontrahent będzie oczekiwał wykonywania zadań wykraczających daleko poza pierwotne ustalenia.

Programista zatrudniony jako backend developer może zostać zobowiązany do tworzenia aplikacji mobilnych, konfiguracji infrastruktury DevOps, prowadzenia wdrożeń u klientów, wsparcia helpdesku czy przygotowywania dokumentacji technicznej. Jeżeli zakres usług został opisany bardzo szeroko, odmowa wykonania takich czynności może zostać potraktowana jako nienależyte wykonanie umowy.

Najlepiej, gdy umowa jasno określa specjalizację wykonawcy, wykorzystywane technologie oraz sposób zlecania nowych zadań. Dobrym rozwiązaniem jest również wskazanie, że zmiana charakteru prac wymaga zgody obu stron.

Takie postanowienie chroni nie tylko programistę. Również zamawiający ma pewność, że otrzyma usługi świadczone przez specjalistę posiadającego odpowiednie kompetencje.

2. Wynagrodzenie i terminy płatności

Wysokość wynagrodzenia zwykle jest przedmiotem najdłuższych negocjacji, ale sam sposób jego wypłaty często pozostaje pomijany.

W praktyce warto sprawdzić przede wszystkim termin płatności faktur, moment rozpoczęcia jego biegu oraz przesłanki odmowy zapłaty.

Zdarzają się umowy, zgodnie z którymi termin płatności rozpoczyna bieg dopiero po zaakceptowaniu raportu prac przez kierownika projektu. Problem polega na tym, że umowa nie określa żadnego terminu na dokonanie takiej akceptacji. W efekcie kontrahent może przez wiele tygodni nie zatwierdzać wykonanych usług, a wykonawca pozostaje bez wynagrodzenia.

Równie niebezpieczne są postanowienia uzależniające zapłatę od odbioru całego projektu przez klienta końcowego albo od otrzymania wynagrodzenia przez software house od własnego kontrahenta. Programista nie ma wpływu na te okoliczności, dlatego nie powinny one decydować o terminie zapłaty za jego pracę.

Bezpieczna umowa powinna przewidywać jednoznaczny termin płatności liczony od doręczenia prawidłowo wystawionej faktury oraz precyzyjnie określać sytuacje, w których zamawiający może zgłosić uzasadnione zastrzeżenia.

3. Prawa autorskie do kodu – jeden z najważniejszych zapisów całej umowy

Większość programistów zakłada, że skoro otrzymuje wynagrodzenie za napisanie kodu, to zamawiający automatycznie staje się jego właścicielem. Tak jednak nie jest.

W modelu B2B zastosowanie mają przede wszystkim przepisy ustawy o prawie autorskim i prawach pokrewnych. Jeżeli strony nie uregulują tej kwestii prawidłowo, może dojść do sytuacji, w której klient zapłaci za wykonanie projektu, ale nie nabędzie pełnych praw autorskich do oprogramowania. Z drugiej strony zdarzają się umowy, które przewidują przeniesienie praw do wszystkich utworów stworzonych przez programistę, również tych, które nie mają żadnego związku z realizowanym projektem.

Przed podpisaniem warto dokładnie sprawdzić, czy przeniesienie praw obejmuje wyłącznie kod powstały w ramach wykonywania umowy. Niedopuszczalne z punktu widzenia interesu programisty są klauzule, które próbują przejąć prawa do bibliotek, frameworków, własnych narzędzi, fragmentów kodu wykorzystywanych wcześniej czy projektów rozwijanych prywatnie.

Równie ważny jest moment przejścia praw autorskich. Część umów przewiduje, że następuje on dopiero po zapłacie całego wynagrodzenia. Inne wskazują, że prawa przechodzą już z chwilą stworzenia kodu. Ta różnica może mieć ogromne znaczenie w przypadku rozwiązania współpracy lub opóźnień w płatnościach.

Dobrą praktyką jest również dopilnowanie, aby wynagrodzenie obejmujące przeniesienie praw autorskich było jednoznacznie określone. Pozwala to uniknąć późniejszych sporów dotyczących tego, czy przeniesienie praw nastąpiło skutecznie.

4. Pola eksploatacji – zapis, który często jest kopiowany bez zrozumienia

Samo stwierdzenie, że wykonawca przenosi prawa autorskie, nie wystarcza. Umowa powinna wskazywać pola eksploatacji, czyli sposoby korzystania z utworu.

W praktyce bardzo często spotyka się postanowienia kopiowane z innych umów, obejmujące kilkadziesiąt różnych pól eksploatacji, z których znaczna część nie ma żadnego związku z oprogramowaniem. Zdarza się, że w kontrakcie dla programisty pojawiają się zapisy dotyczące rozpowszechniania utworu w telewizji, nadawania radiowego czy utrwalania na płytach DVD.

Takie rozwiązania nie zwiększają bezpieczeństwa prawnego żadnej ze stron. Znacznie lepiej jest precyzyjnie opisać sposoby korzystania z kodu źródłowego, kodu wynikowego, dokumentacji technicznej oraz elementów interfejsu użytkownika.

Jeżeli kontrakt przewiduje możliwość dalszej odsprzedaży oprogramowania klientom końcowym albo udzielania sublicencji, również te kwestie powinny zostać wyraźnie uregulowane.

5. Open Source może stać się źródłem odpowiedzialności

Obecnie praktycznie każdy projekt wykorzystuje komponenty open source. Wielu programistów nie zwraca jednak uwagi na to, że niektóre umowy całkowicie zakazują korzystania z bibliotek objętych licencjami open source bez wcześniejszej zgody zamawiającego.

Jeszcze częściej spotyka się klauzule, zgodnie z którymi wykonawca ponosi pełną odpowiedzialność za wszelkie naruszenia licencji open source, niezależnie od tego, kto podjął decyzję o wykorzystaniu konkretnego komponentu.

W praktyce może to prowadzić do bardzo niekorzystnych sytuacji. Projekt realizowany jest przez kilkunastoosobowy zespół, architekt wskazuje konkretne biblioteki, a po kilku latach odpowiedzialność za ewentualny problem próbuje się przerzucić na jednego programistę.

Dlatego warto sprawdzić, czy umowa przewiduje rozsądny podział odpowiedzialności oraz czy decyzje architektoniczne pozostają po stronie klienta lub lidera projektu.

6. AI, GitHub Copilot i ChatGPT – nowe klauzule w umowach B2B

Jeszcze kilka lat temu takie postanowienia praktycznie nie występowały. Dzisiaj coraz więcej kontraktów zawiera zakaz korzystania z narzędzi opartych na sztucznej inteligencji albo nakłada obowiązek uzyskania wcześniejszej zgody klienta.

Powód jest prosty. Zamawiający obawiają się ujawnienia kodu źródłowego, danych osobowych lub informacji poufnych do zewnętrznych modeli językowych.

Nie oznacza to jednak, że każda umowa powinna całkowicie zakazywać korzystania z AI. W wielu projektach narzędzia takie jak GitHub Copilot, ChatGPT czy Claude znacząco zwiększają produktywność programistów.

Znacznie lepszym rozwiązaniem jest określenie zasad korzystania z takich narzędzi. Przykładowo można dopuścić ich wykorzystywanie pod warunkiem, że do modeli nie będą przesyłane dane poufne klienta, fragmenty kodu zawierające tajemnice przedsiębiorstwa ani informacje pozwalające zidentyfikować projekt.

Coraz częściej spotyka się również obowiązek informowania klienta o wykorzystaniu AI przy tworzeniu określonych elementów oprogramowania. Warto sprawdzić, czy taki obowiązek nie jest sformułowany zbyt szeroko, ponieważ w praktyce jego wykonanie mogłoby okazać się niemożliwe.

7. Kary umowne – zapis, który może kosztować więcej niż cały kontrakt

Programiści bardzo często koncentrują się na wysokości wynagrodzenia, pomijając postanowienia dotyczące kar umownych. Tymczasem to właśnie one nierzadko stanowią największe ryzyko finansowe.

Spotyka się umowy przewidujące kary za każdy dzień opóźnienia, naruszenie poufności, naruszenie zakazu konkurencji, opóźnienie w usunięciu błędów, niewykonanie obowiązków raportowych czy nawet brak udziału w spotkaniu projektowym.

Szczególnie niebezpieczne są postanowienia, zgodnie z którymi zamawiający może jednocześnie dochodzić kary umownej oraz odszkodowania przewyższającego jej wysokość. Oznacza to, że zapłata kary nie kończy odpowiedzialności wykonawcy.

Przed podpisaniem umowy warto sprawdzić nie tylko wysokość poszczególnych kar, ale również maksymalny limit odpowiedzialności. W dobrze skonstruowanym kontrakcie odpowiedzialność wykonawcy powinna być ograniczona do rozsądnej kwoty, najczęściej odpowiadającej wielokrotności wynagrodzenia otrzymanego z tytułu umowy.

8. Zakaz konkurencji – nie każda klauzula jest równie groźna

Jednym z najbardziej kontrowersyjnych zapisów w umowach B2B jest zakaz konkurencji. Dla wielu programistów stanowi on jedynie formalność, ponieważ przy podpisywaniu kontraktu skupiają się przede wszystkim na wynagrodzeniu i zakresie obowiązków. Dopiero po kilku miesiącach okazuje się, że zgodnie z podpisaną umową nie mogą podjąć współpracy z inną firmą z tej samej branży, świadczyć usług dla podobnych klientów albo rozwijać własnego produktu informatycznego.

W przeciwieństwie do stosunku pracy przepisy nie nakazują, aby zakaz konkurencji w relacji B2B był odpłatny. Oznacza to, że przedsiębiorca może zobowiązać się do bardzo daleko idących ograniczeń bez otrzymania jakiegokolwiek dodatkowego wynagrodzenia. Sam fakt, że takie rozwiązanie wydaje się niekorzystne, nie oznacza jeszcze, że będzie nieważne.

Kluczowe znaczenie ma sposób zdefiniowania działalności konkurencyjnej. Jeżeli umowa posługuje się bardzo ogólnym sformułowaniem obejmującym „wszelką działalność związaną z oprogramowaniem”, w praktyce może to oznaczać zakaz współpracy z ogromną częścią rynku IT. Zdecydowanie rozsądniejsze są postanowienia odnoszące się do konkretnego rodzaju działalności prowadzonej przez zamawiającego albo do określonego segmentu rynku.

Warto również zwrócić uwagę na zasięg terytorialny zakazu. Coraz częściej spotyka się umowy obejmujące cały świat, mimo że kontrahent prowadzi działalność wyłącznie na rynku europejskim. Podobnie wygląda kwestia czasu obowiązywania. Zakaz konkurencji trwający kilka miesięcy po zakończeniu współpracy można jeszcze uzasadnić ochroną interesów przedsiębiorcy. Ograniczenia obowiązujące przez dwa lub trzy lata powinny natomiast skłonić do bardzo dokładnej analizy ich proporcjonalności.

Nie mniej istotne są kary umowne powiązane z naruszeniem zakazu konkurencji. Często są one wielokrotnie wyższe niż całe wynagrodzenie uzyskane przez programistę w czasie realizacji projektu. W praktyce oznacza to, że nawet przypadkowe podjęcie współpracy z podmiotem uznanym za konkurenta może prowadzić do poważnego sporu sądowego.

Warto pamiętać, że sama nazwa klauzuli nie przesądza jeszcze o jej skutkach. Część umów zawiera bowiem postanowienia określane jako obowiązek lojalności lub zakaz świadczenia usług dla klientów zamawiającego, które w rzeczywistości pełnią funkcję klasycznego zakazu konkurencji.

9. Poufność i tajemnica przedsiębiorstwa – gdzie kończy się NDA?

Obowiązek zachowania poufności jest standardem praktycznie w każdej umowie dotyczącej tworzenia oprogramowania. Nie oznacza to jednak, że wszystkie klauzule NDA są skonstruowane w taki sam sposób.

Najlepiej przygotowane umowy precyzyjnie określają, jakie informacje mają charakter poufny, przez jaki okres obowiązuje obowiązek ich ochrony oraz w jaki sposób wykonawca powinien zabezpieczać otrzymane dane. Dzięki temu obie strony dokładnie wiedzą, jakie informacje podlegają ochronie.

Znacznie większe ryzyko stwarzają postanowienia, zgodnie z którymi poufne są „wszelkie informacje uzyskane podczas współpracy”. Tak szerokie sformułowanie może obejmować nie tylko kod źródłowy czy dokumentację projektową, ale również wiedzę techniczną, doświadczenie zdobyte podczas realizacji projektu, a nawet rozwiązania powszechnie stosowane w branży.

Programista powinien zwrócić uwagę również na to, czy obowiązek poufności nie uniemożliwia mu wykorzystywania własnego doświadczenia zawodowego po zakończeniu współpracy. Nie można przecież oczekiwać, że specjalista po kilkuletnim projekcie zapomni wszystkie poznane technologie, wzorce projektowe czy rozwiązania architektoniczne. Ochronie powinny podlegać konkretne informacje stanowiące tajemnicę przedsiębiorstwa, a nie ogólna wiedza i umiejętności zdobyte podczas wykonywania usług.

Coraz częściej w umowach pojawiają się także obowiązki dotyczące bezpieczeństwa informacji. Mogą one obejmować korzystanie wyłącznie z szyfrowanych dysków, obowiązek stosowania uwierzytelniania wieloskładnikowego, zakaz przechowywania kodu na prywatnych urządzeniach czy konieczność zgłaszania incydentów bezpieczeństwa w bardzo krótkim czasie. Warto upewnić się, że wymagania te są realne do wykonania i odpowiadają rzeczywistemu charakterowi projektu.

10. Odpowiedzialność za błędy i naruszenie praw osób trzecich

Nie istnieje oprogramowanie całkowicie pozbawione błędów. Mimo to niektóre umowy próbują przenieść na programistę odpowiedzialność praktycznie za każdą wadę projektu, niezależnie od jej przyczyny.

Szczególną uwagę należy zwrócić na postanowienia dotyczące naruszenia praw własności intelektualnej. Część kontraktów przewiduje, że wykonawca odpowiada za wszelkie roszczenia osób trzecich związane z projektem. Problem polega na tym, że programista bardzo często nie ma wpływu na całość rozwiązania. Korzysta z bibliotek wskazanych przez klienta, implementuje architekturę przygotowaną przez inny zespół albo rozwija kod napisany wcześniej przez poprzednich wykonawców.

W takich sytuacjach nieuzasadnione byłoby obciążanie jednej osoby pełną odpowiedzialnością za cały produkt. Rozsądna umowa powinna ograniczać odpowiedzialność wykonawcy do tych elementów, które rzeczywiście stworzył samodzielnie i nad którymi miał faktyczną kontrolę.

Podobnie należy ocenić klauzule nakazujące naprawienie wszelkich szkód pośrednich, utraconych korzyści czy utraty reputacji przedsiębiorcy. W praktyce bardzo trudno przewidzieć wysokość takich roszczeń, dlatego ich nieograniczone przyjęcie może oznaczać ryzyko nieproporcjonalne do wartości całego kontraktu.

Dobrym rozwiązaniem jest wprowadzenie maksymalnego limitu odpowiedzialności, z jednoczesnym pozostawieniem wyjątków dla przypadków umyślnego działania, naruszenia poufności lub praw własności intelektualnej. Takie rozwiązanie jest powszechnie spotykane w profesjonalnych kontraktach IT i pozwala zachować rozsądną równowagę interesów stron.

11. Rozwiązanie umowy – czy kontrahent może zakończyć współpracę z dnia na dzień?

Wielu przedsiębiorców zakłada, że skoro umowa została zawarta na czas nieokreślony, będzie obowiązywała przez wiele lat. Tymczasem zdecydowana większość kontraktów B2B przewiduje możliwość ich wypowiedzenia.

Kluczowe znaczenie ma długość okresu wypowiedzenia. Jeżeli wynosi zaledwie kilka dni, wykonawca może praktycznie z dnia na dzień utracić główne źródło dochodu. Z kolei zbyt długi okres wypowiedzenia może utrudniać przyjęcie atrakcyjnej oferty od innego klienta.

Warto również sprawdzić, czy umowa przewiduje możliwość natychmiastowego rozwiązania współpracy z powodu naruszenia obowiązków przez drugą stronę. Takie postanowienia powinny być skonstruowane precyzyjnie. Zbyt ogólne określenie „istotnego naruszenia umowy” może prowadzić do sporów dotyczących tego, czy konkretne zachowanie rzeczywiście uzasadniało rozwiązanie kontraktu.

Coraz częściej spotyka się również klauzule umożliwiające zamawiającemu rozwiązanie umowy bez podania przyczyny przy jednoczesnym zachowaniu prawa do natychmiastowego zaprzestania powierzania nowych zadań. Programista powinien zastanowić się, czy taki model współpracy zapewnia mu wystarczającą stabilność finansową.

12. Prawo właściwe i sąd – zapis, który ujawnia swoje znaczenie dopiero po powstaniu sporu

Ten fragment umowy jest często pomijany jako mało istotny. W rzeczywistości może jednak decydować o tym, czy dochodzenie swoich praw będzie w ogóle opłacalne.

Jeżeli kontrakt przewiduje stosowanie prawa obcego oraz właściwość sądów zagranicznych, prowadzenie sporu może wymagać zaangażowania lokalnej kancelarii, tłumaczenia dokumentów oraz poniesienia znacznie wyższych kosztów postępowania. Dla pojedynczego programisty dochodzenie roszczenia o kilkanaście czy kilkadziesiąt tysięcy euro może okazać się ekonomicznie nieuzasadnione.

Nie oznacza to, że należy zawsze odrzucać takie postanowienia. Współpraca z zagranicznymi klientami jest dziś codziennością w branży IT. Warto jednak świadomie ocenić konsekwencje podpisania umowy podlegającej prawu innego państwa oraz upewnić się, że wszystkie jej postanowienia są zrozumiałe również z perspektywy tego systemu prawnego.

W praktyce zdarza się, że kontrahenci są skłonni negocjować nie tylko wysokość wynagrodzenia, ale również wybór prawa właściwego, miejsca rozstrzygania sporów czy zastosowanie arbitrażu. Są to elementy, które mogą znacząco wpłynąć na bezpieczeństwo prawne obu stron i nie powinny być traktowane jako niezmienny standard.

Podsumowanie

Podpisanie umowy B2B nie powinno sprowadzać się wyłącznie do sprawdzenia wysokości wynagrodzenia i daty rozpoczęcia współpracy. Dla programisty znacznie większe znaczenie mogą mieć postanowienia dotyczące praw autorskich, odpowiedzialności za projekt, zakazu konkurencji czy możliwości rozwiązania umowy. To właśnie one najczęściej stają się źródłem sporów, gdy współpraca nie przebiega zgodnie z oczekiwaniami stron.

Nie każda niekorzystna klauzula będzie nieważna. W relacjach pomiędzy przedsiębiorcami obowiązuje daleko idąca swoboda umów, dlatego wiele postanowień, które byłyby niedopuszczalne w umowie o pracę, może skutecznie wiązać strony kontraktu B2B. Z tego względu analiza umowy przed jej podpisaniem jest inwestycją, która bardzo często pozwala uniknąć kosztownych problemów w przyszłości.

Dobry kontrakt powinien chronić interesy obu stron. Zamawiający ma prawo zabezpieczyć swoje know-how, prawa autorskie i informacje poufne. Programista powinien natomiast mieć pewność, że zakres jego obowiązków jest jasno określony, odpowiedzialność pozostaje proporcjonalna do wykonywanych usług, a możliwość dalszego rozwoju zawodowego nie zostanie nieuzasadnienie ograniczona przez zbyt daleko idące postanowienia umowne. Świadome negocjowanie tych zapisów przed podpisaniem kontraktu jest zdecydowanie prostsze i tańsze niż próba podważania ich skutków w trakcie lub po zakończeniu współpracy.