Umowa B2B dla branży IT w Polsce

Kontrakt B2B (business-to-business) to popularna w Polsce forma współpracy z wykonawcami branży IT – oferuje obu stronom elastyczność oraz korzyści finansowe. Do najczęstszych pytań zadawanych przy tego typu umowach, należą wątpliwości co do skuteczności przenoszenia praw autorskich, zasad rozliczania wynagrodzenia, ryzyka potraktowania umowy B2B za umowę o pracę, kar umownych, zakazu konkurencji czy też ochrony danych osobowych. Sprawy może dodatkowo skomplikować kontekst międzynarodowy współpracy.

Poniżej przedstawiamy nasze zestawienie najlepszych cech umowy B2B, z uwzględnieniem perspektywy zleceniodawcy (np. software house’u, agencji, startupu) oraz wykonawcy (freelancera lub wykonawcy z JDG).

1. Jasno określony charakter współpracy

Nie jest żadną tajemnicą, że zleceniodawcy i wykonawcy często stoją przed alternatywą zaangażowania na podstawie umowy o pracę lub na podstawie umowy B2B. Każde z rozwiązań ma swoją charakterystykę, ale wśród najważniejszych korzyści umowy B2B wymienia się bezpośrednie korzyści finansowe. Umowa B2B jest tańsza dla zatrudniającego, który zaoszczędzone w ten sposób środki może przeznaczyć na podwyższenie oferowanego wykonawcy wynagrodzenia.

Trzeba jednak od razu powiedzieć, że w Polsce o charakterze danej umowy nie decyduje jej nazwa, ale specyficzne cechy związane z konkretnym powstałym stosunkiem prawnym. Jeżeli mamy do czynienia z wykonywaniem pracy określonego rodzaju na rzecz pracodawcy, pod jego kierownictwem, w miejscu i czasie wyznaczonym przez pracodawcę, to mówimy o stosunku pracy i magiczne „B2B” czy „Umowa o współpracy” na górze dokumentu tego nie zmieni.

Dobra umowa B2B powinna podkreślać aspekt niezależności zleceniodawcy oraz wykonawcy jako samodzielnych przedsiębiorców. Wykonawca oczywiście odpowiada za należytą realizację kontraktu, o określonym standardzie, za ustalonym wynagrodzeniem i w przewidzianym terminie, ale zasadniczo powinien mieć pozostawioną swobodę co do sposobu, miejsca i czasu wykonywania powierzonych mu zleceń. Przy zachowaniu tego kluczowego wymogu, strony mogą sobie pozwolić na wprowadzanie dodatkowych, nawet podobnych do etatowych świadczeń (takich jak płatne przerwy w wykonywaniu usług), bez ryzyka posądzania, że umowa B2B powinna być kwalifikowana jako umowa o pracę.

2. Precyzyjny zakres obowiązków i rezultatów

Zakres prac powinien być opisany możliwie konkretnie. Dobra umowa wskazuje, jakie usługi i zadania wykonawca zrealizuje, jakie rezultaty dostarczy, w jakim wymiarze godzin lub terminach. Umowa może mieć też charakter ramowy i przewidywać na jakich zasadach wykonawca będzie wykonywać już konkretne zlecenia ustalane w bardziej elastycznej formie zamówień. Dzięki temu obie strony od początku dokładnie wiedzą, co wchodzi w zakres współpracy, co zapobiega nieporozumieniom i zjawisku tzw. scope creep (niekontrolowanego rozszerzania zadań). Z perspektywy zleceniodawcy precyzyjny zakres ułatwia egzekwowanie Warto określić też organizację współpracy: np. formy komunikacji, narzędzia i częstotliwość raportowania postępów. Przy współpracy międzynarodowej dobrze uwzględnić różnice stref czasowych – już w kontrakcie ustalić sposób komunikacji i dostępność obu stron, by uniknąć napięć. Im bardziej klarowny zakres i reguły współpracy, tym mniejsze ryzyko sporu co do tego, “co było do zrobienia”. Nasza generalna refleksja jest taka, że strony zbyt często szykują się w umowach „na czas wojny”, poprzez wprowadzanie surowych zabezpieczeń na wiele mało prawdopodobnych scenariuszy, zamiast uregulować wyczerpująco jak będzie wyglądał pomiędzy nimi czas pokoju.

3. Warunki wynagrodzenia i rozliczeń

