Umowa z software house: odbiór kodu, prawa autorskie i odpowiedzialność za wdrożenie

Specyfikacja decyduje o zakresie świadczenia

Umowa powinna określać cel biznesowy, funkcjonalności, wymagania bezpieczeństwa, wydajność i integracje z systemami klienta. Zbyt ogólne stwierdzenie „wykonawca dostarczy nowoczesną platformę” utrudnia późniejsze ustalenie, czy świadczenie wykonano prawidłowo. Warto zdefiniować produkt minimalny, harmonogram, kryteria sukcesu i procedurę zmiany zakresu. Szczególnie istotne jest wskazanie odpowiedzialności za niejasne wymagania i sposób dokumentowania ustaleń podczas pracy.

Przeniesienie praw autorskich wymaga właściwej konstrukcji

Zgodnie z prawem autorskim przeniesienie autorskich praw majątkowych wymaga odpowiedniej formy oraz oznaczenia pól eksploatacji. Do programów komputerowych stosuje się także szczególne zasady art. 74. Sam zapis „klient otrzymuje wszystkie prawa do produktu” może rodzić spory, jeśli umowa nie określa zakresu uprawnień i momentu ich przejścia. Warto także uregulować możliwość modyfikacji, dalszego rozpowszechniania, sublicencjonowania i przenoszenia praw na kolejnych inwestorów.

Kod stworzony przez pracowników i podwykonawców

Software house może korzystać z pracowników, programistów B2B i dalszych podwykonawców. Klient powinien otrzymać odpowiednie zapewnienia dotyczące łańcucha praw, w tym tego, czy wykonawca rzeczywiście może przenieść albo udzielić licencji na wszystkie elementy. Sam fakt, że programista pracował dla wykonawcy, nie rozstrzyga wszystkich sytuacji dotyczących współpracowników niebędących pracownikami w rozumieniu prawa pracy. Dokumentacja pozyskania praw ma znaczenie przy późniejszej sprzedaży produktu.

Repozytorium kodu i możliwość zmiany dostawcy

Przedsiębiorca powinien ustalić, kto administruje repozytorium, czy klient otrzyma bieżący dostęp, historię zmian, instrukcję uruchomienia i dokumentację infrastruktury. Posiadanie wyłącznie działającej aplikacji w chmurze wykonawcy może prowadzić do uzależnienia od jednego dostawcy. Warto przewidzieć obowiązek przekazania kodu, kluczy i konfiguracji w bezpieczny sposób po zakończeniu współpracy. Odpowiednia procedura migracji zmniejsza ryzyko przerwy w działalności.

Kryteria odbioru etapów

Protokół odbioru nie powinien być automatyczną formalnością podpisywaną po prezentacji graficznej. W umowie należy wskazać scenariusze testowe, kryteria akceptacji, wady krytyczne, usterki mniej istotne i terminy ich usuwania. Dla wdrożeń iteracyjnych pomocny jest jasny mechanizm potwierdzania sprintów bez zrzeczenia się roszczeń z tytułu wad ukrytych. Nie powinno się utożsamiać samego uruchomienia aplikacji z bezwarunkowym odbiorem całego zamówienia.

Licencje open source i komponenty zewnętrzne

Wiele systemów zawiera biblioteki open source oraz płatne usługi chmurowe. Niektóre licencje mogą wymagać zachowania informacji licencyjnych, udostępnienia kodu źródłowego w określonych scenariuszach albo przestrzegania zasad redystrybucji. Należy prowadzić wykaz komponentów, licencji i wersji oraz ustalić obowiązek informowania o zmianach. Klient powinien wiedzieć, które elementy stanowią jego własność intelektualną, a które pozostają objęte prawami osób trzecich.

SLA, gwarancja jakości i wsparcie techniczne

Po wdrożeniu warto określić czasy reakcji na awarie, priorytety incydentów, godziny wsparcia, procedury aktualizacji i odpowiedzialność za bezpieczeństwo. SLA opisujące jedynie dostępność procentową nie wystarcza, jeśli nie wiadomo, jak mierzyć przestój i jakie konsekwencje wynikają z niedotrzymania poziomu usługi. Warto wyraźnie oddzielić błędy oprogramowania od zmian funkcjonalnych zamawianych później przez klienta.

Bezpieczeństwo, RODO i podwykonawcy

