Umowa startupu z software house'm

Zdarza się, że zespół założycieli startupu nie ma w swoim składzie osób technicznych albo takich, które od A do Z są w stanie wytworzyć np.: aplikację SAAS. W takiej sytuacji wykonanie aplikacji trzeba zlecić firmie zewnętrznej, która kolokwialnie mówiąc zakoduje nasz pomysł. Aby współpraca z wykonawcą aplikacji była sprawna i owocna - musimy dobrze ją uregulować. Chcę, żebyś wiedział, że umowy są fundamentem relacji biznesowej i na ich podstawie powinny - a nie zawsze tak się dzieje, bo czasem umowa swoje a ludzie swoje - ale na podstawie umów powinny być realizowane usługi IT. Chcę, żebyś na swojej biznesowej drodze pamiętał, że z niemądrego konstruowania umów, ale też z nieprzestrzegania mądrych umów wynikają poważne kłopoty. Jeśli uważnie przerobisz ten rozdział handbooka, jestem pewna, że ich unikniesz. 

Umowa ma być instrukcją tego, jak strony będą działały w ich relacji biznesowej. Nie powinna być tylko papierem, który Ty i Twój klient schowacie do szuflady. 

Moim celem jest zapoznanie Cię z praktycznymi aspektami 8 kluczowych elementów umowy z software house’m. W toku lekcji będziemy opierać się na fragmentach rzeczywistej umowy. Zaczynajmy więc. 

1/ Przedmiot umowy na wykonanie aplikacji 

Przedmiot umowy to stwierdzenie nt. tego, co znajduje się w umowie - czyli zasad współpracy oraz tego, co ma z tej współpracy wyniknąć - czyli programu. Kiedy wiadomo co i na jakich warunkach ma powstać, łatwiej analizować progres w budowie aplikacji, a Strony w spójny sposób rozumieją rezultat, jaki chcą osiągnąć. Poza tym, dobrze skonstruowana umowa w relacji z wykonawcą IT jest kluczowa z wielu względów, jednak najważniejszy z nich to przeniesienie na Twój startup autorskich praw majątkowych lub udzielenie  licencji wyłącznej. Przeniesienie praw majątkowych lub udzielenie takiej licencji to clue całej relacji startupu z software house’m - oni są wykonawcą wizji, a efekt za który startup płaci powinien zostać prawnie przypisany w kontrolę startupu. 

Przedmiot umowy o wykonanie aplikacji możemy więc sformułować np. w taki sposób:

1. Przedmiotem Umowy jest:
   1. wykonanie przez Wykonawcę Aplikacji wraz z Dokumentacją i jej wdrożenie na Infrastrukturę w zakresie objętym Specyfikacją w terminach określonych Harmonogramem;
   2. ustalenie zasad składania Zamówień na prace dodatkowe, tzn. niewchodzące w zakres Specyfikacji;
   3. ustalenie zasad współpracy Stron w zakresie realizacji Umowy i Zamówień, a także praw i obowiązków Stron z tym związanych;
   4. przeniesienie autorskich praw majątkowych na korzystanie z utworów na zasadach określonych w pkt 6 Umowy.

W powyższym przykładzie zwróć uwagę na dwie rzeczy. Po pierwsze, we fragmencie umowy określającym jej przedmiot odwołujemy się do różnych pojęć, które w powyższym przykładzie są wyróżnione dużą literą, np. „Aplikacja”, „Dokumentacja”, „Specyfikacja”, „Harmonogram” „Zamówienia”. Po drugie, nie regulujemy dokładnie przeniesienia praw autorskich, a jedynie wskazujemy, w którym miejscu umowy znajdują się dokładne zapisy na ten temat. Dlaczego tak się dzieje? Ano dlatego, że trudno byłoby opisać w przedmiocie umowy dokładnie jakie funkcje ma mieć aplikacja, jaki ma być backend, jaki frontend itd., itp. Podobnie przeniesienie praw autorskich wymaga poświęcenia mu odrębnej przestrzeni w umowie, która ma być uporządkowana i czytelna. Dla porządku i lekkości tworzymy zwykle w umowie z wykonawcą IT słowniczek. Wprowadzamy wtedy paragraf zatytułowany Definicje, który może wyglądać w ten sposób:

DEFINICJE

1. Ilekroć w Umowie zostaną użyte pojęcia pisane dużą literą, Strony nadają im poniższe znaczenie:

1.1.1. Dokumentacja – dokumentacja dotycząca Systemu powstała w wyniku realizacji Umowy, zarówno w postaci elektronicznej, jak i papierowej.

1.1.2 Harmonogram – szczegółowy harmonogram realizacji prac objętych Specyfikacją. Harmonogram jednocześnie opisuje określoną przez Zamawiającego priorytetyzację prac (tj. preferowaną kolejność wykonywania zadań). Harmonogram stanowi Załącznik nr 2 [Harmonogram].

1.1.3. Specyfikacja – szczegółowy opis oprogramowania i wymaganej Dokumentacji, które mają zostać dostarczone Zamawiającemu przez Wykonawcę w ramach Wynagrodzenia określonego w pkt 5.1 Umowy. Specyfikacja nie zawiera opisu ewentualnych prac dodatkowych, których wykonanie będzie następowało na podstawie Zamówień (opis świadczeń objętych Zamówieniem będzie określony w dokumencie Zamówienia). Specyfikacja stanowi Załącznik nr 1 [Specyfikacja].

itd.

