Umowa z software house'em — co musi się w niej znaleźć

Przy wyborze wykonawcy uwaga skupia się na cenie i terminie. Tymczasem to umowa decyduje, co się stanie, gdy coś pójdzie nie tak: gdy termin się przesunie, zakres się zmieni albo zechcesz przenieść rozwój systemu do innej firmy.

Najdroższe problemy w projektach IT rzadko wynikają z samej jakości kodu. Częściej z tego, że firma zapłaciła za system, ale nie ma do niego pełnych praw, dostępu do repozytorium albo kont u dostawcy chmury. Poniżej omawiamy zapisy, które warto sprawdzić przed podpisaniem — w kolejności od najważniejszych.

Uwaga: to materiał informacyjny, nie porada prawna. Przy większych projektach umowę warto skonsultować z prawnikiem specjalizującym się w IT.

Program komputerowy jest w polskim prawie chroniony jak utwór — ustawa o prawie autorskim i prawach pokrewnych poświęca mu osobny rozdział. Z punktu widzenia firmy zamawiającej kluczowe są trzy przepisy.

Forma pisemna. Umowa o przeniesienie autorskich praw majątkowych wymaga zachowania formy pisemnej pod rygorem nieważności (art. 53). Akceptacja oferty mailem albo zapis w regulaminie nie wystarczą.

Pola eksploatacji. Umowa obejmuje tylko te pola eksploatacji, które zostały w niej wyraźnie wymienione (art. 41 ust. 2). Ogólne sformułowanie o przeniesieniu praw „na wszystkich polach eksploatacji” nie zastąpi konkretnej listy.

Zakres praw do programu. Dla programów komputerowych ustawa wymienia wprost m.in. prawo do trwałego lub czasowego zwielokrotnienia programu, do „tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian” oraz do rozpowszechniania (art. 74 ust. 4).

W praktyce masz dwie drogi. Przeniesienie praw oznacza, że po spełnieniu warunków umowy system jest Twój. Licencja oznacza, że możesz z niego korzystać w określonym zakresie, a prawa zostają przy wykonawcy. Licencja bywa uzasadniona, gdy system powstaje na bazie gotowego produktu wykonawcy. Przy oprogramowaniu budowanym od zera pod Twój proces zwykle warto dążyć do przeniesienia praw.

Osobno zadbaj o prawo do modyfikacji kodu i zlecania jego rozwoju innym firmom. Bez wyraźnego zapisu zmiana wykonawcy może stać się sporna.

Moment przeniesienia praw warto ustalić wprost. Najczęstsze warianty to przeniesienie z chwilą zapłaty wynagrodzenia za dany etap albo z chwilą odbioru. Dla wykonawcy bezpieczniejsza jest zapłata, dla zamawiającego — odbiór. Rozsądnym kompromisem jest przeniesienie praw etapami, wraz z płatnością za odebrany etap.

Do momentu przeniesienia praw umowa powinna dawać Ci licencję na korzystanie z tego, co już powstało. Inaczej przez część projektu używasz systemu, do którego formalnie nie masz żadnych uprawnień.

Jeśli umowa ma charakter umowy o dzieło, do odpowiedzialności wykonawcy za wady stosuje się odpowiednio przepisy o rękojmi przy sprzedaży (art. 638 Kodeksu cywilnego). W relacjach między firmami strony mogą jednak co do zasady rękojmię rozszerzyć, ograniczyć lub wyłączyć (art. 558 § 1 k.c.; wyjątki dotyczą m.in. konsumentów) — i w umowach IT często to robią.

Dlatego warto sprawdzić, czy w zamian umowa przewiduje gwarancję: przez jaki czas wykonawca bezpłatnie usuwa błędy i w jakim czasie reaguje. Przy systemach krytycznych dla biznesu dochodzi do tego umowa o utrzymanie z SLA, czyli poziomami usług: czasem reakcji i czasem naprawy dla błędów o różnej wadze.

Dwa czasy warto rozróżniać wprost. Czas reakcji to moment, w którym ktoś zajmie się zgłoszeniem. Czas naprawy to moment, w którym problem zostanie rozwiązany lub obejdzie się go rozwiązaniem tymczasowym. Umowa, która gwarantuje tylko reakcję, gwarantuje niewiele.

Dane osobowe. Jeśli wykonawca będzie miał dostęp do danych osobowych — na przykład do produkcyjnej bazy klientów podczas migracji lub utrzymania — potrzebna jest umowa powierzenia przetwarzania danych w rozumieniu art. 28 RODO. Warto uruchomić ją równolegle z główną umową, bo jej brak potrafi zatrzymać projekt w najmniej wygodnym momencie.

Poufność. Umowa lub osobne NDA powinny obejmować informacje o Twojej firmie, procesach i danych, do których wykonawca uzyska dostęp — także po zakończeniu współpracy.

Zakończenie współpracy. Dobra umowa przewiduje okres wypowiedzenia, przekazanie kodu, dokumentacji i dostępów oraz wsparcie przy przejęciu projektu przez nowy zespół. Jeśli korzystasz z licencjonowanego produktu wykonawcy, rozważ depozyt kodu źródłowego (escrow) na wypadek, gdyby wykonawca przestał działać.

Sposób rozliczenia wpływa na to, jak zapisać odbiory i płatności — oba modele porównujemy w tekście stała cena czy time & materials. Szerszy kontekst decyzji znajdziesz w przewodniku po oprogramowaniu na zamówienie.