Kontrakt B2B dla Programisty (IT) – 5 klauzul, które musisz wykreślić
Wyobraź sobie taką sytuację: dostałeś ofertę życia. Stawka godzinowa? Marzenie. Projekt? Nowoczesny stack technologiczny, zero „legacy code”. HR przesyła Ci umowę, rzucasz okiem – wygląda standardowo. Podpisujesz.
Pół roku później okazuje się, że Software House żąda od Ciebie naprawy błędu w sobotę w nocy (za darmo), a Twój prywatny projekt aplikacji mobilnej, który dłubiesz po godzinach, nagle – zgodnie z papierami – należy do nich. Brzmi jak horror? To codzienność wielu programistów, którzy traktują umowa b2b it jak formalność.
Jako prawnik, który od lat analizuje kontrakty w branży tech, widziałem już łzy wściekłości i wezwania do zapłaty na kwoty, które kasują oszczędności życia. B2B to wolność, ale i pełna odpowiedzialność majątkowa. Dziś przeprowadzę Cię przez pole minowe Twojego kontraktu. Oto 5 rzeczy, które musisz znaleźć i zneutralizować, zanim złożysz podpis.
Przeniesienie praw autorskich – nie oddawaj wszystkiego
Większość wzorów umów, jakie dostaniesz od klienta, zawiera klauzulę w stylu: „Wykonawca przenosi na Zamawiającego wszelkie prawa autorskie do wszystkich utworów stworzonych w trakcie trwania umowy”. Brzmi niewinnie? To pułapka.
Jeśli w czasie trwania kontraktu napiszesz po godzinach kod do własnego startupu albo stworzysz bibliotekę open-source, to przy tak sformułowanym zapisie… wszystko to staje się własnością Twojego klienta. Prawo nie rozróżnia tu „godzin pracy” tak ściśle, jak Kodeks Pracy.
Jak się bronić?
- Ogranicz przeniesienie praw tylko do utworów stworzonych w ramach wykonywania Zlecen (konkretnych zadań), a nie „w trakcie trwania umowy”.
- Zastrzeż, że przeniesienie następuje z chwilą zapłaty wynagrodzenia (to Twoje zabezpieczenie, gdyby klient przestał płacić).
- Jeżeli korzystasz z gotowych bibliotek (open source), upewnij się, że umowa nie wymaga od Ciebie przeniesienia praw do kodu, którego nie jesteś autorem.
Kwestia ta jest skomplikowana, dlatego jeśli tworzysz dużo własnego softu, umowa-b2b-prawa-autorskie to temat, który powinieneś zgłębić w moim osobnym poradniku, gdzie rozkładam te zapisy na czynniki pierwsze.
„Support wieczny” – czy musisz naprawiać błędy po latach?
Wielu programistów myśli: „Będę pisał dobry kod, więc nie martwię się gwarancją”. Błąd. W relacji B2B, jeśli nie wyłączysz w umowie rękojmi (zgodnie z Kodeksem Cywilnym), odpowiadasz za wady przez 2 lata, a klient może żądać obniżenia ceny lub odstąpienia od umowy.
Jeszcze groźniejsze są zapisy o „gwarancji jakości” bez limitu czasowego. Może się okazać, że za 3 lata, gdy będziesz już w innej firmie, stary klient zadzwoni z żądaniem naprawy błędu, bo zmieniła się wersja PHP, a Twój kod przestał działać.
Rozwiązanie: Wpisz wprost: „Strony wyłączają rękojmię”. Zamiast tego udziel gwarancji na np. 3 miesiące od wdrożenia, obejmującej tylko błędy krytyczne, a nie zmiany funkcjonalne (Change Requests).
SLA i kary za dostępność – na co uważać?
Często w umowach dla programistów (nie tylko DevOpsów) pojawiają się zapisy o SLA (Service Level Agreement) przeklejone z umów dla firm hostingowych. Widzisz zapis o karze umownej za „niedostępność systemu”?
Uważaj! Jeśli Twój kod spowoduje crash produkcji, a kara jest naliczana za każdą godzinę przestoju, możesz skończyć z fakturą na minusie. Spotkałem się z sytuacją, gdzie prawa autorskie kod b2b były najmniejszym problemem programisty – większym była kara 500 zł za każdą godzinę awarii, która trwała cały weekend.
Okiem Praktyka – Sąd vs RzeczywistośćCzęsto słyszę: „Eee tam, żaden sąd nie przyklepie takiej kary”. To prawda, w sądzie istnieje instytucja tzw. „miarkowania kary umownej” (sędzia może ją zmniejszyć, jeśli jest rażąco wygórowana). Ale zastanów się – czy masz czas, nerwy i pieniądze na 3-letni proces sądowy, żeby udowodnić swoją rację? Klient potrąci karę z Twojej ostatniej faktury od razu. Ty będziesz musiał walczyć o jej odzyskanie. Lepiej wykreślić ten zapis TERAZ, niż liczyć na sprawiedliwość później.
Dodatkowo, zwróć uwagę na zakaz-konkurencji-b2b. Często idzie on w parze z wysokimi karami umownymi. Nie zgadzaj się na zakaz pracy dla „wszystkich firm z branży IT”. To zawodowe samobójstwo.
Praca zdalna z zagranicy a podatki
Marzy Ci się „workation” na Bali lub Kanarach? Twój umowa b2b programista wzór może milczeć na ten temat, ale przepisy podatkowe już nie. Jeśli pracujesz dla polskiego klienta, siedząc na stałe za granicą (powyżej 183 dni lub przenosząc tam ośrodek interesów życiowych), możesz wpaść w pułapkę podwójnego opodatkowania lub tzw. zakładu zagranicznego (Permanent Establishment).
Klient może wpisać w umowę, że zobowiązujesz się do pokrycia wszelkich szkód wynikających z Twojej rezydencji podatkowej. Jeśli urząd skarbowy w Hiszpanii uzna, że Twój polski klient powinien płacić tam podatki przez Twoją obecność – klient przyjdzie po te pieniądze do Ciebie.
FAQ – Najczęściej zadawane pytania
Co musi być w umowie IT, żeby była bezpieczna?
Kluczowe elementy to: precyzyjne określenie przedmiotu zlecenia (SOW), moment przeniesienia praw autorskich (po zapłacie!), ograniczenie kar umownych (tzw. cap, np. do wysokości jednej faktury) oraz jasne zasady wychodzenia z umowy (okres wypowiedzenia).
Czy odpowiadam za błędy w kodzie całym swoim majątkiem?
W B2B – tak, chyba że ograniczysz tę odpowiedzialność w umowie. To najważniejsza różnica względem umowy o pracę (gdzie odpowiadasz do 3 pensji). Zawsze wprowadzaj limit odpowiedzialności do konkretnej kwoty (np. 50.000 zł lub dwukrotność wynagrodzenia).
Czy mogę pracować dla dwóch software house’ów jednocześnie?
Tak, o ile nie podpisałeś zakazu konkurencji, który tego zabrania. Upewnij się, że definicja „działalności konkurencyjnej” w Twojej umowie nie jest zbyt szeroka. Praca dla klienta z branży FinTech nie powinna blokować Ci zleceń w branży MedTech.
Nie podpisuj w ciemno!
Twoja umowa to nie tylko formalność do faktury – to tarcza, która ma chronić Twój majątek. Masz wątpliwości co do zapisów w swoim kontrakcie? Nie ryzykuj.