Jak widzisz na przykładzie tych dwóch zapisów umowy - jej przedmiotu i części zawierającej definicje - oprócz samej umowy, bardzo istotne są załączniki do niej. O ile w umowie regulujemy tylko warunki brzegowe, o tyle np. w Specyfikacji precyzujemy oczekiwania funkcjonalne, techniczne, UX, UI, itd. W wyżej przytoczonym wzorze Definicji mowa jest również o Dokumentacji - pamiętaj, że software house powinien oddać dokumentację techniczną aplikacji - jest to dla startupu ważne choćby dlatego, że może chcieć utrzymywać i rozwijać ją później z inną firmą IT niż wykonawca. 

Załączniki grają szczególną rolę z jeszcze innego powodu. To głównie one pozwalają dostosować umowę do metodyki, w której realizowany jest projekt. Jeżeli korzystasz z metodyk zwinnych takich jak Agile czy Scrum, pamiętaj, żeby w załącznikach skupić się na harmonogramie i kamieniach milowych poszczególnych sprintów, a w umowie na trosce o bieżącą komunikację, np. poprzez wyznaczenie osób do kontaktu i odpowiedzialnych za poszczególne decyzje w wyraźnie określonych obszarach oraz warunkach odbioru poszczególnych etapów projektu. Jeśli realizujesz projekt w metodyce kaskadowej, koniecznie kilkukrotnie przemyśl opis wymagań które ma spełniać aplikacja przy odbiorze, budżecie i samej czynności odbioru. Do tego ostatniego jeszcze w niniejszym poradniku wrócimy. Teraz powróćmy do przedmiotu umowy. Zwykle w tej części kontraktu IT znajdują się również tzw. oświadczenia Stron. 

Np.: Wykonawca oświadcza tu, że udziela gwarancji na aplikację; że zobowiązuje się wykonać aplikację z zachowaniem najwyższej staranności; że członkowie Personelu oraz Podwykonawcy będą posiadali umiejętności i doświadczenie odpowiednie do wykonania przedmiotu Umowy; a wspólnie Strony oświadczają, że nie istnieją przeszkody do współpracy (np. równoległe relacje biznesowe z konkurentem). 

W oświadczeniach też może pojawić się zapis, czy Wykonawca może powierzyć realizację części prac Podwykonawcom. 

2/ Klauzula osób odpowiedzialnych za realizację

Umowę podpisują osoby reprezentujące Strony czyli najczęściej CEO software house’u i prezes startupu. Ale wiadomo, że nie oni będą te umowę wykonywali, bo umowę w praktyce wykonują:

pracownicy/podwykonawcy piszący program 

testerzy 

UX-owcy

osoby koordynujące i nadzorujące projekt (menadżerowie, kierownicy) 

Dlatego w przypadku projektów IT, w których kluczowe jest współdziałanie Zamawiającego z software house’em, klauzula dot. osób odpowiedzialnych za realizację projektu jest tak naprawdę jedną z absolutnie najważniejszych.

Trzeba w umowie uporządkować role i poinstruować zespół, kto za co odpowiada, żeby uniknąć chaosu, żeby przepływ informacji był płynny a ważne decyzje były podejmowane ze świadomością ich konsekwencji. 

W umowie powinien znaleźć się np. taki zapis:

[Zasady komunikacji Stron]

1. Strony ustanawiają następujących Kierowników Projektu:

1.1. Kierownik Projektu Wykonawcy: [imię i nazwisko], [e-mail], [nr telefonu];

1.2. Kierownik Projektu Zamawiającego: [imię i nazwisko], [e-mail], [nr telefonu].

2. Wszelkie zmiany w zakresie Umowy i Zamówień wymagają zawarcia aneksu w formie pisemnej pod rygorem nieważności, chyba że Umowa stanowi inaczej.

Po każdej stronie umowy powinien zostać wyznaczony Kierownik, który będzie nadzorował realizację projektu i koordynował współpracę. 

3/ Zarządzanie zmianą 

Byłoby idealnie gdybyśmy mogli wprowadzić do naszej umowy z software house’m taki zapis:

Zamawiający może zwrócić się do Wykonawcy z wnioskiem o zmianę funkcjonalności określonej Specyfikacją lub Zamówieniem, bez uprawnienia Wykonawcy do podwyższenia Wynagrodzenia z tego tytułu, a Wykonawca nie odmówi powyższego bez ważnych powodów.

Jednak jest to sformułowanie bardzo proklienckie i rzadko który software house na nie przystanie, ponieważ w praktyce częsty jest następujący scenariusz:

-> zamawiający zgłasza, że dopatrzył się „niezgodności ze specyfikacją” i odmawia odbioru przedmiotu umowy, albo oczekuje od Wykonawcy, by ten poprawił oprogramowanie w ramach kodeksowej rękojmi lub według gwarancji udzielonej w umowie,

-> wykonawca weryfikuje otrzymane zgłoszenie i dochodzi do wniosku, że problemu z kompletnością nie ma, ponieważ dany element lub określona właściwość nie były ujęte w dokumentacji,

-> w efekcie pojawia się zapotrzebowanie na dodatkowe prace, ale strony spierają się o to, czy powinien je sfinansować wykonawca (jako odpowiedzialny za nieprawidłowość) czy zamawiający (który uświadomił sobie nową potrzebę dotyczącą oprogramowania).

Istnieje szereg sposobów, aby uniknąć tego rodzaju sporów:

a) najpewniejszym sposobem jest sporządzenie konkretnej i jasnej specyfikacji na starcie projektu

b) strony powinny trzymać się zasady, że od początku do końca projektu każdą z nich reprezentuje jedna i ta sama osoba (ang. single point of contact ) – w przeciwnym wypadku ten kto zamawiał / przyjmował zamówienie, może interpretować dokumentację inaczej niż ten, kto oprogramowanie wydaje / odbiera;

