Prezes firmy produkcyjnej dostaje od wybranego software house’u wzór umowy na budowę systemu do planowania produkcji. Dwadzieścia cztery strony, porządnie zredagowane, z definicjami i załącznikami. Dział prawny ma tydzień na uwagi, a zarząd chce ruszyć z projektem w przyszłym miesiącu. Na stronie dziewiętnastej jest zdanie: „Z chwilą zapłaty całości wynagrodzenia Zamawiający nabywa niewyłączną licencję na korzystanie z Oprogramowania na potrzeby własne”.
To jedno zdanie oznacza, że po zapłaceniu kilkuset tysięcy złotych firma nie będzie właścicielem kodu, nie będzie mogła zlecić jego rozwoju innemu dostawcy bez zgody autora i nie sprzeda systemu razem ze spółką w taki sposób, w jaki zakładał prezes. Nikt tu nikogo nie oszukuje. Wzór umowy przygotowany przez dostawcę jest po prostu napisany z perspektywy dostawcy: chroni jego kod, ogranicza jego odpowiedzialność i utrudnia odejście klienta. Tak samo wzór przygotowany przez zamawiającego chroniłby zamawiającego.
Ten artykuł jest dla prezesa, dyrektora zakupów albo CTO, który ma przeczytać taką umowę przed podpisaniem. Omawiamy klauzule, które w umowie na oprogramowanie dedykowane decydują o ryzyku zamawiającego: przeniesienie autorskich praw majątkowych i pola eksploatacji, odbiór, SLA i gwarancję, kary umowne, zabezpieczenia dotyczące zespołu, procedurę wyjścia i escrow kodu. Teza brzmi: dobra umowa nie zakłada, że projekt się nie uda, ale sprawia, że gdy coś pójdzie źle, nadal masz kontrolę nad systemem. Jedna uwaga na początek: to nie jest porada prawna. Umowę powinien przejrzeć prawnik znający branżę IT, a ten tekst ma pomóc Ci zadać mu właściwe pytania.
Dlaczego wzór umowy od software house’u chroni głównie software house?
Bo umowa jest przede wszystkim przydziałem ryzyk, a każda strona przydziela je tak, żeby jak najmniej spadło na nią. Dostawca boi się czterech rzeczy: że klient nie odbierze pracy i nie zapłaci, że będzie odpowiadał za szkody nieproporcjonalne do wartości kontraktu, że straci możliwość ponownego użycia własnych komponentów i że klient będzie zmieniał wymagania bez dopłaty. Jego wzór umowy rozwiązuje te cztery problemy starannie i skutecznie.
Zamawiający boi się innych rzeczy: że system będzie opóźniony albo nie będzie działał, że nie będzie mógł go rozwijać bez tego dostawcy, że kluczowi ludzie odejdą w połowie projektu i że przy rozstaniu zostanie z kodem, którego nikt nie rozumie. Wzór dostawcy tych obaw zwykle nie adresuje albo adresuje je ogólnikiem w rodzaju „Wykonawca dołoży należytej staranności”.
Skala ryzyka w projektach IT nie jest teoretyczna. Badanie opublikowane w Harvard Business Review w 2011 roku przez Benta Flyvbjerga i Alexandra Budziera, obejmujące 1471 projektów IT, wykazało, że co szósty projekt przekroczył koszty średnio o 200%, a harmonogram o prawie 70% (HBR, 2011). Umowa nie zmniejsza prawdopodobieństwa takiego scenariusza, ale decyduje o tym, kto poniesie jego skutki i czy da się z niego wyjść.
Praktyczny wniosek jest taki, że negocjacje umowy nie są przeciąganiem liny, tylko wyrównaniem perspektyw. Rzetelny dostawca zaakceptuje większość zapisów chroniących zamawiającego, bo nie ograniczają one jego biznesu, jeśli dobrze wykonuje pracę. Dostawca, który odrzuca przeniesienie praw, dostęp do repozytorium i plan wyjścia, coś Ci w ten sposób mówi. Dlatego najważniejsze warunki warto pokazać już w zapytaniu ofertowym, o czym piszemy w artykule o zapytaniu ofertowym na oprogramowanie dedykowane, a nie dopiero po wyborze.
Przeniesienie praw autorskich czy licencja: co musisz dostać?
To pierwsza i najważniejsza decyzja. Program komputerowy jest w polskim prawie chroniony jak utwór literacki (art. 74 ustawy o prawie autorskim i prawach pokrewnych), a autorskie prawa majątkowe do niego mogą przejść na zamawiającego tylko na podstawie umowy. Zapłata, faktura i protokół odbioru nie wystarczą.
Trzy przepisy ustawy trzeba znać przed negocjacjami (tekst ustawy w ISAP):
- Art. 53: umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. E-mail z akceptacją nie wystarczy; wystarczy podpis odręczny albo kwalifikowany podpis elektroniczny.
- Art. 41 ust. 2 i 4: umowa obejmuje tylko pola eksploatacji wyraźnie w niej wymienione i tylko te, które były znane w chwili jej zawarcia. Ogólne „przenosimy wszelkie prawa” nie działa tak, jak się wydaje.
- Art. 46: jeśli umowa nie stanowi inaczej, twórca zachowuje wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego, nawet gdy przeniesiono całość praw majątkowych. W praktyce oznacza to, że bez wyraźnego zapisu możesz mieć problem z legalnym korzystaniem z opracowań, czyli zmodyfikowanych wersji kodu stworzonych przez kogoś innego.
Licencja nie jest z natury zła. Ma sens, gdy dostawca dostarcza własny produkt albo platformę, którą sprzedaje wielu klientom, i dobudowuje do niej moduły dla Ciebie. Wtedy żądanie przeniesienia praw do całości jest nierealne, a rozsądny układ to licencja na produkt i przeniesienie praw do tego, co powstało wyłącznie dla Ciebie. Ale w projekcie, w którym płacisz za zbudowanie systemu od podstaw, licencja niewyłączna oznacza, że dostawca może sprzedać ten sam kod Twojemu konkurentowi, a Ty nie możesz swobodnie przekazać go nowemu zespołowi.
W umowie powinny się znaleźć cztery elementy. Po pierwsze, przeniesienie autorskich praw majątkowych do kodu źródłowego, wynikowego, dokumentacji i innych utworów powstałych w projekcie. Po drugie, moment przejścia praw, najlepiej z chwilą zapłaty za dany etap, a nie dopiero za całość, bo jeśli projekt zostanie przerwany po trzecim etapie, chcesz mieć prawa do tego, za co zapłaciłeś. Po trzecie, zezwolenie na wykonywanie praw zależnych i przeniesienie tego uprawnienia na zamawiającego, w tym prawo do dalszego przenoszenia. Po czwarte, wynagrodzenie za przeniesienie praw jako część ceny, żeby nie było później sporu, czy przeniesienie było odpłatne.
Starsze, szersze omówienie zasad własności intelektualnej w IT znajdziesz w artykule kto jest właścicielem kodu. Tu skupiamy się na tym, co wpisać do umowy z software house’em.
Jak zapisać pola eksploatacji dla oprogramowania?
Ustawa wymienia dla programów komputerowych trzy grupy uprawnień (art. 74 ust. 4): trwałe lub czasowe zwielokrotnienie programu, jego tłumaczenie, przystosowywanie, zmianę układu i inne zmiany oraz rozpowszechnianie, w tym użyczenie lub najem. Dobra umowa nie poprzestaje na zacytowaniu tego przepisu, tylko opisuje sposoby korzystania, które mają znaczenie dla Twojego biznesu.
Lista pól eksploatacji dla systemu biznesowego zwykle obejmuje:
- utrwalanie i zwielokrotnianie kodu źródłowego i wynikowego dowolną techniką, w tym w pamięci komputerów, na serwerach i w chmurze;
- wprowadzanie do pamięci, uruchamianie, wyświetlanie, przekazywanie i przechowywanie;
- tłumaczenie, przystosowywanie, zmianę układu, modyfikowanie, rozwijanie i łączenie z innym oprogramowaniem, samodzielnie lub przez podmioty trzecie;
- rozpowszechnianie, w tym wprowadzanie do obrotu, użyczanie, najem i dzierżawę;
- udostępnianie w taki sposób, aby każdy mógł mieć dostęp w miejscu i czasie przez siebie wybranym, w tym w modelu SaaS;
- udzielanie licencji i sublicencji osobom trzecim, w tym spółkom z grupy;
- korzystanie z dokumentacji, projektów graficznych i treści w tym samym zakresie.
Dwa pola najczęściej brakują w umowach i najczęściej okazują się potrzebne. Pierwsze to modyfikowanie i rozwijanie przez podmioty trzecie, bez którego trudno legalnie zmienić dostawcę. Drugie to udostępnianie w modelu SaaS i udzielanie sublicencji, bez którego nie zrobisz z wewnętrznego systemu produktu dla klientów ani nie udostępnisz go spółce zależnej.
Zwróć też uwagę na łańcuch praw. Art. 74 ust. 3 przyznaje pracodawcy prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy, jeśli umowa nie stanowi inaczej. Ale wielu programistów w software house’ach pracuje na kontraktach B2B, a nie na umowie o pracę, i ten przepis ich nie obejmuje. Dostawca może przenieść na Ciebie tylko te prawa, które sam nabył. Poproś o oświadczenie i zapewnienie, że wszyscy autorzy, także kontraktorzy i podwykonawcy, przenieśli na dostawcę prawa w zakresie co najmniej takim, jak w Twojej umowie, oraz o zobowiązanie dostawcy do zwolnienia Cię z roszczeń osób trzecich.
Co z open source, bibliotekami dostawcy i kodem generowanym przez AI?
Żaden współczesny system nie powstaje w całości od zera. Kod dostawcy będzie korzystał z bibliotek open source, z wewnętrznych komponentów dostawcy i coraz częściej z kodu wygenerowanego z pomocą asystentów AI. Każda z tych trzech kategorii potrzebuje osobnego zapisu.
Open source. Nie da się przenieść praw do bibliotek, których autorami są osoby trzecie. Umowa powinna więc wyłączyć je z przeniesienia i zobowiązać dostawcę do prowadzenia rejestru komponentów (najlepiej w formie SBOM, czyli zestawienia składników oprogramowania) z ich licencjami. Kluczowe jest też zobowiązanie, że dostawca nie użyje bez Twojej zgody komponentów na licencjach z silnym efektem copyleft, które mogłyby wymagać udostępnienia Twojego kodu, jeśli model dystrybucji systemu na to wpływa.
Komponenty dostawcy. Wiele software house’ów ma własne biblioteki, szablony i moduły, których używa w wielu projektach. Rozsądne jest, żeby zachowały do nich prawa, ale wtedy musisz dostać licencję na te komponenty: bezterminową, nieodwołalną, obejmującą modyfikację i rozwój przez podmioty trzecie, bez dodatkowych opłat. Inaczej odejście od dostawcy oznacza, że część systemu przestaje być legalnie używalna. Poproś o listę takich komponentów w załączniku.
Kod wygenerowany z pomocą AI. Status prawny fragmentów wygenerowanych przez narzędzia AI bez istotnego twórczego wkładu człowieka jest niepewny, a dominujący pogląd jest taki, że ochrona prawnoautorska wymaga twórczego wkładu człowieka. Dla zamawiającego wynikają z tego dwa praktyczne zapisy. Pierwszy: dostawca informuje, czy i jak używa asystentów AI, i ponosi odpowiedzialność za kod niezależnie od tego, jak powstał, w tym za jego zgodność z licencjami i brak naruszeń praw osób trzecich. Drugi: zasady przekazywania Twojego kodu i danych do narzędzi AI, czyli które narzędzia, na jakich warunkach i czy dane mogą trafiać do trenowania modeli. O tym, jakie problemy jakościowe niesie kod pisany z asystentami, piszemy w artykule o audycie kodu z AI.
Jak zdefiniować odbiór, żeby nie stał się polem sporu?
Odbiór to moment, od którego zależą płatność, przejście praw, bieg gwarancji i często kary umowne. Dlatego to najczęstsze źródło sporów. Dobra klauzula odbioru odpowiada na pięć pytań.
Co jest przedmiotem odbioru? Konkretny etap lub przyrost z listą funkcji i kryteriami akceptacji zapisanymi przed rozpoczęciem pracy nad nim. Bez kryteriów odbiór staje się dyskusją o oczekiwaniach.
Jak długo trwają testy akceptacyjne? Konkretna liczba dni roboczych, zwykle od pięciu do dziesięciu dla etapu, z możliwością przedłużenia dla dużych wydań. Dostawca potrzebuje pewności, że nie będzie czekał w nieskończoność; Ty potrzebujesz czasu na rzetelne sprawdzenie.
Co jest wadą, a co zmianą? Wada to niezgodność z kryteriami akceptacji. Zmiana to nowe oczekiwanie. Klasyfikacja wad według krytyczności (blokująca, istotna, drobna) i zasada, że odbiór następuje mimo wad drobnych, z obowiązkiem ich usunięcia w ustalonym terminie, oszczędza wielu kłótni.
Co, jeśli zamawiający milczy? Odbiór dorozumiany po upływie terminu bez zgłoszenia wad chroni dostawcę przed blokowaniem płatności. To uczciwy zapis, ale termin musi być realny dla Twojego zespołu.
Co, jeśli odbiór nie przechodzi kolejny raz? Po drugim lub trzecim negatywnym odbiorze tego samego etapu powinieneś mieć prawo do odstąpienia od umowy w części, obniżenia wynagrodzenia albo powierzenia poprawek osobie trzeciej na koszt dostawcy (wykonanie zastępcze). Bez tego zapisu nieudany etap może się ciągnąć miesiącami.
Jeden zapis zasługuje na osobną uwagę: odbiór nie powinien być warunkiem dostępu do kodu. Kod powinien trafiać do repozytorium w Twojej organizacji na bieżąco, z każdym commitem, niezależnie od odbiorów i płatności. Przejście praw może być powiązane z zapłatą, ale fizyczny dostęp do kodu nie powinien być zakładnikiem sporu.
Jakie SLA i gwarancja mają sens po wdrożeniu?
Gwarancja i SLA to dwie różne rzeczy, często mylone w umowach. Gwarancja dotyczy wad w tym, co dostawca dostarczył: przez określony czas usuwa je bezpłatnie. SLA (umowa o poziomie usług) dotyczy utrzymania i wsparcia: określa, jak szybko dostawca reaguje na zgłoszenia i jaką dostępność systemu zapewnia, zwykle za stałą opłatą lub w ramach abonamentu.
Gwarancja. Typowy okres to od trzech do dwunastu miesięcy od odbioru etapu lub całości. Ważniejsze od długości są szczegóły: od kiedy liczy się okres (od odbioru każdego etapu czy od odbioru końcowego), czy obejmuje wady ujawnione w środowisku produkcyjnym, jakie są czasy usunięcia według krytyczności i czy gwarancja wygasa, gdy system modyfikuje ktoś inny. Ostatni zapis jest uzasadniony w odniesieniu do zmodyfikowanych części, ale nie powinien unieważniać gwarancji na cały system.
SLA. Dobrze napisane SLA ma cztery elementy:
- klasyfikację zgłoszeń z jednoznacznymi definicjami (krytyczne: system lub kluczowy proces nie działa; wysokie: istotna funkcja nie działa, istnieje obejście; normalne; niskie);
- czasy reakcji i czasy obejścia lub naprawy dla każdej klasy, z rozróżnieniem godzin pracy i trybu całodobowego;
- sposób pomiaru, czyli w jakim narzędziu, kto zgłasza, od kiedy liczy się czas i jak raportowane są wyniki co miesiąc;
- konsekwencje niedotrzymania, zwykle w formie obniżki opłaty abonamentowej (service credits) albo kar umownych, a przy powtarzających się naruszeniach prawo do wypowiedzenia.
Najczęstszy błąd to SLA, które mierzy tylko czas reakcji. Odpowiedź „przyjęliśmy zgłoszenie” w piętnaście minut niczego nie naprawia. Liczy się czas przywrócenia działania, choćby przez obejście. Drugi błąd to dostępność systemu zapisana jako procent bez wskazania, co jest liczone (cały system czy kluczowe procesy), w jakim okresie i czy prace planowane są wyłączone. 99,5% miesięcznie to około 3,6 godziny niedostępności w miesiącu; 99,9% to około 43 minuty. Różnica w koszcie infrastruktury i dyżurów jest duża, więc wybierz poziom, którego biznes naprawdę potrzebuje.
Jak ustawić kary umowne, żeby działały, a nie tylko straszyły?
Kara umowna to w polskim prawie zryczałtowane odszkodowanie za niewykonanie lub nienależyte wykonanie zobowiązania niepieniężnego (art. 483 Kodeksu cywilnego). Jej zaleta jest taka, że nie musisz wykazywać wysokości szkody. Ale kary w umowach IT często są napisane tak, że albo nie działają, albo dostawca i tak przerzuca je w cenę.
Pięć zasad pomaga zapisać je rozsądnie.
Wiąż karę z mierzalnym zdarzeniem. Opóźnienie w osiągnięciu kamienia milowego z przyczyn leżących po stronie dostawcy, niedotrzymanie czasu naprawy w SLA, naruszenie poufności, nieuprawniona zmiana kluczowego członka zespołu. Kara za „nienależyte wykonanie umowy” bez definicji zachęca do sporu, a nie do lepszej pracy.
Rozróżnij przyczyny opóźnień. W projektach IT część opóźnień wynika z braku decyzji, danych albo dostępów po stronie zamawiającego. Kara powinna dotyczyć opóźnień z winy dostawcy, a umowa powinna przewidywać przesunięcie terminów, gdy zamawiający nie wywiązuje się ze swoich obowiązków. Inaczej kara jest nieegzekwowalna w praktyce.
Ustal limit. Łączny limit kar, na przykład jako procent wartości umowy, jest standardem. Kary bez limitu są dla dostawcy ryzykiem nie do wyceny, więc albo podniesie cenę, albo nie podpisze umowy. Poza tym Kodeks cywilny przewiduje, że dłużnik może żądać zmniejszenia kary, jeśli zobowiązanie zostało w znacznej części wykonane albo gdy kara jest rażąco wygórowana (art. 484 § 2 k.c.). Sąd może ją więc zmniejszyć, a Ty tracisz przewidywalność.
Zastrzeż odszkodowanie uzupełniające. Domyślnie kara umowna zastępuje odszkodowanie i nie możesz żądać więcej, chyba że umowa stanowi inaczej (art. 484 § 1 k.c.). Jeśli realna szkoda może przekroczyć karę, zapisz prawo do dochodzenia odszkodowania przenoszącego wysokość kary.
Uzgodnij ograniczenie odpowiedzialności świadomie. Wzory dostawców prawie zawsze ograniczają odpowiedzialność do wartości umowy albo wynagrodzenia z ostatnich miesięcy i wyłączają utracone korzyści. To rynkowy standard, ale wyjątki od limitu powinny obejmować co najmniej szkody wyrządzone umyślnie, naruszenie poufności i ochrony danych osobowych oraz roszczenia osób trzecich dotyczące naruszenia praw autorskich.
Kara umowna nie zastąpi dobrego zarządzania projektem. Jej rolą jest ustawienie zachęt i ochrona w sytuacji skrajnej. Jeśli w trakcie projektu dochodzi do naliczania kar, współpraca zwykle jest już w kryzysie, a wtedy ważniejsza od kary jest możliwość wyjścia.
Jak zabezpieczyć się przed odejściem kluczowych osób i podwykonawcami?
W oprogramowaniu dedykowanym kupujesz w praktyce pracę konkretnych ludzi. Jeśli architekt, który zaprojektował system, odchodzi w trzecim miesiącu, a jego następca potrzebuje kilku tygodni na wdrożenie, płacisz za to opóźnieniem. Umowa może to ryzyko ograniczyć.
Lista kluczowego personelu. Załącznik z nazwanymi osobami w kluczowych rolach (architekt, lider techniczny, kierownik projektu) i zobowiązanie, że dostawca nie zmieni ich bez Twojej zgody, poza sytuacjami od niego niezależnymi, takimi jak rozwiązanie współpracy przez samego specjalistę czy choroba.
Zastępstwo i przekazanie. Gdy zmiana jest konieczna, termin przedstawienia kandydata o porównywalnych kwalifikacjach, Twoje prawo do odrzucenia kandydata i okres nakładania się osób, w którym dostawca nie fakturuje nowej osoby albo fakturuje ją z rabatem.
Prawo do żądania zmiany. Ty też powinieneś móc zażądać wymiany członka zespołu, który nie spełnia oczekiwań, z uzasadnieniem i w określonym terminie.
Podwykonawcy. Zgoda zamawiającego na podwykonawców, odpowiedzialność dostawcy za ich działania jak za własne, te same wymagania co do poufności, bezpieczeństwa i przeniesienia praw. Pytanie o podwykonawców warto zadać wprost, bo w wielu firmach część zespołu to kontraktorzy z zewnątrz.
Zakaz przejmowania pracowników. Wzory dostawców zawierają zwykle zakaz zatrudniania ich specjalistów przez klienta. To zrozumiałe, ale warto negocjować jego czas trwania i wyjątki: możliwość przejęcia osoby po określonym czasie za ustaloną opłatą, co bywa najprostszym sposobem na zachowanie wiedzy przy przejęciu rozwoju do własnego zespołu.
Dla porównania, jak takie zapisy wyglądają w praktyce u nas: w modelach rozliczeń opisanych w naszym cenniku obowiązuje dwutygodniowa gwarancja satysfakcji z bezpłatną wymianą specjalisty, który nie spełnił oczekiwań, a w razie odejścia specjalisty w trakcie współpracy gwarantujemy zastępstwo w ciągu pięciu dni roboczych. Umowy można rozwiązać z 30-dniowym wypowiedzeniem, bez kar za rozwiązanie. Takie warunki warto mieć na piśmie u każdego dostawcy, niezależnie od tego, kogo wybierzesz.
Jak zaprojektować procedurę wyjścia i przekazania?
Procedura wyjścia to klauzula, o której nikt nie chce rozmawiać na starcie, a która ma największe znaczenie, gdy współpraca się kończy, dobrze lub źle. Jej celem jest jedno: żebyś mógł przekazać system innemu zespołowi bez utraty ciągłości działania i bez renegocjowania warunków z pozycji słabszej strony. Szerzej o tym, jak uniknąć uzależnienia od jednego dostawcy, piszemy w artykule o vendor lock-in.
Dobra klauzula wyjścia ma sześć elementów.
Ciągły dostęp zamiast przekazania na końcu. Repozytorium kodu, system zgłoszeń, dokumentacja, pipeline CI/CD i konta w chmurze w Twojej organizacji od pierwszego dnia, z dostawcą jako użytkownikiem. Jeśli przez cały projekt wszystko jest u Ciebie, wyjście jest w dużej części formalnością.
Okres wypowiedzenia dopasowany do przekazania. Zbyt krótki uniemożliwia uporządkowane przejęcie; zbyt długi zamyka Cię w współpracy, która już nie działa. Typowo od jednego do trzech miesięcy, z prawem do natychmiastowego rozwiązania przy istotnym naruszeniu.
Lista rzeczy do przekazania. Kod źródłowy wszystkich komponentów, konfiguracje, skrypty wdrożeniowe, infrastruktura jako kod, dokumentacja architektury i API, dane w uzgodnionym formacie, dostępy i hasła, lista otwartych zgłoszeń i znanych problemów, lista komponentów zewnętrznych z licencjami.
Przekazanie wiedzy. Określona liczba godzin warsztatów i konsultacji z nowym zespołem, po ustalonej z góry stawce, w okresie przejściowym. Bez tego zapisu przekazanie wiedzy staje się przedmiotem negocjacji w najgorszym możliwym momencie.
Współpraca z nowym dostawcą. Zobowiązanie do odpowiadania na pytania i udziału w przekazaniu w dobrej wierze, także wtedy, gdy nowy dostawca jest konkurentem.
Brak prawa zatrzymania. Dostawca nie może wstrzymywać przekazania kodu i dokumentacji z powodu sporu o płatności, przynajmniej w odniesieniu do etapów już opłaconych. Spór o pieniądze rozstrzyga się osobno.
Warto też zapisać prawo zamawiającego do zlecenia niezależnego przeglądu kodu w trakcie projektu. Audyt na zakończenie albo w punkcie zwrotnym projektu pozwala ocenić, co dokładnie przejmujesz. U nas taki audyt kondycji kodu trwa od tygodnia do dwóch, ma stały zakres i kosztuje od 18 000 PLN, a gdy system wymaga stabilizacji po zmianie dostawcy, możemy kontynuować w ramach Software Rescue.
Kiedy escrow kodu źródłowego ma sens?
Escrow kodu źródłowego to umowa trójstronna: dostawca deponuje kod u niezależnego agenta, a agent wydaje go klientowi, gdy zajdzie określone zdarzenie, na przykład upadłość dostawcy albo zaprzestanie wsparcia. Bywa przedstawiany jako uniwersalne zabezpieczenie, ale w oprogramowaniu dedykowanym często jest zbędny.
Jeśli kod od pierwszego dnia trafia do repozytorium w Twojej organizacji, prawa są przeniesione, a dokumentacja i infrastruktura jako kod są aktualizowane na bieżąco, escrow niczego nie dodaje. Masz już wszystko, co agent mógłby Ci wydać, i to w bieżącej wersji.
Escrow ma sens w trzech sytuacjach. Po pierwsze, gdy dostawca licencjonuje Ci własny produkt albo platformę, na której zbudowano Twój system, i nie dostajesz jej kodu. Po drugie, gdy system jest krytyczny dla biznesu, a dostawca jest małą firmą, której ciągłość działania trudno ocenić. Po trzecie, gdy kod jest dostarczany w wydaniach, a nie na bieżąco, na przykład w niektórych systemach przemysłowych albo w oprogramowaniu wbudowanym.
Jeśli decydujesz się na escrow, sprawdź cztery rzeczy: jak często dostawca aktualizuje depozyt (depozyt sprzed roku jest mało wart), czy agent weryfikuje, że da się z niego zbudować działający system, jakie dokładnie zdarzenia uprawniają do wydania kodu i jakie prawa do korzystania z wydanego kodu dostajesz. Bez licencji na modyfikację wydany kod jest tylko plikiem.
Jak wygląda lista kontrolna klauzul przed podpisaniem?
Poniższa tabela zbiera klauzule omówione wyżej. Kolumna „minimum” to poziom, poniżej którego warto się zatrzymać i zapytać dostawcę o powody. Kolumna „sygnał ostrzegawczy” pokazuje zapisy, które często pojawiają się we wzorach dostawców.
| Obszar | Minimum dla zamawiającego | Sygnał ostrzegawczy we wzorze |
|---|---|---|
| Prawa autorskie | Pisemne przeniesienie praw majątkowych z chwilą zapłaty za etap, z prawami zależnymi | Licencja niewyłączna, przejście praw dopiero po zapłacie całości |
| Pola eksploatacji | Wyliczone, w tym modyfikacja przez podmioty trzecie, SaaS i sublicencje | „Wszelkie prawa” bez wyliczenia pól |
| Łańcuch praw | Zapewnienie, że wszyscy autorzy, także kontraktorzy B2B, przenieśli prawa na dostawcę | Brak zapisu o podwykonawcach i kontraktorach |
| Komponenty i open source | Rejestr komponentów z licencjami, licencja bezterminowa na komponenty dostawcy | „Narzędzia Wykonawcy” bez listy i bez licencji |
| Odbiór | Kryteria akceptacji, termin testów, klasyfikacja wad, skutki kolejnych negatywnych odbiorów | Odbiór według uznania dostawcy albo bez terminu |
| Gwarancja i SLA | Czas naprawy według krytyczności, sposób pomiaru, konsekwencje naruszeń | Tylko czas reakcji, dostępność bez definicji |
| Kary umowne | Powiązane z mierzalnym zdarzeniem, limit, odszkodowanie uzupełniające | Brak kar albo kary symboliczne przy wysokich karach dla klienta |
| Odpowiedzialność | Limit z wyjątkami: wina umyślna, poufność, dane osobowe, naruszenie praw autorskich | Limit do wynagrodzenia z jednego miesiąca, bez wyjątków |
| Zespół | Lista kluczowego personelu, zasady zastępstwa, zgoda na podwykonawców | „Odpowiednio wykwalifikowany personel” |
| Dostęp do kodu | Repozytorium u zamawiającego od pierwszego dnia | Przekazanie kodu po odbiorze końcowym |
| Wyjście | Lista rzeczy do przekazania, godziny transferu wiedzy po ustalonej stawce, brak prawa zatrzymania | Brak klauzuli albo przekazanie „na warunkach do uzgodnienia” |
| Escrow | Tylko przy licencjonowanym produkcie lub krytycznym systemie bez bieżącego dostępu do kodu | Escrow zamiast przeniesienia praw w projekcie budowanym od zera |
Jeśli w umowie, którą masz przed sobą, trzy lub więcej obszarów wypada w prawej kolumnie, nie podpisuj jej w tej wersji. To nie znaczy, że dostawca jest nieuczciwy. Znaczy, że umowa jest jego wzorem i jeszcze nie była negocjowana.
Które zapisy warto odpuścić, a o które walczyć do końca?
Negocjacje umowy mają koszt: czas, relację z dostawcą i często cenę. Dostawca, któremu narzucisz wszystkie ryzyka, doliczy je do wynagrodzenia, tak samo jak w ofercie dolicza rezerwę na niejasny zakres. Jak dostawca przekłada ryzyko na cenę, opisujemy w artykule o tym, jak software house wycenia projekt. Dlatego warto wiedzieć, gdzie ustąpić.
O to walcz do końca: przeniesienie praw autorskich z polami eksploatacji obejmującymi modyfikację przez podmioty trzecie, dostęp do repozytorium od pierwszego dnia, klauzula wyjścia z listą rzeczy do przekazania i brakiem prawa zatrzymania, łańcuch praw od kontraktorów oraz wyjątki od limitu odpowiedzialności dla naruszenia praw autorskich i danych osobowych. To zapisy, bez których tracisz kontrolę nad systemem, i rzetelny dostawca nie ma powodu, żeby ich odmówić.
O to negocjuj rozsądnie: wysokość i limit kar umownych, długość gwarancji, czasy w SLA, okres wypowiedzenia, zakaz przejmowania pracowników. Tu istnieje realna wymiana: wyższe kary i krótsze czasy naprawy oznaczają wyższą cenę, a dostawca ma uzasadnione powody, żeby się bronić.
To możesz odpuścić: zachowanie przez dostawcę praw do jego ogólnych komponentów (pod warunkiem dobrej licencji dla Ciebie), ograniczenie odpowiedzialności za utracone korzyści, odbiór dorozumiany przy realnym terminie, rozsądny zakaz przejmowania pracowników. Te zapisy chronią uzasadnione interesy dostawcy i ich odrzucanie zwykle kosztuje więcej, niż daje.
Jeśli projekt startuje w modelu stałej ceny, w umowie powinna się też znaleźć procedura zmian: kto zgłasza zmianę, kto ją wycenia, po jakich stawkach i w jakim czasie. Model rozliczeń i to, kto ponosi koszt niepewności, omawiamy w artykule abonament zespołu, time & materials czy fixed price.
Jakie są kluczowe wnioski?
Umowa z software house’em nie zabezpiecza przed nieudanym projektem, ale decyduje, czy po nieudanym projekcie nadal masz system, kod i możliwość pójścia dalej z kimś innym. Wzór od dostawcy jest punktem wyjścia do negocjacji, nie dokumentem do podpisu.
Zapamiętaj sześć rzeczy. Po pierwsze, prawa autorskie nie przechodzą z zapłatą: potrzebujesz pisemnej umowy z wyliczonymi polami eksploatacji (art. 41 i 53 ustawy o prawie autorskim) i zezwoleniem na prawa zależne (art. 46). Po drugie, sprawdź łańcuch praw, bo przepis o programach tworzonych przez pracowników nie obejmuje kontraktorów B2B. Po trzecie, odbiór opisz kryteriami akceptacji, terminem testów i skutkami kolejnych negatywnych odbiorów, a dostęp do kodu oddziel od odbioru. Po czwarte, SLA mierz czasem przywrócenia działania, a nie tylko czasem reakcji. Po piąte, kary umowne wiąż z mierzalnymi zdarzeniami, z limitem i odszkodowaniem uzupełniającym, bo kara rażąco wygórowana może zostać zmniejszona przez sąd. Po szóste, procedurę wyjścia zaprojektuj tak, żeby przez cały projekt wszystko było u Ciebie, a escrow stosuj tylko tam, gdzie nie masz bieżącego dostępu do kodu.
Jeśli przygotowujesz umowę na tworzenie oprogramowania na zamówienie i chcesz porozmawiać o tym, jak wyglądają te zapisy u nas, albo przejmujesz system od dostawcy, z którym umowa nie przewidziała wyjścia, umów rozmowę. Powiemy wprost, które zapisy przyjmujemy bez dyskusji, a które warto omówić, i co zrobić, jeśli kod już jest poza Twoją kontrolą.