Jeżeli dostawca ma dostęp do danych osobowych, trzeba ocenić role stron i umowę powierzenia zgodnie z art. 28 RODO. Istotne są testy bezpieczeństwa, dostęp do środowiska produkcyjnego, audyt logów i reakcja na incydent. Umowa powinna regulować korzystanie z podwykonawców i zasady przekazywania danych poza EOG. Zabezpieczenie praw autorskich nie zastępuje ochrony informacji poufnych i danych klientów.

Zmiana zakresu i rozliczanie dodatkowych prac

Projekty IT zmieniają się w trakcie realizacji, dlatego kluczowy jest mechanizm change request. Powinien obejmować opis nowego wymagania, wpływ na cenę i termin oraz wskazanie osoby uprawnionej do akceptacji. Bez tej procedury powstają spory, czy praca stanowiła usunięcie wady, realizację pierwotnej specyfikacji czy odpłatną zmianę funkcjonalną. Dobre reguły ograniczają konflikt bez blokowania zwinnych metod realizacji.

Odpowiedzialność za niepowodzenie projektu

Klauzule ograniczające odpowiedzialność powinny być analizowane z uwzględnieniem prawa cywilnego, charakteru szkody i możliwości dochodzenia roszczeń. Nie każda szeroka klauzula „as is” jest dopuszczalna lub uzasadniona przy indywidualnym zamówieniu. Trzeba przewidzieć skutki opóźnienia, braku odbioru i nienaprawionych wad, a także zasady rozwiązania umowy i zwrotu niewykorzystanych opłat. Warto przygotować awaryjny plan kontynuacji projektu przez innego dostawcę.

Powiązane publikacje

Program komputerowy stworzony przez pracownika · Umowa wdrożenia systemu AI

Czy przelew za fakturę daje prawo do dowolnego wykorzystania kodu?

Nie należy automatycznie utożsamiać zapłaty wynagrodzenia z przeniesieniem autorskich praw majątkowych. Trzeba sprawdzić formę i treść umowy, pola eksploatacji oraz uprawnienia wykonawcy do komponentów stworzonych przez współpracowników i osoby trzecie. Przy programach komputerowych istotne są szczególne przepisy art. 74 prawa autorskiego. W praktyce klient powinien posiadać odpowiednio uregulowane uprawnienia do uruchamiania, modyfikowania, rozwijania i przekazywania programu następnym wykonawcom, jeśli taki jest biznesowy cel kontraktu.

Jak postępować, gdy klient odmawia podpisania protokołu odbioru?

Należy porównać dostarczony zakres ze specyfikacją i ustalonymi kryteriami odbioru. Wykonawca powinien znać konkretne wady i oczekiwany sposób ich usunięcia, a klient nie powinien odmówić odbioru z powodów niezwiązanych z umową. Warto oddzielić usterki krytyczne uniemożliwiające korzystanie z produktu od drobnych poprawek, które można wykonać w określonym terminie. Dobrze udokumentowana procedura ogranicza ryzyko wzajemnych oskarżeń o opóźnienie i umożliwia rozliczenie rzeczywiście zakończonych etapów.

Jak zabezpieczyć się przed utratą dostępu do repozytorium?

Umowa powinna określać, kto administruje repozytorium i jaką rolę dostępową ma klient, kiedy przekazuje się kod źródłowy oraz jakie dokumenty są potrzebne do samodzielnego uruchomienia projektu. Szczególne znaczenie ma dostęp do konfiguracji środowiska, dokumentacji API i prawidłowe przekazanie informacji niezbędnych do migracji. Przechowywanie haseł jedynie na prywatnym koncie programisty może doprowadzić do uzależnienia firmy od jednej osoby. Należy przewidzieć bezpieczną procedurę zmiany dostawcy i odebrania dostępów po zakończeniu.

Czy biblioteka open source blokuje sprzedaż oprogramowania?

Samo korzystanie z komponentów open source nie oznacza zakazu sprzedaży systemu. Ważne jest jednak spełnienie konkretnych warunków licencyjnych, które mogą różnić się między bibliotekami i sposobami dystrybucji. Niektóre licencje przewidują określone obowiązki informacyjne lub dotyczące udostępnienia kodu. Klient powinien otrzymać wykaz komponentów wraz z wersjami i licencjami oraz wiedzieć, czy planowany model komercjalizacji jest zgodny z ich warunkami. Wymaga to audytu techniczno-prawnego, a nie ogólnej opinii o „bezpłatnym kodzie”.