c) rozwiązaniem może być też np. powołanie mieszanego zespołu złożonego z przedstawicieli obu stron (określanego np. jako Komitet Sterujący), który będzie roboczo ustalał, co w konkretnych przypadkach jest wadą lub brakiem;

d) umowa powinna przewidywać prawo wykonawcy do kwestionowania „usterek” zgłaszanych przez zamawiającego i interpretowania ich jako wniosków o zmianę specyfikacji (ang. change request , CR) – przy czym prawo to powinno być ukształtowane w sposób satysfakcjonujący dla obu stron, tak aby wykonawca nie nadużywał go przy rzeczywistych usterkach.

e) całkiem dobry sposób - wybór metodyki zwinnej 

Opisane wcześniej konflikty są rzadkie w projektach Agilowych, ponieważ model agile jest elastyczny, złożony z wielu sprintów, pod koniec których Zamawiający weryfikuje czy aplikacja odpowiada jego oczekiwaniom. Mówimy w Agile o tzw. definicji ukończenia sprintu.

W tej definicji określa się warunki brzegowe, po spełnieniu których można uznać dany sprint za ukończony z wynikiem pozytywnym. 

Ta definicja zawiera najczęściej takie elementy:

- przyrost danego sprintu musi być kompatybilny z poprzednimi przyrostami, innymi słowy kolejny element oprogramowania musi integrować się z poprzednim 

- kod elementu wytworzonego w danym sprincie jest kompletny 

- zostały przeprowadzone z wynikiem pozytywnym testy, tzw. historyjki sprintu 

- element spełnia wymagania prawne np.: zasadę privacy by design, której omówienie znajdziesz w tym rozdziale handbooka: link

Jak zatem najlepiej uregulować tę kwestię ?

Np. w ten sposób:

2. W związku ze stosowaniem zwinnych metodyk projektowych Zamawiający może zwrócić się do Wykonawcy z wnioskiem o zmianę funkcjonalności określonej Specyfikacją lub Zamówieniem, bez uprawnienia Wykonawcy do podwyższenia Wynagrodzenia z tego tytułu, a Wykonawca nie odmówi powyższego bez ważnych powodów, przy czym powyższe zobowiązanie nie ma zastosowania w następujących przypadkach:
   1. gdy taka nowa / zmieniona funkcjonalność miałaby mieć wyższy poziom złożoności;
   2. gdy pierwotnie określona funkcjonalność została już wykonana i odebrana przez Zamawiającego, przy czym ustala się, że w ramach procedury Odbioru Zamawiający tylko jednokrotnie może wnieść o zmianę konkretnej funkcjonalności – każda kolejna zmiana tej samej funkcjonalności powinna podlegać odrębnemu Zamówieniu.  
3. W przypadku, w którym zostanie przedstawiony wniosek o zmianę, o której mowa w pkt 3.13. powyżej, o czas realizacji takiej zmiany przesuwają się wiążące Wykonawcę terminy określone w Harmonogramie i/lub Zamówieniu.
4. Zmiana, o której mowa w pkt 3.13 powyżej, zostanie potwierdzona przez Strony co najmniej drogą poczty elektronicznej.

4/ Wynagrodzenie software house’u 

Modele rozliczania projektów technologicznych można w uproszczeniu zredukować do dwóch grup:

a) Model Ryczałtowy (ang. Fixed Price ¸ FP) przewiduje stałą i z góry umówioną cenę, w ramach której wykonawca zobowiązuje się wykonać zamówienie; zmiany zakresu wprowadzane w toku realizacji projektu – w tym wnioski o zmianę specyfikacji – nie mają wpływu na jego łączny koszt, ale przez to mogą być dla wykonawcy nieopłacalne;

b)  Model nakładowy (ang. Time & Materials , T&M) przewiduje rozliczenie za cały rzeczywisty czas efektywnie poświęcony na realizację zamówienia; w tym przypadku za projekt przedłużający się – na przykład ze względu na dodanie etapu prac uzupełniających – zapłaci Zamawiający.

Łatwo z tego wywnioskować, że korzystniejszy dla startupu jest model wynagrodzenia ryczałtowego. 

Ważne jest też określenie, czy wynagrodzenie jest płatne jednorazowo po odbiorze, miesięcznie czy w ratach, a jeśli tak, to w jakich terminach. Zazwyczaj rozłożenie płatności na części jest dla startupu korzystniejsze. 

Zapisy w tym zakresie mogą mieć np. następujące brzmienie: 

1. Z tytułu realizacji Umowy w zakresie określonym Specyfikacją Wykonawcy przysługuje Wynagrodzenie w łącznej wysokości [xxx] ([xxx]) złotych netto.
2. Wynagrodzenie będzie płatne odrębnie za każdy Etap określony Harmonogramem, w następującej wysokości:

Etap 1 – [xxx] ([xxx]) złotych netto;

Etap 2 – [xxx] ([xxx]) złotych netto.

3. Wykonawca wystawi fakturę VAT za dany Etap po dokonaniu Odbioru (przez co rozumie się także jednostronne podpisanie Protokołu Odbioru w przypadkach określonych w pkt X Umowy).

4. Wynagrodzenie będzie płatne na podstawie faktury VAT wystawionej przez Wykonawcę na nr rachunku bankowego wskazany na tej fakturze. Za dzień zapłaty Wynagrodzenia uważa się dzień uznania rachunku Wykonawcy.

5. Kwoty należne Wykonawcy zgodnie z Umową i Zamówieniem nie zawierają podatku VAT (tj. są to kwoty netto), który zostanie doliczony zgodnie z obowiązującymi przepisami prawa w chwili wystawienia faktury VAT (o ile podatek VAT ma zastosowanie)

