Umowa B2B w IT: stawki, IP i dostępność

Umowa B2B w IT dzieli się na dwa główne modele, które różnią się prawie wszystkim: sposobem wyceny, zakresem odpowiedzialności i tym, jak łatwo można ją pomylić z etatem. Poza modelem współpracy trzeba jeszcze rozstrzygnąć prawa do kodu, dostęp do repozytoriów, dyżury i wybór stawki. Ten tekst przechodzi przez każdy z tych punktów z perspektywy praktycznej, nie tylko teoretycznej.

Body leasing kontra praca na rezultat

Body leasing, czyli udostępnienie czasu i kompetencji programisty na rzecz zespołu klienta, jest najprostszym modelem do wyceny: stawka za godzinę albo dzień pracy, klient kieruje bieżącymi zadaniami, wykonawca dostarcza umiejętności. Problem w tym, że model ten najbardziej przypomina zatrudnienie, bo klient faktycznie zarządza pracą na bieżąco, podobnie jak przy stanowisku etatowym.

Praca na rezultat wygląda inaczej: wykonawca dostaje zadanie, ustala sposób realizacji samodzielnie, dostarcza rezultat i podlega odbiorowi zgodnie z kryteriami z umowy. To model bliższy typowej relacji przedsiębiorca-przedsiębiorca, bo klient nie zarządza codzienną pracą, tylko odbiera efekt.

W praktyce wiele umów IT jest hybrydą: wykonawca ma przypisane konkretne zadania z backlogu, ale sam decyduje, jak i kiedy je realizować, w ramach ustalonych terminów sprintu. To rozwiązanie może działać dobrze, jeśli umowa i faktyczna praktyka konsekwentnie zachowują element samodzielności, na przykład brak obowiązku pracy w konkretnych godzinach i możliwość realizacji zadań z innych projektów równolegle.

Transfer praw autorskich do kodu

Klient kupujący oprogramowanie chce mieć pewność, że może z niego korzystać bez ograniczeń, sprzedawać je dalej albo modyfikować bez zgody wykonawcy. Prawo autorskie nie działa jednak automatycznie: sama zapłata wynagrodzenia nie przenosi majątkowych praw autorskich, jeśli umowa tego wyraźnie nie stwierdza.

Umowa IT powinna wskazywać, że wraz z zapłatą pełnego wynagrodzenia za dany etap, wykonawca przenosi na klienta majątkowe prawa autorskie do kodu stworzonego w ramach tego etapu, na konkretnie wymienionych polach eksploatacji, na przykład zwielokrotnianie, wprowadzanie do obrotu, tworzenie opracowań. Bez wskazania pól eksploatacji zapis o "przeniesieniu praw" jest prawnie niepełny.

Odrębną kwestią są biblioteki, komponenty i narzędzia własne wykonawcy, powstałe przed danym projektem albo używane w wielu projektach dla różnych klientów. Umowa powinna wyraźnie wyłączyć je z transferu praw i zamiast tego przyznać klientowi licencję w zakresie potrzebnym do korzystania z rezultatu, na przykład prawo do używania i modyfikowania komponentu w ramach dostarczonego systemu, bez prawa do jego samodzielnej dalszej odsprzedaży jako osobnego produktu.

Trzeci element to komponenty open source. Wykonawca powinien wskazać, jakie licencje open source zostały użyte i czy mają wymogi, na przykład publikację kodu pochodnego. Klient powinien wiedzieć o takich zależnościach przed wdrożeniem systemu do produkcji, nie odkrywać ich przy audycie prawnym rok później.

Dostęp do repozytoriów i bezpieczeństwo

Kontrakty IT często wymagają, aby wykonawca pracował w repozytorium, systemie CI/CD i środowisku dostarczonym przez klienta, a nie na własnej infrastrukturze. To rozsądne z perspektywy bezpieczeństwa, ale warto to opisać w umowie, zamiast zostawiać jako ustną praktykę.

Zapis powinien wskazywać: kto zarządza dostępami, jak wygląda proces ich odbierania po zakończeniu współpracy, czy wykonawca może korzystać z własnych narzędzi lokalnie, na przykład edytora kodu czy menedżera pakietów, oraz jakie zasady bezpieczeństwa obowiązują, na przykład dwuetapowe uwierzytelnianie czy zakaz kopiowania kodu poza wskazane środowisko.

