EULA, SaaS Agreement i licencja na oprogramowanie: jakie prawa otrzymuje klient

Klient opłacił korporacyjną subskrypcję usługi SaaS, udostępnił ją pracownikom grupy i zapewnił dostęp zewnętrznemu wykonawcy. Dostawca uznał, że licencja zezwala na korzystanie z produktu wyłącznie przez jedną firmę. Klient natomiast zakładał, że subskrypcja obejmuje cały jego zespół.

Takie spory powstają, gdy umowa ogranicza się do ogólnego sformułowania o niewyłącznym prawie do korzystania. Nie odpowiada ono na praktyczne pytania: kto może korzystać z produktu, czy dozwolony jest dostęp dla podmiotów powiązanych, czy można zapewnić dostęp wykonawcom, instalować program na kilku serwerach lub wykorzystywać go przy świadczeniu usług na rzecz osób trzecich. Zakres praw powinien odpowiadać sposobowi dostarczania produktu. Chmurowy SaaS, program zainstalowany na serwerze klienta i rozwiązanie white-label wymagają różnych modeli umownych.

Czym SaaS różni się od licencji na zainstalowane oprogramowanie

W klasycznym modelu licencyjnym klient otrzymuje kopię programu oraz prawo do wykonywania z nim określonych czynności. Może zainstalować oprogramowanie na uzgodnionej liczbie urządzeń lub serwerów, uruchamiać je przez ustalony okres i tworzyć niezbędne kopie techniczne w granicach określonych przez prawo właściwe i umowę.

W modelu SaaS program pozostaje w infrastrukturze dostawcy. Klient otrzymuje zdalny dostęp do funkcjonalności za pośrednictwem przeglądarki, aplikacji lub API. Zazwyczaj nie dochodzi do przekazania kopii oprogramowania do samodzielnej instalacji.

Dlatego umowa SaaS często łączy kilka elementów: prawo dostępu do usługi, świadczenie usług, wsparcie techniczne, przetwarzanie danych oraz ograniczone zezwolenie na korzystanie z interfejsu i innych chronionych elementów produktu. Nazwa dokumentu nie zmienia faktycznego modelu. Jeżeli umowa nosi nazwę licencji, klient nie otrzymuje automatycznie prawa do pobrania kodu, zainstalowania systemu na własnym serwerze ani przekazania produktu innej firmie.

Jak wybrać model umowny

Sposób dostarczania produktu określa, jakie prawa należy opisać i jakie ograniczenia będą miały znaczenie.

Czasami jeden produkt wymaga kilku dokumentów. Klient B2B podpisuje SaaS Agreement, jego pracownicy akceptują Terms of Use, a wersja mobilna lub desktopowa jest dodatkowo regulowana przez EULA. Postanowienia tych dokumentów nie powinny być ze sobą sprzeczne.

Jakie prawa klienta należy określić w umowie

Sformułowanie „klientowi udziela się niewyłącznej, nieprzenoszalnej licencji” opisuje jedynie część relacji. Aby umowa licencyjna na oprogramowanie była skuteczna, należy powiązać warunki prawne ze sposobem, w jaki klient będzie korzystać z produktu.

Określić krąg uprawnionych użytkowników

Umowa powinna wyjaśniać, kto może uzyskać dostęp: pracownicy klienta, podmioty należące do jego grupy kapitałowej, personel tymczasowy, konsultanci czy zewnętrzni wykonawcy.

Jeżeli produkt kupuje spółka holdingowa, a korzystać z niego będą spółki zależne, prawo grupy do korzystania z produktu należy wskazać wprost. Można wymagać, aby klient odpowiadał za działania wszystkich użytkowników posiadających dostęp i zapewniał przestrzeganie przez nich ustalonych ograniczeń.

W przypadku wykonawców zazwyczaj zezwala się na dostęp wyłącznie w celu wykonywania prac na rzecz klienta. Samodzielne korzystanie z produktu na rzecz innych klientów nie mieści się w takim modelu.

Opisać dozwolony cel korzystania

Sformułowanie „do wewnętrznych celów biznesowych” nie jest odpowiednie dla każdego produktu. Może ono uniemożliwić klientowi korzystanie z systemu przy świadczeniu usług na rzecz własnych klientów, mimo że właśnie w tym celu nabył rozwiązanie.

Jeżeli produkt jest przeznaczony dla agencji, konsultantów, operatorów platform lub managed service providers, umowa powinna zezwalać na obsługę projektów klientów końcowych. Jednocześnie można zakazać odsprzedaży samej usługi, tworzenia konkurencyjnego produktu oraz zapewniania osobom trzecim samodzielnego dostępu.