Kwestie finansowe to podstawa każdego kontraktu B2B. Umowa powinna precyzować wysokość wynagrodzenia, sposób i termin płatności oraz formę rozliczeń. Strony powinny uzgodnić, czy rozliczenie następuje ryczałtowo (stała stawka miesięczna za tzw. gotowość do wykonywania zlecenia czy za projekt) czy godzinowo. Jeśli stawka godzinowa – dobrze ustalić z góry zasady ewidencji czasu pracy (np. miesięczne zestawienia godzin) oraz ich akceptacji przez zleceniodawcę. Pozwoli to uniknąć sytuacji, gdzie z jednej strony wykonawca raportuje godziny w kumulacji utrudniającej rozsądną weryfikację, a z kolei zleceniodawca arbitralnie je kwestionuje (z czasem łatwo zapomnieć jak czasochłonna była realizacja danego projektu). Termin płatności powinien być rozsądny – w praktyce często spotyka się 14 dni od faktury, zamiast odległych terminów w stylu 45 czy 60 dni (tutaj uwaga na ustawowe obostrzenia co do terminów zapłaty w transakcjach handlowych). Z punktu widzenia wykonawcy krótszy termin to mniejsze ryzyko finansowe, zleceniodawca zaś może negocjować np. płatność etapami po odbiorze kolejnych części projektu.

Ważne jest także ustalenie, w jakiej formie nastąpi rozliczenie – standardowo w modelu B2B będzie to faktura VAT (jeśli wykonawca jest płatnikiem VAT) lub rachunek. Warto wyraźnie zapisać, że stawka jest netto + VAT, aby obie strony miały jasność co stanowi kwotę brutto. Jeśli kontrakt jest międzynarodowy, koniecznie określcie walutę rozliczenia (złoty, euro, dolar etc.).

Dobrze skonstruowane warunki płatności zabezpieczają interesy obu stron: wykonawcy gwarantują terminową zapłatę za pracę, a zleceniodawcy – pewność, że płaci za faktycznie dostarczone rezultaty (np. po akceptacji określonych kamieni milowych projektu).

4. Klauzula poufności (NDA)

Większość projektów IT wiąże się z dostępem do wrażliwych informacji – kodu źródłowego, danych klientów, know-how firmy. Dobry kontrakt B2B zawiera mocną klauzulę poufności (NDA), która chroni te informacje. W umowie warto zdefiniować, co jest informacją poufną, jak długo obowiązuje tajemnica oraz przewidzieć sankcje za jej naruszenie. Z perspektywy zleceniodawcy kluczowe jest, by wykonawca nie ujawnił żadnych sekretów biznesowych ani nie wykorzystał ich przeciwko firmie. Wykonawca natomiast powinien upewnić się, że definicja poufnych informacji nie jest zbyt szeroka (wyłączając np. informacje publicznie znane lub własne pomysły niezwiązane z projektem) i że podoła obowiązkowi zachowania tajemnicy przez wskazany okres. Często NDA warto zawrzeć już na etapie negocjacji współpracy (warto podpisać go przed dostępem do kodu czy dokumentacji) oraz na pewien czas po zakończeniu umowy.

5. Prawa własności intelektualnej (IP)

Kwestię praw autorskich do wytworzonego oprogramowania traktujemy jako kluczową w kontraktach z wykonawcami branży IT, często bardzo zaniedbaną przez Strony. Podejście co do zapisów może znacząco różnić się w zależności od perspektywy danej strony umowy.

Dla zleceniodawcy kluczowe jest zabezpieczenie interesów firmy, szczególnie jeśli zlecone prace mają charakter twórczy. Zleceniodawca powinien dążyć do zapisu, który jednoznacznie przenosi na niego pełne prawa autorskie majątkowe do wszystkich rezultatów prac, w tym także takich jak dokumentacja, kod źródłowy, grafika czy raporty analityczne. Zleceniodawca powinien zadbać o przeniesienie tych praw bez ograniczeń czasowych i terytorialnych, na wszystkich istotnych z perspektywy jego działalności polach eksploatacji. Taki zapis zapewnia możliwość swobodnego korzystania, rozwijania, dystrybucji oraz komercjalizacji produktów bez obaw o przyszłe roszczenia.

Pełne przeniesienie praw autorskich majątkowych może być sprzeczne z interesem wykonawcy, jeżeli wprowadzone przez niego rozwiązania miały być w jego intencji wykorzystywane wyłącznie w sposób ograniczony, do konkretnego zastosowania w ramach umowy. W takich przypadkach rozwiązaniem preferowanym prze wykonawcę powinno być udzielenie licencji. Wykonawca powinien zadbać o zabezpieczenie własnych interesów poprzez jasne uregulowanie kwestii ewentualnego wykorzystania własnych bibliotek czy wcześniejszych rozwiązań wprowadzonych do projektu.