6. Termin płatności faktury VAT wynosi 14 (czternaście) dni i liczony będzie od daty wysłania Zamawiającemu faktury.

7. Faktury w formie elektronicznej będą wysyłane na adres mailowy [xxx], na co Zamawiający niniejszym wyraża zgodę.

Zwróć uwagę na punkt 3, w którym mowa o tym, że faktura zostanie wystawiona dopiero po podpisaniu przez startup protokołu odbioru. To oznacza, że wynagrodzenie będzie należne za poprawne zrealizowanie części projektu, które odpowiada oczekiwaniom startupu określonym w Specyfikacji. To bardzo ważny zapis, a odbiór jest wyjątkowo newralgicznym momentem w projekcie IT, bo najczęściej wybuchają w nim spory, które ujawniają, czy specyfikacja zamówienia została sporządzona wystarczająco precyzyjnie czy pozostawiała pola swobodnej interpretacji każdej ze Stron. Przypominam Ci, że niepozostawiająca wątpliwości Specyfikacja Projektu jest kluczowym punktem startowym każdego projektu IT. Zaniedbanie tego etapu negocjacji kontraktu jest fatalne w skutkach. 

Ważna kwestia związana z zapisami o wynagrodzeniu to kwestia momentu przejścia praw autorskich. 

Z punktu widzenia software house'u dobrym myśleniem strategicznym jest przesunięcie przejścia autorskich praw majątkowych do oprogramowania na moment zapłaty wynagrodzenia, a nie odbioru. 

Dla startupu lepiej jest nie uregulować tego w umowie, gdyż wtedy - zgodnie z art. 64 ustawy o prawach autorskich i prawach pokrewnych - przejście praw nastąpi z chwilą odbioru. 

Software house może nalegać, aby przesunąć zapisem umownym przejście praw na moment zapłaty wynagrodzenia, ponieważ zmieni w ten sposób rozkład ryzyka pomiędzy stronami. 

Żeby zilustrować Ci to zagadnienie, proszę wyobraź sobie taką sytuację. Projekt jest realizowany z opóźnieniem w harmonogramie prac. Za opóźnienia są w umowie przewidziane kary umowne dla Wykonawcy. Następuje spór, czyją winą są te opóźnienia. Zamawiający twierdzi, że są winą Wykonawcy, a Wykonawca że winą braku współdziałania ze strony Zamawiającego. 

Jeżeli punktem wyjścia dla software house’u w tej sytuacji jest przejście praw w momencie odbioru, to Zamawiający wypłaci wynagrodzenie z potrąceniem kar umownych i może powiedzieć, że jeśli software house uważa że opóźnienia były jego winą i Zamawiający kary naliczył niesłusznie, to może wejść na drogę sądową. Która, jak powszechnie wiadomo, jest długa, trudna i żmudna.  

Jeżeli natomiast software house przesunie moment przejścia praw na moment wynagrodzenia, to ryzyko się zmienia. 

Startup owszem, potrąci kary umowne z wynagrodzenia, ale jeżeli po wielu latach sporu w sądzie, sąd uzna że rację miał Wykonawca i kary były niesłuszne, to okaże się, że wynagrodzenie nie zostało uiszczone w prawidłowej wysokości, więc prawa autorskie nie przeszły na Zamawiającego. Zamawiający znajduje się wtedy w bardzo niekorzystnej pozycji, bo w efekcie korzystał z oprogramowania wiele lat bez uprawnień. 

Zmiana ryzyka polega tutaj na tym, że w pierwszym przypadku to Wykonawca musi wykazywać że zrobił wszystko ok i kary były niesłuszne. W drugim przypadku to Zamawiający musi wykazywać, że naliczył kary słusznie i zapłacił wynagrodzenie, które dało mu uprawnienia korzystania z oprogramowania. 

Jeśli w umowie moment przejścia praw autorskich będzie przesunięty na moment wynagrodzenia, to przy konflikcie pod koniec projektu, każdy prawnik doradzi startupowi żeby wypłacił całe wynagrodzenie, a potem dopiero zażądał zapłaty kar zamiast potrącać je z wynagrodzenia. 

W efekcie to startup musi dochodzić w sądzie zapłaty kar, na niego jest przerzucona udowodnienie swoich racji i koszty postępowania, a software house ma w kasie całe wynagrodzenie za wdrożenie.  

5/ Prawa autorskie do aplikacji 

Ochrona programu komputerowego, jakim jest aplikacja SaaS obejmuje formę jego wyrażenia, a nie idee i zasady, o czym więcej przeczytasz w tym rozdziale handbooka: link

To, co chcę wyjaśnić Ci w tym miejscu, to ważne rozróżnienie na kod źródłowy (backend aplikacji) oraz UI, czyli interfejs użytkownika. Interfejs użytkownika (UI) to część systemu lub aplikacji, która pozwala na interakcję między użytkownikiem a urządzeniem lub oprogramowaniem. W jego skład wchodzą różnorodne elementy graficzne jak przyciski, menu, ikony, a także aspekty interakcyjne i strukturalne, które mają ułatwić obsługę. Z punktu widzenia Prawa autorskiego, tylko kod źródłowy lub wynikowy, czyli warstwa programistyczna, kwalifikuje się jako program komputerowy, natomiast warstwa graficzna, będąca tym, co użytkownicy najczęściej kojarzą z danym oprogramowaniem, nie jest uznawana za program komputerowy w rozumieniu Prawa autorskiego. Jest to oddzielna część, chroniona na innych zasadach przez ogólne przepisy dotyczące utworów. Zgodnie z orzeczeniem Trybunału Sprawiedliwości UE z 22 grudnia 2010 r. (sprawa C-393/09), graficzny interfejs użytkownika nie jest uznawany za formę wyrażenia programu komputerowego. W rezultacie, pod kątem prawa autorskiego, program komputerowy i interfejs użytkownika to odrębne utwory. 

