Zamawiasz oprogramowanie na zamówienie czy SaaS?

Ramy decyzyjne: kupujesz rezultat czy usługę

Pierwsze pytanie nie jest prawne, lecz operacyjne. Oprogramowanie na zamówienie oznacza, że płacisz za stworzenie czegoś, co dotąd nie istniało, i chcesz to zatrzymać. SaaS oznacza, że wynajmujesz dostęp do gotowego rozwiązania, które dostawca utrzymuje i rozwija dla wszystkich klientów.

Różnica ma trzy praktyczne konsekwencje. Przy tworzeniu na zamówienie gra toczy się o prawa do kodu i dokumentację, przy SaaS o dostępność, dane i warunki wyjścia. Przy tworzeniu oprogramowania jesteś narażony w momencie przekazania, przy SaaS przez cały okres eksploatacji. A przy tworzeniu największym ryzykiem jest to, że otrzymasz coś, czego nikt inny nie potrafi przejąć, przy SaaS – że dostawca jednostronnie zmieni warunki.

Większość rzeczywistych projektów to hybryda: gotowa platforma plus dostosowania na zamówienie, i właśnie przy tych dostosowaniach okazuje się, że umowa reguluje tylko jedną z obu części. Praktycznym rozwiązaniem jest opisanie obu warstw oddzielnie i określenie dla każdej z osobna, kto posiada prawa, kto odpowiada za funkcjonalność i co obowiązuje po zakończeniu umowy. Warstwie operacyjnej SaaS poświęcamy szczegółowo artykuł Umowne zabezpieczenie dostępności i jakości usług chmurowych (SLA).

Czwartym wariantem, na który firmy natrafiają dopiero później, jest tworzenie oprogramowania z wykorzystaniem narzędzi generatywnych. Kluczowe jest tu ustalenie, przy użyciu czego dostawca tworzył kod, ponieważ wpływa to na to, co faktycznie może ci przekazać. Tę kwestię omawiamy w artykule Tworzenie oprogramowania z wykorzystaniem sztucznej inteligencji – do kogo należy kod.

Postępowanie krok po kroku

Kolejność kroków odpowiada fazom negocjacji. Kto je pominie, zapłaci za to w trakcie eksploatacji.

Pierwszym krokiem jest opisanie rezultatu tak, aby dało się go zmierzyć. Do specyfikacji należą funkcje, parametry wydajnościowe i scenariusze, na których będą prowadzone testy. Sformułowanie typu „system będzie przyjazny dla użytkownika” nie obroni się w protokole odbioru, sformułowanie „czas odpowiedzi do dwóch sekund przy pięćdziesięciu jednoczesnych użytkownikach” się obroni.

Drugim krokiem jest uregulowanie praw do kodu, i to na piśmie oraz przed podpisaniem umowy głównej. Zdecyduj, czy potrzebujesz wykonywać majątkowe prawa autorskie do kodu, czy wystarczy ci odpowiednio szeroka licencja, a jeśli licencja, to w jakim zakresie: na ilu użytkowników, na ile instalacji, z prawem przekazania kodu osobie trzeciej, która będzie rozwijać system zamiast dostawcy.

Trzecim krokiem jest odbiór. Do umowy należy wpisać, kto przeprowadza test, jak długo trwa, co się dzieje w razie częściowej awarii i kiedy dzieło uważa się za przyjęte nawet bez podpisu. Bez tego powstaje spór o to, czy dzieło zostało ukończone i przekazane oraz czy odpowiednia część ceny jest wymagalna. Ustawa nie przewiduje podpisania protokołu jako warunku zapłaty, ale umowa może zapłatę od niego uzależnić.

Czwartym krokiem jest eksploatacja: dostępność, czasy reakcji, okna serwisowe i sankcje za ich nieprzestrzeganie. Tu opłaca się ustalić sankcje jako automatyczne kredyty, a nie jako odszkodowanie, które zamawiający musiałby udowadniać.

Piątym krokiem jest zabezpieczenie na wypadek, gdyby dostawca zakończył działalność. Klasycznym narzędziem jest depozyt kodu źródłowego u osoby trzeciej ze zdefiniowanymi warunkami wydania. Depozyt bez aktualnej dokumentacji jest bezużyteczny, dlatego do umowy należy wpisać obowiązek deponowania również dokumentacji i aktualnego buildu.

