Ostatnie publikacje z kategorii nowe technologie

autor artykułu

Tomasz Derwich

radca prawny

602 607 214

t@derwich.pl

Śledź mnie na:

W obrocie technologicznym pojęcia „SaaS” i „licencja” bywają używane zamiennie, co prowadzi do nieporozumień już na etapie oferty, a później – do sporów przy wdrożeniu, awariach i zakończeniu współpracy. Tymczasem wybór modelu nie jest kwestią nazewnictwa, lecz określenia przedmiotu świadczenia i rozkładu ryzyk pomiędzy stronami. W praktyce wpływa to na zasady aktualizacji, poziom dostępności, odpowiedzialność za przestoje, sposób przetwarzania danych oraz możliwość migracji do innego rozwiązania.

Poniżej przedstawiam najważniejsze różnice pomiędzy modelem SaaS (z ang. software as a service) a licencją (zwłaszcza on-premise), a także wskazuję typowe „punkty zapalne” w negocjacjach oraz proponuję minimalny zakres postanowień, które warto ująć w umowie – zarówno z perspektywy dostawcy, jak i klienta.

SaaS a licencja – różnica w przedmiocie świadczenia

SaaS: świadczenie usług i zapewnienie dostępu do funkcjonalności

W modelu SaaS klient co do zasady nabywa uprawnienie do korzystania z funkcjonalności systemu utrzymywanego przez dostawcę (lub jego podwykonawców). Świadczenie dostawcy obejmuje zwykle nie tylko „dostęp”, lecz także elementy utrzymaniowe: hosting, aktualizacje, monitoring, kopie zapasowe, a często również wsparcie i obsługę incydentów. Z prawnego punktu widzenia w polskiej doktrynie wskazuje się, że typowa umowa SaaS może być kwalifikowana jako umowa o świadczenie usług (z odpowiednim zastosowaniem art. 750 k.c.), przy czym kwalifikacja zależy od konkretnego sposobu korzystania z rozwiązania.

Konsekwencja biznesowa jest oczywista - jeżeli dostawca odpowiada za środowisko działania systemu, to klient będzie oczekiwał mierzalnych parametrów jakości usługi (dostępności, czasów reakcji, czasów usunięcia awarii).

Licencja: uprawnienie do korzystania z programu w środowisku klienta

W modelu licencyjnym (często on-premise) klient instaluje i uruchamia program w swoim środowisku (serwer, komputer, chmura klienta). Wtedy kluczowe jest określenie, na jakich warunkach wolno korzystać z programu: ilu użytkowników, na jakich urządzeniach, w jakich lokalizacjach, czy można tworzyć kopie zapasowe i testowe, czy wolno modyfikować, integrować, udostępniać podwykonawcom itd. Dodatkowo trzeba rozstrzygnąć utrzymanie: czy aktualizacje i wsparcie są w cenie, czy jako osobny pakiet.

Z perspektywy negocjacyjnej różnica jest istotna - w licencji większa część ryzyk operacyjnych (konfiguracja, dostępność infrastruktury, poprawność środowiska) jest po stronie klienta, a po stronie dostawcy pozostaje ryzyko prawidłowego ukształtowania zakresu uprawnień licencyjnych oraz jakości dostarczonej wersji.

Umowy „mieszane”: kiedy SaaS wymaga elementów licencyjnych

Wiele modeli dostawy oprogramowania jest mieszanych. Nawet jeśli „rdzeń” to SaaS, to pojawiają się elementy, które w praktyce wymagają licencyjnego uporządkowania, np.:

• aplikacja desktopowa lub mobilna instalowana po stronie klienta,
• wtyczki, konektory, agent synchronizacji,
• biblioteki lub SDK do integracji,
• komponenty uruchamiane lokalnie (czasem z dostępem do fragmentów kodu).