Co to implikuje? Że w umowie z software house’m musisz zadbać o nabycie praw zarówno do programu, jak i pozostałych elementów aplikacji. 

Ale w jaki sposób nabyć te prawa? Są dwie możliwości:

1/ przeniesienie przez software house za wynagrodzeniem autorskich praw majątkowych do aplikacji i pozostałych elementów na startup

2/ udzielenie startapowi licencji na korzystanie z aplikacji na określonych warunkach, zasadniczo będzie to licencja wyłączna. 

Przeniesienie praw autorskich majątkowych jest podobne do umowy sprzedaży rzeczy materialnej, a umowa licencji jest podobna do umowy najmu. 

Jeżeli sprzedamy samochód, to nie będziemy mogli dalej z niego korzystać i dokładnie tak jest z umową, która przenosi całość praw autorskich majątkowych na nabywcę. Ale, możemy np. wymontować z auta tłumik i sprzedać go innemu nabywcy. Auto i tłumik to przekładając przykład na język prawny dwa różne pola eksploatacji. Możemy więc przenieść autorskie prawa majątkowe do całego utworu, a możemy do poszczególnych elementów, którymi są pola eksploatacji. 

Umowa licencji z kolei umożliwia korzystanie z autorskich praw majątkowych, co oznacza, że zbywca tych praw nadal jest ich właścicielem, ale umożliwia też korzystanie innemu podmiotowi.

Licencja może być wyłączna lub niewyłączna. Licencja wyłączna jest podobną sytuacją, jak wynajem auta. W momencie wynajmowania auta już nie możesz z niego korzystać, natomiast najemca będzie mógł z niego korzystać przez cały okres wynajmu na wyłączność, mimo że auto pozostało w Twoim majątku. Po zakończeniu okresu na jaki licencja wyłączna została udzielona, ona wygasa, więc możesz udzielić takiej licencji innemu klientowi. 

Umowa licencji niewyłącznej umożliwia z kolei udzielenie możliwości korzystania z oprogramowania nieograniczonej liczbie podmiotów. Tak działa np. Microsoft, który udziela licencji do swoich programów komputerowych na całym świecie i w jednym czasie nieograniczonej liczbie odbiorców. 

W przypadku umów licencji, tak samo jak w przypadku umów przeniesienia autorskich praw majątkowych mają znaczenie pola eksploatacji. W każdej umowie dot. autorskich praw majątkowych pojawiają się więc zapisy dot. pól eksploatacji, które wyjaśniają, w jakim zakresie przechodzi na nabywcę własność utworu, albo w jakim zakresie może z niego korzystać. 

Co do zasady te pola eksploatacji, czyli sposoby używania oprogramowania to:

- trwałe lub czasowe zwielokrotnienie programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie,

- tłumaczenie, przystosowywanie, zmiana układu lub jakiekolwiek inne zmiany w programie,

- rozpowszechnianie programu lub jego kopii 

Co ważne, prawo autorskie gwarantuje nabywcy oprogramowania pewne uprawnienia, niezależnie czy będą zawarte w umowie czy nie. 

Są to uprawnienia do:

- sporządzenia kopii zapasowej (jeżeli jest to niezbędne do korzystania z programu komputerowego),

- obserwowania, badania i testowania funkcjonowania programu komputerowego w celu poznania jego idei i zasad (jeśli następuje to w trakcie wprowadzania, wyświetlania, stosowania, przekazywania lub przechowywania programu),

- zwielokrotniania kodu lub tłumaczenia jego formy, jeżeli jest to niezbędne do uzyskania informacji koniecznych do osiągnięcia współdziałania niezależnie stworzonego programu komputerowego z innymi programami.

Nie możemy też zapomnieć o tzw. prawach zależnych. W umowach przenoszących autorskie prawa majątkowe startup powinien zadbać, aby software house przeniósł na niego nie tylko autorskie prawa majątkowe, ale także wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego. 

Co to oznacza dla startupu?

Oznacza, że będzie mógł:

- modyfikować program (czyli rozwijać oprogramowanie)

- albo tego rodzaju prace będzie mógł zlecić innej firmie.

Te kwestie są najważniejszym przedmiotem negocjacji pomiędzy stronami umów IT na wykonanie aplikacji. Trzeba zaadresować wszelkie uprawnienia, w jaki sposób startup będzie mógł korzystać z zakupionego oprogramowania. 

Dla uproszczenia i podsumowania, można powiedzieć, że są 3 grupy uprawnień, które może uzyskać Zamawiający oprogramowanie klient software house’u:

1) zwielokrotnianie 

2) wprowadzanie zmian czyli modyfikacja

3) rozpowszechnianie 

Uprawnieniem, którego udziela się zawsze jest zwielokrotnienie, bo ono polega po prostu na instalacji oprogramowania w infrastrukturze klienta i korzystaniu do realizacji swoich procesów biznesowych. Startup interesuje pełnia tych praw, zatem możliwość modyfikacji i rozpowszechnienia również powinna znaleźć się w naszych zapisach. A jak one mogą brzmieć w świetle tego, co przed momentem przeczytałeś?

Np. w ten sposób:

5. Z chwilą dokonania Odbioru przez Zamawiającego, Wykonawca przekazuje Zamawiającemu autorskie prawa majątkowe do Utworów (przy.red. - oprogramowania i UI) bez ograniczeń czasowych i terytorialnych, na wszystkich znanych w chwili zawarcia Umowy polach eksploatacji, a w szczególności:
   1. w zakresie utworów będących programami komputerowymi:
