W umowie z software housem najważniejsze są 4 zapisy: przeniesienie autorskich praw majątkowych na wymienionych polach eksploatacji, wydanie kodu źródłowego z dokumentacją, procedura odbioru z terminem na uwagi oraz warunki gwarancji i wsparcia po wdrożeniu. Jeśli brakuje któregokolwiek z nich, po zakończeniu projektu nie kontrolujesz własnego produktu.
Poniżej każdy zapis po kolei: po co jest i co zrobić, gdy wykonawca odmawia. Przykładowe sformułowania są jednak tylko poglądowe i nie stanowią porady prawnej. Jeśli jesteś przed wyborem wykonawcy, zacznij od tekstu o tym, jak wybrać software house.
Dlaczego w umowie z software housem licencja na kod to za mało?
Częsta pułapka w umowie z software housem: zamiast przenieść prawa, wykonawca tylko udziela licencji. Tymczasem licencję na czas nieoznaczony twórca może wypowiedzieć (art. 68 ustawy o prawie autorskim). Z kolei licencja bez wskazanego okresu wygasa po pięciu latach (art. 66).
Przeniesienie praw wymaga też formy pisemnej pod rygorem nieważności (art. 53), dlatego ustalenia mailowe nie przenoszą niczego.
Pola eksploatacji
Prawa przechodzą tylko na polach wymienionych w umowie (art. 41 ust. 2), więc zapis „przenosi wszelkie prawa” jest martwy. Dlatego wymień co najmniej: utrwalanie i zwielokrotnianie dowolną techniką, wprowadzanie do obrotu, wprowadzanie do pamięci serwera, udostępnianie w sieci, dystrybucję w App Store i Google Play.
Moment przejścia praw
Standard wykonawcy to przejście praw po zapłacie całości, czyli ostatniej faktury. Tak pracujemy też my. Umowa musi to mówić wprost: z jaką chwilą przechodzą prawa oraz kiedy i w jakiej formie dostajesz kod. Dopisz też wariant, w którym umowa kończy się przed ostatnim etapem: ostatnią fakturą jest wtedy rozliczenie wykonanych prac, a po jej zapłacie kod i prawa przechodzą na Ciebie.
Prawa zależne i modyfikacje
Rozporządzanie opracowaniem utworu zależy od zgody twórcy pierwotnego (art. 2 ust. 2), więc dopisz zgodę na utwory zależne, na modyfikacje kodu i zobowiązanie do niewykonywania praw osobistych.
Z kolei prawa do programu napisanego przez pracownika przysługują pracodawcy z mocy ustawy (art. 74 ust. 3), ale współpraca B2B tej reguły nie obejmuje - stąd kwestia podwykonawców i ich oświadczeń o przeniesieniu praw.
„Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do Utworów powstałych w ramach Umowy, na polach eksploatacji wymienionych w § …, z chwilą zapłaty całego wynagrodzenia, w tym ostatniej faktury, wraz z prawem do modyfikacji i rozporządzania utworami zależnymi.”
Materiał poglądowy, nie porada prawna.
Jaki kod i jakie dostępy musi przekazać software house?
Prawa bez plików to jednak prawo do czegoś, czego nie masz. Dlatego umowa z software housem powinna wymieniać komplet, który dostajesz:
- Kod źródłowy aplikacji i części serwerowej z historią repozytorium.
- Skrypty budowania, konfiguracja środowisk, instrukcja uruchomienia od zera.
- Schemat bazy i migracje, nie tylko zrzut danych.
- Dokumentacja, czyli architektura, integracje i procedura wdrożenia.
- Źródłowe pliki interfejsu i grafiki w wersjach edytowalnych.
- Klucze podpisywania, a także konta w App Store Connect i Google Play na Twoją firmę.
- Wykaz bibliotek zewnętrznych z licencjami.
„Najpóźniej w dniu odbioru końcowego Wykonawca przekaże dokumentację. Jej przekazanie jest warunkiem podpisania protokołu odbioru. W terminie … dni od zapłaty ostatniej faktury Wykonawca przekaże kod źródłowy z historią repozytorium, skrypty budowania, źródłowe pliki interfejsu, klucze podpisywania i wykaz bibliotek.”
Materiał poglądowy, nie porada prawna.
Kto jest właścicielem repozytorium w trakcie projektu?
Zwykle wykonawca - do zapłaty ostatniej faktury. Tak pracujemy też my: każdy klient ma u nas osobne repozytorium projektu, prowadzone tylko dla niego. Sprawdź w umowie trzy rzeczy: że repozytorium jest indywidualne, kiedy i jak przechodzi na Ciebie z pełną historią oraz że dokumentacja jest warunkiem odbioru. Postęp oglądasz natomiast na środowisku testowym, gdzie po każdym etapie klikasz działającą wersję.
Jak opisać zakres prac - fixed price czy time & material?
Zakres należy do załącznika umowy na stworzenie aplikacji: lista funkcji, lista integracji, definicja ukończenia każdej z nich, a także lista rzeczy, których w projekcie nie ma. Ostatni punkt jest najważniejszy, bo spór dotyczy tego, czego nikt nie zapisał.
Jak rozłożyć zakres na etapy i pieniądze, opisaliśmy w tekście o budżetowaniu projektu dedykowanego systemu IT.
| Kryterium | Fixed price | Time & material |
|---|---|---|
| Zakres na starcie | Opisany do poziomu ekranu | Wystarczy kierunek i priorytety |
| Ryzyko niedoszacowania | U wykonawcy, dlatego wycena ma bufor | U zamawiającego |
| Zmiana pomysłu w trakcie | Nowa wycena, a potem aneks | Zmiana priorytetu w kolejnym tygodniu |
| Rozliczenie | Kwoty przypisane do etapów | Raport godzin i stawki z umowy |
| Przewidywalność budżetu | Wysoka przy stałym zakresie | Niższa, więc wymaga limitu miesięcznego |
| Nakład pracy po Twojej stronie | Skupiony na starcie | Decyzje przez cały projekt |
Fixed price wybieraj przy zamkniętym zakresie, gdy aplikacja odtwarza proces działający już w firmie. Time & material - gdy produkt weryfikujesz na użytkownikach; wpisz wtedy limit godzin na miesiąc i stawkę godzinową.
Oba modele porównujemy szerzej w tekście fixed price czy time & material, a od czego zależy budżet, opisujemy w tekście o tym, ile kosztuje aplikacja mobilna.
Procedura zmian
Zapisz formę zgłoszenia zmiany, termin na wycenę, skutek dla terminu i budżetu oraz zasadę, że bez pisemnej akceptacji zmiana nie jest realizowana ani płatna.
Jak zapisać w umowie odbiory aplikacji, kary i gwarancję?
Odbiory i terminy
Odbiór to coś więcej niż mail „wygląda dobrze”. Dlatego umowa na stworzenie aplikacji określa przedmiot odbioru każdego etapu, osoby uprawnione, liczbę dni roboczych na uwagi, czas na poprawki i skutek braku uwag.
Rozdziel też wady blokujące, wstrzymujące odbiór, od uwag kosmetycznych, które nie zatrzymują płatności. Terminy etapów rozpisaliśmy w tekście o tym, ile trwa zbudowanie aplikacji.
„Zamawiający zgłosi uwagi w terminie … dni roboczych od przekazania Etapu, kwalifikując je jako wady blokujące albo uwagi niekrytyczne. Brak uwag w terminie oznacza odbiór bez zastrzeżeń.”
Materiał poglądowy, nie porada prawna.
Kary umowne - po obu stronach
Kara umowna dotyczy tylko zobowiązań niepieniężnych (art. 483 § 1 Kodeksu cywilnego), natomiast za opóźnioną zapłatę służą odsetki. Kary jednostronne to sygnał nierównej umowy, bo Ty też odpowiadasz za zwłokę w odbiorach i przekazaniu dostępów.
Wpisz limit sumy kar jako procent wynagrodzenia netto i stawkę za dzień opóźnienia liczoną od wynagrodzenia za etap. Przepisy nie podają tu widełek, jednak rażąco wygórowaną karę sąd może zmniejszyć na żądanie dłużnika (art. 484 § 2 Kodeksu cywilnego). Bez limitu wykonawca przy pierwszym poślizgu liczy raczej koszt wyjścia z umowy niż naprawy.
„Za opóźnienie w oddaniu Etapu Wykonawca zapłaci karę umowną w wysokości …% wynagrodzenia za Etap za każdy dzień. Za zwłokę w odbiorze Zamawiający zapłaci karę w tej samej wysokości. Suma kar każdej ze Stron nie przekroczy …% wynagrodzenia netto.”
Materiał poglądowy, nie porada prawna.
Gwarancja, rękojmia i wsparcie po wdrożeniu
Rękojmia przy umowie o dzieło wynika z przepisów i trwa dwa lata (art. 568 Kodeksu cywilnego). Między firmami można ją jednak umownie ograniczyć albo wyłączyć (art. 558 § 1) - sprawdź, czy projekt umowy tego nie robi bez gwarancji w zamian.
Gwarancja jest natomiast umowna - w naszych projektach trwa 3 miesiące od odbioru końcowego i jest wliczona w cenę - i wymaga jednej definicji: co jest błędem objętym gwarancją, a co nową funkcją płatną osobno.
Dopisz czasy reakcji zależne od wagi zgłoszenia, utrzymanie reguluj osobną umową, a gwarancję zachowaj też wtedy, gdy aplikację rozwija inny wykonawca.
Opisz aplikację w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Na życzenie dołączamy też wzór zakresu prac, który może stać się załącznikiem do umowy. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Co zapisać o RODO, poufności i wyjściu z umowy?
Poufność, RODO i powierzenie przetwarzania
Gdy wykonawca ma dostęp do danych osobowych, choćby na środowisku testowym, potrzebujesz umowy powierzenia przetwarzania (art. 28 RODO), bo klauzula poufności jej nie zastępuje.
Sprawdź w niej także listę podprocesorów, lokalizację serwerów, przekazywanie danych poza Europejski Obszar Gospodarczy, usunięcie danych po zakończeniu, prawo do audytu i termin zgłoszenia naruszenia.
Wyjście z umowy i przekazanie kodu aplikacji
Umowa z software housem musi też opisywać rozstanie w wariancie, w którym strony się nie zgadzają: przesłanki odstąpienia i wypowiedzenia dla obu stron, rozliczenie prac wykonanych do tego dnia, termin przekazania kodu i dostępów.
Poza tym potrzebna jest zasada, że po zapłacie faktury za wykonane prace kod i prawa do niego przechodzą na Ciebie. Dopisz również płatne przekazanie projektu następnemu zespołowi.
„W razie rozwiązania Umowy Wykonawca w terminie … dni od zapłaty wynagrodzenia za prace wykonane do dnia rozwiązania przekaże kod źródłowy, dokumentację i dostępy w stanie z dnia rozwiązania oraz zapewni płatne wsparcie w przekazaniu projektu do … godzin według stawki z § … .”
Materiał poglądowy, nie porada prawna.
Czego nie da się wynegocjować i dlaczego
- Nieograniczona odpowiedzialność odszkodowawcza. Limit do wartości umowy jest standardem; kto podpisuje bez limitu, nie zamierza tego respektować.
- Gwarancja bezbłędności. Zobowiązaniem jest usuwanie zgłoszonych błędów w określonym czasie, nie brak błędów.
- Prawa do bibliotek zewnętrznych. Nikt nie przeniesie na Ciebie praw do Fluttera ani biblioteki open source. Wykonawca odpowiada jednak za to, że licencje dopuszczają użycie komercyjne.
- Prawa do wielokrotnie używanych komponentów wykonawcy. Realne rozwiązanie to bezterminowa licencja na te fragmenty, a także przeniesienie praw do kodu pisanego dla Ciebie.
Mówimy wprost: jeśli oczekujesz nieograniczonej odpowiedzialności i kar bez limitu, takiej umowy nie podpiszemy i nie podpisze jej większość software house’ów naszej wielkości.
Jak sprawdzić umowę z software housem przed podpisem - lista kontrolna?
Najpierw dwanaście zapisów, których szukasz w projekcie umowy.
| Zapis | Dlaczego istotny | Co zrobić, gdy go brakuje |
|---|---|---|
| Przeniesienie praw majątkowych | Bez niego kod zostaje u wykonawcy | Żądać przeniesienia praw |
| Wyliczone pola eksploatacji | Prawa przechodzą tylko na polach wymienionych | Dopisać listę pól |
| Zgoda na modyfikacje i prawa zależne | Bez niej rozwijanie kodu można zakwestionować | Dodać zgodę na utwory zależne |
| Prawa od podwykonawców | Umowa B2B nie przenosi praw automatycznie | Wymagać oświadczenia wykonawcy |
| Wydanie kodu i dokumentacji | Prawa bez plików są bezużyteczne | Dopisać termin: dokumentacja przy odbiorze, kod po ostatniej fakturze |
| Indywidualne repozytorium projektu | Kod nie miesza się z innymi projektami i przechodzi na Ciebie w całości, z historią | Dopisać, kiedy i jak repozytorium przechodzi na Ciebie |
| Konta w sklepach na Twoją firmę | Aplikacja na koncie wykonawcy zostaje przy nim | Założyć konta, zanim ruszy projekt |
| Załącznik z zakresem | Rozstrzyga, czy funkcja jest zrobiona | Nie podpisywać bez załącznika |
| Procedura zmiany zakresu | Chroni przed pracą bez akceptacji | Ustalić formę i termin wyceny |
| Procedura odbioru z terminem | Bez terminów odbiory i płatności się ciągną | Wpisać dni na uwagi |
| Kary obustronne z limitem | Kara jednostronna zniechęca do naprawy | Zrównać kary i wpisać wspólny limit |
| Gwarancja i zasady rozstania | Rozstrzyga, kto płaci za błędy po wdrożeniu | Zdefiniować błąd i czasy reakcji |
Lista do odhaczenia przed podpisaniem umowy na aplikację
Potem krótka lista do odhaczenia przed podpisem:
- Forma pisemna z podpisami, także dla praw autorskich; prawa przenoszone, nie licencjonowane.
- Pola eksploatacji wymienione z nazwy i zapisany moment przejścia praw, czyli zapłata ostatniej faktury.
- Zgoda na modyfikacje i utwory zależne, a także oświadczenie o nabyciu praw od podwykonawców.
- Indywidualne repozytorium projektu, dokumentacja jako warunek odbioru i termin wydania kodu po zapłacie ostatniej faktury.
- Konta w sklepach na Twoją firmę.
- Załącznik z zakresem i listą wyłączeń oraz procedura zmian z terminem wyceny.
- Termin na uwagi i podział wad.
- Kary w dwie strony ze wspólnym limitem oraz gwarancja z definicją błędu i czasami reakcji.
- Umowa powierzenia przetwarzania danych, jeśli wykonawca ma do nich dostęp.
Wzór zakresu umowy na stworzenie aplikacji
Jak ten zakres wygląda u nas w praktyce, opisaliśmy krok po kroku na stronie proces współpracy; z kolei odpowiedzi na częste pytania o umowę i rozliczenia są w FAQ. Całą ofertę dla firm znajdziesz na stronie aplikacja dla firmy.
Wysyłamy wzór zakresu umowy razem z wyceną - bez pytania o zgodę marketingową i bez zapisu na cokolwiek. Napisz, co ma robić aplikacja i kto z niej korzysta: biuro@appcreo.pl lub +48 783 477 243.
Działa też formularz kontaktowy. Pracujemy zdalnie w całej Polsce, biura mamy w Poznaniu, Warszawie i Wrocławiu - zespół poznasz na stronie o AppCreo.