W doktrynie wskazuje się, że zawarcie licencji może być potrzebne w przypadkach granicznych, np. gdy uruchomienie usługi wymaga instalacji komponentów po stronie użytkownika (w tym wtyczek). W rezultacie kwalifikacja umowy SaaS może się zmieniać w zależności od tego, czy i w jakim zakresie użytkownik korzysta z programu „po swojej stronie”.

Wniosek praktyczny - jeżeli oferujesz SaaS, a jednocześnie dostarczasz klientowi jakiekolwiek elementy instalowane lokalnie, należy rozważyć wprowadzenie części licencyjnej (nawet krótkiej), zamiast pozostawiać tę kwestię nieuregulowaną.

Najważniejsze obszary umowy: gdzie najczęściej dochodzi do sporów

Dostępność usługi i przestoje (SLA)

W SaaS podstawą jest ustalenie parametrów dostępności (np. miesięczny poziom dostępności), okien serwisowych oraz procedury obsługi incydentów. Warto również przesądzić, jakie konsekwencje wywołuje niedotrzymanie SLA (najczęściej: kredyty/rabaty), oraz jasno opisać sytuacje wyłączające odpowiedzialność (np. awarie po stronie łączy klienta). 

W modelu licencyjnym SLA często dotyczy nie tyle „dostępności systemu”, co wsparcia i czasu reakcji (bo infrastruktura jest po stronie klienta).

Aktualizacje i zmiany funkcjonalności

SaaS zakłada ciągły rozwój produktu. Umowa powinna zatem określać:

• zasady wdrażania aktualizacji, 
• sposób komunikowania zmian, 
• kryteria „istotnej zmiany” (np. usunięcie kluczowej funkcji, ograniczenie integracji), 
• uprawnienia klienta w razie istotnej zmiany (np. możliwość wypowiedzenia, okres przejściowy, alternatywne rozwiązanie).

Przy licencji kluczowe jest ustalenie, czy i na jakich warunkach klient nabywa prawo do nowych wersji oraz czy aktualizacje są objęte ceną, czy pakietem utrzymania (maintenance). Zazwyczaj kwestie te regulowane są w tzw. umowach serwisowych czy SLA.

Dane i zakończenie współpracy

W SaaS najbardziej newralgicznym elementem jest „wyjście” klienta z systemu. Dobre postanowienia powinny obejmować:

• zakres i format eksportu danych (w tym metadanych i konfiguracji), 
• termin i tryb udostępnienia eksportu, 
• okres dostępu po rozwiązaniu umowy,
• retencję i zasady usunięcia danych,
• relację do kopii zapasowych (czas ich przechowywania, sposób nadpisywania).

Niedookreślenie tych kwestii zazwyczaj skutkuje konfliktem dopiero wtedy, gdy klient rzeczywiście chce zmienić dostawcę – czyli w sytuacji, gdy napięcie negocjacyjne jest już najwyższe.

Najczęstsze błędy stron

Jeżeli umowa ma „działać” także wtedy, gdy pojawi się napięcie po stronie operacyjnej lub finansowej, warto unikać kilku klasycznych błędów, które powtarzają się u dostawców i klientów.

Po stronie dostawców:

• stosowanie nazwy „SaaS” bez uregulowania SLA, procedur awarii i zasad zmian, 

• brak klarownego podziału na elementy „w cenie” oraz usługi dodatkowe (wdrożenie, migracja, integracje),

• niewystarczające postanowienia o eksporcie danych i zakończeniu współpracy, 

• dostarczanie elementów instalowanych lokalnie bez części licencyjnej (i bez zakazów nadużyć), 

• limity odpowiedzialności sformułowane skrajnie (albo zbyt szeroka odpowiedzialność, albo zapisy, których poważny klient B2B nie zaakceptuje).

Po stronie klientów:

• koncentracja na cenie i funkcjach, z pominięciem kwestii danych i migracji,