Dla zleceniodawcy istotne jest, aby mieć wpływ na sposób wykonywania autorskich praw osobistych wykonawcy. Umowa powinna umożliwiać np. anonimowe udostępnianie oraz modyfikowanie utworów. Wykonawca z kolei powinien zadbać, aby takie zapisy były proporcjonalne i nie naruszały jego interesów osobistych w sposób zbyt daleko idący (z perspektywy wykonawcy często istotnym jest możliwość przedstawienia swojego konkretnego doświadczenia projektowego dla własnej promocji).

Dobra umowa wyważa interesy: chroni prawa klienta do projektu w sposób racjonalny z perspektywy projektu, ale nie uniemożliwia wykonawcy dalszego rozwoju z wykorzystaniem ogólnej wiedzy i umiejętności zdobytych w trakcie współpracy.

6. Ochrona danych osobowych (RODO)

Jeżeli w ramach współpracy wykonawca otrzymuje dostęp do danych osobowych (np. baz użytkowników, danych klientów zleceniodawcy), umowa musi uwzględniać także ten aspekt. Zgodnie z RODO potrzebna jest podstawa prawna do przekazania danych wykonawcy. W praktyce oznacza to często konieczność podpisania dodatkowej umowy powierzenia danych (Data Processing Agreement), jeśli wykonawca działa poza strukturą organizacyjną zleceniodawcy. Taki aneks reguluje m.in. cel i zakres przetwarzania, bezpieczeństwo danych oraz obowiązek ich zwrotu/usunięcia po zakończeniu współpracy. Jeśli wykonawca pracuje samodzielnie w ramach jednoosobowej działalności gospodarczej, zazwyczaj staje się procesorem danych – wówczas podpisanie umowy powierzenia jest standardem dla ochrony obu stron.

Z punktu widzenia zleceniodawcy kluczowe jest zapewnienie zgodności z RODO i ochrona przed wyciekiem danych (co grozi wysokimi karami). Wykonawca powinien zaś znać swoje obowiązki jako procesor – m.in. przetwarzać dane tylko w zakresie i celu przewidzianym umową, zachować je w poufności i zabezpieczyć technicznie. Warto również zawrzeć w kontrakcie postanowienia dotyczące bezpieczeństwa informacji (np. standardów ochrony haseł, szyfrowania, zgłaszania incydentów) – to leży w interesie obu stron, bo minimalizuje ryzyko incydentów. Przy współpracy transgranicznej należy dodatkowo pamiętać o przepisach dot. transferu danych za granicę, zwłaszcza jeżeli istniałoby ryzyko, że dane mogą być przekazywane poza EOG. Podsumowując, kwestii danych osobowych nie można pominąć – dobra umowa B2B w IT powinna zawierać odpowiednie klauzule zapewniające zgodność z przepisami o ochronie danych.

7. Zakaz konkurencji i pokrewne klauzule

Wielu zleceniodawców chce zabezpieczyć się przed sytuacją, w której zatrudniony kontraktor zaczyna świadczyć usługi konkurencji lub wykorzystuje zdobytą wiedzę w sposób im szkodzący. Stąd częstym elementem umów B2B w IT jest klauzula zakazu konkurencji. Taki zapis może obowiązywać w trakcie trwania kontraktu, a bywa że i pewien czas po jego zakończeniu. Ważne, by definicja “działalności konkurencyjnej” była precyzyjna – umowa powinna jasno wskazywać, jakiego rodzaju aktywności, na rzecz jakich kategorii podmiotów, wykonawca ma unikać. Zbyt ogólny lub szeroki zakaz może być dla wykonawcy nieczytelny i krępujący, np. budzić wątpliwość czy może rozwijać własny startup pobocznie.

Z perspektywy zleceniodawcy klauzula konkurencyjna chroni jego uzasadnione interesy (np. know-how, bazę klientów). Wykonawca zaś powinien zwrócić uwagę na dwie rzeczy: zakres i czas trwania zakazu. Im dłużej i szerzej obowiązuje zakaz po zakończeniu współpracy, tym większe ograniczenie dla freelancera w poszukiwaniu kolejnych zleceń – dlatego takie postanowienie powinno być proporcjonalne. W przeciwieństwie do umów o pracę, w kontraktach B2B brak jest ustawowego minimum odszkodowania za powstrzymanie się od konkurencji, dlatego ewentualne wynagrodzenie za okres zakazu konkurencji warto zapisać w umowie. Dobrym obyczajem (choć nie wymogiem prawnym) jest, by jeśli zakaz konkurencji obowiązuje po rozwiązaniu umowy, wykonawca otrzymał za ten okres np. procent swojego wynagrodzenia.