Określić ograniczenia techniczne

Zakres licencji można obliczać na podstawie liczby użytkowników, urządzeń, serwerów, instancji, transakcji, projektów lub zapytań API. Wybrany wskaźnik powinien być mierzalny i odpowiadać modelowi cenowemu. Należy określić, czy uwzględnia się nieaktywne konta, środowiska testowe i instancje zapasowe. Jeżeli dostawca ma prawo weryfikować przestrzeganie limitów, umowa powinna określać źródła danych, procedurę powiadamiania oraz konsekwencje przekroczenia limitów.

Określić okres i moment wygaśnięcia praw

Licencja może obowiązywać przez okres subskrypcji, przez uzgodniony czas lub bezterminowo. Słowo perpetual nie oznacza, że dostawca ma obowiązek bezterminowo zapewniać wsparcie, aktualizacje i infrastrukturę chmurową. Usługi te są regulowane odrębnie.

W przypadku SaaS należy określić, co dzieje się po rozwiązaniu umowy: kiedy konta zostają zablokowane, przez jaki czas klient może eksportować dane oraz kiedy informacje są usuwane. W modelu on-premise należy określić obowiązek zaprzestania korzystania z produktu, usunięcia kopii i potwierdzenia ich usunięcia.

Uregulować przenoszenie praw i sublicencjonowanie

Zakaz przeniesienia licencji może utrudnić reorganizację klienta, sprzedaż przedsiębiorstwa lub przeniesienie umowy na inną spółkę z grupy. W umowie warto osobno uwzględnić połączenie spółek, sprzedaż istotnej części aktywów oraz zmianę kontroli.

Prawo do korzystania z produktu przez klientów końcowych zazwyczaj wymaga zezwolenia na sublicencjonowanie lub zastosowania innej konstrukcji umownej. Standardowa licencja korporacyjna nie zapewnia takiego prawa. W modelach white-label i OEM określa się również terytorium, kanały dystrybucji oraz warunki umów z użytkownikami końcowymi.

Określić dozwolone modyfikacje i integracje

W przypadku produktu on-premise należy wskazać, czy klient może zmieniać ustawienia, tworzyć rozszerzenia i integrować system z innym oprogramowaniem. Sam dostęp do API nie zawsze zezwala na kopiowanie dokumentacji, masowe pozyskiwanie danych lub tworzenie konkurencyjnego interfejsu. Ograniczenia dotyczące dekompilacji i inżynierii wstecznej powinny uwzględniać prawo właściwe. W UE określone działania niezbędne do korzystania z programu przez legalnego nabywcę lub zapewnienia interoperacyjności mogą być dozwolone przez prawo po spełnieniu określonych warunków. Całkowity zakaz umowny nie zawsze będzie skuteczny.

Rozdzielić prawa do produktu, danych i rezultatów

Licencja na program nie określa automatycznie praw do danych klienta, ustawień, raportów i materiałów utworzonych za pomocą produktu. Kategorie te należy opisać osobno.

Klient zazwyczaj zachowuje prawa do przesłanych danych. Dostawca otrzymuje ograniczone prawo do ich przetwarzania w celu wykonania umowy. Jeżeli usługa tworzy raporty analityczne, szablony, wygenerowane treści lub wytrenowane konfiguracje, umowa powinna określać, kto ma prawo korzystać z rezultatów po zakończeniu subskrypcji.

Jakie ograniczenia można wprowadzić

Dostawca może zakazać kopiowania poza uzgodniony zakres, przekazywania danych uwierzytelniających, odsprzedaży usługi, obchodzenia limitów technicznych oraz wykorzystywania produktu do tworzenia konkurencyjnego rozwiązania. Ograniczenia powinny być konkretne i odpowiadać architekturze produktu.

Zakaz udostępniania produktu osobom trzecim będzie wymagał wyjątku dla wykonawców, jeżeli uczestniczą oni we wdrożeniu i obsłudze systemu. Zakaz wykorzystania komercyjnego nie jest odpowiedni dla produktu, który klient nabywa na potrzeby swojej działalności gospodarczej.

Dostawca powinien również określić konsekwencje naruszenia. Umowa może przewidywać zawieszenie dostępu, opłatę za przekroczenie uzgodnionego zakresu, usunięcie naruszenia w określonym terminie lub rozwiązanie umowy. Natychmiastową blokadę należy stosować ostrożnie, jeżeli usługa jest wykorzystywana w krytycznych procesach klienta lub do przechowywania jego danych.