• brak ustaleń co do dostępności systemu, przy jednoczesnym traktowaniu rozwiązania jako krytycznego operacyjnie,

• akceptacja dowolnych zmian funkcjonalności bez mechanizmów ochronnych,

• niedoszacowanie ograniczeń w zakresie użytkowników, podwykonawców i spółek z grupy,

• brak weryfikacji limitu odpowiedzialności w relacji do rzeczywistej szkody (np. koszt przestoju).

Minimalna checklista postanowień umownych

W praktyce umowy dotyczące oprogramowania „psują się” w tych samych miejscach: strony nie doprecyzowują, co jest przedmiotem świadczenia, jak wygląda aktualizacja i utrzymanie, kto odpowiada za dane, oraz jak ma przebiegać zakończenie współpracy. Ponieważ artykuł porównuje dwa modele (SaaS oraz licencję), poniżej dzielę checklistę na trzy części: elementy wspólne, a następnie postanowienia typowe dla SaaS oraz typowe dla licencji. Taki podział pozwala szybko sprawdzić w minimalnym zakresie, czy projekt umowy rzeczywiście odpowiada temu, jak ma działać produkt i relacja biznesowa.

Część wspólna (SaaS i licencja):

• opis świadczenia i zakresu: co dokładnie dostarczasz/otrzymujesz (funkcje, moduły, integracje, ograniczenia),

• aktualizacje i rozwój: czy aktualizacje są w cenie, jak są komunikowane i jak wpływają na kompatybilność,

• bezpieczeństwo i poufność: minimalne standardy, dostęp do systemu/danych, zasady zgłaszania incydentów,

• odpowiedzialność: limit (cap), wyłączenia (np. utracone korzyści) oraz wyjątki, które zwykle wymagają odrębnego podejścia (np. poufność, dane),

• zakończenie współpracy: co oznacza „koniec” (zaprzestanie korzystania, rozliczenia, zwrot/usunięcie materiałów, obowiązki po rozwiązaniu),

• odpowiedzialność (limity, wyłączenia, wyjątki).

Postanowienia typowe dla SaaS:

• SLA i dostępność: poziomy dostępności, okna serwisowe, czasy reakcji/usunięcia awarii, rekompensaty (np. rabat na kolejny okres),

• zmiany w usłudze: kiedy dostawca może wprowadzać zmiany funkcjonalne, co jest „istotną zmianą” i jakie uprawnienia ma klient w takim przypadku,

• dane i „exit”: eksport danych (format, zakres, termin, koszt), okres dostępu po zakończeniu, retencja i usunięcie danych oraz zasady dotyczące kopii zapasowych,

• podwykonawcy (np. chmura): zasady korzystania z dostawców infrastruktury i wpływ na bezpieczeństwo oraz dostępność.

Postanowienia typowe dla licencji (zwłaszcza on-premise):

• zakres licencji i sposób liczenia: na ilu użytkowników/stanowisk/urządzeń/instancji, czy obejmuje spółki z grupy i podwykonawców.,

• środowiska i kopie: środowisko produkcyjne/testowe/awaryjne, kopie zapasowe, prawo do odtworzenia środowiska po awarii,

• modyfikacje i integracje: czy wolno modyfikować, kto odpowiada za zmiany, co z kompatybilnością po aktualizacjach,

• utrzymanie (maintenance): czy wsparcie i aktualizacje są w cenie, jaki jest czas wsparcia dla danej wersji, zasady instalacji poprawek,

• zakończenie i zgodność: obowiązek odinstalowania/usunięcia kopii, a jeżeli przewidujecie kontrolę zgodności (audyt) – to w rozsądnym i proporcjonalnym zakresie.

Minimalna checklista postanowień umownych

