Umowa na prace "po godzinach" - co w niej warto zapisać

Hej co jakiś czas wpadają mi dodatkowe zlecenia, często dzielę się nimi ze znajomymi itp. Głupio się przyznać, ale ciągle robię to "na gębę". Zazwyczaj wygląda to tak, że odzywa się do mnie ktoś z kimś kiedyś współpracowałem, albo "znajomy znajomego". Mam też 2-3 firmy, które co jakiś czas podsyłają mi tematy na które nie mają wewnętrznie zasobów. Jakoś nie odczuwałem nigdy potrzeby zbytniego formalizowania. Nigdy nie miałem problemów z płatnościami, reklamacjami tip. Jako podwykonawców biorę osoby z którymi pracowałem i mam do nich zaufanie. Biorę tylko zlecenia jeśli mam na nie moce przerobowe etc.

W sumie jednak zlecenia nie są małe - zdarzyły się już dwa powyżej 100.000 więc jak tak sobie teraz o tym pomyślę, to jednak głupio robię, że nie zabezpieczam sobie tyłka.

Idę więc do prawnika aby spisał mi odpowiednią umowę - zastanawiam się co tam w sumie warto wrzucić.

Na razie na liście mam:

• ograniczenie odpowiedzialności za błędy do 50.000zł
• możliwość korzystania z podwykonawców
• możliwość wykorzystania projektów do tworzenia case studies, umieszczenia ich w portfolio, stronie internetowej i innych działań promocyjnych
• informacja o przekazaniu praw autorski do napisanego na rzecz projektu kodu z wyłączeniem kodu OS, kodu generycznego stosowanego w innych projektach etc.
• zakaz odsprzedaży wytworzonego kodu
• zastrzeżenie, że zamawiający pokrywa dodatkowe koszty niezbędne do wykonania projektu - licencje, infrastruktura itp.
• temat NDA po stronie klienta - wszystko co nie zostało ujęte w NDA nie jest uznawane za tajemnicę przedsiębiorstwa

Co byście jeszcze dołożyli do takiej listy?

Jak pójdziesz do takiego coś się zna na IT to ci zrobi jeszcze 100 innych punktów, o którym nie masz pojęcia. Możesz też spróbować kupić taką umowę: https://umowywit.pl/sklep/