Oprócz zakazu konkurencji, w umowach B2B z programistami często pojawiają się klauzule pokrewne: non-solicitation, czyli zakaz podbierania klientowi pracowników lub kontrahentów, a także zakaz przejmowania jego klientów. Te również powinny być wyraźnie określone co do zakresu i czasu. Dla zleceniodawcy to dodatkowa tarcza ochronna, a dla wykonawcy – kolejny obszar do negocjacji w razie zbyt restrykcyjnych zapisów. Kluczem jest osiągnięcie równowagi: zapisy chroniące biznes zleceniodawcy nie powinny nadmiernie utrudniać specjaliście dalszej kariery.

8. Zasady odpowiedzialności i kary umowne

Z perspektywy zleceniodawcy istotne jest, by mieć narzędzia egzekwowania umowy: np. kary umowne za opóźnienia w oddaniu projektu czy naruszenie poufności, oraz możliwość natychmiastowego rozwiązania umowy w razie rażących naruszeń. Dla wykonawcy kluczowe jest ograniczenie ryzyka – w przeciwieństwie do pracownika, kontraktor B2B odpowiada całym swoim majątkiem na zasadach ogólnych prawa cywilnego. Dlatego warto negocjować wprowadzenie limitów odpowiedzialności (np. maksymalnie do wysokości dwukrotności wynagrodzenia) w przypadku zwykłego niedbalstwa. Taki limit zabezpiecza wykonawcę przed katastrofalnymi roszczeniami, a dla zleceniodawcy nadal stanowi motywację dla kontraktora do należytego wykonania pracy.

Jeśli w umowie przewidziano kary umowne, warto zwrócić uwagę na ich wysokość i okoliczności naliczania. Nadmiernie wygórowane kary (np. bardzo wysokie sumy za drobne opóźnienie) mogą zostać uznane za nieważne jako sprzeczne z zasadami współżycia społecznego, ale lepiej nie dopuszczać do takich zapisów – lepiej od razu negocjować obniżenie rażąco wysokich kar umownych. Typowo kary pojawiają się przy klauzulach o poufności, zakazie konkurencji czy zakazie podbierania klientów. W interesie zleceniodawcy leży, by były one na tyle dotkliwe, aby zniechęcały do naruszeń; w interesie wykonawcy – by nie przekraczały realnej skali potencjalnej szkody i były naliczane obiektywnie (np. za każdy dzień zwłoki określony ułamek wynagrodzenia, a nie arbitralna kwota). Dobrze też uregulować, czy zapłata kary wyklucza dochodzenie dalszych odszkodowań czy nie.

Balans jest tutaj najważniejszy – umowa powinna chronić zleceniodawcę przed brakiem wykonania lub szkodą, ale nie może przewidywać odpowiedzialności wykonawcy nawet za okoliczności od niego niezależne. Dlatego precyzyjne klauzule odpowiedzialności i kar umownych świadczą o dojrzałości kontraktu B2B.

9. Czas trwania umowy i warunki wypowiedzenia

Każda umowa powinna określać, na jaki okres zostaje zawarta – nie inaczej jest w B2B. Dobra umowa z programistą wskazuje, czy jest to kontrakt na czas określony (do konkretnej daty lub przez wskazany okres), nieokreślony, czy może mieszane rozwiązanie (np. na czas nieokreślony, ale z zastrzeżeniem, że nie może zostać wypowiedziana wcześniej niż po X miesiącach). Wybór formy wpływa na elastyczność współpracy: czas określony daje pewność zatrudnienia na dany okres, ale utrudnia wcześniejsze zakończenie; czas nieokreślony – odwrotnie, zapewnia swobodę zakończenia z odpowiednim wypowiedzeniem.

Okres wypowiedzenia to kolejny ważny element – umowa powinna precyzować, z jakim wyprzedzeniem i w jakiej formie każda ze stron może rozwiązać kontrakt. Strony często negocjują długość wypowiedzenia, dążąc do równowagi: zleceniodawca może preferować krótszy okres (aby móc szybko zakończyć współpracę w razie problemów lub zmiany planów projektowych), podczas gdy wykonawca woli dłuższy (dający czas na znalezienie nowego zlecenia). Spotyka się np. jednomiesięczny okres wypowiedzenia przy kontraktach B2B na czas nieokreślony, ale to zależy od siły negocjacyjnej stron.