Z perspektywy dostawcy oprogramowania kluczowe jest takie ułożenie dokumentów (umowy, regulaminu, oferty), aby od początku było jasne, co dokładnie sprzedajesz: dostęp do usługi (SaaS) czy uprawnienie do korzystania z programu (licencja), ewentualnie model mieszany. To nie jest kwestia semantyki – od tej decyzji zależy m.in. sposób rozliczeń, aktualizacji, odpowiedzialność za dostępność oraz to, czy i jakie uprawnienia licencyjne są potrzebne dla komponentów instalowanych po stronie klienta. W praktyce – zwłaszcza u mniejszych dostawców negocjujących z większymi organizacjami – jasne zakomunikowanie różnic między modelami na początku rozmów ogranicza „wojnę wzorców”, przyspiesza negocjacje i pozwala skuteczniej chronić IP oraz ograniczać nieautoryzowane użycie.

Natomiast z punktu widzenia klienta najczęstszy problem polega na tym, że warunki umowy nie odpowiadają planowanemu sposobowi wykorzystania rozwiązania. Warto więc weryfikować, czy zakres uprawnień (w licencji lub w elementach licencyjnych w SaaS) obejmuje realne potrzeby biznesowe – w szczególności wtedy, gdy w grę wchodzi korzystanie przez podwykonawców, spółki z grupy, integracje z systemami zewnętrznymi, budowanie własnych rozwiązań na API albo udostępnianie dostępu dalej w organizacji. Równolegle obie strony powinny świadomie negocjować odpowiedzialność: klient potrzebuje realnych instrumentów ochrony na wypadek naruszenia umowy, a dostawca – przewidywalnej ekspozycji ryzykowej, adekwatnej do ceny i charakteru usługi..

Wreszcie, rynek wyraźnie zmierza w stronę rozwiązań „niezależnych od jednego środowiska” (multi-cloud, hybryda, migracje pomiędzy dostawcami) oraz większego nacisku na przenoszalność danych i ograniczanie vendor lock-in. Sam Data Act wprowadza reżim obowiązków ułatwiających switching między dostawcami usług przetwarzania danych (w tym usług chmurowych; a w analizach wprost omawia się implikacje także dla SaaS). To sprawia, że coraz trudniej obronić umowy, które pomijają kwestie „wyjścia” z rozwiązania. Niezależnie od tego, czy wybierasz SaaS czy licencję, coraz częściej standardem będzie precyzyjne uregulowanie: eksportu danych, formatów, terminów, wsparcia migracyjnego, retencji i zasad zakończenia współpracy. Krótko: dobrze dobrany model to dopiero początek – realne bezpieczeństwo daje dopiero kontrakt dopasowany do konkretnego produktu i sposobu jego używania.

Powyższe informacje mają charakter ogólny i edukacyjny – nie stanowią porady prawnej w konkretnej sprawie. Każda sytuacja wymaga analizy stanu faktycznego i dokumentów. Jeśli chcesz zweryfikować model (SaaS/licencja) lub postanowienia wzorca umowy, rozważ konsultację indywidualną.

Więcej z kategorii prawo nowych technologii

Artykuł to jednak za mało?

r. pr. Tomasz Derwich

Formularz kontaktowy

Zadzwoń, napisz lub wyślij formularz.

Podczas tego pierwszego kontaktu dowiem się dokładnie jakie są Twoje potrzeby i wyjaśnię jak mogę Ci pomóc.

Administratorem Twoich danych osobowych jest Kancelaria Radcy Prawnego Tomasz Derwich. Dane będą przetwarzane w celu udzielenia odpowiedzi lub kontaktu zgodnie z polityką prywatności.

Obserwuj mnie

Informacje prawne

Specjalizacje

Na skróty

Kancelaria Radcy Prawnego

Tomasz Derwich

ul. I. Paderewskiego 6/5

61-770 Poznań

NIP: 6182057887

REGON: 361662365

Zadzwoń lub napisz do mnie w celu umówienia bezpłatnej konsultacji wstępnej Twojej sprawy - w formie rozmowy telefonicznej lub wideokonferencji online.