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