2. trwałe lub czasowe zwielokrotnianie programu komputerowego w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie, w tym wprowadzenie, wyświetlanie, stosowanie, przekazywanie i przechowywanie niezbędne do zwielokrotniania;
3. tłumaczenie, przystosowywanie, zmiany układu lub jakiekolwiek inne zmiany w programie komputerowym;
4. rozpowszechnianie, w tym wprowadzanie do obrotu, użyczenie lub najem utworów, a także rozpowszechnianie w inny sposób;
5. prawo do zwielokrotniania kodu źródłowego, tłumaczenia jego formy (dekompilacja), włączając w to prawo do trwałego lub czasowego zwielokrotniania w całości lub w części jakimikolwiek środkami i w jakiejkolwiek formie, testowania, a także opracowania (tłumaczenia, przystosowania lub jakichkolwiek innych zmian) bez ograniczania warunków dopuszczalności tych czynności, w szczególności (ale nie wyłącznie) w celu wykorzystania dla celów współdziałania z programami komputerowymi lub rozwijania, wytwarzania lub wprowadzania do obrotu, użyczania, najmu lub innych form korzystania o podobnej lub zbliżonej formie;
   2. w zakresie utworów niebędących programami komputerowymi:
6. w zakresie utrwalania i zwielokrotniania – trwałe lub czasowe zwielokrotnianie utworów w całości lub w części dla wewnętrznych potrzeb Zamawiającego związanych z korzystaniem z tych utworów, w tym utrwalanie i zwielokrotnianie dowolną techniką;
7. w zakresie obrotu oryginałem albo egzemplarzami, na których utwór utrwalono – wprowadzanie do obrotu, użyczenie lub najem oryginału albo egzemplarzy;
8. w zakresie rozpowszechniania utworu w sposób inny niż określony powyżej – publiczne wykonanie, wystawienie, wyświetlenie, odtworzenie oraz nadawanie i reemitowanie, a także publiczne udostępnianie utworu w taki sposób, aby każdy mógł mieć do niego dostęp w miejscu i w czasie przez siebie wybranym, w tym w sieci Internet oraz innych sieciach teleinformatycznych i platformach cyfrowych.

Wraz z przekazaniem autorskich praw majątkowych Wykonawca przenosi na Zamawiającego prawo do zezwalania na wykonywanie zależnego prawa autorskiego do Utworów Dedykowanych i ich opracowań.

6. W momencie przeniesienia na Zamawiającego autorskich praw majątkowych do Utworów Dedykowanych przenoszona jest na Zamawiającego także własność nośnika fizycznego, na którym utwory te utrwalono. 
7. Sposób przekazywania kodów źródłowych zostanie ustalony przez Strony w toku współpracy.
8. Wykonawca zobowiązuje się zapewnić, że osoby uprawnione z tytułu osobistych praw autorskich do Utworów Dedykowanych nie będą wykonywać takich praw w stosunku do Zamawiającego.

6/ Procedura odbioru 

Kluczowe jest, aby procedura odbioru była sprawiedliwa dla obu stron, tj. żeby zachować równowagę między ochroną praw klienta do otrzymania funkcjonalnego produktu, a uczciwym traktowaniem pracy włożonej przez software house w jego powstanie. 

Co więc powinno znaleźć się w zapisach dot. odbioru?

Definicja Kryteriów Akceptacji: W umowie powinny zostać określone jasne kryteria, według których oprogramowanie będzie oceniane i akceptowane. Mogą to być np. spełnienie określonych funkcji, wydajności, czy zgodności z dokumentacją.

Testy i Recenzje: Umowa powinna określać, kto i w jaki sposób będzie przeprowadzał testy oprogramowania, najlepiej aby przeprowadzał je i software house i startup i strony trzecie. 

Procedura zgłaszania i rozwiązywania błędów: Należy ustalić proces zgłaszania ewentualnych błędów lub niedociągnięć w oprogramowaniu oraz określić terminy, w jakich software house ma obowiązek je naprawić.

Finalna Akceptacja: Koniecznie trzeba określić procedurę finalnej akceptacji oprogramowania przez startup po zakończeniu testów i ewentualnych poprawek.

7/ Kary umowne 

Kary umowne w kontraktach IT są rynkowym standardem. Nie masz podstaw do obaw, jeśli zechcesz je zastrzec w umowie z software house’m, ponieważ jako klient płacisz za usługi software house’u i możesz być z nich niezadowolony. Z jednej strony kary są zabezpieczeniem przed opóźnieniem lub tzw. zwłoką i gwarantują, że firma z którą współpracujesz będzie działać tak, by przedstawić aplikację do odbioru w terminie. Z drugiej strony, mogą też chronić przed pewnego rodzaju naruszeniami, np.: naruszeniem obowiązku zachowania w poufności informacji na temat Twojej aplikacji. 

Prawo wypowiada się na temat kar umownych w ten sposób:

Art. 483 § 1 KC mówi, że „można zastrzec w umowie, że naprawienie szkody wynikłej z niewykonania lub nienależytego wykonania zobowiązania niepieniężnego nastąpi przez zapłatę określonej sumy”. 

Proszę zwróć uwagę, że ta suma musi być oznaczona, ale nie musi być określona kwotą, a np. jako % wartości zamówienia. Ten % wartości zamówienia najczęściej pojawia się w umowach na wykonanie aplikacji jako określenie limitu kar umownych. 

np. „Kary umowne za opóźnienia nie przekroczą łącznie ……% Wynagrodzenia”.