• Skoro piszesz o kodzie (dalsza możliwość odsprzedaży), to kwestia praw autorskich. O ile prawa autorskie osobiste są niezbywalne i zawsze Ty będziesz twórcą, to jest jeszcze kwestia praw majątkowych. Wyraźnie zaznacz w umowie, czy je przekazujesz, czy nie. Jeśli nie, to musisz udzielić licencji, w której określisz na jakich zasadach ta licencja jest udzielona,
• Ważna rzecz - podczas omawiania praw autorskich (zresztą na pewno prawnik o tym wie) musisz wskazać pola eksploatacji, których umowa dotyczy. Czasami ktoś chce być sprytny i do umowy wpisze "na wszelkich polach" - ale taki zapis jest nieważny. Art. 41 ustawy o prawach autorskich mówi wprost "Umowa o przeniesienie autorskich praw majątkowych lub umowa o korzystanie z utworu, zwana dalej "licencją", obejmuje pola eksploatacji wyraźnie w niej wymienione.". Jest tam wprost zaznaczone, że trzeba wykazać w umowie te pola. Orzecznictwo idzie w kierunku konieczności wymienienia tych pól, zapisy o "wszelkich polach" są uznawane za zbyt szerokie a także niespełniające konieczności szczegółowego wymienienia tych pól - przez co są traktowane jako nieważne. Musimy tutaj wymienić pola, na których jest dozwolone korzystanie z dzieła,
• Gwarancja i rękojmia: często ludzie stosują te pojęcia zamiennie, ale to błąd. To są dwie osobne sprawy, rękojmię udzielasz z automatu (w przypadku stosunków między podmiotami można ją ograniczyć lub wyłączyć, jeśli Twoim klientem jest osoba prywatna to nie ma takiej opcji), gwarancja jest dobrowolna. Jeśli chcesz udzielić gwarancji to najlepiej określ jej warunki (tutaj masz baaardo dużą dowolność), ale jeśli napiszesz że udzielasz gwarancji i nie określisz jej szczegółów, to będą miały zastosowanie przepisy wynikające z Kodeksu, które swoim zakresem są zbliżone do rękojmi i mogą być dla Ciebie niekorzystne,
• Doprecyzuj sposób komunikacji oraz powiadamiania - w jakich terminach trzeba przekazywać zgłoszenia (zarówno podczas pracy, jak i np. zgłoszenia reklamacyjne), w jakiej postaci - czy mailowo jest OK, czy trzeba w formie pisemnej (niektóre czynności prawne wymagają takiej formy pod rygorem nieważności),
• Kwestia protokołów odbioru prac: ustal procedurę ich wykonywania (kiedy masz zgłaszać prace do odbioru, w jakim terminie oni muszą się ustosunkować, co w przypadku zastrzeżeń, termin ich usunięcia itp.) oraz zabezpiecz się możliwością dokonania jednostronnego odbioru w sytuacji, jakby druga strona chciała grać na czas,
• Temat kar umownych: po pierwsze pamiętaj, że są one bardzo wygodne (ale także niebezpiecznie): o ile w przypadku dochodzenia odszkodowania na zasadach ogólnych, strona poszkodowana musi wykazać, że w efekcie działań (lub zaniechań) drugiej strony doszło do szkody, podać jej wysokość oraz wykazać związek przyczynowo-skutkowy między działaniem a szkodą, to kara umowna jest zwolniona z tego obowiązku. Mówiąc inaczej - jeśli nie dostarczysz w umówionym terminie produktu i przez to będzie jakaś szkoda, to musisz ją pokryć. Ale jeśli szkoda nie powstała (a Ty po prostu się spóźniłeś) to nie ma podstawy do odszkodowania. ALE jeśli była zapisana kara umowna, to już sam fakt spóźnienia (niezależnie od tego, czy jakiekolwiek szkody powstały) daje podstawę do naliczenia kary.
• Poszerzając poprzedni punkt - sam fakt wpisania do umowy oraz ewentualnego naliczenia kar nie blokuje możliwości dalszego dochodzenia odszkodowania, więc tą kwestię należy także przemyśleć. No i oczywiście pamiętaj, że kary mogą być zapisane w obie strony, Ty także możesz mieć prawo je naliczyć,
• modne hasło: RODO
• Jeszcze w temacie kar i odszkodowań - są różne podstawy ich naliczenia i tutaj też temat przemyśl. Czy chcesz ponosić odpowiedzialność tylko za straty rzeczywiste, czy także ze utracone korzyści, straty wizerunkowe i parę tematów pokrewnych (teraz nie pamiętam dokładnie jak się te hasła nazywają, ale prawnik powinien temat kojarzyć)
• Kwestia wyboru technologii - kto ustala w czym i w jaki sposób ma to zostać napisane. Żeby nie okazało się, że napiszesz to w jakiejś technologii, którą potem oni będą podważać - na zasadzie, że zrobisz to w Javie, a oni potem uznają, że do tego bardziej się nadaje PHP, a przez Twój wybór teraz mają problemy (droższe serwery, niższa wydajność, dodatkowe opłaty za licencje, większa awaryjność, ograniczone możliwości rozwoju itp.). To powinno być też uwzględnione
• Kwestia utrzymania - czy poza napisaniem samej aplikacji, coś jeszcze masz robić? Bo czymś innym jest rękojmia/gwarancja, czyli usuwanie przez jakiś czas stwierdzonych usterek, a czymś innym bieżąca obsługa (chociażby kwestia przeglądania logów, aktualizacji serwera, obsługi zgłoszeń niebędących zgłoszeniami gwarancyjnymi)
• Jeszcze w temacie praw autorskich (wiem, lekko nie po kolei, ale teraz mi przyszło to do głowy) - ustal. czy masz prawo korzystać z tego kodu w innych swoich projektach. Jeśli nie przekazujesz praw a jedynie udzielasz licencji na korzystanie, to problemu raczej nie ma. Ale w przypadku odsprzedaży praw, ten kod się staje ich własnością. Jeśli napiszesz jakiś kolejny program i w nim wykorzystasz swój kod napisany dla tego klienta, to formalnie rzecz biorąc sam się spiraciłeś ;) Oczywiście - szanse, że takie coś wypłynie są bliskie zera, ale dla bezpieczeństwa dobrze jest dodać zapis, że mimo przekazania praw majątkowych do kodu, nadal masz prawo go wykorzystać w innych swoich projektach,
• Poszerzając poprzedni punkt, mamy coś, o czym trochę napisałeś w pierwszym poście - zamawiający pokrywa dodatkowe koszty niezbędne do wykonania projektu - licencje, infrastruktura itp.. Wszystkie zewnętrzne biblioteki, nawet jeśli są OSS, powinny zostać wyszczególnione, żeby nie było wątpliwości co do tego, że to nie jest Twój kod. Ja bym zrobił z tego jakiś załącznik, w którym wykażesz co zostało wykonane oraz ja jakiej licencji są te fragmenty kodu osadzone w projekcie.
• Dodaj wprost zapis, że w przypadku zaległości w płatnościach, niewywiązywania się przez Zleceniodawcę ze swoich obowiązków, nie dostarczania Ci potrzebnych materiałów, masz prawo wstrzymać się z realizacją umowy, a wszelkie opóźnienia z tego wynikające będą uznane za powstałe z winy klienta. Aktualnie sprawa wygląda tak, że nawet jeśli klient nie płaci, to umowa obowiązuje i Ty możesz być pociągnięty z tytułu niewykonania swoich obowiązków z niej wynikających. Oczywiście - jeśli to wynika z tego, że np. klient nie dał Ci materiałów i przez to stoisz z robotą, a Ty będziesz w stanie udowodnić (np. pokazując maile), że prosiłeś o ich wydanie i informowałeś, że bez nich nie ruszysz dalej, to sąd raczej to uwzględni. Ale jeśli na 2 miesiące wstrzymasz się z pracą bo nie dostałeś obiecanego wynagrodzenia, to potem klient ma możliwość obciążenia Cię jakimiś karami czy innymi konsekwencjami i raczej nikogo brak płatności nie będzie interesować,
• Warunki odstąpienia od umowy - kiedy możesz to zrobić (np. jeśli powstaną okoliczności wymienione w poprzednim punkcie i przez jakiś czas nie zostaną rozwiązane). Kwestia rozliczenia w takiej sytuacji: wiadomo, że należy Ci się wynagrodzenie za wykonane prace, ale także można się zastanowić nad jakimś odszkodowaniem/karą umowną. Żeby było sprawiedliwie - warto dodać analogiczne zapisy na ich korzyść - jeśli Ty przyjmiesz zlecenie i olejesz temat
• Kwestia projektu, konsultacji, wybadania potrzeb klienta, przygotowania szczegółowej specyfikacji. Dobrze, jakby te materiały stanowiły załącznik do umowy. Czy za to pobierasz osobne wynagrodzenie? Najczęściej się stosuje takie podejście, że jest to wycenione na jakąś kwotę, przeprowadzasz analizę potrzeb, proponujesz rozwiązanie. Klient za to płaci i potem ma możliwość zlecenia tego Tobie, albo innej firmie. Jeśli zleci Tobie, to wtedy tą kwotę się odlicza od wartości zlecenia. Przykładowo - za 5 tysięcy przygotowujesz specyfikację, na której podstawie ustalasz, że całość będzie kosztowac 80k. Klient płaci Tobie piątaka, a potem albo idzie z tym gdzieś indziej (to są jego materiały, zapłacił za ich sporządzenie), albo zleca Tobie. A wtedy Ty go za tą robotę fakturujesz na 75k,
• Pamiętaj, że jeśli już gdzieś pracujesz, a te zlecenia robisz po godzinach, to upewnij się, czy w swojej "głównej" umowie nie masz jakiegoś zakazu konkurencji albo innych zapisów, które mogą spowodować problemy,
• Dokładnie opisz sposób rozliczania - czy etapami (po wykonaniu określonych modułów opisanych w specyfikacji), czy czasowo (np. co miesiąc). Zaznacz, kiedy masz prawo wystawić fakturę. I unikaj (często stosowanego przez wiele firm) zapisu, który podaje w umowie numer konta do przelania środków. Zamiast tego napisz, że płatność będzie dokonywana na numer konta określony na fakturze, w terminie także na niej określonym. Ale w umowie zaznacz, że faktury będą posiadały jakiś termin (np. 14 dni) i wystawiaj je zgodnie z tym, co zostało zawarte w umowie.