Jeśli dostajesz w piątek o 20:00 e‑mail z gotową umową B2B i 24‑hour deadline, nie otwieraj drzwi i nie podpisuj. Najpierw sprawdź kilka konkretnych zapisów: prawo do kodu (IP), zakres usług, odpowiedzialność, SLA i klauzule dotyczące osób trzecich. Bardziej niż etykietka "prawnik IT" ratuje projekt doświadczenie prawnika z danym modelem biznesowym i jego zrozumienie architektury produktu.
W piątek o 20:00 klient wysyła gotową umowę, deadline 24 godziny, a w treści jest zapis o automatycznym przejściu praw do repozytorium. Dla zespołu to wygląda jak normalny sprint, dla projektu to ryzyko, które może zablokować komercjalizację.
Jak szybko ocenić umowę, gdy masz 24 godziny
- Sprawdź, kto ma prawo autorskie do kodu i czym jest objęty transfer praw. Umowa często miesza pojęcia: "licencja" i "przeniesienie" są różne w skutkach.
- Przejrzyj SLA: dostępność, kara umowna, limit odpowiedzialności. Jeśli SLA ma kary z automatycznym offsetem przy płatnościach, to ryzyko finansowe rośnie.
- Zidentyfikuj klauzule o podwykonawcach i osobach trzecich: czy klient wymaga escrow kodu, specjalnych licencji OSS, audytu bezpieczeństwa, albo prawa do inspekcji u Ciebie.
- RODO i przetwarzanie danych: czy Twoja usługa klasyfikuje się jako administrator czy procesor, czy trzeba podpisać DPA, jakie są transfery międzynarodowe.
- Ochrona know‑how i klauzule konkurencyjne: czy umowa zabrania Ci pracy dla innych klientów w określonym segmencie lub używania bibliotek open source.
Kiedy etykietka "prawnik IT" jest przesadzona i co ma znaczenie w praktyce
Sam tytuł "prawnik IT" nic nie mówi o praktyce. Ważniejsze są trzy rzeczy jednocześnie: doświadczenie w modelu biznesowym (np. SaaS, body‑leasing, sprzedaż/licencje kodu); rozumienie stosowanej architektury — microservices, multi‑tenant, LLM integration; oraz praktyka w negocjowaniu ryzyk technicznych (escrow, DPA, SLA). Prawnik, który rozumie, jak działa Twój delivery pipeline, potrafi napisać zapisy, które realnie ochronią produkt.
Pamiętam rozmowę z młodym developerem z Poznania, który dowiedział się za późno, że nieuregulowane kontrybucje do repozytorium zablokowały komercjalizację aplikacji — projekt stanął, bo nie udało się zebrać zgód od kontrybutorów. To nie był brak wiedzy o prawie autorskim, tylko brak procedury dokumentującej status prawny kodu.
Czy wiesz, że przypadki związane z prawami autorskimi do materiałów cyfrowych bywają przewrotne; zobacz, jak problemy z zawłaszczeniem zasobu online wyglądają w praktyce w artykule o prawa autorskie w praktyce
Co sprawdzić pierwszy raz, gdy klient wysyła gotowy projekt umowy
- Kim jesteś w relacji do danych: administrator czy procesor, i czy załączony jest DPA. - Czy umowa wymaga przeniesienia praw autorskich, czy daje licencję ograniczoną. Jeśli jest przeniesienie, jakie pola kodu obejmuje.
- Kto odpowiada za błędy/zwłoki w integracji z systemami trzecimi oraz czy są limity odpowiedzialności i wyjątki (force majeure, act of God, third‑party outages).
- Klauzule o open source: czy umowa zabrania użycia bibliotek GPL, czy wymaga ujawnienia modyfikacji.
- Escrow: czy kod źródłowy ma być deponowany, w jakiej formie i jakie warunki odsłonięcia będą obowiązywać.
- Warunki rozwiązania umowy: jakie są okresy wypowiedzenia, co się dzieje z danymi klientów i kopią kodu po zakończeniu współpracy.
Krótka lista terminów, które musisz znać i ich praktyczne znaczenie
SLA — Service Level Agreement, opisuje dostępność i kary; w praktyce oznacza to numery: uptime 99,9% to ~43 minuty niedostępności miesięcznie. MSA — Master Service Agreement, ramy dla kolejnych SOW. SOW — Statement of Work, zakres konkretnego zadania. Escrow — depozyt kodu u trzeciej strony na wypadek braku dostępu do dostawcy. DPA — Data Processing Agreement, wymagany przy przetwarzaniu danych osobowych. OSS license — rodzaj licencji open source (MIT, GPL), każda ma inne obowiązki udostępniania zmian. Transfer praw autorskich — formalny akt, nie równy zwykłej licencji.
Najczęstsze błędy, które widzę
- Podpisanie umowy z automatycznym przeniesieniem IP bez listy plików i kontrybutorów.
- Brak DPA lub mylenie ról procesora i administratora przy integracji z zewnętrznym CRM.
- Zgoda na nieograniczoną odpowiedzialność za szkody pośrednie.
- Użycie bibliotek OSS o restrykcyjnej licencji bez zgód lub bez mechanizmu zastąpienia ich w architekturze.
Co zrobić natychmiast
- Zawiesić automatyczny workflow podpisu elektronicznego i poprosić o 48 godzin na weryfikację, jeśli kontrahent dopuszcza krótkie opóźnienie.
- Wysłać precyzyjną listę pytań: jakie repo, kto jest autorem, jakie biblioteki OSS, czy jest escrow, jakie są SLA i limity kar.
- Ocenę ryzyka z punktu widzenia modelu biznesowego: SaaS potrzebuje inaczej sformułowanego SLA i DPA niż body‑leasing.
Kiedy kupić retainer
Jeżeli masz ciągłe wdrożenia i negocjujesz umowy regularnie, retainer opłaca się przy przynajmniej kilku kontraktach miesięcznie — daje szybsze odpowiedzi i mniejsze ryzyko decyzji ad hoc.
FAQ
P: Kiedy szukać prawnika natychmiast
O: Natychmiast, gdy umowa zawiera przeniesienie IP, wymóg escrow, lub limit odpowiedzialności wyłącza szkody pośrednie.
P: Czy prawnik IT musi rozumieć kod
O: Nie musi być deweloperem, ale musi rozumieć architekturę produktu i model komercyjny, żeby skutecznie alokować ryzyko.
Te artykuły mogą Cię zainteresować
Prawo autorskie w Polsce - dlaczego jest nagminnie łamane na stronach internetowych — przykład, jak brak kontroli nad treścią może zniszczyć model monetyzacji.
Czy można nagrywać rozmowę bez zgody drugiej osoby — krótkie omówienie ryzyka publikacji nagrań, które często pojawia się przy dowodzeniu uzgodnień ustnych.
RODO w praktyce — za co firmy najczęściej dostają kary — przykłady proceduralnych błędów przy przetwarzaniu danych klientów.