Kto powinien posiadać prawa do oprogramowania

Dostawca może udzielić licencji wyłącznie w granicach praw, które sam posiada. Przed rozpoczęciem sprzedaży należy sprawdzić umowy z założycielami, zatrudnionymi deweloperami i zewnętrznymi wykonawcami. Samo opłacenie prac programistycznych nie zawsze oznacza przeniesienie na klienta praw wyłącznych. Osobnej weryfikacji wymagają komponenty open-source, komercyjne biblioteki, SDK, fonty oraz treści osób trzecich. Ich licencje mogą określać zasady dystrybucji, oznaczania autorstwa, udostępniania kodu źródłowego lub wykorzystywania w produkcie komercyjnym.

W umowie z klientem nie należy obiecywać szerszego zakresu praw niż ten, który firma uzyskała od deweloperów i dostawców komponentów. Taki błąd może zostać wykryty podczas due diligence, pozyskiwania inwestycji lub po otrzymaniu roszczenia od podmiotu uprawnionego.

Czym umowa licencyjna różni się od EULA

EULA reguluje korzystanie z programu przez użytkownika końcowego. Taki dokument jest zazwyczaj stosowany w przypadku aplikacji mobilnych, programów desktopowych, gier i innego oprogramowania, które użytkownik pobiera lub instaluje.

B2B SaaS Agreement reguluje szerszy zakres kwestii: dostęp do usługi chmurowej, płatności, wsparcie, dostępność, przetwarzanie danych, odpowiedzialność oraz działania użytkowników korporacyjnych. Zastąpienie takiej umowy krótką EULA pozostawia znaczną część relacji bez odpowiedniego uregulowania.

Jeżeli aplikacja jest dystrybuowana za pośrednictwem App Store lub Google Play, EULA i warunki korzystania należy uzgodnić z zasadami danej platformy. Platforma może określać własne postanowienia dotyczące płatności, zwrotów, subskrypcji i standardowej licencji użytkownika końcowego.

Typowe błędy przy licencjonowaniu SaaS i oprogramowania

Częstym błędem jest wykorzystywanie jednego wzoru dla produktu chmurowego i instalowanego. W SaaS Agreement pojawia się prawo do zainstalowania kopii, mimo że klient nie otrzymuje programu, natomiast umowa on-premise nie określa liczby serwerów i środowisk testowych.

Czasami ograniczenia licencyjne nie są zgodne z ofertą handlową. Dział sprzedaży obiecuje dostęp dla całej grupy klienta, podczas gdy umowa zezwala na korzystanie z produktu tylko przez jedną firmę. Pakiet cenowy jest obliczany na podstawie aktywnych użytkowników, ale umowa ogranicza łączną liczbę utworzonych kont.

Problemy pojawiają się również przy łączeniu licencji ze wsparciem. Bezterminowe prawo do korzystania z zainstalowanej wersji nie oznacza bezterminowego prawa do aktualizacji, poprawek i konsultacji. Koszt i okres świadczenia tych usług należy określić osobno.

Kolejne ryzyko wiąże się z zakończeniem umowy. Klient traci dostęp do SaaS natychmiast po rozwiązaniu umowy i nie może wyeksportować danych, podczas gdy dostawca nadal przechowuje informacje bez uzgodnionego terminu. Warunki zakończenia korzystania z usługi należy ustalić przed rozpoczęciem używania produktu.

Co sprawdzić przed podpisaniem umowy

Dostawca powinien porównać warunki licencyjne z architekturą produktu, pakietami cenowymi i sposobem działania działu sprzedaży. Jeżeli produkt umożliwia kilka sposobów wdrożenia, dla każdego z nich należy określić odrębny zakres praw.

Klient powinien ustalić, czy umowa obejmuje wszystkie spółki i osoby, które będą korzystać z systemu, czy dozwolona jest praca z danymi klientów końcowych oraz czy można zapewnić dostęp wykonawcom. W przypadku produktu on-premise należy dodatkowo sprawdzić serwery, środowiska testowe, kopie zapasowe oraz prawo do przeniesienia produktu w przypadku modernizacji infrastruktury.

Przed podpisaniem należy również ocenić, czy prawa przysługują dostawcy, jakie komponenty zewnętrzne są wykorzystywane, jakie są zasady aktualizacji, konsekwencje przekroczenia limitów oraz możliwość eksportowania danych po zakończeniu współpracy.