Szóstym krokiem jest exit. Do umowy należy wpisać format, w jakim otrzymasz dane, termin ich wydania, okres współpracy po zakończeniu umowy i cenę za asystę przy migracji. Przy oprogramowaniu na zamówienie exit jest wyłącznie kwestią umowy, a bez uzgodnionej ceny staje się negocjacjami pod presją.

W przypadku usług chmurowych i SaaS o exicie nie decyduje już jednak wyłącznie umowa. Od 12 września 2025 stosuje się rozdział VI unijnego rozporządzenia w sprawie danych (Data Act), który nakłada na dostawców usług przetwarzania danych obowiązek usuwania przeszkód w przejściu do innego dostawcy i umożliwienia eksportu danych. Opłaty za zmianę dostawcy są przejściowo ograniczone do kosztów bezpośrednio z nią związanych, a od 12 stycznia 2027 mają zostać całkowicie zniesione. Przy negocjacjach warto więc sprawdzić, czy projekt umowy respektuje te zasady, czy też jest z nimi sprzeczny.

Siódmym krokiem jest proces zmian. Bez opisanej procedury dla wniosków o zmianę zmiany załatwia się e-mailem, a spór o to, co było wliczone w cenę, jest pewny. Do umowy należy więc wpisać, kto zatwierdza zmianę, w jakim terminie dostawca przedstawia wycenę pracochłonności i co dzieje się z terminem, jeśli zamawiający wyceny nie zatwierdzi.

Co jest standardem rynkowym, a co sygnałem ostrzegawczym

W zdrowych projektach normą jest, że cena za stworzenie oprogramowania jest podzielona na etapy powiązane z odbiorami częściowymi, a ostatnią część płaci się dopiero po przyjęciu do eksploatacji. Normą jest również, że dostawca odpowiada za wady w okresie gwarancji i równolegle świadczy płatne wsparcie – to dwie różne rzeczy, których nie należy łączyć w jedną.

W przypadku SaaS standardem jest dostępność określona jedną liczbą miesięcznie, definicja planowanej przerwy, która nie wlicza się do dostępności, oraz kredyty za nieprzestrzeganie. Standardem jest także to, że dostawca może zmieniać funkcje, ale nie obniżać uzgodnionego poziomu usługi, i że o zmianie informuje z wyprzedzeniem.

Sygnały ostrzegawcze są trzy i rozpoznasz je od razu przy lekturze projektu umowy. Pierwszym jest umowa, która nie zawiera ani słowa o kodzie źródłowym ani o dokumentacji, ponieważ oznacza to, że przejęcie systemu przez innego dostawcę nie będzie technicznie możliwe. Drugim jest odpowiedzialność dostawcy ograniczona do wysokości miesięcznej opłaty, co przy rocznej eksploatacji oznacza, że praktycznie nie odpowiada za wyrządzoną szkodę.

Trzecim sygnałem ostrzegawczym jest powiązanie danych z formatem, którego nigdzie indziej nie odczytasz. Sformułowanie „dane zostaną wydane w formacie używanym przez dostawcę” oznacza w praktyce eksport, za którego przetworzenie zapłacisz dwa razy. Tak samo należy czytać postanowienia o przetwarzaniu danych osobowych; poświęcamy im artykuł Platforma SaaS w UE.

Gdzie przebiega granica prawna

Regulacja ustawowa jest w przypadku oprogramowania surowsza, niż firmy oczekują, a w jednym punkcie przeciwnie – bardziej przychylna.

Zgodnie z § 58 ust. 7 czeskiej ustawy o prawie autorskim (dalej „ustawa o prawie autorskim”) programy komputerowe i bazy danych uważa się za utwory pracownicze również wtedy, gdy zostały stworzone przez autora na zamówienie, a zamawiającego uważa się w takim przypadku za pracodawcę. Oznacza to, że w przypadku programisty-freelancera, który napisał kod na twoje zamówienie, prawa majątkowe wykonujesz ty, jeśli nie uzgodniono inaczej.

Sytuacja zmienia się jednak, gdy dostawcą jest firma programistyczna. Jeśli kod piszą jej pracownicy, prawa majątkowe na podstawie tego samego przepisu wykonuje ona jako pracodawca, a na ciebie prawa przechodzą tylko w zakresie określonym w umowie.

