Najważniejsze elementy umowy z software house
Umowa z software house z klientem to nie jeden dokument, lecz zestaw rozstrzygnięć: rodzaj umowy, zakres prac, prawa do kodu, odbiór, gwarancja i kary umowne. Jeżeli chcesz przeanalizować te kwestie szerzej, sprawdź obsługa prawna firm IT. Poniżej najważniejsze punkty, w których najczęściej można znaleźć źródła ryzyka.
- Prawa do kodu przechodzą tylko wtedy, gdy umowa wyraźnie wymienia pola eksploatacji. Bez tego nabywasz co najwyżej licencję.
- Przeniesienie praw wymaga formy pisemnej pod rygorem nieważności. Mail nie wystarcza; kwalifikowany podpis elektroniczny – tak.
- Rodzaj umowy przesądza o odpowiedzialności za wady: umowa o dzieło uruchamia rękojmię, umowa o świadczenie usług – nie.
- Całkowitego wyłączenia odpowiedzialności dostawcy nie da się zastrzec skutecznie, za szkodę wyrządzoną umyślnie zawsze ponosisz odpowiedzialność.
- Kara umowna działa wyłącznie przy zobowiązaniach niepieniężnych, a sąd może ją miarkować, gdy jest rażąco wygórowana.
- Przy dostawcy pracującym na współpracownikach B2B prawa do kodu nie przechodzą automatycznie, potrzebny jest udokumentowany łańcuch nabycia (chain of title).
Podpisujesz umowę z software house i masz dwie różne role do rozegrania. Jeśli jesteś klientem, który zamawia oprogramowanie, chcesz mieć pewność, że po zapłacie dostajesz działający produkt i pełne prawa do kodu, a nie tylko obietnicę. Jeśli prowadzisz software house, chcesz precyzyjnie ograniczyć swoją odpowiedzialność, zabezpieczyć płatności i nie oddać więcej praw, niż sam nabyłeś od swoich współpracowników oraz móc wykorzystać to, co wytworzyłeś w tym projekcie do innych realizacji.
Ten sam kontrakt IT z klientem czyta się więc z dwóch stron. Ten artykuł pokazuje warunki współpracy z software house od strony konkretnych klauzul: co musi się w umowie znaleźć, żeby żadna ze stron nie została z ryzykiem, którego nie zauważyła przy podpisie.
Umowa z software house krok po kroku
Współpraca z software house przebiega w siedmiu powtarzalnych etapach, a dobrze skonstruowana umowa odwzorowuje każdy z nich. Każdy etap generuje własne ryzyko prawne, które łatwiej zamknąć klauzulą niż późniejszym sporem. Poniżej lista elementów, jakie powinna zawierać taka umowa.
- NDA i rozmowy wstępne – zanim ujawnisz pomysł, koncept produktu czy dane, podpisujesz umowę o zachowaniu poufności (NDA z software house).
- Specyfikacja wymagań projektowych – strony ustalają zakres prac: co ma powstać, w jakim standardzie, z jakimi funkcjami.
- Wybór modelu i rodzaju umowy – Fixed Price czy Time & Material, umowa o dzieło czy o świadczenie usług. To rozstrzygnięcie determinuje bardzo dużo w umowie.
- Umowa główna i załączniki – kontrakt IT z firmą programistyczną wraz z harmonogramem, specyfikacją i wzorem protokołu odbioru.
- Realizacja i odbiory – praca w etapach (kamieniach milowych), z formalnym odbiorem oprogramowania po każdym z nich.
- Przeniesienie praw autorskich – najczęściej z chwilą zapłaty za dany etap; wymaga wyraźnej klauzuli.
- Wsparcie i utrzymanie – SLA w umowie IT na okres gwarancyjny i ewentualną dalszą obsługę.
Rodzaj umowy z software house: dzieło czy świadczenie usług?
Rodzaj umowy przesądza o tym, za co dostawca odpowiada i kiedy uznaje się, że wykonał umowę. To pierwsza realna decyzja, nie formalność redakcyjna, jak nazwiemy sobie dokument. W praktyce spotkasz różne nazwy tego samego kontraktu: umowa o współpracy IT, umowa deweloperska software czy kontrakt na realizację oprogramowania. To określenia handlowe, nie kategorie prawne, a prawny reżim odpowiedzialności zależy od treści umowy, a nie od jej tytułu.
Klient umowę o dzieło zawiera z software house wtedy, gdy liczy się konkretny rezultat, z góry określony produkt. Dostawca odpowiada za jego osiągnięcie, a klientowi przysługuje rękojmia za wady. Umowa o świadczenie usług (art. 750 KC) opiera się na starannym działaniu: dostawca zobowiązuje się pracować profesjonalnie, ale nie gwarantuje konkretnego efektu.
W praktyce ten podział pokrywa się z modelem rozliczeń:
- Fixed Price zwykle przybiera formę umowy o dzieło, gdzie została ustalona stała cena za zdefiniowany rezultat, ryzyko przekroczenia zakresu prac jest po stronie dostawcy.
- Time & Material jest bliżej umowy o świadczenie usług, rozliczasz przepracowany czas, a ryzyko przekroczenia zakresu jest po stronie zamawiającego, gdyż wiąże się z dodatkowymi kosztami za wykonane prace.
- Głębiej różnice między T&M a Fixed Price – zalety, wady i model hybrydowy – zostały opisane w osobnym tekście: Fixed Price vs Time & Material.
Jeżeli projekt dotyczy sektora finansowego i nowych technologii, sprawdź również obsługa prawna FinTech.
Prawa autorskie do kodu źródłowego – kiedy przechodzą na klienta?
Prawa autorskie do kodu źródłowego nie przechodzą na klienta przez sam fakt zapłaty wynagrodzenia, ale na podstawie wyraźnej klauzuli o ich przeniesieniu. Ponadto, mimo wpisania do umowy przeniesienia praw, należy również pamiętać o obowiązku dostawcy do wydania kodu źródłowego. Samo przeniesienie praw nie powoduje, że dostawca ma obowiązek go wydać. To najczęściej pomijana kwestia w praktyce i źródło sporów.
Umowa przenosi autorskie prawa majątkowe tylko na tych polach eksploatacji, które wprost w niej wymieniono. Należy pamiętać, że istnieją dwa osobne katalogi przeniesienia praw. W przypadku programów komputerowych pola eksploatacji określa art. 74 ust. 4 pr.aut. Dla dokumentacji oraz innych utworów, jak np. grafiki, pola eksploatacji określa art. 50 pr.aut. Jeśli umowa milczy o przeniesieniu, przyjmuje się, że udzielono jedynie licencji, a to znaczy, że prawa do oprogramowania zostały przy dostawcy.
Należy jeszcze zwrócić uwagę na dwie pułapki w projektach IT, związane z przeniesieniem praw:
Forma pisemna pod rygorem nieważności – przeniesienie praw wymaga podpisu, umowa zawarta samym mailem nie przenosi praw.
Reguła pracownicza nie działa przy B2B – prawa do programu stworzonego przez pracownika przechodzą na pracodawcę z mocy ustawy. Ale współpracownik na kontrakcie B2B to nie pracownik: jego prawa dostawca musi nabyć osobną umową, inaczej nie ma czego przenieść na klienta.
Dla software house wynika z tego odmienny obowiązek: zanim złożysz klientowi oświadczenie o przeniesienie praw, musisz mieć udokumentowany łańcuch nabycia od każdego developera. Klient z kolei powinien zażądać wykazania łańcucha nabycia, jako prawo wglądu w umowy z kontraktorem B2B (oczywiście po anonimizacji danych).
Przykładowa klauzula przeniesienia praw autorskich
Przykładowe brzmienie klauzuli (do uzupełnienia po Twojej stronie):
„Z chwilą zapłaty wynagrodzenia za dany etap Dostawca przenosi na Zamawiającego całość majątkowych praw autorskich do utworów – w tym do programu komputerowego – powstałych w ramach realizacji tego etapu, na następujących polach eksploatacji: trwałe i czasowe zwielokrotnianie w całości i w części, jakimikolwiek środkami i w jakiejkolwiek formie; tłumaczenie, przystosowywanie, zmiana układu oraz wprowadzanie jakichkolwiek innych zmian; rozpowszechnianie, w tym użyczenie i najem.
Przeniesienie obejmuje kod źródłowy, kod wynikowy oraz dokumentację techniczną jako formy wyrażenia programu. Dostawca oświadcza, że nabył od osób współtworzących utwory (w tym współpracowników B2B) prawa w zakresie umożliwiającym niniejsze przeniesienie, i przedstawi na żądanie Zamawiającego odpowiednie postanowienia tych umów, z prawem anonimizacji danych nieistotnych dla weryfikacji łańcucha nabycia praw.
Jak wygląda spór o prawa do kodu – przykład
Startup zamawia aplikację w modelu Fixed Price, płaci pełną kwotę i wdraża produkt. Umowa o realizację oprogramowania w jednym zdaniu wspomina o „przekazaniu praw”, ale nie wymienia żadnych pól eksploatacji i nie mówi o kodzie źródłowym. Rok później do spółki wchodzi inwestor. Due diligence wykrywa, że formalnie startup ma jedynie licencję, a kod źródłowy pozostał przy software house. Dostawca warunkuje podpisanie aneksu o przeniesieniu praw za dopłatą, bo wie, że transakcja zależy od jego zgody. Cały problem i jego koszt sprowadza się do trzech linijek, których nie było w pierwotnej umowie.
Specyfikacja wymagań i odbiór prac w projekcie IT
Bez kryteriów akceptacji projekt nigdy nie ma jednoznacznego końca, i to jest problem obu stron. Dostawca nie wie, kiedy dostanie ostatnią płatność; zamawiający nie wie, czego może żądać jako „gotowego rozwiązania”.
Specyfikacja wymagań projektowych i procedura odbioru to dwa połączone elementy. Specyfikacja opisuje, co ma powstać; odbiór ustala, jak sprawdzamy, że powstało. Umowa IT powinna zawierać konkretne wymagania, a nie ogólny wymóg „zaakceptowania przez Zamawiającego”.
Dobra procedura odbioru zawiera:
- Kryteria akceptacji (Definition of Done) – mierzalne warunki, po spełnieniu których etap uznaje się za odebrany.
- Termin na zgłoszenie uwag – np. 10 dni roboczych; po jego upływie brak uwag oznacza odbiór.
- Procedurę poprawek – co się dzieje, gdy zamawiający zgłasza wady: termin na naprawę i ponowny odbiór.
- Powiązanie z płatnością – warunki płatności projekt IT wiążą płatności z odbiorem etapu, nie z upływem czasu.
Przykładowa klauzula odbioru prac
Przykładowe brzmienie klauzuli (do uzupełnienia po Twojej stronie):
„Odbiór każdego etapu następuje na podstawie protokołu odbioru, po potwierdzeniu spełnienia kryteriów akceptacji określonych w Załączniku nr … . Zamawiający zgłasza uwagi w terminie … dni roboczych od przekazania rezultatu etapu. Brak uwag w tym terminie jest równoznaczny z odbiorem etapu. W razie zgłoszenia wad Dostawca usuwa je w terminie … dni, po czym etap podlega ponownemu odbiorowi. Zapłata wynagrodzenia za etap następuje po podpisaniu protokołu odbioru bez zastrzeżeń.”
Odpowiedzialność za wady oprogramowania: rękojmia, gwarancja i granice wyłączeń
Odpowiedzialność za wady oprogramowania opiera się na trzech różnych podstawach, których nie należy mylić: rękojmi ustawowej, umownej gwarancji jakości oraz ogólnej odpowiedzialności kontraktowej. Każda działa inaczej i każdą trzeba w umowie świadomie ustawić.
Rękojmia – przy umowie o dzieło wynika z ustawy. Zamawiający może żądać naprawy, obniżenia wynagrodzenia, a przy wadzie istotnej odstąpienia od umowy.
Gwarancja jakości – dobrowolne, umowne zobowiązanie dostawcy: definiuje SLA w umowie IT, czyli czasy reakcji i naprawy błędów w podziale na kategorie (krytyczny, poważny, nieistotny).
Odpowiedzialność kontraktowa – za nienależyte wykonanie zobowiązania (art. 471 i art. 472 KC), z miernikiem należytej staranności podwyższonej dla profesjonalisty.
Dostawca może ograniczyć swoją odpowiedzialność, ale nie może wyłączyć jej w zakresie szkody wyrządzonej umyślnie (art. 473 § 2 KC). Klauzula „Dostawca nie ponosi żadnej odpowiedzialności” jest po prostu nieważna. W praktyce strony ustalają kwotowy limit (cap) odpowiedzialności – najczęściej w relacji do wartości umowy – z wyższym progiem dla scenariuszy wysokiego ryzyka.
Przykładowa klauzula gwarancji i odpowiedzialności
Przykładowe brzmienie klauzuli (do uzupełnienia po Twojej stronie):
„Dostawca udziela gwarancji jakości na okres … miesięcy od odbioru końcowego. W ramach gwarancji Dostawca usuwa zgłoszone błędy w następujących czasach: błąd krytyczny – reakcja … godz., naprawa … godz.; błąd poważny – reakcja … godz., naprawa … dni; błąd drobny – w ramach najbliższej aktualizacji. Całkowita odpowiedzialność Dostawcy z tytułu Umowy jest ograniczona do kwoty … (… % wartości Umowy), z wyłączeniem szkód wyrządzonych umyślnie i nie obejmuje utraconych korzyści.”
Kary umowne i harmonogram – jak zabezpieczyć terminy projektu?
Karę umowną można skutecznie zastrzec za opóźnienie w wykonaniu etapu czy naruszenie poufności, ale nie za brak zapłaty. Na opóźnienie w płatności służą odsetki, nie kara.
Harmonogram projektu IT działa jako zabezpieczenie dopiero wtedy, gdy kamienie milowe są powiązane z konsekwencją. Sam wykaz dat bez skutku prawnego jest deklaracją, nie klauzulą. Zabezpieczenie umowy z firmą IT po stronie terminów opiera się na kilku regułach:
Kara za zwłokę, nie za opóźnienie – ważne rozróżnienie: „zwłoka” to opóźnienie zawinione; „opóźnienie” obejmuje też przyczyny niezależne od dostawcy. Ustal świadomie, którą wersję zapisujesz.
Osobny, niższy limit kar – kary umowne zwykle mają własny cap, niższy niż ogólny limit odpowiedzialności, by nie przekroczyły rozsądnej proporcji do wartości umowy.
Świadomość miarkowania – sąd może obniżyć karę rażąco wygórowaną lub gdy zobowiązanie wykonano w znacznej części (art. 484 § 2 KC). Zbyt wysoka kara nie jest więc gwarancją wypłaty, celem kary nie jest to, aby ktoś na niej „zarobił”, ale ma uprościć naprawienie szkody.
Współdziałanie zamawiającego – jeśli opóźnienie wynika z braku decyzji klienta, dostawca uwolni się od zapłaty kary.
NDA i tajemnica przedsiębiorstwa przy współpracy z software house
NDA z software house chroni informacje tylko wtedy, gdy obejmuje nie samą firmę dostawcy, ale też konkretne osoby, które mają dostęp do danych. To najczęstsza luka: umowę poufności podpisuje spółka, a do systemów wchodzi programista, którego to NDA formalnie nie wiąże, jeśli jest podwykonawcą na B2B.
Skuteczne NDA przy współpracy z software house ma dwa poziomy. Pierwszy to ochrona informacji poufnych między firmami. Drugi to zobowiązanie dostawcy, że osoba realnie mająca dostęp jest osobiście związana równoważnym NDA, jak i to, że możesz egzekwować od dostawcy odszkodowania za naruszenie przez jego podwykonawcę.
Przykładowa klauzula NDA
Przykładowe brzmienie klauzuli (do uzupełnienia po Twojej stronie):
„Dostawca zobowiązuje się do zachowania w tajemnicy informacji poufnych Zamawiającego, w tym danych technicznych, danych klientów, danych osobowych, know-how oraz informacji handlowych. Dostawca zapewnia, że każda osoba skierowana do realizacji Umowy jest związana zobowiązaniem do poufności o standardzie nie niższym niż w niniejszej Umowie, także na korzyść Zamawiającego.”
Pięć najczęstszych błędów w umowach z software house
Najczęstsze błędy w umowach z software housem powtarzają się niezależnie od branży i wielkości projektu. Poniżej pięć, które w praktyce najczęściej kończą się sporem lub problemem przy transakcji.
- Brak katalogu pól eksploatacji – „przekazujemy prawa” bez wymienienia pól nie przenosi praw skutecznie (art. 41 ust. 2 pr.aut.).
- Brak formalnej procedury odbioru – bez protokołu i kryteriów akceptacji nie da się jednoznacznie ustalić, czy etap został wykonany.
- Prawa „po zapłacie” – jeśli powstaje spór o płatność, a prawa miały przejść dopiero po niej, klient zostaje z produktem, którego nie jest właścicielem.
- Brak łańcucha nabycia od współpracowników B2B – dostawca oświadcza, że przenosi prawa, których sam nie nabył od swoich developerów.
- Wyłączenie całej odpowiedzialności – klauzula wyłączająca odpowiedzialność „w każdym przypadku” jest nieważna co do szkody umyślnej.
Podsumowanie
Umowa z software house z klientem chroni obie strony tylko wtedy, gdy każdy z siedmiu etapów współpracy ma odpowiadającą mu klauzulę. Najwięcej ryzyka koncentruje się w trzech miejscach: przeniesieniu praw do kodu (art. 41 ust. 2, art. 74 ust. 4, art. 53 pr.aut.), procedurze odbioru oraz granicach odpowiedzialności (art. 471–473 KC). To właśnie te punkty najczęściej decydują o wyniku późniejszego sporu lub transakcji.
Sprawdź naszą usługę: audyt prawny umów IT – zweryfikujemy Twoją umowę z software house pod kątem praw do kodu, odbioru i odpowiedzialności.
FAQ – umowa z software house
Co powinna zawierać umowa z software house?
Umowa z software house powinna zawierać: określenie rodzaju umowy (dzieło albo usługi), zakres prac i specyfikację, harmonogram z kamieniami milowymi, procedurę odbioru z kryteriami akceptacji, klauzulę przeniesienia praw autorskich z katalogiem pól eksploatacji, gwarancję i SLA, kary umowne oraz NDA. Brak któregokolwiek z tych elementów przenosi ryzyko na jedną ze stron.
Jakie prawa do kodu źródłowego przysługują klientowi po podpisaniu umowy?
Po podpisaniu umowy klientowi przysługują dokładnie te prawa, które umowa wyraźnie wymienia. Jeśli umowa nie zawiera klauzuli przeniesienia z katalogiem pól eksploatacji (art. 41 ust. 2 i art. 74 ust. 4 pr.aut.), klient nabywa co najwyżej licencję (art. 65 pr.aut.), a nie własność praw do kodu.
Ile kosztuje współpraca z software house?
Koszt zależy przede wszystkim od modelu rozliczeń, a nie od stawki godzinowej samej w sobie. W Fixed Price płacisz stałą kwotę za zdefiniowany rezultat i przenosisz ryzyko zakresu na dostawcę; w Time & Material płacisz za przepracowany czas i sam ponosisz ryzyko zmian. Z perspektywy prawnej istotniejsze od kwoty jest to, jak model wpływa na odpowiedzialność za wady i moment przejścia praw.
Co to jest umowa T&M i kiedy warto ją wybrać?
Umowa T&M (Time & Material) to model rozliczenia za faktycznie przepracowany czas i wykorzystane zasoby, bliski umowie o świadczenie usług (art. 750 KC). Warto ją wybrać, gdy zakres nie jest z góry sztywno określony i spodziewasz się zmian w trakcie. Szczegółowe porównanie znajdziesz w artykule o modelach Fixed Price i Time & Material.
Czym różni się umowa Fixed Price od Time & Material?
Fixed Price to stała cena za z góry określony rezultat, zwykle w formie umowy o dzieło; Time & Material to rozliczenie za czas pracy, bliższe umowie o świadczenie usług. Główna różnica dotyczy rozłożenia ryzyka: w Fixed Price ryzyko zakresu ponosi dostawca, w Time & Material – zamawiający.
Co powinna zawierać umowa NDA z software housem?
Umowa NDA z software house powinna obejmować definicję informacji poufnych, dwa poziomy ochrony (firma dostawcy oraz osoby faktycznie mające dostęp), okres obowiązywania oraz sankcję za naruszenie.
Co to jest SLA w umowie z software housem?
SLA (Service Level Agreement) w umowie IT to część gwarancji jakości określająca czasy reakcji i naprawy błędów, zwykle w podziale na kategorie: krytyczny, poważny i drobny. SLA jest zobowiązaniem umownym dostawcy i działa niezależnie od ustawowej rękojmi, warto powiązać je z karą umowną za przekroczenie zadeklarowanych czasów.
Jak zabezpieczyć się prawnie przy współpracy z software housem?
Zabezpieczenie umowy z firmą IT opiera się na pięciu klauzulach: przeniesieniu praw z katalogiem pól eksploatacji, procedurze odbioru z kryteriami akceptacji, gwarancji i SLA, karach umownych za zwłokę oraz NDA obejmującym osoby skierowane do projektu. Dla klienta dochodzi prawo wglądu w łańcuch nabycia praw; dla dostawcy – limit odpowiedzialności.
