Umowa B2B z programistą: 7 klauzul, które chronią IP

Większość Software House'ów nieświadomie działa na ,,tykającej bombie’’. Jest nią przekonanie, że opłacona faktura oznacza nabycie praw do kodu. Niestety, w polskim prawie to mit. Jeśli Twoja umowa B2B to prosty wzór z internetu, prawdopodobnie sprzedajesz klientom oprogramowanie, którego formalnie nie posiadasz.

W relacji B2B z programistą (wykonawcą) musisz pogodzić dwa światy: elastyczność (Agile) z twardym zabezpieczeniem interesów firmy (IP, odpowiedzialność). Źle skonstruowana umowa może zablokować Cię na etapie wdrożenia IT lub uniemożliwić sprzedaż spółki w przyszłości.

Oto 7 klauzul, które muszą znaleźć się w profesjonalnej umowie z programistą, abyś mógł spać spokojnie.

1. Skuteczne nabycie praw autorskich

To najważniejszy punkt całej umowy. Polskie prawo autorskie jest bezlitosne: umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności.

Jeśli ustaliliście warunki na Whatsapp albo wymieniliście się skanami PDF przez e-mail, przeniesienie praw jest nieważne.

Co musi być w umowie:

• Forma: fizyczny podpis na papierze lub Kwalifikowany Podpis Elektroniczny (np. mSzafir, Autenti z kwalifikowanym certyfikatem). Zwykły DocuSign czy skan nie wystarczą.
• Moment przeniesienia: zadbaj, aby prawa przechodziły na Ciebie z chwilą ustalenia utworu (powstania kodu), a nie z chwilą zapłaty wynagrodzenia. To chroni Cię w przypadku sporów o fakturę.
• Pola eksploatacji: wymień je wyczerpująco (kopiowanie, modyfikacja, wprowadzanie do obrotu), ponieważ w prawie autorskim niczego nie można domniemywać.

Pro tip: pamiętaj o łańcuchu praw. Nie możesz przenieść praw na swojego klienta w Umowie SaaS, jeśli najpierw skutecznie nie nabędziesz ich od programisty.

2. Przedmiot umowy: kod + dokumentacja

W metodologii Agile przedmiot umowy zmienia się dynamicznie. Jednak ,,zwinność’’ nie może oznaczać chaosu. Kod bez dokumentacji to dług technologiczny, za który Ty zapłacisz w przyszłości.

Co wpisać:

• Definicja prac: to nie tylko kod źródłowy, ale też dokumentacja techniczna, pliki konfiguracyjne i instrukcje wdrożeniowe.
• Kryterium odbioru: zapisz wprost: ,,Prace uznaje się za wykonane tylko wtedy, gdy kod został zacommitowany do repozytorium wraz z aktualną dokumentacją i przeszedł testy automatyczne’’.
• Dokumentacja na bieżąco: wymuszaj aktualizację dokumentacji w każdym sprincie, a nie ,,na koniec projektu’’ (kiedy programista będzie już myślami gdzie indziej).

3. Procedura odbioru i poprawki

W B2B nie ma Kodeksu pracy - programista odpowiada za jakość swojej usługi jak profesjonalista.

Co wpisać:

• Procedura zgłaszania uwag: określ, w jaki sposób zgłaszasz poprawki (np. Jira) i jaki czas ma programista na ich uwzględnienie.
• Milczący odbiór: mechanizm, który chroni programistę, ale i dyscyplinuje Ciebie - brak zgłoszenia uwag w terminie X dni oznacza akceptację prac.
• Gwarancja jakości: zobowiązanie do bezpłatnego usuwania błędów wykrytych np. w ciągu 30 dni od odbioru sprintu lub w trakcie testów akceptacyjnych z klientem końcowym.

4. Zakaz konkurencji i non-solicitation

Twój Software House inwestuje w zdobycie klienta. Nie możesz pozwolić, by programista ,,wyciął pośrednika’’ i dogadał się z Twoim klientem bezpośrednio.

Co wpisać:

• Zakaz współpracy z klientami: programista nie może świadczyć usług na rzecz Twoich klientów (obecnych i potencjalnych, z którymi prowadziłeś rozmowy) przez czas trwania umowy i np. 12 miesięcy po niej.
• Non-solicitation: zakaz namawiania innych członków Twojego zespołu do odejścia z pracy.
• Kary umowne: za naruszenie tych zakazów musisz przewidzieć konkretną karę pieniężną, która będzie pełniła funkcję odstraszającą.

5. Dostępność i zasady współpracy

Umowa B2B daje dużą elastyczność, ale projekt musi być dowieziony na czas. Unikaj zapisów sugerujących stosunek pracy, ale zabezpiecz dostępność.

Co wpisać:

• Deklaracja dostępności: zamiast sztywnych godzin, wpisz zobowiązanie do dostępności w wymiarze pozwalającym na realizację zadań (np. reakcja na komunikaty w oknie 10:00–15:00).
• Kanały komunikacji: obowiązek korzystania z firmowych narzędzi (Slack, Jira, MS Teams) i zakaz używania prywatnych komunikatorów do spraw służbowych.
• Zgłaszanie przerw: procedura informowania o ,,urlopie’’ z odpowiednim wyprzedzeniem.

6. Podwykonawstwo

Czy Twój senior developer może zlecić napisanie kodu swojemu koledze studentowi? W B2B - co do zasady tak, chyba że tego zakażesz.

Co wpisać:

• Zgoda na podwykonawców: wprowadź wymóg Twojej pisemnej zgody na każdego podwykonawcę. Musisz wiedzieć, kto ma dostęp do Twojego repozytorium i danych klientów.
• Odpowiedzialność: programista odpowiada za działania swoich podwykonawców jak za własne.
• NDA dla podwykonawcy: warunkiem zgody musi być podpisanie przez podwykonawcę identycznego NDA, jakie wiąże głównego programistę.

7. Poufność i exit plan

Co się dzieje, gdy współpraca się kończy? Umowa musi regulować proces ,,offboardingu’’.

Co wpisać:

• Zwrot dostępów: natychmiastowy obowiązek zwrotu sprzętu i przekazania haseł/kluczy dostępowych.
• Trwałe usunięcie danych: oświadczenie o usunięciu kodu źródłowego i danych z prywatnych nośników programisty.
• Transfer wiedzy: obowiązek przeprowadzenia spotkania przekazującego wiedzę nowemu deweloperowi, rozliczany np. według stawki godzinowej.

5 czerwonych flag: rozpoznasz je w 30 sekund

1. Forma dokumentowa (e-mail/skan) zamiast pisemnej: ryzyko nieważności przeniesienia praw autorskich.
2. Przeniesienie praw ,,z chwilą zapłaty’’: jesteś zakładnikiem jednej faktury, a klient czeka na kod.
3. Brak uregulowania podwykonawstwa: ryzyko, że kod pisze ktoś, kogo nie znasz i kto nie podpisał NDA.
4. Brak wymogu dokumentacji: dostajesz kod, którego nikt inny nie będzie potrafił utrzymać ani rozwijać.
5. Brak kar umownych za naruszenie poufności/konkurencji: dochodzenie odszkodowania na zasadach ogólnych jest trudne i długotrwałe.

Chcesz mieć pewność, że Twój Software House jest bezpieczny?

Zamów profesjonalny wzór umowy B2B z programistą w Lexable, który zabezpiecza IP, dokumentację i zakaz konkurencji, albo prześlij nam swoją obecną umowę do weryfikacji.

Wolisz mailowo? Napisz: contact@lexable.pl