„Łączny limit odpowiedzialności Wykonawcy na jakiejkolwiek podstawie z tytułu niewykonania lub nienależytego wykonywania jakichkolwiek zobowiązań wynikających z Umowy i Zamówienia wynosi X % Wynagrodzenia wypłaconego na podstawie Umowy lub Zamówienia, którego szkoda dotyczy.”

Na to będzie nalegał software house, aby ostateczna suma kar była limitowana, a im wyższy % wynagrodzenia mogą stanowić kary tym wyższe wg software house’u to wynagrodzenie powinno być. To jest element negocjacji umowy. Zwyczajowo kary oscylują pomiędzy 70 a 100% wartości Wynagrodzenia. 

Specyfika kontraktów IT jest też taka, że wprowadza się różne rodzaje naruszeń i odpowiadające im różne wysokości kar. 

W umowach na wykonanie aplikacji uzależnia się wysokość kar od wielokrotności naruszeń i wprowadza kary progresywne, jak tutaj:

„ Zamawiający naliczy kary umowne w przypadku opóźnienia w zgłoszeniu do Odbioru każdego z Etapów opisanych Harmonogramem, w wysokości: 

1) (…) PLN za każdy z rozpoczętych pierwszych X dni opóźnienia, 

2) (…) za każdy rozpoczęty dzień opóźnienia, począwszy od Y dnia opóźnienia aż do Z dnia opóźnienia”. 

3) (…) PLN za każdy rozpoczęty dzień powyżej Z dnia opóźnienia. ”

To jest metoda na dyscyplinowanie software house’u, żeby realizował projekt zgodnie z Harmonogramem. 

Kolejna sprawa, której trzeba mieć świadomość to to, że przesłanką wynikającą z KC do żądania kary umownej jest niewykonanie lub nienależyte wykonanie, ale będące następstwem okoliczności, za które odpowiedzialność ponosi Wykonawca. To jest reguła kodeksowa. Natomiast, tę zasadę będziemy chcieli umownie ominąć, tzn. tak ukształtować postanowienia umowne, żeby Wykonawca przyjął odpowiedzialność z tytułu określonych w umowie okoliczności, za które z mocy KC odpowiedzialności by nie ponosił. 

Wtedy mamy taki wariant kary umownej, który nazywamy zastrzeżeniem gwarancyjnym. To jest umowne ustalenie obowiązku zapłaty określonej sumy w razie niewykonania lub nienależytego wykonania zobowiązania spowodowanego okolicznościami, za które software house nie ponosi odpowiedzialności, czyli np. za uchybienie terminu bez względu na przyczynę. Jest to tzw. odpowiedzialność na zasadzie ryzyka. Zwykle wyłącza się z tej odpowiedzialności np. siłę wyższą, którą mogą być okoliczności zaburzające funkcjonowanie firmy niezależne od niej, np. epidemia dezorganizująca pracę czy pożar niszczący siedzibę software house’u. Wyłącza się również okoliczności, do których przyczyni się Twój startup - np. brak współdziałania w zakresie dostarczenia niezbędnych do realizacji projektu materiałów. Jak taki zapis może wyglądać? Spójrz poniżej:

np. „ O ile wyraźnie nie postanowiono inaczej, w zakresie kar umownych opisanych Umową, odpowiedzialność za opóźnienie oznacza przyjęcie przez Wykonawcę odpowiedzialności za przekroczenie terminu wskazanego w Umowie lub wyznaczonego zgodnie z postanowieniami Umowy na zasadzie ryzyka, od której może się uwolnić wykazując, że opóźnienie nastąpiło z przyczyn, za które odpowiedzialność ponosi Zamawiający lub było spowodowane przyczynami o charakterze siły wyżej”.

Kolejna kwestia to jest zapis o tym, czy kara umowna jest wyłączna czy zaliczalna. Chodzi o to, że jeżeli strony nie wpiszą w umowie, że naliczenie kary nie wyłącza możliwości dochodzenia odszkodowania na zasadach ogólnych z art. 471 KC to będziemy mieć karę tzw. wyłączną, co znaczy że jako klient software house’u nie będziesz uprawniony dochodzić w sądzie odszkodowania w przypadku, gdy szkoda jest wyższa od kary umownej. To jest bardzo korzystna sytuacja dla Wykonawcy, dlatego my będziemy chcieli zawrzeć w umowie dokładnie taki zapis, co spowoduje, że kara będzie zaliczalna. 

Zapis o karze zaliczalnej może wyglądać tak:

„Naliczenie zastrzeżonych Umową kar umownych nie wyłącza możliwości dochodzenia odszkodowania na zasadach ogólnych do pełnej wysokości szkody poniesionej przez Zamawiającego w związku ze zdarzeniem, które było podstawą naliczenia danej kary”. 

Rzadko uda się przekonać software house do zapisu o karze kumulatywnej, czyli na przyznanie nam uprawnienia do łącznego dochodzenia kary umownej i odszkodowania na podstawie art. 471 KC. Kara zaliczalna jest dość sprawiedliwym rozwiązaniem. 

8/ Odstąpienie od umowy i wykonanie zastępcze 

Umowa o wykonanie aplikacji jest co do zasady umową o dzieło. W związku z tym, aby ją rozwiązać możemy od niej odstąpić (inaczej niż w przypadku świadczenia usług, gdzie stosujemy mechanizm wypowiedzenia). 

W myśl przepisów Kodeksu Cywilnego możemy odstąpić od umowy z software housem wtedy, gdy:

