law-how® umowy it

advertisement
przewodnik prawny dla
firm IT i nie tylko
Law-how
®
umowy IT
Treści zawarte w tej publikacji nie stanowią opinii czy porady prawnej, a mają jedynie charakter
informacyjny. Jeśli potrzebujesz pomocy prawnej – skontaktuj się z prawnikami z Legal Geek:
| LegalGeek.pl | [email protected] | +48 797 711 924
LAW-HOW® UMOWY IT
Z przyjemnością przygotowaliśmy kolejne Law-how® Tym razem kierując je do
firm IT (takich jak szeroko rozumiane software house’y czy agencje interaktywne),
ale też dla podmiotów, które korzystają z usług takich firm.
Postanowiliśmy przygotować prosty, krótki i czytelny przewodnik prawny po
umowach rynku IT. Wybraliśmy dla Was te kwestie, o które nasi Klienci pytaj najczęściej, a także te które uznaliśmy za najistotniejsze. Zdajemy sobie sprawę, że
nasze Law-how® nie wyczerpuje tematu. Niemniej liczymy na to, że ten „wstęp” do
tematyki umów IT będzie dla Was przydatny.
W pierwszej części przewodnika znajdziecie klauzule, które naszym zdaniem można uznać za typowe dla wszystkich, a przynajmniej dla większości umów IT. Dalej
natomiast skupiamy się na konkretnych typach umów. Zaproponowany przez nas
podział umów wynika z naszego doświadczenia, ale nie powinien być traktowany
jako wyrocznia. Praktyka rynku IT pokazuje, że tytuły i nazwy umów są stosowane
w bardzo różny sposób. Nie ma też przeszkód, aby jedna umowa stanowiła hybrydę kilku innych, tak jest np. z umową o poufności, która występuje samodzielnie,
ale równie często implementowana jest do pozostałych umów (np. umowy wdrożeniowej). Pamiętajcie również, że ta publikacja dotyczy tylko relacji B2B i nie
uwzględnia aspektów związanych z ochroną konsumentów.
Oto nasze Law-how® dla firm IT! Jak zawsze podane w przystępny, charakterystyczny dla prawników z Legal Geek sposób.
Zofia Babicka-Klecor
Tomasz Klecor
Legal Geek
Stan prawny: luty 2017 r.
Co znajdziesz na kolejnych stronach?
01. Ogólne klauzule umów IT
02. Umowa wdrożeniowa
03. Umowa utrzymaniowa
04. Umowa wdrożeniowa Agile
05. Umowa licencyjna (EULA)
06. Umowa SaaS / Regulamin SaaS
07. Umowa o poufności (NDA)
AUTORZY
Zofia Babicka-Klecor
założycielka Legal Geek, prawniczka
Zofia jest założycielką Legal Geeka oraz ekspertem
w zakresie praw konsumentów i świadczenia usług drogą elektroniczną. Posiada kilkuletnie doświadczenie jako
prawnik w spółce ICT (gdzie wcześniej pracowała również
w zespole projektowym), administracji publicznej oraz kancelarii radcowskiej. Ukończyła studia na Wydziałach Prawa
oraz Zarządzania na Uniwersytecie Gdańskim, a obecnie
przygotowuje pracę doktorską na temat prawnych aspektów
e-biznesu.
Jest autorką artykułów o prawnych aspektach e-handlu oraz biznesu w Internecie, m.in.
w serwisie AntyWeb. Doradzała przy licznych projektach z zakresu IT oraz e-commerce.
W Legal Geeku jako Partner odpowiada właśnie za te obszary. Specjalizuje się również w
kwestiach związanych z ochroną danych osobowych.
Prywatnie mama dwójki dzieci, zapalony fotograf i miłośniczka Italii.
Tomasz Klecor
prawnik
Tomasz jest ekspertem z zakresu regulacji usług płatniczych. Obsługą prawną sektora nowych technologii zajmuje
się od dekady. Posiada bogate doświadczenie w prowadzeniu spraw instytucji finansowych przed Komisją Nadzoru
Finansowego oraz NBP, a także brytyjskim FCA i niemieckim
BaFin, w tym w zakończonych sukcesem postępowaniach
licencyjnych. Obsługiwał spółki zarówno z Unii Europejskiej
jak i USA, doradzał przy transakcjach typu M&A oraz Venture Capital. Specjalizuje się również w zagadnieniach związanych z przeciwdziałaniem praniu pieniędzy i bezpieczeństwem transakcji finansowych.
Jest autorem licznych publikacji dotyczących prawnych aspektów świadczenia usług płatniczych, w tym pieniądza elektronicznego oraz Bitcoina. Autor w serwisie LEX dla Banków,
prowadzonym przez Wolters Kluwer. Pracuje nad doktoratem z ekonomicznej analizy prawa,
był wykładowcą m.in. w Wyższej Szkole Bankowej. Do 2016 roku był Zastępcą Dyrektora
Działu Prawnego w Blue Media S.A. Od 2016 roku jest Partnerem w Legal Geeku, gdzie kieruje obsługą podmiotów FinTech oraz startupów.
Prywatnie jest tatą dwójki dzieci, miłośnikiem innowacji i motoryzacji, właścicielem własnoręcznie odrestaurowywanego zabytkowego Porsche.
01. OGÓLNE KLAUZULE UMÓW IT
Każdy projekt informatyczny jest inny i to nie tylko pod względem technologicznym, ale
również z uwagi na założenia biznesowe stron. Nie da się wskazać jednej, zamkniętej „checklisty” właściwej dla każdej umowy, której przedmiotem jest projekt IT. Istnieją jednak pewne
elementy, które warto wziąć pod uwagę podczas tworzenia takiej umowy. Przygotowując
poniższe zestawienie kierowaliśmy się przede wszystkim aspektami prawnymi. Przy każdej
umowie trzeba jeszcze uwzględnić kwestie biznesowe i techniczne, takie jak choćby sposób
deponowania kodu źródłowego, kopie zapasowe itp.
Zdajemy sobie sprawę, że praktyka i teoria w przypadku umów IT nie zawsze idą w parze
– dlatego też nasz poradnik nie powinien być traktowany jako kompleksowe omówienie
tematyki umów IT. To co Wam przedstawiamy to ramowe ujęcie najważniejszych (ale nie
wszystkich) aspektów umów, które w branży IT są chlebem powszednim.
Co powinna/może zawierać każda umowa IT?
Oznaczenie stron
W każdej umowie powinny zostać oznaczone jej strony, tj. podmioty, które są związane umową. Należy podać ich dane oraz imiona i nazwiska osób reprezentujących każdą ze stron.
Ważne jest to, aby umowę zawierały w imieniu spółki upoważnione do tego osoby. W przypadku spółki z o.o. sprawa jest stosunkowo prosta i sposób reprezentacji spółki możecie
sprawdzić w Krajowym Rejestrze Sądowym (KRS) dostępnym pod adresem: ems.ms.gov.pl.
Co ważne – w przypadku spółek cywilnych stroną umowy są wszyscy jej wspólnicy działający wspólnie, a nie sama spółka cywilna, która nie ma zdolności do zawierania umów.
Definicje
Warto wprowadzić definicje dla poszczególnych pojęć występujących w umowie.
Po pierwsze pomoże to ją uprościć (unikniecie konieczności tłumaczenia pewnych
kwestii po kilka razy), a poza tym zminimalizuje ryzyko nieścisłości. Definicje są często bagatelizowane, jednak to one pozwalają na stwierdzenie, czy te same pojęcia
rozumiecie w taki sam sposób. Istotne jest
to żeby zarówno w umowie jak
i w załącznikach do niej zachować dyscyplinę i pamiętać o stworzonych definicjach.
Przykładem pojęcia, które warto zdefiniować jest błąd – powinniście w sposób
jasny i wyraźny wskazać co zostanie
uznane za błąd. Dokładne określenie tego
ma zasadnicze znaczenie, zwłaszcza w przypadkach, w których z błędami wiążą się np.
kary umowne czy też od ich braku jest uzależniony odbiór wykonanych przez wykonawcę
prac. Często wykonawca rozumie pojęcie błędu zupełnie inaczej niż zamawiający. Ponadto
powszechną praktyką w umowach IT jest stopniowanie błędów – wtedy powinniście określić
jasne kryteria pozwalające na stwierdzenie co jest błędem „zwykłym”, a co krytycznym.
Przedmiot umowy
Przedmiot umowy, a więc określenie co na jej podstawie ma powstać, powinien zostać przez
strony dokładnie określony. Szerszy opis przedmiotu umowy (czyli taka specyfikacja techniczna), w tym np. funkcje oraz parametry wdrażanego oprogramowania, najlepiej zawrzeć
w załączniku do umowy. Opis powinien być z jednej strony szczegółowy, a z drugiej powinien
pozostawiać pewien margines, żeby nie okazało się, że poszczególne prace, bez których
oprogramowanie nie jest w pełni funkcjonalne dla zamawiającego, nie zostały uwzględnione
w zbyt szczegółowym opisie i de facto wykonawca nie wykona ich w ramach zawartej umowy. Nie tylko warto wskazać prace jakie wykonawca ma wykonać, ale również jakie funkcje
ma posiadać oprogramowanie. Niedokładne określenie przedmiotu umowy może prowadzić
do konfliktu pomiędzy stronami, dlatego też dla obu stron musi być jasne jaki cel ma zostać
osiągnięty w wyniku realizacji
umowy.
W ramach umowy wykonawca
może nie tylko wykonać oprogramowanie, ale również np. przeszkolić zamawiającego z korzystania
z niego. Takie usługi poboczne
również powinny zostać wskazane
w opisie przedmiotu umowy.
Szczególnymi prawami rządzą się
opisy przedmiotów umowy
w umowach wdrożeniowych
w metodykach agile – przeczytacie
o tym w dalszej części naszego
poradnika.
Określenie obowiązków obu stron
Obowiązki wynikające z umowy nie dotyczą wyącznie wykonawcy, ale również zamawiającego i nie zawsze będzie chodzić wyłącznie o obowiązek zapłaty. Warto w umowie precyzyjnie
wskazać do czego każda ze stron jest zobowiązana.
Terminy
W umowie ważne jest nie tylko co, ale również kiedy, dlatego z kontraktu powinno wyraźnie
wynikać w jakich terminach mają zostać spełnione poszczególne obowiązki stron.
Z upływem terminów (zarówno skutecznym jak i nieskutecznym) wiążą się obowiązki lub
uprawnienia Stron (np. dotyczące kar umownych). Jeśli jednak decydujecie się na określenie harmonogramu w trakcie prac (co też jest powszechne) – to umowa będzie wymagała
szczególnych mechanizmów związanych z zapewnieniem terminowego wykonania projektu.
Wynagrodzenie
Poza określeniem wysokości wynagrodzenia warto w umowie określić
moment, w którym wykonawcy należy się wynagrodzenie. Przykładowo
w umowie wdrożeniowej - jeśli tego nie ustalicie – będzie to moment
oddania dzieła, a w przypadku większych projektów, w których wynagrodzenie zostało określone osobno dla każdego etapu – moment
zrealizowania poszczególnych etapów.
Powinniście również ustalić sposób określania wynagrodzenia – czy
będzie ono ryczałtowe (fixed) czy też rozliczane wg. stawki godzinowej (time and material), a może będziecie stosować zupełnie inny
sposób ustalania wynagrodzenia?
Wykonanie zastępcze
Zgodnie z prawem w przypadku, gdy wykonawca ze swojej winy spóźnia się z wykonaniem
umowy zamawiający może żądać upoważnienia przez sąd do wykonania czynności na koszt
wykonawcy, czyli tzw. wykonania zastępczego. Jednak, co istotne, strony mogą wprowadzić
do umowy mechanizmy, dzięki którym możliwe będzie zlecenie prac komuś innemu na koszt
wykonawcy, bez zgody sądu. Warto zwrócić uwagę czy takie postanowienie znajduje się
w podpisywanej umowie, ma ono duże znaczenie dla obu stron.
Odpowiedzialność
Odpowiedzialność za wykonanie umowy różni się w zależności od charakteru umowy, ale
ogólna zasada stanowi, że każda ze stron umowy jest obowiązana do naprawienia szkody,
która wynikła z niewykonania lub nienależytego wykonania zobowiązania, chyba że nie ponosi za nie odpowiedzialności – czyli np. zamawiający nie udostępnił wykonawcy odpowiedniego środowiska, w związku z czym wykonawca nie był w stanie zainstalować zamówionego oprogramowania.
Wyżej wskazaną zasadę można zmodyfikować i kwestie odpowiedzialności uregulować
w inny sposób np. poprzez znaczące jej ograniczenie lub wyłączenie odpowiedzialności za
utracone korzyści.
O innych rodzajach odpowiedzialności (np. o rękojmi w odniesieniu do wykonywanego dzieła) przeczytasz na kolejnych stronach poradnika.
Kary umowne
Można zastrzec w umowie, że jeśli jedna ze stron nie wykona lub
wykona nienależycie zobowiązanie niepieniężne wynikające z umowy, to będzie zobowiązana do zapłaty kary umownej w wysokości
określonej w umowie.
Jednak żeby strona otrzymująca karę mogła żądać odszkodowania
przewyższającego wysokość tej kary – musi wynikać to z zawartej przez strony umowy. Jeśli takie postanowienie nie znalazło się w kontrakcie - zapłata kary umownej zamyka drogę
do dochodzenia odszkodowania przewyższającego wysokość tej kary.
Jeśli strony zdecydują się na kary umowne powinny w umowie dokładnie określić sytuacje,
w których kary będą miały zastosowanie i w jakiej będą wysokości.
Pamiętaj, że kary umowne powinny być wyrażone w pieniądzu, przy czym można określić
ich wysokość np. przy wykorzystaniu wskaźników procentowych.
Formy zakończenia współpracy (wypowiedzenie umowy i odstąpienie)
Strony mogą przewidzieć w umowie dodatkowe, poza wynikającymi z ustawy, formy „wyjścia z umowy”. Chodzi tutaj o zasady wypowiedzenia umowy (zazwyczaj przy umowach o
świadczenie usług) oraz odstąpienia od niej (zazwyczaj przy umowach wdrożeniowych),
czyli np. terminy wypowiedzenia umów. Możecie wskazać w umowie szczególnie ważne dla
Was sytuacje, w których chcecie mieć prawo do zakończenia współpracy z drugą stroną.
Zmiana umowy
W umowie warto określić procedurę zmiany umowy – chodzi tutaj przede wszystkim o formę takiej zmiany (np. pisemna lub elektroniczna), ale nic nie stoi na przeszkodzie, żeby dla
poszczególnych zmian, ze względu na ich rangę lub zakres, przewidzieć różne zasady.
Właściwy Sąd
Dobrze przygotowana umowa minimalizuje ryzyko sporu sądowego, ale jeśli już do niego
dojdzie warto, aby sądem właściwym był sąd właściwy dla Twojej siedziby – możesz to
zastrzec w umowie, oczywiście o ile druga strona się na to zgodzi.
Poufność
Jeśli nie podpisujesz odrębnej umowy o poufności – pamiętaj, aby stosowne postanowienia
znalazły się w umowie głównej. Określ co jest informacjami poufnymi, w jakich okolicznościach można je ujawnić, a także co się stanie jeśli dojdzie do nieuprawnionego ich ujawnienia. Pewnym standardem jest również zobowiązanie do tego, aby klauzule o poufności
znalazły się również w umowach z podwykonawcami stron umowy.
Dane osobowe
W przypadku gdy podczas wykonywania zlecenia
wykonawca ma dostęp do danych osobowych, których
administratorem jest wykonawca (np. dane użytkowników serwisu internetowego) strony powinny
uregulować kwestie z tym związane w umowie np.
poprzez powierzenie przetwarzania danych osobowych wykonawcy.
02. UMOWA WDROŻENIOWA
Umowa wdrożeniowa to bardzo szerokie pojęcie i może dotyczyć szeregu różnych działań.
Najczęściej jednak spotykamy się z umową wdrożeniową, która dotyczy przygotowania
oprogramowania wraz z jego uruchomieniem w wersji produkcyjnej. Oczywiście to od stron
umowy zależy na co się umówią i jaki będzie zakres tej umowy, czy obejmie ona ewentualne
usługi dodatkowe, takie jak np. szkolenia zamawiającego.
Kluczowe klauzule umowy wdrożeniowej
Harmonogram prac
Harmonogram to takie „deadline’y” dla poszczególnych etapów. Najlepiej zdefiniować kolejne etapy
projektu, tj. co dokładnie ma zostać wykonane
w danym etapie, oraz wskazać w jakim terminie powinny zostać zrealizowane. Podzielenie prac
na etapy daje zlecającemu możliwość
czuwania nad przebiegiem wdrożenia.
Co istotne w przypadku, gdy wykonawca opóźnia się z wdrożeniem tak
mocno, że nie jest prawdopodobne, że
da radę zakończyć pracę w umówionym terminie, zamawiający może
bez wyznaczenia dodatkowego terminu
odstąpić od umowy jeszcze przed upływem terminu wykonania całego wdrożenia.
Zaplanowanie zmian
Projekty IT mają to do siebie, że lubią się przeciągać, a koncepcje zamawiających ulegać
zmianie, dlatego też warto w umowie przewidzieć zasady postępowania w przypadku konieczności wprowadzania zmian, zwłaszcza w zakresie przedmiotu umowy, a także
w ustalonym wcześniej harmonogramie. Ponadto warto ustalić w jaki sposób będą wyceniane dodatkowe prace.
Przykładowo strony mogą określić formę wprowadzania zmian. Są pewne zmiany, dla
których warto zastrzec formę pisemną (co ważne zwykły e-mail nie stanowi takiej formy!),
ale dla mniejszych zmian warto przewidzieć prostszy dla obu stron sposób komunikacji –
np. mailowy ze wskazaniem konkretnych osób, które mogą dokonywać wiążących zmian
ustaleń w tzw. trybie roboczym.
Prawa autorskie/licencje
Jeśli w ramach umowy powstanie utwór podlegający ochronie na podstawie ustawy
o prawie autorskim i prawach pokrewnych wykonawca powinien zdecydować co zamierza
z tym utworem zrobić tj. czy chce przekazać go całkowicie zleceniodawcy i tym samym
przenieść prawa autorskie majątkowe na niego czy też zostawić utwór dla siebie udzielając
klientowi jedynie licencji na korzystanie z niego. Te kwestie powinny wynikać właśnie z umowy, a ponadto jeśli udzielona zostanie licencja należy określić w umowie jej warunki.
Pamiętajcie, że przeniesienia praw autorskich można dokonać wyłącznie w formie pisemnej. Jeśli chodzi o licencje to tylko dla licencji wyłącznej jest wymagana taka forma.
Ponadto w umowie trzeba wskazać na jakich polach eksploatacji będzie możliwe wykorzystanie utworu, przykładowym polem eksploatacji będzie rozpowszechnianie programu.
Odpowiedzialność za wady oprogramowania (rękojmia)
Za wady oprogramowania wykonawca odpowiada nie tylko na zasadach ogólnych, ale również w oparciu o rękojmię uregulowaną przez Kodeks cywilny. W przypadku wystąpienia wad
oprogramowania niezadowolony zleceniodawca może żądać m.in. obniżenia ceny, naprawy
lub wymiany przedmiotu umowy (jeśli ma to zastosowanie), a nawet - w przypadku wady
istotnej - odstąpić od umowy. Co istotne, wykonawca może tę odpowiedzialność w umowie
wyłączyć lub ograniczyć, np. kwotowo lub w zakresie możliwych żądań reklamacyjnych.
Gwarancja
Wykonawca może dodatkowo, lub wyłączając swoją odpowiedzialność w pozostałym zakresie, udzielić zamawiającemu gwarancji na wykonane oprogramowanie. Warunki gwarancji
mogą zostać określone np. w załączniku do umowy.
Odebranie oprogramowania
Warto określić w umowie procedurę odebrania dzieła, żeby nie było wątpliwości kiedy to nastąpiło. Przy tym dobrze jest uzależnić odebranie oprogramowania od podpisania protokołu
odbioru (jego wzór może być załącznikiem do umowy).
Przeniesienie praw autorskich - co to oznacza?
Jeśli w umowie wykonania dzieła, np. aplikacji
mobilnej, jest takie zdanie:
„Wykonawca przenosi na Zleceniodawcę
autorskie prawa majątkowe do utworu (...)”
Oznacza to, że m.in.:
wykonawca nie będzie mógł sprzedać/wykonać takiego samego utworu, np. takiej samej
aplikacji;
zleceniodawca będzie mógł czerpać korzyści z używania utworu przez inne osoby, np.
wynajmując go czy pozwalając innym na jego
powielanie;
zleceniodawca będzie mógł sprzedać utwór
komuś innemu.
firma
prawnicza
dla wykonawców Przygotowywanie umów
software house’ów
agencji interaktywnych
i nie tylko
Przygotowujemy umowy dla projektów IT, w tym umowy
wdrożeniowe w metodykach Agile. Projektujemy rozwiązania
bezpieczne dla wykonawców i zamawiających.
umów i negocjacje
oraz Analizowanie
Analizujemy umowy i pomagamy w ich negocjowaniu. Doradla zamawiających dzamy przy wyborze najlepszych rozwiązań oraz zabezpie-
czeń. Wskazujemy ryzyka prawne, ale również prawno-biznesowe.
Regulaminy
Tworzymy regulaminy dla platform i serwisów, usług SaaS
oraz licencje dla rozwiązań „pudełkowych” (EULA). Zapewniamy analizę prawną modelu biznesowego.
Sprawy pracownicze i podwykonawcy
Wspieramy w obsłudze prawnej spraw pracowniczych – od
początku do końca współpracy. Pomagamy w relacjach
z podwykonawcami, w tym współpracującymi w oparciu
o umowy o dzieło/zlecenie.
Bieżąca obsługa prawna
Zapewniamy bieżącą obsługę prawną, w tym w formie „zewnętrznego działu prawnego” oraz reprezentację w postępowaniach administracyjnych czy sądowych.
Dochodzenie roszczeń
Naszym Klientom pomagamy w dochodzeniu roszczeń
związanych z niewłaściwym wykonaniem lub niewykonaniem umów, nieuczciwą konkurencją czy naruszeniami praw
autorskich.
LegalGeek.pl
03. UMOWA UTRZYMANIOWA
Równie popularną jak umowa wdrożeniowa umową w branży IT jest umowa utrzymaniowa. W przeciwieństwie do umowy wdrożeniowej jej rezultatem nie jest dzieło, ale działania
wykonawcy, które mają zapewnić prawidłowe funkcjonowanie oprogramowania. Termin
„umowa utrzymaniowa” w praktyce stosowany jest do całego wachlarza usług, od zwykłego
hostingu, przez kompleksowe utrzymanie oprogramowania we własnej infrastrukturze, aż
po kolokację serwerów. Na potrzeby naszego opracowania przyjęliśmy umowę utrzymania
oprogramowania w infrastrukturze IT usługodawcy (w tym usuwanie błędów, itp.).
Kluczowe klauzule umowy utrzymaniowej
Zgłaszanie błędów i support
Umowa powinna określać w jaki sposób będą zgłaszane błędy (np. przez system ticketowy),
w jakich godzinach mogą być zgłaszane (ma to wpływ na dochowanie założeń SLA), a także
na jakich warunkach będzie świadczony support.
Zasady usuwania błędów
W umowie powinny zostać uregulowane zasady usuwania błędów zaczynające się od zdefiniowania błędów z podziałem na ich rangę, a także obejmujące sposób zgłaszania błędów
oraz czas ich usunięcia. Dla poszczególnych rodzajów błędów mogą obowiązywać inne
zasady, np. czas usuwania błędów krytycznych może być krótszy niż w przypadku pozostałych błędów.
Dostępność oraz parametry oprogramowania (SLA oraz KPI)
Zapewne nikt z nas nie lubi kiedy potrzebne nam w danej chwili oprogramowanie nie działa,
dlatego też w umowie utrzymaniowej należy wskazać jaki poziom dostępności oprogramowania zostanie zapewniony przez wykonawcę (SLA - Service Level Agreement). SLA może
stanowić załącznik do umowy.
Warto również wskazać w umowie Kluczowe Wskaźniki Efektywności
(KPI - Key Performance Indicators), które określą
jakich parametrów oczekuje od wykonawcy
zamawiający. Pamiętajcie, żeby wskaźniki były
precyzyjnie określone i stosunkowo proste do
zweryfikowania dla obu stron.
Ważne jest, by terminy użyte w SLA i KPI były dobrze zdefiniowane - aby strony nie miały wątpliwości na co się umówiły. Odpowiednio przygotowane SLA i wskaźniki KPI pozwalają uniknąć
wielu problemów i sporów. Co istotne – umowa
powinna wskazywać sposób monitorowania
gwarantowanych parametrów.
Exit Plan
Podpisując umowę nie zawsze myśli się o momencie zakończenia współpracy między
stronami, a warto to zrobić i zawrzeć w umowie tzw. Exit Plan określający wzajemne relacje
stron w tej sytuacji. Szczególnie istotne jest to dla wypowiedzenia umowy ze skutkiem
natychmiastowym. Exit Plan powinien określać np. w jaki sposób nastąpi „wydanie” utrzymywanego oprogramowania, jak długo przechowywane będą ewentualne backupy itp.
04. UMOWA WDROŻENIOWA AGILE
Zwinne metodyki realizacji projektów IT są coraz popularniejsze. Sposób w jaki realizowane
są projekty Agile znacząco odbiega od realiów klasycznej umowy wdrożeniowej. Klasyczna umowa wdrożeniowa zakłada, że z góry znamy szczegółowy opis produktu i wiemy co
powstanie, a załącznikiem do niej najczęściej jest rozbudowana specyfikacja techniczna
i wszystkie odstępstwa od niej są „utrudnione”. Przy wdrożeniach Agile, w tym Scrum, na
dzień podpisywania umowy znamy tylko wizję produktu, wiemy co mniej więcej chcemy
wyprodukować, ale zakładamy, że ta wizja może się jeszcze zmienić i z pewnością będzie
dostosowywana do potrzeb użytkowników produktu.
Wdrożenia oparte o Agile wydają się być idealne dla projektów „startupowych”, produktów, które od MVP do wersji „produkcyjnej”
zmienią się niezliczoną ilość razy – pod wpływem działań ich
użytkowników. I to właśnie ta zmienność projektu sprawia, że
przygotowanie umowy na wdrożenie Agile nastręcza wielu
trudności.
Dlatego też przygotowując umowę Agile potrzeba „świadomego” prawnika. Metodyki Agile są zwinnie dostosowywane do potrzeb poszczególnych softwarehousów czy
klientów – dlatego ważne jest zrozumienie stron i pełna
współpraca na linii prawnik-użytkownik umowy. Umowa
wdrożeniowa Agile powinna mieć jeden główny cel – nie
doprowadzić do sporu między stronami i rozwiewać wszelkie
wątpliwości gdy tylko pojawi się sytuacja konfliktowa. Dlatego też
powinna stanowić odzwierciedlenie negocjacji i intencji stron.
Kluczowe klauzule umowy wdrożeniowej Agile
Wizja produktu
W umowie powinien znaleźć się opis tego co chcemy zrobić, dlaczego to chcemy zrobić
i zwięzłe wskazanie jak to chcemy zrobić. Niech umowa określa główne cele i założenia
produktu.
Definicje
Aby uniknąć błędnego zrozumienia pojęć metodyk Agile – powinny zostać one określone
w umowie. Przygotowanie definicji pozwala wszystkim stronom zorientować się, że chodzi
im o to samo.
Role w projekcie
Kto będzie Product Ownerem, do czego jest uprawniony? Czy i jak można go zmienić? A jak
ze Scrum Masterem? To wszystko powinno się znaleźć w umowie. Jeśli jest się zamawiającym – warto zapewnić sobie prawo do oceny kompetencji zespołu deweloperskiego.
Product Backlog i user stories
Czy główne funkcje produktu (np. w postaci user stories) znane są na dzień zawarcia umowy? Jeśli tak warto zrobić z nich załącznik. Na jakich zasadach może być modyfikowany
backlog? Kiedy Product Owner może zmieniać priorytety poszczególnych user stories?
A może umowa zawierana jest na konkretny pakiet user stories?
Sprint
Długość sprintów, sposób przeprowadzania spotkań, sposób włączania user stories i zadań
do sprintów, a także ich rolowanie czy zmiana priorytetów poszczególnych zadań – to takie
umowne „must have”.
Definition of Done
No właśnie – kiedy dany element projektu jest skończony? Co jeśli
strony umowy nie są zgodne czy np. dana user story jest realizowana
prawidłowo? Warto wprowadzić checklistę i mechanizmy weryfikacyjne.
Prawa autorskie
W przypadku wdrożeń Agile, ze względu na duże zaangażowanie zamawiającego, kwestia praw autorskich może się trochę skomplikować. Dlatego też szczególnie
ważne jest określenie w umowie jak będzie wyglądać kwestia własności intelektualnej. Kto
ma prawa autorskie? Kiedy udzielane są licencje, a kiedy następuje przeniesienie praw?
Rozliczenia
Jak dany projekt będzie rozliczany? Czy nastawiacie się na rozliczenie godzinowe? A może
fixed price? Jeśli wybierzecie fixed price to ustalcie czy ma być to cena za cały projekt, ilość
sprintów, a może ilość user stories? Odpowiednio skonstruowany mechanizm rozliczeń jest
kluczowym elementem umowy – to właśnie rozliczenia budzą zawsze najwięcej wątpliwości.
Odpowiedzialność stron
Kto i na jakich zasadach odpowiada za prawidłową realizację umowy? Kto odpowiada za
opóźnienia w realizacji poszczególnych sprintów? Czy przewidywane są jakieś gwarancje
po zakończeniu projektu?
Zakończenie projektu
Umowa powinna określać kiedy projekt zostanie zrealizowany. Jest to szczególnie istotne jeśli przyjmujecie, że Product Backlog i lista user stories zmieniają
się dynamicznie w czasie realizacji projektu.
Wyjście z projektu (Exit Plan)
W umowie powinna istnieć odpowiednia procedura
wyjścia (i rozliczeń), na wypadek gdyby z jakiegoś powodu dalsze prace nad produktem zostały przerwane.
Oczywiście – należy tu rozróżnić różne przypadki. To
jedna z najistotniejszych klauzul. W połączeniu z odpowiednio zaprojektowanym mechanizmem rozliczeń
pozwala stronom uniknąć niepotrzebnych sporów.
Dodatkowo „zwinny exit” pozwala zleceniodawcy na
szybkie przeniesienie projektu do innego wykonawcy.
SLA
Ponieważ wdrożenie Agile, w tym testowanie i wykrywanie błędów, przebiegają inaczej niż
przy klasycznej umowie wdrożeniowej – konieczne będzie odpowiednio zmodyfikowane
SLA, dostosowane do realiów pracy w sprintach.
Standardy programowania i dokumentowania
Strony (zwłaszcza zamawiający) mogą chcieć określić
jakieś standardy przygotowania i dokumentowania kodu.
Od wyboru języka programowania i platformy (np. PHP
7.0, Laravel) po sposób komentowania kodu czy przygotowania dokumentacji.
05. UMOWA LICENCYJNA (EULA)
Jest to bez wątpienia jedna z najpopularniejszych form udostępniania oprogramowania.
Umowa licencyjna określa warunki na jakich oprogramowanie może być używane przez
użytkownika końcowego (funkcjonuje również jako EULA – End User License Agreement).
Najczęściej stosowana jest do tzw. rozwiązań pudełkowych, gdzie jest akceptowana w
formie niepodlegającej negocjacjom (np. jako regulamin). W przypadku oprogramowania
tworzonego na indywidualne zamówienie - licencja zawarta jest w umowie wdrożeniowej.
Kluczowe klauzule umowy licencyjnej
Określenie typu licencji i uprawnienia licencjobiorcy
Większość umów licencyjnych dotyczy licencji niewyłącznych. Ponadto umowa licencyjna
powinna określać czy licencjobiorca może dokonywać sublicencji oraz czy może przenieść
licencję na podmiot trzeci (przy czym nie zawsze prawo do przeniesienia licencji można całkowicie wyłączyć, zwłaszcza przy oprogramowaniu sprzedawanym na nośnikach materialnych). Umowa powinna wskazywać również na inne uprawnienia i ograniczenia uprawnień
licencjobiorcy (np. możliwość wykorzystania oprogramowania wyłącznie w celach niekomercyjnych itp.).
Odpowiedzialność i gwarancja
Najczęściej dostawca oprogramowania dokonuje możliwie szerokiego ograniczenia swojej
odpowiedzialności i nie udziela gwarancji na oprogramowanie sprzedawane w oparciu
o EULA. Jest to „zapożyczenie” z umów licencyjnych funkcjonujących w USA. Należy jednak
pamiętać, że przepisy w Unii Europejskiej uniemożliwiają całkowite wyłączenie (lub istotne
ograniczenie) odpowiedzialności wobec konsumenta. Takie klauzule stanowią klauzule
niedozwolone i nie tylko są nieważne, ale zagrożone są dużymi karami. Dlatego też wszelkie
ograniczenia odpowiedzialności wobec konsumenta powinny być zweryfikowane.
Obowiązywanie umowy
EULA powinna wskazywać na jaki czas udzielana jest licencja, oraz na jakim terytorium.
W przypadku oprogramowania pudełkowego najczęściej jest to czas nieokreślony, nie ma
jednak problemu aby okres obowiązywania umowy ograniczyć. Takie praktyki są stosowane
na rynku, np. przy programach księgowych. Umowa może obowiązywać zarówno do konkretnej daty (np. ostatni dzień roku) lub przez zdefiniowany okres czasu (np. 12 miesięcy). Nie
ma też przeszkód aby ograniczyć licencję do wybranego terytorium.
06. UMOWA SAAS / REGULAMIN SAAS
Umowa na oprogramowanie udostępniane w modelu Software as a Service jest swoistym
połączeniem umowy licencyjnej z umową utrzymaniową, a czasem również wdrożeniową.
W ramach SaaS producent oprogramowania nie tylko udziela licencji na korzystanie z niego,
ale również zobowiązuje się do jego utrzymania we własnej infrastrukturze informatycznej. W ramach tej umowy dochodzi więc do świadczenia usług. Umowy te bardzo często
przyjmują formę regulaminów, wzorców akceptowanych przez usługobiorcę bez możliwości
negocjacji.
Zazwyczaj umowa SaaS dotyczy oprogramowania w wersji „pudełkowej”, prekonfigurowanego i gotowego do użycia. Natomiast nie ma przeszkód, aby usługodawca SaaS oprócz
samego zapewnienia dostępu do oprogramowania oferował usługi dodatkowe, takie jak
wdrożenie oprogramowania w dostosowanej do potrzeb usługobiorcy formie.
Kluczowe klauzule umowy SaaS
Uprawnienia i obowiązki usługobiorcy, w tym typ licencji
Umowa powinna określać z czego w ramach usługi może korzystać usługobiorca, ale także
do czego jest zobowiązany i czego nie może zrobić. Np. jeśli dana forma oprogramowania/
licencji udostępniana jest wyłącznie w celach niekomercyjnych, to stosowna adnotacja
powinna znaleźć się w treści umowy.
Zobowiązania usługodawcy
W umowie SaaS należy określić do czego zobowiązuje się usługodawca. Jeśli ma być to
np. rozszerzona pomoc techniczna – powinien być wskazany jej zakres. Dodatkowo umowa
powinna opisywać również podstawowe funkcjonalności oprogramowania SaaS.
Gwarancja i odpowiedzialność
Podobnie jak przy EULA i tutaj ograniczenie odpowiedzialności wobec konsumenta powinno
być dokładnie przemyślane.
SLA
Istotnym elementem umów SaaS jest utrzymanie oprogramowania – rekomendujemy usługodawcom, aby dla własnego bezpieczeństwa i komfortu ustalili odpowiednie SLA dotyczące usługi.
Obowiązywanie umowy
Umowy SaaS często mają formę abonamentową
(subskrypcyjną), dodatkowo popularne jest stosowanie konstrukcji jej automatycznego przedłużenia
na kolejne okresy rozliczeniowe. Nie każdy mechanizm odnowienia subskrypcji będzie odpowiedni
dla usług oferowanych konsumentom (B2C).
Elementy wymagane ustawą o świadczeniu usług drogą elektroniczną
Ponieważ SaaS to usługa – umowy SaaS mają
formę regulaminów i powinny spełniać wymogi
wynikające z ustawy o świadczeniu usług drogą
elektroniczną. W szczególności powinny zawierać
informację o trybie reklamacyjnym.
Oczywiście nie są to jedyne elementy Umowy SaaS – jeśli planujecie rozszerzony support
czy prace wdrożeniowe – konieczne będzie umieszczenie innych postanowień szczególnych.
07. UMOWA O POUFNOŚCI (NDA)
Umowa o poufności (NDA) jest często pierwszą umową podpisywaną w trakcie prac nad
projektem. Jej celem jest zapewnienie ochrony informacji przekazywanych sobie przez
strony, a najczęściej informacji otrzymywanych przez wykonawcę od klienta. Jest to dosyć
prosty dokument, który nie nastręcza większych problemów negocjacyjnych.
Kluczowe klauzule umowy o poufności
Definicja informacji poufnych
Od stron zależy co zostanie uznane za informacje poufne. Najpowszechniejszą praktyką jest
szerokie traktowanie informacji poufnych i przyjmowanie, że poufne są wszelkie informacje
wymieniane między stronami – chyba, że strona ujawniająca wskazała, że dana informacja
ma charakter jawny. Za poufne nie powinny być uznawane informacje powszechnie znane.
Odpowiedzialność za naruszenie umowy
Powszechne jest stosowanie kar umownych za naruszenie zobowiązania do dochowania
poufności. Możliwe jest też pozostawienie odpowiedzialności na zasadach ogólnych – jest
to jednak mniej korzystne rozwiązanie dla poszkodowanego.
Wyłączność negocjacyjna
Czasem w ramach umowy o poufności zawierana jest również klauzula wyłączności
negocjacyjnej. Ma ona zagwarantować każdej ze stron, że w danym czasie druga strona
nie prowadzi negocjacji z nikim innymi i nie będzie realizowała danego projektu z innym
podmiotem.
Potrzebujesz dobrej
umowy o poufności?
Wykreuj sobie NDA w 5 minut.
Po polsku i po angielsku!
L eg a
lG ee k.t ech
SKONTAKTUJ SIĘ Z NAMI!
Legal Geek
ul. Olimpijska 2, 81-538 Gdynia
(działamy globalnie)
LegalGeek.pl
[email protected]
legalgeekpl
Zobacz nasze inne publikacje z serii Law-how®!
Law-how
®
e-commerce
Regulaminy i obowiązki w e-commerce
Świadczenie usług drogą elektroniczną
Ścieżka zakupowa zgodna z prawem
Odstąpienie od umowy i reklamacje
Dane osobowe i polityka prywatności
E-marketing oraz inne zagadnienia
Law-how
®
startupów
Forma prawna i Founders Agreement
Term sheet oraz Umowa Inwestycyjna
Znaki towarowe, wzory przemysłowe
Prawa Autorskie
Regulaminy e-usług
LegalGeek.pl/law-how
Download