Cel zleceniodawcy – co chcesz realnie zabezpieczyć
Zleceniodawca, który angażuje software house, ma trzy główne cele: uzyskać działający system, mieć prawo do korzystania i dalszego rozwijania oprogramowania oraz ograniczyć ryzyka sporów i uzależnienia od jednego dostawcy.
Umowa z software house powinna więc zabezpieczać nie tylko termin i budżet, ale przede wszystkim prawa autorskie do oprogramowania, zasady licencjonowania oraz dostęp do kodu źródłowego i dokumentacji.
Kontekst współpracy z software house’em – o jakie ryzyka chodzi
Projekt szyty na miarę a produkt pudełkowy
W relacjach z software house’ami można wyróżnić dwa skrajne modele: tworzenie oprogramowania „pod klienta” oraz licencjonowanie gotowego produktu (tzw. pudełkowego lub SaaS).
W pierwszym modelu zamawiasz dedykowany system, np. specyficzny CRM, platformę B2B czy aplikację produkcyjną. Takie oprogramowanie jest ściśle dopasowane do procesów w firmie i często stanowi element przewagi konkurencyjnej. Ryzyko: bez jasnego uregulowania przeniesienia autorskich praw majątkowych lub właściwej licencji, możesz być tylko „użytkownikiem” bez realnego wpływu na rozwój.
W drugim modelu kupujesz licencję na gotowy produkt (on-premise lub w chmurze). Tu zwykle nie ma opcji przeniesienia praw – dostajesz licencję na określonych warunkach. Ryzyko pojawia się, gdy software house dorabia do tego produktu dedykowane moduły lub integracje i w umowie nie jest rozdzielone, co jest „produktem”, a co „utworem tworzonym na zamówienie”.
Najczęstsze ryzyka po stronie klienta biznesowego
Bez dobrze skonstruowanej umowy z software house może dojść do sytuacji, w której:
klient nie ma praw do kodu, mimo że zapłacił za jego stworzenie,
zakres licencji jest zbyt wąski (np. tylko dla jednej spółki, jednego kraju, bez prawa modyfikacji),
o kluczowych sprawach decydują ogólne warunki umów lub regulamin, którego nikt nie czytał,
brakuje zapisów o przekazaniu kodu źródłowego, dostępu do repozytorium i dokumentacji,
firma jest całkowicie uzależniona od jednego wykonawcy – nie może łatwo zmienić dostawcy lub przenieść rozwoju do wewnętrznego działu IT.
Ryzyka te materializują się zazwyczaj po 1–3 latach, kiedy trzeba większej rozbudowy systemu, zmiany architektury lub migracji do innego dostawcy.
Usługa IT a przeniesienie praw do programu – dwie różne rzeczy
Software house zwykle sprzedaje „usługi IT”: analiza, projektowanie, programowanie, wdrożenie, support. Prawo autorskie traktuje efekt tych usług (program komputerowy, dokumentacja) jako odrębny przedmiot obrotu. To, że płacisz za usługę, nie oznacza jeszcze przejścia autorskich praw majątkowych.
Umowa powinna rozróżniać te dwa poziomy: z jednej strony zakres i rozliczenie usług (dni robocze, sprinty, fixed price), z drugiej – kwestię przeniesienia praw lub udzielenia licencji na oprogramowanie. Brak wyraźnego rozdzielenia kończy się sporami typu „przecież zapłaciłem, więc to jest moje”, na co wykonawca odpowiada „zapłacił Pan za usługę zaprogramowania, nie za pełne prawa”.
Krótki przykład z praktyki
Średnia firma handlowa zleciła budowę systemu B2B do obsługi kontrahentów. Umowa mówiła tylko o „wykonaniu i wdrożeniu systemu” oraz „przekazaniu kodu źródłowego”, ale nie zawierała klauzul o przeniesieniu autorskich praw majątkowych ani o licencji.
Po dwóch latach firma chciała zlecić rozwój systemu innemu software house’owi. Poprosiła o wydanie kodu z repozytorium. Wykonawca odmówił, twierdząc, że kod jest jego własnością, a klient ma jedynie prawo korzystania w formie dostępu do gotowego systemu. Spór skończył się negocjacjami i dodatkowymi kosztami za wykup praw. Taki scenariusz można było wyeliminować jedną, dobrze napisaną sekcją o prawach autorskich i kodzie źródłowym.
Podstawy prawne – co regulują przepisy, a czego nie
Program komputerowy jako utwór
W polskim prawie program komputerowy jest traktowany jako utwór w rozumieniu ustawy o prawie autorskim. To oznacza, że automatycznie – z chwilą stworzenia – powstaje ochrona autorska, bez potrzeby rejestracji.
Ochroną objęty jest przede wszystkim kod źródłowy, ale także dokumentacja techniczna, struktura bazy danych, interfejsy (w określonym zakresie) i inna twórcza część projektu. Sam pomysł na system (np. „portal do obsługi zgłoszeń”) nie jest chroniony, lecz konkretny sposób jego realizacji już tak.
Autorskie prawa majątkowe i osobiste – istotna różnica
Autorskie prawa osobiste są niezbywalne – twórca zawsze pozostaje autorem. Dotyczą m.in. prawa do autorstwa i oznaczenia utworu imieniem i nazwiskiem, integralności utworu czy nadzoru nad sposobem korzystania.
Autorskie prawa majątkowe to prawo do korzystania z utworu i rozporządzania nim na określonych polach eksploatacji oraz prawo do wynagrodzenia. To właśnie one mogą być przenoszone lub licencjonowane. Przy umowie z software house chodzi przede wszystkim o te prawa.
Dlatego w umowie trzeba jasno wskazać, czy następuje przeniesienie autorskich praw majątkowych, czy udzielana jest licencja na oprogramowanie. Bez tego domyślne regulacje nie zapewniają klientowi kontroli nad systemem.
Domyślny stan bez umowy lub przy umowie niedoprecyzowanej
Jeżeli program tworzy pracownik w ramach stosunku pracy, co do zasady autorskie prawa majątkowe przechodzą na pracodawcę w zakresie wynikającym z celu umowy o pracę i zamiaru stron. W relacjach B2B / zlecenie takie domniemanie nie działa.
W modelu współpracy z software house’em, gdzie developerzy są zatrudnieni przez wykonawcę, a nie przez klienta, twórcą jest programista (lub zespół), a prawa majątkowe z reguły przysługują software house’owi. Klient nie staje się „z automatu” właścicielem praw. Bez wyraźnej klauzuli o przeniesieniu praw lub licencji klient zyskuje najwyżej domyślne, wąskie uprawnienie do korzystania z przekazanego mu egzemplarza oprogramowania, co dla biznesu jest dalece niewystarczające.
Dlaczego klauzula „klient ma pełne prawa” nie wystarcza
W prawie autorskim liczą się konkrety. Zapis typu „klient ma pełne prawa do oprogramowania” jest zbyt ogólny. Ustawa wymaga, aby umowa szczegółowo określała pola eksploatacji, na których przenoszone są prawa lub udzielana jest licencja.
Bez katalogu pól eksploatacji przeniesienie praw może zostać uznane za nieważne w tej części lub bardzo ograniczone. Skutek: klient będzie przekonany, że „ma wszystko”, a w razie sporu sąd będzie interpretował umowę wąsko, po stronie twórcy. To najczęstsza pułapka w źle skonstruowanych umowach IT.
Model własności: przeniesienie praw czy licencja – który wariant wybrać
Kiedy dążyć do przeniesienia autorskich praw majątkowych
Przeniesienie autorskich praw majątkowych ma sens, gdy oprogramowanie jest kluczowe dla biznesu i ma charakter unikalny. Dotyczy to szczególnie:
systemów stanowiących przewagę konkurencyjną (np. algorytmy wyceny, silniki rekomendacji, dedykowane ERP),
oprogramowania wbudowanego w produkt fizyczny (np. elektronika przemysłowa),
platform, które będą dalej komercjalizowane przez klienta (white-label, franczyza, licencjonowanie innym podmiotom).
Przeniesienie praw daje pełnię kontroli: możliwość modyfikacji, sublicencjonowania, odsprzedaży, a także swobodę zmiany wykonawcy. Zazwyczaj wiąże się to z wyższą ceną i twardym negocjowaniem pól eksploatacji oraz zakresu „przenoszonego” kodu.
Licencja wyłączna a licencja niewyłączna – praktyka
Gdy software house używa własnych frameworków, modułów lub tworzy elementy, które planuje wykorzystywać także u innych klientów, często nie zgodzi się na pełne przeniesienie praw. Wtedy w grę wchodzi licencja.
Licencja wyłączna daje klientowi wyłączność korzystania z utworu na określonych polach eksploatacji w danym zakresie. Wykonawca zobowiązuje się, że nie udzieli takiej licencji innym podmiotom. Często stosowana przy krytycznych systemach, gdy software house nie chce oddać praw, ale jest gotowy zagwarantować, że nie wdroży identycznego rozwiązania u konkurencji.
Licencja niewyłączna to standard przy typowych produktach i modułach wielokrotnego użytku. Klient może korzystać z oprogramowania, ale nie ma wyłączności, a wykonawca może oferować ten sam kod innym. Taki model jest tańszy, ale oznacza mniejszą kontrolę nad oprogramowaniem.
Modele mieszane – kiedy część kodu na własność, a część „wspólna”
Najczęściej spotykanym w praktyce rozwiązaniem jest model mieszany. Polega on na tym, że:
elementy stworzone pod konkretnego klienta (np. integracje z jego systemami, specyficzne moduły biznesowe) są przenoszone na niego lub licencjonowane wyłącznie,
elementy reusable (frameworki, silniki workflow, komponenty UI) pozostają własnością software house’u i są licencjonowane niewyłącznie.
Model mieszany trzeba jasno opisać w umowie. Pomaga rozdzielenie na: komponenty dedykowane, komponenty wspólne oraz komponenty zewnętrzne (third-party). Każda kategoria powinna mieć osobny zestaw postanowień dotyczących praw autorskich i licencji.
Wpływ modelu na cenę, elastyczność i możliwość zmiany wykonawcy
Pełne przeniesienie praw zazwyczaj podnosi cenę. Software house oddaje bowiem możliwość wtórnego zarabiania na tym samym kodzie, więc rekompensuje to jednorazowym wynagrodzeniem. Z drugiej strony zapobiega to późniejszym konfliktom i kosztom wykupu praw.
Licencja, zwłaszcza niewyłączna, jest tańsza, ale może ograniczać elastyczność rozwoju. Jeżeli licencja nie reguluje wyraźnie prawa do modyfikacji przez inne podmioty, klient zostaje praktycznie związany z jednym wykonawcą. To też należy uwzględnić w negocjacjach.
Jak jasno nazwać i opisać model w umowie
Umowa z software house powinna używać precyzyjnych sformułowań, np.:
„Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do Utworów, o których mowa w §…, na następujących polach eksploatacji: …”
„Wykonawca udziela Zamawiającemu licencji wyłącznej/niewyłącznej do korzystania z Modułów Wspólnych, na polach eksploatacji: …, na czas …, na terytorium …”
Nie wystarczy jedno zdanie „klient ma licencję na oprogramowanie”. Trzeba wskazać rodzaj licencji, pola eksploatacji, terytorium, okres, wynagrodzenie, dopuszczalne modyfikacje i prawo do dalszego licencjonowania.
Przedmiot umowy i zakres prac – jak opisać, co właściwie jest tworzone
Dokładny opis przedmiotu: specyfikacja, backlog, dokumentacja
Solidny opis przedmiotu umowy to podstawa, aby później nie było sporu, czego dotyczą prawa autorskie i licencja. Najczęściej wykorzystuje się:
specyfikację funkcjonalną – opis funkcji systemu, user stories, wymagania biznesowe,
backlog produktowy – listę zadań/sprintów w metodyce Agile,
makiety i prototypy – wizualizacje ekranów, przepływów,
dokumentację techniczną – architektura, diagramy, opis API.
Te elementy mogą być załącznikami do umowy. Kluczowe jest, aby umowa odwoływała się do nich w sposób jednoznaczny (np. numer wersji dokumentu, data, repozytorium). Inaczej każda zmiana backlogu może rodzić pytanie, czy jest jeszcze w zakresie umowy, czy już poza nią.
Iteracyjność (Agile) a przenoszenie praw i odbiory
W projektach Agile zakres zmienia się w czasie. Tu ważne jest powiązanie odbioru sprintów z momentem przejścia praw lub momentem udzielenia licencji. Można to uregulować np. tak:
po odbiorze każdego sprintu dochodzi do przeniesienia praw do utworów wykonanych w tym sprincie,
zapłata za sprint jest wynagrodzeniem za przeniesienie praw/licencję,
w protokołach odbioru wskazuje się, jakie moduły i pliki są objęte przekazaniem.
Dzięki temu nie trzeba czekać do końca całego projektu, aby uregulować prawa. Jednocześnie sprinty stają się kamieniami milowymi, co porządkuje zarówno kwestie rozliczeń, jak i własności kodu.
Rozdzielenie kodu, dokumentacji, konfiguracji i narzędzi
Przedmiot umowy nie powinien ograniczać się do „systemu”. Dobrze rozróżnić:
kod źródłowy (aplikacja, skrypty, testy automatyczne),
Elementy niematerialne, które łatwo „wypadają” z zakresu
Poza samym kodem źródłowym w projekcie powstaje sporo utworów, o których umowy milczą. To m.in.:
dokumentacja użytkownika (instrukcje, help online, artykuły w bazie wiedzy),
Umowa powinna wymieniać te elementy z nazwy i przesądzać, czy są objęte przeniesieniem praw lub licencją, na jakich zasadach i w jakich formatach są przekazywane. Inaczej kończy się sytuacją, w której klient ma system, ale nie ma dokumentacji ani testów i każda zmiana trwa dwa razy dłużej.
Zmiany zakresu: change request i wpływ na prawa
Przy dłuższych wdrożeniach zakres rzadko zostaje niezmieniony. Jeżeli zmiany są wprowadzane na podstawie change requestów, w umowie warto określić prostą regułę:
każdy zaakceptowany change request jest załącznikiem do umowy,
utwory powstałe w jego wyniku są obejmowane tym samym reżimem praw autorskich, co reszta projektu, chyba że strony wyraźnie postanowią inaczej,
w razie innego modelu (np. wyłączna licencja tylko do części) trzeba to wpisać w treść change requestu.
Bez takiego mechanizmu część modułów może „wypaść” poza uzgodniony model praw, bo powstawała już po podpisaniu umowy i nie została nigdzie doprecyzowana.
Prawa autorskie i pola eksploatacji – zapisy, bez których umowa jest pusta
Jak opisać pola eksploatacji dla oprogramowania
Pola eksploatacji nie mogą być przepisanym z ustawy ogólnikiem. Dla oprogramowania przydaje się katalog dostosowany do realnego użycia, np.:
utrwalanie i zwielokrotnianie w pamięci komputerów, urządzeń mobilnych i serwerów (w tym w środowiskach chmurowych),
wprowadzanie do obrotu i użyczanie w ramach usług świadczonych przez klienta,
wprowadzanie do pamięci urządzeń końcowych użytkowników końcowych (jeżeli jest aplikacja mobilna / desktop),
publiczne udostępnianie w sieci (SaaS, dostęp przez WWW, API),
tłumaczenie, modyfikacja, dekompilacja w zakresie koniecznym do utrzymania i rozwoju,
tworzenie i eksploatacja utworów zależnych (forki, modyfikacje, rozszerzenia, pluginy).
Lista powinna być dostosowana do modelu biznesowego. SaaS ma inne potrzeby niż system wewnętrzny działający tylko w sieci lokalnej.
Uprawnienie do modyfikacji i utworów zależnych
Bez wyraźnego uprawnienia do tworzenia utworów zależnych (modyfikacji) klient może mieć problem z zaangażowaniem innego wykonawcy do rozwoju systemu. Software house będzie mógł wtedy argumentować, że tylko on ma prawo zmieniać kod.
Bezpieczny zapis powinien:
przy przeniesieniu praw – potwierdzać, że klient może dowolnie modyfikować i rozwijać oprogramowanie, a prawa do modyfikacji przysługują jemu,
przy licencji – przyznawać licencjobiorcy prawo modyfikacji przez siebie i przez osoby trzecie (podwykonawców, inne software house’y).
W projektach produktowych sensowne bywa rozróżnienie: klient ma pełne prawa do modyfikacji komponentów dedykowanych, ale w komponentach wspólnych może tylko proponować zmiany lub rozwijać je w forku, który będzie wykorzystywał wyłącznie u siebie.
Terytorium i czas trwania – drobne słowa, duże konsekwencje
Jeżeli umowa milczy o terytorium, domyślnie zakłada się je wąsko (najczęściej domyślne regulacje krajowe). Dla większości biznesów, zwłaszcza działających globalnie lub w modelu SaaS, to za mało.
Najprostszy i zazwyczaj bezpieczny zapis to terytorium: „cały świat”. Ograniczenia geograficzne mogą mieć sens jedynie w specyficznych relacjach partnerskich (np. resellerzy na konkretne kraje).
Przy czasie trwania:
przy przeniesieniu praw – wskazuje się, że następuje ono na cały okres trwania autorskich praw majątkowych,
przy licencji – konieczne jest wskazanie, czy jest ona czasowa (na określony okres) czy bezterminowa.
Licencja na czas określony bez szczegółowego mechanizmu przedłużania i zasad po wygaśnięciu to częsty powód nerwowych negocjacji tuż przed końcem okresu umowy.
Wynagrodzenie a przeniesienie praw lub licencja
W polskim prawie przyjmuje się, że wynagrodzenie za przeniesienie praw lub udzielenie licencji powinno być wyodrębnione, chociażby w sposób pośredni. W praktyce można zastosować różne modele:
wyraźne rozbicie: X zł za wykonanie usługi + Y zł za przeniesienie praw/licencję,
jedna kwota z klauzulą, że „wynagrodzenie obejmuje również wynagrodzenie z tytułu przeniesienia autorskich praw majątkowych/udzielenia licencji”,
stawka godzinowa, z dopisanym mechanizmem, że obejmuje w całości przeniesienie praw do rezultatów pracy.
Ważne, by nie zostawiać pola do twierdzenia, że wynagrodzenie dotyczyło wyłącznie usług, a nie przeniesienia praw. W sporze taki argument często się pojawia.
Źródło: Pexels | Autor: RDNE Stock project
Kod źródłowy, repozytoria i escrow – jak nie zostać „zakładnikiem”
Dostęp do kodu w trakcie projektu, nie tylko na końcu
Umowy często przewidują przekazanie kodu źródłowego dopiero po zakończeniu projektu. To ryzyko. Przerwanie współpracy w środku oznacza wtedy, że klient nie ma nic.
Bezpieczniej uregulować, że:
kod powstaje i jest utrzymywany w repozytorium (np. Git),
klient ma dostęp od początku (co najmniej „read-only”),
przy każdym odbiorze sprintu lub kamienia milowego następuje formalne „przekazanie” bieżącej wersji kodu (tag, release).
Jeżeli z jakichś względów klient nie chce lub nie może mieć dostępu do repozytorium wykonawcy, można ustanowić repozytorium lustrzane, do którego kod jest wypychany po każdym sprincie.
Konfiguracja środowisk, skrypty i infrastruktura jako osobny temat
Kod źródłowy bez wiedzy o konfiguracji i bez skryptów wdrożeniowych niewiele daje. Dlatego w umowie trzeba objąć zakresem także:
pliki konfiguracyjne (z wyłączeniem haseł i kluczy produkcyjnych),
skrypty deploymentu (CI/CD),
instrukcje uruchomienia systemu w środowiskach deweloperskim, testowym i produkcyjnym.
Częstym rozwiązaniem jest przekazanie klientowi pełnego opisu infrastruktury jako kodu (np. Terraform, Ansible). Ułatwia to ewentualną migrację do innego wykonawcy lub innej chmury.
Mechanizmy escrow: kiedy mają sens
Escrow kodu źródłowego to mechanizm, w którym kod jest deponowany u zewnętrznego, zaufanego podmiotu (np. kancelarii, firmy escrow). Kod jest wydawany klientowi tylko po spełnieniu określonych warunków, np. upadłość wykonawcy, istotne naruszenie umowy, długotrwała przerwa w świadczeniu usług.
Escrow sprawdza się przy:
krytycznych systemach, bez których firma nie może funkcjonować,
modelu licencyjnym, w którym wykonawca nie chce ujawniać kodu na co dzień,
współpracy z mniejszymi software house’ami, gdzie ryzyko upadłości jest większe.
Konieczne jest doprecyzowanie w umowie:
jak często kod jest aktualizowany w depozycie,
jakie dokładnie zdarzenia uruchamiają wydanie kodu,
jakie prawa do kodu nabywa klient po jego wydaniu (zazwyczaj licencja awaryjna z prawem do modyfikacji).
Bez takich konkretów escrow jest ładnym hasłem w umowie, ale niewiele zmienia w praktyce.
Rozstanie z wykonawcą: plan wyjścia i przeniesienie utrzymania
W projektach wieloletnich trzeba założyć scenariusz rozstania – z powodów biznesowych, cenowych albo organizacyjnych. Umowa powinna przewidywać:
obowiązek przekazania aktualnego kodu źródłowego, dokumentacji i konfiguracji na żądanie klienta przy zakończeniu umowy,
współpracę przy przeniesieniu utrzymania do nowego wykonawcy (np. pakiet godzin na „knowledge transfer”),
zakres wynagrodzenia za takie przejęcie (z góry określony cennik lub ryczałt).
Bez takiej procedury klient bywa zakładnikiem, bo każdy krok do innego wykonawcy kosztuje dodatkowo i nie jest uregulowany.
Licencjonowanie i ograniczenia użytkowania – jak ująć to precyzyjnie
Parametry licencji: kto, gdzie, na ilu urządzeniach
Licencja bez parametrów rodzi konflikty. Trzeba określić przynajmniej:
podmiot licencjobiorcy – czy licencja obejmuje tylko spółkę-matkę, czy także spółki zależne, oddziały, franczyzobiorców, partnerów,
zakres użytkowników – licencja per użytkownik, per instancja, per CPU, per transakcja czy „site license” dla określonej lokalizacji,
typ użytkowników – pracownicy, kontrahenci, klienci końcowi korzystający z systemu jako usługi.
Dobrą praktyką jest rozróżnienie użytkowników „wewnętrznych” (pracownicy, zleceniobiorcy) i „zewnętrznych” (klienci w portalu, użytkownicy SaaS), bo często obowiązują dla nich różne stawki lub inne ograniczenia.
Modele rozliczeń licencyjnych a rozwój biznesu klienta
Model licencyjny, który na starcie wydaje się tani, potrafi stać się pułapką przy wzroście skali. Przykłady:
opłata per użytkownik nazbyt ogranicza onboarding nowych pracowników,
opłata per instancja serwera utrudnia skalowanie horyzontalne,
opłata per transakcja zabija rentowność przy dużym wolumenie.
W umowie można od razu przewidzieć mechanizmy skalowania, np. rabaty przy przekroczeniu progów, przejście na inny plan licencyjny po osiągnięciu określonych parametrów, maksymalny pułap opłat rocznych.
Dopuszczalne pola sublicencjonowania i white-label
Jeżeli klient planuje dalej oferować oprogramowanie swoim klientom (np. SaaS, white-label, franczyza), potrzebuje wyraźnego uprawnienia do:
udzielania sublicencji swoim klientom,
modyfikacji oznaczeń (brandowanie, własne logo),
tworzenia własnych pakietów usług opartych na tym oprogramowaniu.
Bez takich klauzul każdy model partnerstwa czy resellerstwa może naruszać licencję. Prowadzi to do sytuacji, w której rosnący biznes klienta jest ograniczony przez niedoprecyzowane postanowienia umowy IT.
Zakazy i ograniczenia: czego nie przeciążać
Software house’y często wpisują długie listy zakazów: brak prawa do reverse engineeringu, brak prawa do benchmarków, zakaz udostępniania kodu lub wyników audytów. Część z tych zakazów jest uzasadniona ochroną know-how, ale ich nadmiar bywa paraliżujący.
Dobrą praktyką jest:
dopuszczenie audytów bezpieczeństwa i testów penetracyjnych, przy zachowaniu poufności wyników,
zezwolenie na reverse engineering w zakresie wymaganym przez prawo i koniecznym do zapewnienia interoperacyjności,
rozsądne ograniczenia benchmarków (np. zakaz publicznego publikowania wyników bez zgody, ale możliwość wewnętrznych porównań).
Z perspektywy klienta liczy się, aby ograniczenia nie blokowały rozwoju, integracji z innymi systemami ani zapewnienia bezpieczeństwa.
Konsekwencje naruszenia licencji i mechanizmy naprawcze
Sama groźba wypowiedzenia licencji „ze skutkiem natychmiastowym” za każde naruszenie jest zbyt ostra. Przy dużych wdrożeniach takie postanowienie staje się ryzykiem egzystencjalnym dla biznesu.
Rozsądnym kompromisem jest:
wprowadzenie procedury „notice and cure” – wykonawca wzywa do zaniechania naruszenia i daje czas na naprawę,
rozróżnienie naruszeń istotnych (świadome łamanie zakazów sublicencjonowania, ujawnienie kodu konkurencji) i nieistotnych (błędy w liczeniu liczby użytkowników),
jasne określenie, że wypowiedzenie ze skutkiem natychmiastowym jest zastrzeżone tylko dla naruszeń istotnych, powtarzających się lub zawinionych.
Serwis, utrzymanie i rozwój – oddzielać od licencjonowania
Wyraźne rozdzielenie: licencja vs. usługi
Licencja to prawo do korzystania z oprogramowania. Serwis i rozwój to osobne świadczenia. W umowie dobrze jest od razu rozbić je na osobne sekcje (a czasem nawet osobne umowy lub załączniki).
Praktyczne rozwiązanie:
umowa główna regulująca prawa autorskie i licencję,
Przy większych projektach bywa wymagane ISO 27001 lub równoważne certyfikacje – wtedy umowa powinna to wprost wskazywać.
Dane osobowe i RODO: DPIA, powierzenie, audyty
Jeżeli w systemie będą przetwarzane dane osobowe, umowa z software house’em zwykle jest jednocześnie umową powierzenia przetwarzania.
Powinna zawierać m.in.:
zakres i cel przetwarzania danych przez wykonawcę,
kategorie danych i osób, których dane dotyczą,
podwykonawców (subprocesorów) i warunki ich angażowania,
prawo klienta do audytu lub otrzymywania raportów z audytów zewnętrznych.
Przy systemach wysokiego ryzyka przydatne jest też uzgodnienie, kto wykonuje ocenę skutków dla ochrony danych (DPIA) i w jakim zakresie software house wspiera ten proces.
Poufność know-how i kodu po obu stronach
Oprogramowanie często zawiera know-how zarówno wykonawcy, jak i klienta. Klauzula poufności powinna działać w obie strony.
Typowe elementy:
katalog informacji poufnych (w tym kod, dokumentacja, roadmapy, dane biznesowe),
okres obowiązywania poufności po zakończeniu umowy (np. 5 lat lub bezterminowo),
warunki ujawnienia informacji organom publicznym (np. na żądanie regulatora).
Warto jasno ustalić, czy wykonawca może używać nazwy klienta i opisu projektu jako referencji, a jeśli tak – w jakim zakresie.
Zmiany zakresu, pivoty i „żywe” projekty – jak się nie zatracić
Change management: prosty proces zamiast mailowego chaosu
Przy długich projektach zmiana jest pewna. Jeżeli każda decyzja ma „dogadywać się” mailowo, szybko powstaje bałagan.
Lepsze podejście to formalny, ale lekki proces:
inicjacja zmiany (ticket / formularz CR),
szacunek wpływu na budżet i harmonogram,
akceptacja zmiany przez uprawnione osoby po obu stronach,
aktualizacja backlogu, zakresu sprintu lub załącznika z zakresem.
Nawet prosta tabelka w załączniku „Historia zmian zakresu” często rozwiązuje spory o to, „co było w umowie”.
Model zwinny (Agile) a zapisy kontraktowe
Przy Agile umowa nie może być klasyczną „książką specyfikacji”, bo założeniem jest zmiana wymagań. Zamiast tego:
opisuje się cele biznesowe, a nie wyłącznie funkcje,
odwołuje się do backlogu jako dokumentu żyjącego, aktualizowanego na bieżąco,
ustala się mechanizmy priorytetyzacji i zakresu sprintów.
Przydaje się klauzula, że „zakres” oznacza wykorzystanie określonej puli budżetu/czasu, a nie konkretny zestaw funkcjonalności – o ile osiągnięte zostaną uzgodnione cele.
Stały zespół vs. body leasing – skutki prawne
Gdy software house deleguje stały zespół pracujący wyłącznie dla jednego klienta, projekt zaczyna przypominać body leasing. Wtedy trzeba zadbać, by:
relacje z osobami fizycznymi nie były traktowane jako stosunek pracy z klientem (ryzyko „ukrytego zatrudnienia”),
umowa jasno określała, kto jest pracodawcą i kto ponosi odpowiedzialność za naruszenia (np. BHP, dane osobowe),
był opisany tryb wymiany członków zespołu i przekazywania wiedzy.
W wielu jurysdykcjach pojawia się też aspekt podatkowy – rosnąca zależność może być interpretowana jako stały zakład podatkowy.
Odpowiedzialność, gwarancja i kary umowne – gdzie leży granica
Limit odpowiedzialności i jego wyjątki
Standardem w umowach IT jest limit odpowiedzialności wykonawcy, najczęściej powiązany z wartością wynagrodzenia.
Często przyjmuje on formę:
„do wysokości łącznego wynagrodzenia netto zapłaconego w ciągu ostatnich 12 miesięcy” albo
„do dwukrotności łącznego wynagrodzenia za cały kontrakt”.
Po stronie klienta sensownie jest wyłączyć z limitu np. odpowiedzialność za naruszenia poufności, danych osobowych czy świadome naruszenia praw autorskich.
Odpowiedzialność za osoby trzecie i komponenty open source
Software house’y korzystają z bibliotek i komponentów firm trzecich, w tym open source. Umowa powinna rozstrzygać, kto ponosi ryzyko ewentualnych roszczeń z tym związanych.
Przydatne postanowienia:
obowiązek informowania o użytych licencjach open source i ich warunkach,
gwarancja, że integracja tych komponentów nie wymusi „otwarcia” całego kodu klienta (np. unikanie copyleft tam, gdzie to problem),
odpowiedzialność wykonawcy za naruszenie licencji komponentów, które sam dobrał.
Przy zakupie płatnych komponentów trzeba też ustalić, na kogo wystawiane są licencje – klienta czy software house’u.
Rękojmia, gwarancja jakości i czas ich trwania
Obok SLA przy serwisie wiele podmiotów oczekuje dodatkowych mechanizmów ochronnych: rękojmi i/lub gwarancji jakości.
Typowy model:
okres gwarancji na oprogramowanie (np. 12 miesięcy od odbioru) z obowiązkiem usuwania błędów bez dodatkowego wynagrodzenia,
zastrzeżenie, że użycie kodu niezgodnie z dokumentacją lub jego modyfikacja przez klienta może ograniczać gwarancję,
wskazanie relacji między gwarancją a płatnym serwisem (co wchodzi w który pakiet).
Dobrze jest także przewidzieć procedurę przedłużenia gwarancji przy większych poprawkach lub refactoringu całych modułów.
Kary umowne: za co i w jakiej wysokości
Kary umowne są narzędziem dyscyplinującym, ale zbyt wysokie potrafią zabić projekt już na etapie negocjacji.
Najczęściej pojawiają się za:
opóźnienia w realizacji kamieni milowych,
naruszenie poufności lub bezpieczeństwa danych,
brak osiągnięcia gwarantowanych parametrów SLA.
Z praktycznego punktu widzenia dobrze, gdy łączny limit kar jest skorelowany z ogólnym limitem odpowiedzialności i nie prowadzi do sytuacji, w której każda drobna zwłoka wstrząsa współpracą.
Jurysdykcja, prawo właściwe i rozwiązywanie sporów
Prawo państwa siedziby klienta czy wykonawcy
Przy współpracy międzynarodowej wybór prawa właściwego ma realne skutki: inaczej działa odpowiedzialność, inaczej rękojmia, inaczej konstrukcja autorskich praw majątkowych.
Z perspektywy klienta z Polski bezpieczniej jest, gdy stosuje się prawo polskie (zwłaszcza przy systemach kluczowych). W przeciwnym razie warto zaangażować prawnika znającego dany porządek prawny.
Arbitraż, sądy powszechne, mediacja
W dużych kontraktach częste jest odwołanie do arbitrażu (np. sądów arbitrażowych przy izbach gospodarczych). Postępowania są szybsze i bardziej wyspecjalizowane, ale droższe.
Coraz częściej strony wpisują też obowiązek mediacji przed skierowaniem sporu do sądu. Ma to sens, jeśli po obu stronach są osoby gotowe rozmawiać i ustalać kompromis, a nie tylko „przerzucać się pismami”.
Język umowy i wersje rozstrzygające
Przy dwóch wersjach językowych trzeba jasno wskazać, która jest rozstrzygająca w razie rozbieżności. Najlepiej unikać sytuacji, w której „obie wersje są równorzędne” – wtedy każdy ciągnie w swoją stronę.
Jeśli codzienna komunikacja projektowa odbywa się po angielsku, a prawo właściwe to polskie, rozsądne jest mieć wersję angielską, ale wskazać polską jako nadrzędną, dobrze przełożoną przez kogoś, kto rozumie terminy IT.
Najczęściej zadawane pytania (FAQ)
Jakie zapisy w umowie z software house’em są kluczowe, żeby „kod był mój”?
Kluczowe są trzy elementy: wyraźne postanowienie o przeniesieniu autorskich praw majątkowych (albo udzieleniu licencji), szczegółowe wskazanie pól eksploatacji oraz zapisy o przekazaniu kodu źródłowego i dokumentacji. Sam zwrot typu „klient ma pełne prawa” jest zbyt ogólny i w razie sporu może okazać się bezwartościowy.
W praktyce umowa powinna wskazywać, że z chwilą zapłaty wynagrodzenia prawa majątkowe przechodzą na klienta na konkretnych polach (np. utrwalanie, modyfikacja, dalsze udostępnianie, komercjalizacja), a wykonawca zobowiązuje się przekazać aktualne repozytorium, skrypty wdrożeniowe i dokumentację techniczną w uzgodnionym formacie.
Czy jak płacę za stworzenie systemu, to automatycznie mam do niego pełne prawa?
Nie. Zapłata za usługę IT oznacza co do zasady wynagrodzenie za czynność (programowanie, wdrożenie, support), a nie automatyczne przejęcie autorskich praw majątkowych do efektu. W relacji B2B nie działa domniemanie z prawa pracy.
Bez wyraźnego zapisu o przeniesieniu praw lub licencji masz jedynie wąskie uprawnienie do korzystania z przekazanego egzemplarza programu, zwykle w ramach bieżącej współpracy z wykonawcą. Przy próbie zmiany dostawcy lub samodzielnego rozwijania systemu pojawia się konflikt.
Co lepiej wybrać w umowie: przeniesienie praw autorskich czy licencję?
Przeniesienie praw autorskich ma sens, jeśli system jest kluczowy dla biznesu, unikalny i planujesz dalej go komercjalizować lub intensywnie rozwijać (np. dedykowana platforma B2B, oprogramowanie wbudowane w produkt, własny SaaS). Daje pełną kontrolę, ale jest droższe i trudniej negocjowalne po stronie software house’u.
Licencja (wyłączna lub niewyłączna) wystarczy, gdy korzystasz z gotowego produktu lub gdy wykonawca używa własnych frameworków i komponentów, które wdraża też u innych klientów. Wtedy kluczowe jest możliwie szerokie określenie pól eksploatacji, zakresu terytorialnego, czasu trwania, liczby użytkowników i prawa do modyfikacji.
Jak zabezpieczyć w umowie dostęp do kodu źródłowego i dokumentacji?
Po pierwsze, umowa powinna wprost wskazywać, że wykonawca zobowiązuje się przekazać kod źródłowy, dokumentację techniczną i projektową oraz materiały niezbędne do samodzielnego utrzymania i rozwoju systemu. Warto doprecyzować formę (repozytorium Git, paczka na koniec sprintu, eksport bazy), terminy oraz moment przejścia praw do poszczególnych wersji.
Po drugie, przy projektach długoterminowych dobrze jest zapewnić sobie ciągły dostęp do repozytorium (np. klient jako współwłaściciel przestrzeni w GitLabie) oraz obowiązek aktualizowania dokumentacji. Dzięki temu przy zmianie dostawcy nie trzeba „wykupywać” dostępu do własnego systemu.
Jak uniknąć uzależnienia od jednego software house’u?
Podstawą jest model prawny: przeniesienie praw majątkowych albo licencja dająca prawo modyfikacji, tworzenia utworów zależnych i zlecania prac innym podmiotom. Bez tych uprawnień każdy kolejny wykonawca będzie miał związane ręce, a poprzedni dostawca łatwo zablokuje rozwój systemu.
Poza tym w umowie warto zadbać o: przekazywanie kodu i dokumentacji w regularnych interwałach, brak klauzul zakazujących współpracy z innymi wykonawcami przy danym systemie, jasne zasady zakończenia współpracy (procedura „offboardingu”: wydanie kodu, baz danych, dostępów, środowisk).
Na co zwrócić uwagę przy licencjonowaniu gotowego produktu (SaaS, „pudełko”) z dodatkowymi modułami?
Trzeba rozdzielić w umowie dwie rzeczy: licencję na produkt standardowy (np. system SaaS, pudełkowy ERP) oraz zasady własności i licencjonowania modułów tworzonych na zamówienie (integracje, dedykowe funkcje). Jeśli tego brakuje, wykonawca może potraktować wszystko jako jeden produkt, do którego masz tylko ograniczony dostęp.
Przy modułach dedykowanych doprecyzuj, czy prawa do nich przechodzą na Ciebie, czy masz szeroką licencję na rozwój i modyfikację u innych dostawców. Ustal także, czy w razie zakończenia umowy SaaS zachowujesz możliwość korzystania z tych modułów (np. w wersji on-premise) oraz dostęp do danych w otwartym formacie.
Czy wystarczy, że w umowie wpiszemy „klient ma pełne prawa do oprogramowania”?
Nie wystarczy. Prawo autorskie wymaga, aby umowa wskazywała konkretne pola eksploatacji (sposoby korzystania z utworu). Ogólne stwierdzenia o „pełni praw” są interpretowane wąsko i często nie obejmują np. prawa do modyfikacji, sublicencjonowania czy komercyjnego udostępniania systemu innym podmiotom.
Co warto zapamiętać
Umowa z software house’em ma zabezpieczać nie tylko termin i budżet, ale przede wszystkim prawa autorskie, zasady licencjonowania oraz dostęp do kodu źródłowego i dokumentacji – bez tego klient nie kontroluje swojego systemu.
Model współpracy (dedykowany system vs. produkt pudełkowy/SaaS) diametralnie wpływa na prawa do oprogramowania; trzeba precyzyjnie rozdzielić, co jest gotowym produktem wykonawcy, a co tworzonym na zamówienie utworem klienta.
Zapłata za usługę IT (analiza, development, wdrożenie) nie oznacza automatycznego nabycia autorskich praw majątkowych – te muszą być wyraźnie przeniesione w umowie albo objęte odpowiednią licencją.
Brak jasnych zapisów o prawach autorskich i licencji prowadzi do typowych problemów: zbyt wąski zakres licencji, brak prawa modyfikacji, brak dostępu do repozytorium i dokumentacji oraz pełne uzależnienie od jednego dostawcy.
Program komputerowy i dokumentacja są chronionymi utworami; chroniony jest konkretny sposób realizacji rozwiązania (kod, struktura, interfejsy), a nie sam pomysł na system.
W relacjach B2B z software house’em domyślnie to wykonawca (lub jego pracownicy) ma autorskie prawa majątkowe; klient nie staje się „właścicielem” oprogramowania bez wyraźnej klauzuli o przeniesieniu praw lub udzieleniu licencji.
Jedna, precyzyjna sekcja o prawach autorskich, licencji oraz wydaniu kodu źródłowego potrafi uchronić przed kosztownymi sporami po 1–3 latach, gdy system trzeba rozwijać, przepisać lub przenieść do innego dostawcy.