• spóźnia się z realizacją projektu na tyle, że ukończenie aplikacji w uzgodnionym umownie terminie jest nieprawdopodobne - tym bardziej, gdy termin już upłynął;
• wykonuje projekt wadliwie, tzn. niezgodnie ze standardami rynkowymi albo sprzecznie z umową, tzn. samodzielnie dokonuje zmian w zakresie tego, co było umówione. 

Żeby odstąpić od umowy w drugim scenariuszu, musisz najpierw dać software house’owi szansę i wezwać go do zmiany sposobu wykonania umowy. Możesz to zrobić mailowo lub pocztą. 

Kiedy to zrobisz i nie przyniesie to oczekiwanych rezultatów, możesz skorzystać z tzw. wykonania zastępczego, które polega na tym, że na koszt software house’u zamówienie może być przekazane do wykonania innemu podmiotowi. 

Software house też może odstąpić od umowy i zasadniczą ku temu przesłanką będzie brak współdziałania z Twojej strony w realizacji projektu albo nieterminowa zapłata transzy. 

Co się dzieje, kiedy jedna ze stron użyje odstąpienia od umowy?

Art. 395 § 2 KC mówi nam, że w sytuacji odstąpienia „umowa uważana jest za niezawartą”. Skutek tego jest taki, że każda ze stron jest wtedy zobowiązana zwrócić tej drugiej dotychczasowe świadczenia. 

Wygląda to wtedy np. tak:

„ 1. W razie wykonania przez Zamawiającego umownego prawa odstąpienia od umowy z przyczyn, za które odpowiedzialność ponosi Wykonawca, oświadczenie o odstąpieniu ma skutek w stosunku do całej umowy. W takim przypadku:_

1) Zamawiający zwróci Wykonawcy lub usunie w sposób uniemożliwiający produkcyjne wykorzystanie wszelkie przekazane przez Wykonawcę Produkty lub inne świadczenia, a Wykonawca zobowiązany będzie zwrócić otrzymane Wynagrodzenie w terminie ……………… dni od daty otrzymania oświadczenia Zamawiającego o odstąpieniu od umowy.”

W świecie IT ten skutek odstąpienia w postaci obowiązku zwrotu wzajemnych świadczeń jest niebywałym problemem, zarówno dla software house’u jak i jego klienta. Software house jako wykonawca systemu stawia do pracy duży zespół, ponosi koszty wytworzenia oprogramowania dedykowanego dla Zamawiającego, część tego systemu powstaje…i co zrobić z tym, co wykonano dotychczas, gdy strony są niezadowolone ze współpracy?

Żeby ten problem rozwiązać, jest pewna wariacja klauzuli umownej o odstąpieniu, tzn. przewidzenie w umowie, że odstąpienie dot. tylko niektórych skutków umowy. 

Taki wariant zapisu o odstąpieniu w umowach IT nazywa się odstąpieniem częściowym w odniesieniu do produktów nieodebranych. 

Wygląda on tak:

„ 1. W razie wykonania przez Zamawiającego umownego prawa odstąpienia od Umowy z przyczyn, za które odpowiedzialność ponosi Wykonawca, Strony uzgadniają, że oświadczenie o odstąpieniu - o ile Umowa dalej wyraźnie nie stanowi inaczej - ma skutek wyłącznie do nieodebranych Produktów.

2. _W ww. przypadku:_

_1)Zamawiający zachowa Produkty które zostały odebrane (w tym uprawnienia nabyte na podstawie Umowy, takie jak autorskie prawa majątkowe lub udzielone licencje), a Wykonawca:_

_a) zachowa prawo do Wynagrodzenia za odebrane Produkty;_

_b) ma prawo do wynagrodzenia za odebrane Produkty, które nie zostały zapłacone.”

Oprócz kodeksowych reguł odstąpienia, możemy do umowy dodać zapisy, które uregulują tę kwestię bardziej szczegółowo, według naszych potrzeb. Najczęściej wśród przesłanek, od których strony uzależniają powstanie uprawnienia do odstąpienia są: 

→ okoliczności, które stanowią nienależyte wykonanie zobowiązania, czyli np. system jest pisany niezgodnie ze specyfikacją, nie spełnia wymagań  

→ zawiniony brak spełnienia świadczenia w ściśle określonym terminie  

→ rożne okoliczności mające cechy zdarzenia przyszłego i niepewnego, np. wycofał się inwestor Zamawiającego 

Wszystkie te przypadki są zastrzeżeniem prawa do odstąpienia pod warunkiem zawieszającym, czyli jak zdarzy się A, to niejako aktywuje się prawo do odstąpienia. 

Podsumowując, strony powstanie lub wygaśnięcie umownego prawa odstąpienia mogą uzależnić od warunku, w tym od warunku polegającego na określonym zachowaniu jednej ze stron umowy. 

Podsumowanie

Podsumowując, kluczowe zapisy w umowach na wykonanie aplikacji mają fundamentalne znaczenie dla zapewnienia przejrzystości, bezpieczeństwa i efektywności współpracy między zleceniodawcą a wykonawcą. Ważne jest, aby umowa zawierała precyzyjnie określone cele projektu, zakres prac, harmonogram, warunki płatności oraz szczegółowe kryteria akceptacji końcowego produktu. Ponadto, nie można pominąć kwestii związanych z prawami autorskimi oraz odpowiedzialnością za ewentualne błędy. Klauzule dotyczące możliwości wprowadzania zmian w projekcie są równie istotne dla zapewnienia elastyczności oraz efektywnego zarządzania ryzykiem. Dobre zrozumienie i odpowiednie sformułowanie tych kluczowych aspektów w umowie na wykonanie aplikacji może znacząco przyczynić się do sukcesu projektu, zabezpieczając interesy obu stron i minimalizując ryzyko nieporozumień i konfliktów.