Warto także zwrócić uwagę na klauzule natychmiastowego rozwiązania umowy – często umowa przewiduje, że zleceniodawca (czasem obie strony) może rozwiązać ją ze skutkiem natychmiastowym w razie wystąpienia określonych naruszeń. Takie przyczyny powinny być jasno sprecyzowane, a nie opisane ogólnikowo typu “rażące naruszenie umowy”. Dla wykonawcy zbyt ogólna klauzula stwarza ryzyko, że nawet drobne uchybienie (np. spóźnienie w raporcie godzin) posłuży jako pretekst do nagłego zerwania współpracy. Dlatego lepiej, by katalog przyczyn natychmiastowego wypowiedzenia był zamknięty i ograniczony do poważnych przewinień (np. naruszenie poufności, wielokrotna nieusprawiedliwiona absencja, odmowa wykonania kluczowych zadań itp.). Dobrze sformułowana umowa dba o interesy obu stron: daje możliwość rozstania się w uzasadnionych przypadkach, ale gwarantuje też stabilność współpracy na co dzień, bez obawy przed arbitralnym wypowiedzeniem.

10. Procedury na zakończenie współpracy i klauzule końcowe

Nawet najlepsza współpraca kiedyś się kończy – umowa B2B powinna więc przewidywać, co dzieje się po jej zakończeniu. Przede wszystkim warto ustalić, co stanie się z powierzonym mieniem i danymi. Jeśli programista otrzymał od zleceniodawcy np. sprzęt (laptop, telefon) lub dostęp do zasobów i danych, umowa powinna zobowiązywać go do zwrotu sprzętu i zabezpieczonych usunięcia danych po ustaniu współpracy, w określonym terminie. Dobrze jest też przewidzieć sankcje za niewywiązanie się z tych obowiązków (choćby potrącenie kosztu sprzętu lub kara za zatrzymanie danych). Klauzule te chronią zleceniodawcę przed utratą kontroli nad swoim mieniem i informacjami, a wykonawcy wskazują jasno jego obowiązki “po wszystkim”.

Ponadto, standardem jest, że pewne zobowiązania przetrwają rozwiązanie umowy – dotyczy to zwłaszcza omawianej wcześniej poufności (NDA często obowiązuje jeszcze przez kilka lat po wygaśnięciu kontraktu) oraz ewentualnego zakazu konkurencji (przez ustalony czas). Wykonawca powinien pamiętać, że podpisując kontrakt bierze na siebie te dalsze obowiązki, a zleceniodawca – że może egzekwować je także po rozstaniu.

W klauzulach końcowych dobrej umowy B2B warto uregulować też inne kwestie formalne. Dla kontraktów międzynarodowych konieczny jest wybór prawa właściwego i jurysdykcji – czyli ustalenie, czy np. zastosowanie ma prawo polskie czy obce oraz który sąd (lub arbitraż) będzie właściwy do rozstrzygania ewentualnych sporów. To krytyczne, bo w razie konfliktu unikamy dodatkowej niepewności co do procedury dochodzenia roszczeń. Zwykle każda ze stron woli “swój” kraj; często wygrywa strona silniejsza. Jeśli polski kontraktor współpracuje z zagraniczną firmą i nie jest w stanie wynegocjować polskiego prawa, warto rozważyć neutralne rozwiązanie, np. arbitraż w niezależnym sądzie polubownym. Ponadto, umowa powinna wskazywać język kontraktu – przy transgranicznych projektach najlepiej, aby dokument był dwujęzyczny (polski i angielski) lub przynajmniej w języku zrozumiałym dla obu stron. Warto również dodać zapis, że w przypadku sporu strony podejmą w pierwszej kolejności próbę polubownego rozwiązania konfliktu, zanim udadzą się do sądu – to buduje dobrą kulturę współpracy.

Na koniec, dobrze skonstruowana umowa B2B z programistą cechuje się równowagą i przewidywalnością. Uwzględnia interesy zleceniodawcy – chroniąc jego własność intelektualną, poufność i ciągłość biznesu – a zarazem respektuje prawa i samodzielność wykonawcy, jasno określając warunki współpracy bez nadmiernego ograniczania jego działalności. Ustalając powyższe elementy i negocjując sporne zapisy, obie strony budują fundament pod udaną i bezpieczną współpracę, niezależnie od tego, czy odbywa się ona lokalnie, czy ponad granicami państw.