Podpis elektroniczny dla software house: umowy B2B, NDA, wdrożenia i odbiory

Tabela porządkuje dokumenty, które powstają w typowym projekcie: od rekrutacji kontraktora po odbiór wdrożenia u klienta.

Ta sama zasada działa w obie strony. Programista przenosi prawa na software house, a software house przenosi je dalej na klienta. Oba ogniwa wymagają formy pisemnej.

Art. 53 ustawy o prawie autorskim i prawach pokrewnych stanowi, że umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności. Formę pisemną elektronicznie spełnia wyłącznie kwalifikowany podpis elektroniczny (art. 25 ust. 2 eIDAS). Przeniesienie obejmuje tylko pola eksploatacji wyraźnie wymienione w umowie, więc samo podpisanie w dobrej formie nie wystarczy, jeśli lista pól jest niepełna.

Trzy rozwiązania, które stosują firmy IT:

1. Umowa ramowa z przeniesieniem praw w formie pisemnej. Raz, na początku współpracy, obie strony podpisują ją kwalifikowanym podpisem albo odręcznie. Zlecenia, specyfikacje i protokoły odbioru idą potem przez link.
2. Osobna umowa przeniesienia praw. Umowa B2B podpisana przez link, a przeniesienie praw za dany okres lub etap w osobnym dokumencie w formie pisemnej.
3. Licencja niewyłączna tam, gdzie wystarcza. Jeśli klient potrzebuje tylko prawa do korzystania z systemu, licencja niewyłączna nie ma zastrzeżonej formy i można ją podpisać przez link.

Więcej o tym piszemy w poradniku umowa o przeniesienie praw autorskich: jaki podpis.

Umowa wdrożeniowa i umowa SLA między przedsiębiorcami nie mają zastrzeżonej formy. Uważaj jednak na klauzulę „zmiany umowy wymagają formy pisemnej pod rygorem nieważności”, którą często wnosi dział prawny klienta. Jeśli się w umowie znajdzie, każdy aneks zmieniający zakres albo stawki trzeba podpisać odręcznie albo kwalifikowanym podpisem. Zamiast niej można zapisać formę dokumentową, wtedy aneks podpisany przez link wystarcza. Wzór umowy opisaliśmy na stronie umowa SLA i wdrożeniowa.

Protokół odbioru ma większe znaczenie, niż wynika z jego długości. Od daty odbioru biegną zwykle terminy płatności, gwarancji i zgłaszania wad. Akceptacja w komentarzu do zadania albo krótka odpowiedź mailowa „wygląda dobrze” łatwo staje się sporna, gdy trzy miesiące później klient zgłasza błędy i odmawia zapłaty. Protokół podpisany przez link przez Product Ownera klienta i kierownika projektu ma datę, godzinę i skrót dokumentu z listą odebranych funkcji.

• API i webhooki. Umowy B2B, NDA dla kandydatów i protokoły odbioru mogą wychodzić z Waszego systemu do zarządzania projektami albo kontraktorami. Webhook informuje, że dokument został podpisany, więc status zadania może zmienić się bez ręcznego sprawdzania.
• Kolejność podpisów. Umowa wdrożeniowa: najpierw klient, potem dwóch członków zarządu software house, jeśli reprezentacja jest łączna.
• Szablony NDA. Jedno NDA dla kandydatów, jedno dla klientów przed wyceną. Wysyłka zajmuje chwilę przed spotkaniem, nie po nim.
• Masowa wysyłka do kontraktorów. Nowa polityka bezpieczeństwa informacji albo aneks o zasadach dostępu do repozytoriów trafia do wszystkich kontraktorów, każdy podpisuje własny egzemplarz.
• Walidator. Klient albo audytor może sprawdzić podpisany PDF na stronie walidatora podpisu.
• Zespół. W planie Team kierownicy projektów i biuro pracują na wspólnych dokumentach firmy.

Kontraktor odchodzi, a przeniesienia praw nie było. Umowa B2B była podpisana przez link z klauzulą przeniesienia praw, więc przeniesienie jest nieważne. Uzupełnij umowę przeniesienia w formie pisemnej, póki współpraca trwa. NDA podpisane po spotkaniu. Poufne informacje były już przekazane. Link wysłany przed spotkaniem zamyka tę lukę. Klient zmienia stawkę w PDF po podpisie. Skrót SHA-256 w Karcie Podpisów pokazuje, że plik różni się od podpisanego. Klient spoza Polski. Rozporządzenie eIDAS działa w całej Unii, a przy klientach spoza Unii o skutkach podpisu decyduje prawo, któremu strony poddały umowę.