Wymóg pracy wyłącznie w systemach klienta, z narzędziami monitorującymi aktywność w czasie rzeczywistym, zbliżony do nadzoru nad pracownikiem, jest jednym z sygnałów, które mogą sugerować podporządkowanie, a nie samodzielną współpracę B2B. Rozsądne wymogi bezpieczeństwa to jedno, stały nadzór operacyjny jak nad etatowym programistą to inna sprawa.

Dyżury i dostępność poza standardowymi godzinami

On-call, czyli dyżur w gotowości do reakcji na incydent poza standardowymi godzinami pracy, wymaga osobnego rozliczenia. Ukrycie dyżurów w stałej stawce miesięcznej, bez limitu godzin i bez dodatkowej opłaty za faktyczną interwencję, prowadzi do sytuacji, w której wykonawca jest teoretycznie dostępny 24 godziny na dobę za tę samą kwotę, co przy standardowym zakresie.

Lepszy model rozdziela dwie kwestie: opłatę za samą gotowość, czyli fakt bycia dostępnym w danym oknie czasowym, oraz opłatę za realną interwencję, liczoną według stawki godzinowej albo stałej kwoty za incydent. Umowa powinna też wskazać czas reakcji, na przykład 30 minut od zgłoszenia, oraz maksymalną liczbę dyżurów w danym okresie, żeby dostępność nie rozrastała się bez ograniczeń.

Stawka godzinowa czy miesięczna

Stawka godzinowa działa dobrze, gdy zakres pracy jest zmienny i trudny do przewidzenia z góry, na przykład wsparcie techniczne albo prace konsultingowe. Wymaga jednak rzetelnego raportowania czasu i jasnej zasady, czy klient zatwierdza raport przed wystawieniem faktury.

Stawka miesięczna, czyli forma zbliżona do ryczałtu, pasuje do stałej współpracy o przewidywalnym zakresie, na przykład opieka nad systemem albo praca w jednym zespole przez określoną liczbę dni w tygodniu. Kluczowe jest ustalenie, ile godzin albo dni obejmuje stawka i co się dzieje, gdy klient potrzebuje więcej pracy niż ustalony limit. Bez tego zapisu miesięczna stawka bywa interpretowana przez klienta jako nieograniczona dostępność za tę samą kwotę.

Niezależnie od modelu, warto dopisać zasadę indeksacji albo przeglądu stawki po określonym czasie, na przykład raz w roku, żeby uniknąć sytuacji, w której stawka z 2024 roku obowiązuje bez zmian przez pięć lat współpracy, mimo zmian na rynku.

PIP w IT: gdzie leży granica

Branża IT jest jedną z tych, w których kontrole PIP dotyczące przekwalifikowania B2B na etat pojawiają się częściej, właśnie ze względu na popularność body leasingu. Programista pracujący w zespole klienta, w tych samych godzinach co pracownicy etatowi, pod bezpośrednim kierownictwem lidera zespołu, korzystający wyłącznie ze sprzętu i narzędzi klienta, z zakazem pracy dla innych podmiotów, ma cechy zbliżone do stosunku pracy, niezależnie od formy umowy.

Elementy, które pomagają utrzymać charakter współpracy B2B, to możliwość samodzielnej organizacji pracy w ramach terminów, prawo do realizacji zadań z innych projektów, brak obowiązku pracy w sztywno wyznaczonych godzinach oraz odpowiedzialność za rezultat, a nie tylko za czas spędzony przy komputerze. Żaden z tych elementów w izolacji nie decyduje o kwalifikacji umowy, ale razem budują obraz realnej niezależności wykonawcy.

Przed podpisaniem kontraktu warto przejrzeć dziesięć klauzul umowy B2B do negocjacji oraz przygotować dokument z pomocą generatora umowy B2B, dostosowanego do specyfiki IT, w tym praw autorskich i modelu rozliczeń. Sam uniwersalny wzór umowy B2B pokazuje też, jak uzupełnić klauzule branżowe bez naruszania struktury całego dokumentu.