W praktyce dostawca często łączy ponadto pracę pracowników, współpracowników zewnętrznych, podwykonawców, bibliotek open source i komponentów osób trzecich, dlatego trzeba zweryfikować cały łańcuch uprawnień, a nie tylko oświadczenie dostawcy. Również w przypadku programisty-freelancera do umowy należy więc wpisać przekazanie kodu źródłowego, dokumentacji, uprawnienie do modyfikacji oraz wykaz użytych komponentów osób trzecich.

W odniesieniu do utworów, których ta zasada nie obejmuje, zgodnie z § 61 ustawy o prawie autorskim autor udzielił licencji tylko w celu wynikającym z umowy. Korzystanie wykraczające poza te ramy wymaga umowy licencyjnej. W przypadku grafiki, tekstów lub projektów interfejsu dostarczonych wraz z oprogramowaniem jest to często pomijany szczegół.

Sama umowa licencyjna ma ustawowe minimum. Zgodnie z § 2358 czeskiego Kodeksu cywilnego (ustawa nr 89/2012 Sb., dalej „k.c.”) licencjodawca udziela licencji w uzgodnionym ograniczonym lub nieograniczonym zakresie, a licencjobiorca zobowiązuje się zapłacić wynagrodzenie, jeśli nie uzgodniono inaczej; formy pisemnej umowa wymaga w przypadku licencji wyłącznej. Zakres trzeba więc opisać, inaczej będzie przedmiotem sporu.

Na exit wpływa również zasada dotycząca przeniesienia licencji. Zgodnie z § 2364 k.c. licencjobiorca może przenieść licencję na osobę trzecią tylko za zgodą licencjodawcy, która wymaga formy pisemnej. W przypadku zbycia przedsiębiorstwa lub jego samodzielnej części zgoda jest zgodnie z § 2365 wymagana tylko wtedy, gdy zostało to wyraźnie uzgodnione. Kto planuje sprzedaż firmy lub wydzielenie działu, powinien rozwiązać tę kwestię już przy podpisywaniu umowy IT.

Przy odbiorze stosuje się następnie przepisy o dziele. Zgodnie z § 2610 k.c. prawo do zapłaty ceny dzieła powstaje z chwilą jego wykonania, a jeśli dzieło jest odbierane częściami, prawo do zapłaty za każdą część powstaje z chwilą jej wykonania. Zgodnie z § 2605 dzieło jest przy tym ukończone, jeśli wykazano jego zdolność do służenia swojemu celowi, a jeśli zamawiający przejmie dzieło bez zastrzeżeń, sąd nie przyzna mu prawa z tytułu wady jawnej, jeżeli dostawca podniesie zarzut spóźnionego zgłoszenia. Podpisanie protokołu odbioru nie jest więc ustawowym warunkiem powstania roszczenia o cenę, ale umowa może uzależnić od niego wymagalność, i dlatego negocjuje się jego kształt.

Ostatnią granicę stanowi ograniczenie odpowiedzialności. Zgodnie z § 2898 k.c. nie uwzględnia się postanowienia, które z góry wyłącza lub ogranicza obowiązek naprawienia szkody wyrządzonej człowiekowi w jego dobrach osobistych albo wyrządzonej umyślnie lub wskutek rażącego niedbalstwa. Uzgodniony limit odpowiedzialności nie obejmuje więc tych przypadków, niezależnie od tego, jak strony go ustalą.

Podsumowanie końcowe

Umowę IT należy pisać od końca. Najpierw odpowiedz sobie, co musisz mieć w ręku w dniu, w którym zakończysz współpracę z dostawcą: kod źródłowy, dokumentację, dane w użytecznym formacie i kogoś, kto przejmie system. Dopiero potem zajmij się ceną i terminami. Kryteria odbioru sformułuj w sposób mierzalny, exit opisz łącznie z ceną za asystę, a proces zmian wprowadź od samego początku.

Granica prawna jest przy tym w jednym punkcie korzystniejsza, niż firmy przypuszczają, a w innym surowsza. W przypadku programisty działającego na zamówienie prawa majątkowe wykonujesz ty, w przypadku firmy programistycznej masz je tylko w zakresie uzgodnionym w umowie. Kancelaria adwokacka ARROWS jest ubezpieczona od odpowiedzialności zawodowej z limitem 350 000 000 CZK (ok. 14,4 mln EUR) i negocjuje umowy IT w ramach usługi Prawo IT i oprogramowania, cyberbezpieczeństwo. Napisz na konsultacja@arws.cz.