SaaS a on premise: kto odpowiada za licencje i zgodność?

Scenka z życia: audyt, który obnaża różnicę między SaaS a on premise

Krótka historia firmy, która „myślała, że to dostawca wszystko ogarnia”

Średniej wielkości firma produkcyjna. Do tej pory wszystko „działało”: system ERP on premise na własnych serwerach, kilka rozwiązań SaaS do CRM, HR i księgowości online. Pewnego dnia przychodzi pismo od producenta ERP z zapowiedzią audytu licencyjnego. Dział IT wzrusza ramionami – „przecież integrator mówił, że mamy zapas licencji”. Zarząd wzrusza bardziej nerwowo – nikt nie potrafi pokazać aktualnej ewidencji licencji.

Audyt ujawnia, że liczba realnych użytkowników ERP dawno przekroczyła zakupione licencje. Na dodatek kopie testowe systemu, używane przez zewnętrznego integratora, też wymagają licencji, których nikt nie przewidział. Firma dostaje propozycję „ugodowego” dopłacenia za brakujące licencje oraz kary za nieuprawnione użycie. Równolegle, przy przeglądzie umów SaaS, wychodzi inny problem: handlowcy przekazują loginy do CRM partnerom handlowym, co jest jawnym naruszeniem regulaminu dostawcy chmurowego.

W obu przypadkach pojawia się to samo pytanie: kto odpowiada za licencje i zgodność – producent, dostawca SaaS, integrator, reseller, a może jednak sama firma? Odpowiedź jest mniej oczywista, niż się wydaje, a granica odpowiedzialności przebiega zupełnie inaczej w modelu on premise i w modelu SaaS.

Konflikty z producentami oprogramowania i dostawcami usług chmurowych rzadko biorą się ze złej woli. Częściej z założenia, że „przecież dostawca się zna, to on odpowiada”. Tymczasem umowy licencyjne i regulaminy są napisane tak, że cała odpowiedzialność za zgodność bardzo często ląduje po stronie klienta. Brak jasności w tym, kto co kontroluje i dokumentuje, to gotowy przepis na drogie dopłaty po audycie i nieprzyjemne rozmowy z zarządem.

Podstawy: czym różni się SaaS od on premise z perspektywy prawa i licencji

Model dostarczania a model licencjonowania – to nie to samo

On premise i SaaS najczęściej opisuje się jako różne sposoby dostarczenia oprogramowania: na własnym serwerze lub przez Internet z chmury. Z punktu widzenia prawa autorskiego i licencji ważniejsze jest jednak, jak ukształtowano prawa do korzystania z programu i kto ma kontrolę nad środowiskiem, w którym on działa.

On premise to zwykle klasyczna licencja na korzystanie z programu komputerowego, instalowanego w infrastrukturze klienta. Klient dostaje prawo do zainstalowania określonej liczby kopii, używania ich w określony sposób (np. na własne potrzeby biznesowe) i przez określoną liczbę użytkowników czy urządzeń. Prawa autorskie pozostają przy producencie – klient nie „kupuje” programu, tylko uprawnienie do jego wykorzystywania zgodnie z licencją.

SaaS to natomiast przede wszystkim usługa dostarczania funkcjonalności oprogramowania przez Internet. Użytkownik zwykle nie otrzymuje kopii programu, nie instaluje go, nie ma dostępu do kodu. Dostaje prawo dostępu do usługi, często w formie subskrypcji czasowej. Gdzieś pod spodem też jest licencja na oprogramowanie – ale najczęściej między producentem a dostawcą usługi (jeśli to dwie różne firmy), a nie bezpośrednio z użytkownikiem końcowym.

Model dostarczania (lokalnie vs chmura) i model licencjonowania (per użytkownik, per urządzenie, per instancja, per wolumen) mogą się mieszać: można mieć licencję per użytkownik zarówno w SaaS, jak i w on premise, a także licencję serwerową w obu modelach. To umowa określa, na jakich zasadach klient używa oprogramowania czy usługi, a nie sama etykietka „SaaS” lub „on premise”.

On premise: licencja na kopię programu u klienta

W modelu on premise centrum wszystkiego jest kopia programu zainstalowana u klienta. Producent lub jego partner sprzedaje licencję (trwałą lub czasową), określając jasno (lub mniej jasno):

• na ilu serwerach, stacjach roboczych czy urządzeniach program może być zainstalowany,
• ilu użytkowników (nazwanych, równoczesnych, przyłączonych do systemu) może z niego korzystać,
• czy licencja obejmuje środowiska testowe, deweloperskie, zapasowe,
• jakie działania są zakazane (np. modyfikacje kodu, odsprzedaż, udostępnianie podmiotom trzecim).

Klient ma fizyczną lub wirtualną kontrolę nad serwerem i kopiami programu. To on decyduje, kto ma dostęp, instaluje aktualizacje, tworzy kopie zapasowe, klonuje maszyny wirtualne. I to on ma obowiązek pilnować, by liczba instalacji i użytkowników nie przekroczyła zakresu licencji. Producent nie widzi na co dzień, co klient robi w swoim data center – ma jedynie prawo przyjść z audytem.

Aspekty finansowe też są inne: w on premise często dominuje podejście CAPEX – jednorazowy wydatek na licencje (plus ewentualne roczne utrzymanie). W praktyce bywa, że „stare” licencje są traktowane jak coś, co „zawsze można wykorzystać” – bez refleksji, czy nowa wersja programu, nowe środowisko czy nowa metoda wirtualizacji nie zmieniły zasad licencjonowania. Stąd częste rozjazdy między rzeczywistością a umową.

SaaS: licencja w cieniu usługi subskrypcyjnej

W SaaS klient najczęściej nie dostaje klasycznej licencji na kopię programu. Dostaje prawo dostępu do usługi w ramach subskrypcji: comiesięcznego lub rocznego abonamentu. Dostawca kontroluje infrastrukturę, serwery, instancje baz danych, aktualizacje i składniki techniczne. Klient nie ma uprawnień do samodzielnego instalowania oprogramowania – ma jedynie korzystać z funkcji, które dostawca udostępnia przez przeglądarkę, aplikację mobilną czy API.

Jeśli dostawca SaaS korzysta z oprogramowania firm trzecich (system operacyjny, baza danych, biblioteki, frameworki), to on musi mieć odpowiednie licencje i zadbać o ich zgodność z warunkami. Klient końcowy zwykle nie ma z tym bezpośredniej relacji; jego prawa i obowiązki wynikają z umowy (MSA, regulaminu) podpisanej z dostawcą SaaS. Granica odpowiedzialności przebiega tam, gdzie umowa i architektura usługi dzielą kontrolę nad środowiskiem.

W SaaS model finansowy to głównie OPEX – bieżące koszty operacyjne. Z punktu widzenia licencji kluczowe stają się:

• liczba kont użytkowników (seatów),
• zakres funkcjonalny (pakiety, moduły),
• limity wolumenowe (np. liczba transakcji, ilość danych, liczba wywołań API),
• warunki udostępniania dostępu osobom trzecim (partnerzy, podwykonawcy).

Mini-wniosek z tej części jest prosty: techniczna forma dostarczenia (serwer w piwnicy czy chmura) to tylko powierzchnia. Liczy się to, jak zdefiniowano prawa do korzystania, gdzie przebiega linia kontroli i jakie zapisy znalazły się w umowie i regulaminach.

Kto za co odpowiada w modelu on premise – role i granice odpowiedzialności

Rola klienta: „strażnik” liczby instalacji, użytkowników i środowisk

W on premise odpowiedzialność klienta jest najszersza, choć wiele firm tego nie docenia. Klient odpowiada m.in. za:

• legalność posiadanych kopii – każda instalacja programu musi mieć podstawę w licencji,
• liczbę użytkowników – aby nie używało systemu więcej osób, niż przewiduje licencja,
• środowiska testowe, deweloperskie, szkoleniowe – czy są objęte licencją, czy wymagają osobnych uprawnień,
• kopie zapasowe i klony maszyn wirtualnych – czy ich użycie nie powoduje „ukrytych” dodatkowych instalacji.

Typowy błąd to skupienie się wyłącznie na liczbie wykupionych „userów” w momencie zakupu, bez bieżącego monitorowania faktycznego użycia. Pracownicy przychodzą i odchodzą, role się zmieniają, nowe działy dostają dostęp „tymczasowo”, a po kilku latach realna liczba aktywnych kont może być znacznie wyższa niż kupione licencje.

Drugi klasyk to środowiska testowe i deweloperskie. Wiele licencji komercyjnych wyraźnie wskazuje, że również takie instalacje wymagają licencji, chyba żeby umowa przewidywała osobne, darmowe lub tańsze licencje testowe. W praktyce integrator lub zespół IT, tworząc nowe środowisko testowe czy kopię bazy na potrzeby analizy, używa tej samej licencji produkcyjnej, co przy audycie bywa liczone jako dodatkowe instalacje.

Odpowiedzialność klienta obejmuje też zapewnienie zgodności wewnętrznej: polityki IT, które regulują, kto może instalować oprogramowanie, jak ewidencjonuje się licencje, jak raportuje się zmiany w liczbie użytkowników. Brak takiego systemu to wyraźny sygnał dla audytora, że ryzyko niezgodności jest wysokie – a to zwykle przekłada się na twardsze stanowisko w negocjacjach.

Obowiązki producenta: jasne warunki licencji i ich komunikacja

Producent oprogramowania zwykle:

• udziela licencji na korzystanie z programu (np. w formie EULA lub umowy licencyjnej),
• określa szczegółowo zasady użycia: zakres terytorialny, czasowy, liczbę użytkowników, typ środowisk,
• dostarcza dokumentację (czasem w formie cenników i warunków licencyjnych) opisującą modele licencjonowania,
• ma prawo do audytu, jeśli umowa tak stanowi.

Z punktu widzenia klienta kluczowe jest to, jak te warunki są sformułowane. Im bardziej ogólne i nieczytelne zapisy, tym większe ryzyko błędnej interpretacji. Przykładowo, licencja „per użytkownik” może znaczyć coś innego u dwóch różnych producentów:

• u jednego – użytkowników nazwanych, niezależnie od tego, czy się logują,
• u drugiego – użytkowników równoczesnych, licząc tylko aktywne logowania.

Producent odpowiada za to, by opis licencji był dostępny i aktualny – ale nie musi „pilnować” klienta na co dzień. Standardem są klauzule typu: „Użytkownik zobowiązuje się do używania oprogramowania wyłącznie w zakresie udzielonej licencji oraz do stosowania odpowiednich środków nadzoru w celu zapewnienia zgodności.” Innymi słowy – producent wskazuje zasady, ale nie bierze odpowiedzialności za ich codzienne przestrzeganie u klienta.

Warto zwrócić uwagę na zapisy o zmianach licencji przy aktualizacji wersji. Zdarza się, że przejście na nową wersję programu pociąga za sobą zmianę polityki licencyjnej (np. inny sposób liczenia użytkowników). Akceptacja nowych warunków przy aktualizacji bywa równoznaczna z przyjęciem nowych ograniczeń. Brak monitorowania takich zmian to częste źródło nieświadomych naruszeń.

Reseller, integrator i konsultant – pośrednicy, nie właściciele licencji

W ekosystemie on premise występują też pośrednicy: resellerzy, partnerzy wdrożeniowi, integratorzy systemów. Ich rola polega najczęściej na:

• sprzedaży licencji w imieniu producenta,
• doradztwie w doborze modelu licencyjnego do potrzeb klienta,
• projektowaniu i wdrażaniu rozwiązania, konfiguracji, integracjach, szkoleniach.

Kluczowe jest to, że reseller nie jest właścicielem licencji – nie może z własnej woli interpretować ich inaczej niż producent. Jeśli przedstawiciel handlowy „na słowo” zapewnia, że dodatkowe środowisko testowe „na pewno nie wymaga licencji”, ale nie ma tego w umowie czy oficjalnych warunkach, przy audycie liczy się dokument, nie ustna obietnica.

Integrator, tworząc instalacje testowe lub klonując bazy danych, często robi to na sprzęcie klienta, używając jego licencji. Jeżeli nie określono jasno w umowie wdrożeniowej zasad licencjonowania takich środowisk, klient może usłyszeć od producenta: „To państwo jako posiadacz licencji odpowiadacie za to, co integrator z nimi zrobił”.

Mini-wniosek: w modelu on premise odpowiedzialność za faktyczne użycie licencji spoczywa przede wszystkim na kliencie. Producent ustala zasady, reseller doradza, integrator technicznie wdraża – ale to klient jest „strażnikiem” liczby instalacji, użytkowników i środowisk. Nikt z zewnątrz za niego tego nie policzy, a skutki błędów uderzą przede wszystkim w jego budżet i reputację.

Kto za co odpowiada w modelu SaaS – granice odpowiedzialności dostawcy i klienta

Usługa zamiast kopii programu: kto kontroluje co

W modelu SaaS sytuacja wygląda inaczej. Klient nie kontroluje serwerów ani oprogramowania jako takiego – zarządza kontami użytkowników i konfiguracją w ramach udostępnionej aplikacji. Dostawca SaaS odpowiada za:

• legalność oprogramowania użytego do świadczenia usługi (systemy operacyjne, bazy danych, aplikacje firm trzecich),
• utrzymanie infrastruktury i bezpieczeństwo techniczne,
• zapewnienie parametrów dostępności i wydajności (zgodnie z SLA),
• zgodność z przepisami dotyczącymi danych (np. RODO), o ile wynika to z umowy.

Klient SaaS odpowiada natomiast za:

• korzystanie z usługi wyłącznie zgodnie z umową i regulaminem,

Granica „tu kończy się SaaS, tu zaczyna klient”

W pewnej spółce logistycznej wybuchła awantura po wewnętrznym audycie IT: dział prawny twierdził, że za nadmiarowe konta w systemie CRM odpowiada dostawca, bo „przecież wszystko jest w chmurze”, a dostawca wskazywał palcem na administratora po stronie klienta. Po kilku mailach z prawnikami obu stron okazało się, że spór rozbija się o jedno zdanie w regulaminie, którego nikt wcześniej nie czytał.

Granica odpowiedzialności w SaaS przebiega tam, gdzie kończy się realna kontrola klienta nad środowiskiem. Zwykle układa się to następująco:

• dostawca kontroluje infrastrukturę (serwery, systemy, oprogramowanie bazowe) oraz logikę aplikacji (kodu, modułów, mechanizmów licencyjnych w systemie),
• klient kontroluje to, co wprowadza do systemu i jak z niego korzysta (użytkownicy, konfiguracja, dane, integracje po swojej stronie).

Jeżeli więc umowa przewiduje licencjonowanie „per użytkownik nazwany”, a panel administracyjny pozwala tworzyć nowych użytkowników bez twardego limitu, dostawca zwykle nie bierze odpowiedzialności za to, że klient „przeklika” się ponad wykupioną pulę. Mechanizmy kontrolne bywają, ale są raczej pomocą niż gwarancją zgodności. W regulaminie znajdzie się z reguły klauzula, że klient odpowiada za wszelkie działania wykonane przy użyciu jego kont.

Mini-wniosek: jeśli klient ma możliwość samodzielnego „rozrastania” usługi (dodawanie użytkowników, rozszerzanie modułów), to jednocześnie bierze na siebie odpowiedzialność za to, by takie rozszerzenia miały pokrycie w umowie lub aneksach.

Samodzielne zarządzanie użytkownikami i planami – ukryte ryzyko „nadkliku”

Scenariusz jest częsty: szef sprzedaży naciska, by „już dziś” dodać kilku nowych handlowców do systemu SaaS. Administrator włącza kolejne konta, korzystając z opcji „dodaj użytkownika” w panelu, bo technicznie da się to zrobić jednym kliknięciem. Po pół roku rozliczenie z dostawcą pokazuje, że liczba aktywnych kont kilkukrotnie przekroczyła liczbę zadeklarowaną przy podpisaniu umowy.

W takim układzie odpowiedzialność za zgodność zwykle leży po stronie klienta. To on:

• przydziela i odbiera dostępy użytkownikom końcowym,
• decyduje, którzy partnerzy, podwykonawcy czy pracownicy tymczasowi otrzymują konto,
• konfiguruje integracje, które mogą tworzyć „techniczne” konta (np. do API),
• zarządza planami taryfowymi w panelu (upgrade, downgrade, dodatkowe moduły).

Dostawca natomiast liczy na to, że system zliczający aktywne konta i plan rozliczeniowy spią się po jego stronie. Nawet jeśli przez jakiś czas nie generuje faktur za nadmiarowe konta, przy audycie wewnętrznym może sięgnąć po logi aktywności i naliczyć opłaty wstecz, powołując się na regulamin.

Bez przejrzystej polityki po stronie klienta (kto może tworzyć konta, jak się je dezaktywuje, kto zatwierdza zmiany planu) SaaS staje się licencyjnym „samograjem”, w którym rachunek przychodzi dopiero po czasie. Im większa organizacja, tym dotkliwsze bywają takie niespodzianki.

Odpowiedzialność dostawcy za techniczną stronę zgodności

Inny obrazek: audytor producenta bazy danych zgłasza się do dostawcy SaaS z pytaniem o liczbę instancji uruchomionych w chmurze. Dostawca musi wysłać szczegółowy raport i udowodnić, że liczba jąder CPU oraz instancji mieści się w zakupionych licencjach. Klient końcowy nawet nie wie, że takie pismo krąży.

Z poziomu klienta wygląda to komfortowo – dostawca „załatwia” wszystkie licencje na warstwie infrastruktury. On negocjuje warunki z dostawcami chmury, baz danych, systemów operacyjnych czy komponentów middleware. To po jego stronie leży:

• dobranie właściwych licencji do architektury (np. klastry, HA, kontenery, serwery zapasowe),
• pilnowanie metryk technicznych powiązanych z licencją (CPU, rdzenie, RAM, instancje),
• monitorowanie zmian w modelach licencyjnych producentów trzecich,
• reagowanie na wyniki audytów prowadzonych wobec niego jako klienta tych producentów.

Jeżeli dostawca SaaS popełni błąd i będzie używał komponentów ponad zakres zakupionych licencji, to formalnie on ponosi konsekwencje wobec swoich dostawców. Klient może zostać „dotknięty” jedynie pośrednio – np. podwyżką cen lub zmianą modelu rozliczeń w kolejnym cyklu umowy.

Mini-wniosek: w SaaS klient przenosi na dostawcę ryzyko licencyjne na poziomie infrastruktury i komponentów technicznych, ale nie pozbywa się odpowiedzialności za to, jak korzysta z samej aplikacji i jakie rzeczy robią w niej jego użytkownicy.

Integracje, API i automaty – szara strefa odpowiedzialności

W jednej z firm produkcyjnych integrator stworzył skrypt, który co kilka minut wywoływał API systemu SaaS do raportowania wyników z maszyn. Przetestowano rozwiązanie na małym wolumenie, a potem uruchomiono na całą fabrykę. Po kwartałowym rozliczeniu okazało się, że przekroczono o rząd wielkości limit wywołań API przewidziany w planie – a faktura od dostawcy SaaS opiewała na kilka razy większą kwotę niż zwykle.

Takie sytuacje rodzą pytanie: kto odpowiada za zgodność z warunkami licencji, gdy do gry wchodzą integracje i automatyzacje?

• Dostawca SaaS definiuje limity (liczba wywołań API, przepustowość, zdarzenia) i publikuje warunki korzystania z API oraz cennik nadwyżek.
• Klient decyduje, jak intensywnie używa tych interfejsów, czy stosuje mechanizmy ograniczające (throttling), a także czy monitoruje wykorzystanie limitów.
• Integrator projektuje konkretne rozwiązanie techniczne (częstotliwość wywołań, batchowanie, cache’owanie), ale jego odpowiedzialność zależy od tego, co zapisano w umowie wdrożeniowej.

Jeżeli umowa wdrożeniowa jest ogólna („integrator przygotuje integrację z systemem X”), a nie odnosi się do limitów licencyjnych i potencjalnych kosztów nadwyżkowych, trudno będzie przerzucić odpowiedzialność na integratora. Klient, jako strona umowy SaaS, pozostaje tym, kto odpowiada przed dostawcą za przestrzeganie limitów.

Bezpieczniejszym podejściem jest wpisanie do umowy wdrożeniowej konkretnych założeń: maksymalnej akceptowalnej liczby wywołań, sposobu monitoringu, obowiązku integratora do zaprojektowania mechanizmów ochronnych i poinformowania o konsekwencjach licencyjnych. W praktyce mało który projekt taką klauzulę zawiera, co później wychodzi przy pierwszym „przestrzeleniu” limitów.

Subprocesorzy i podwykonawcy po stronie dostawcy SaaS

Często wychodzi na jaw przy audycie bezpieczeństwa: klient pyta dostawcę SaaS, z jakich podwykonawców korzysta, gdzie fizycznie przetwarzane są dane i jakie umowy licencyjne regulują używane tam komponenty. Dostawca pokazuje listę subprocesorów (np. dostawców chmury, systemów monitoringu, narzędzi analitycznych) i deklaruje, że posiada niezbędne prawa do ich używania.

Zasadniczo to dostawca SaaS:

• wybiera subprocesorów i zawiera z nimi umowy (hosting, backup, monitoring, mailing, analityka),
• odpowiada wobec klienta za ich działania w granicach określonych w umowie głównej i DPA (umowie powierzenia danych),
• musi zapewnić, że licencje udzielone mu przez subprocesorów pozwalają świadczyć usługę dla klientów końcowych.

Klient zwykle nie ma bezpośredniej relacji licencyjnej z tymi podmiotami. Jeżeli któryś z subprocesorów naruszy warunki licencyjne lub przepisy, pierwszym adresem roszczeń klienta jest dostawca SaaS. Ten z kolei może później regresowo dochodzić roszczeń od własnego podwykonawcy.

Wyjątkiem są sytuacje, gdy regulamin SaaS wymaga, aby klient sam zawarł osobną umowę z określonym dostawcą (np. narzędzie do podpisu elektronicznego, usługa SMS). Wówczas w łańcuchu licencyjnym pojawia się dodatkowe ogniwo, a obowiązki trzeba czytać w dwóch (lub więcej) zestawach dokumentów.

Odpowiedzialność klienta za dane i ich legalność

Do systemu SaaS można wgrać wiele rzeczy: dane osobowe, dokumenty, zdjęcia, nagrania, fragmenty kodu. Mało kto myśli przy tym o licencjach, koncentrując się wyłącznie na RODO i bezpieczeństwie. Tymczasem umowy SaaS niemal zawsze zawierają zapisy, że klient:

• odpowiada za to, że ma prawa do wszystkich wprowadzanych danych (np. prawa autorskie, zgody),
• nie umieszcza w systemie treści naruszających prawo (w tym prawa własności intelektualnej osób trzecich),
• zapewnia poprawność i aktualność danych (np. przy przetwarzaniu danych osobowych).

Jeśli więc dział marketingu wgra do narzędzia SaaS cudze zdjęcia stockowe bez właściwej licencji, a właściciel praw wystąpi z roszczeniami, dostawca SaaS zwykle zwróci się do klienta, powołując się na te klauzule. Z jego perspektywy jest tylko procesorem lub hostingodawcą – nie weryfikuje legalności każdego pliku.

Analogicznie z licencjami na oprogramowanie embedowane w danych: skrypty, macro, dodatki. Jeżeli klient umieszcza w systemie SaaS kawałki kodu naruszającego licencję open source (np. w repozytorium kodu w chmurze) i potem ten fakt wychodzi przy publicznym udostępnieniu, odpowiedzialność prawna za naruszenie spoczywa na kliencie jako podmiocie, który tym kodem zarządza.

Samoregulacja po stronie klienta: polityki korzystania z SaaS

W jednej grupie kapitałowej po dwóch głośnych sporach z dostawcami SaaS zarząd podjął decyzję: żadna jednostka nie może samodzielnie kupować subskrypcji w modelu „karta firmowa + akceptuj regulamin”. Wprowadzono centralną politykę zakupów SaaS z obowiązkowym udziałem działu prawnego i bezpieczeństwa.

Tego typu samoregulacja to praktyczny sposób na zmniejszenie ryzyka nieświadomych naruszeń licencyjnych. W politykach korzystania z SaaS, obok kwestii bezpieczeństwa, można wprost uregulować m.in.:

• kto zatwierdza wybór planu i modelu licencyjnego (np. per user, per tenant, per volume),
• kto odpowiada za bieżące monitorowanie liczby kont i wykorzystania limitów,
• jak często przegląda się aktywne subskrypcje (np. kwartalne „czyszczenie” martwych kont),
• kiedy dany zespół musi angażować dział prawny (np. przy przekazywaniu dostępu partnerom),
• jak dokumentuje się akceptację regulaminów (szczególnie gdy zmieniają się one jednostronnie po stronie dostawcy).

Mini-wniosek: nawet najlepiej napisana umowa SaaS nie „załatwi” zgodności, jeśli organizacja po stronie klienta nie ma gospodarza dla danej usługi i choćby minimalnego procesu liczenia użytkowników oraz kontroli limitów.

Umowy licencyjne i regulaminy: co dokładnie reguluje odpowiedzialność za zgodność

Dlaczego ten sam system „znaczy” co innego w on premise i w SaaS

Czasem ten sam produkt występuje w dwóch odsłonach: jako oprogramowanie instalowane lokalnie i jako usługa SaaS. Menedżerowie widzą tę samą nazwę handlową i zakładają, że zasady licencjonowania będą podobne. Tymczasem wystarczy porównać dokumenty, by zauważyć, że zmienia się nie tylko model finansowy, ale i układ obowiązków.

W on premise podstawowym dokumentem jest zwykle umowa licencyjna (lub EULA), która opisuje zakres pól eksploatacji i modele licencjonowania (per urządzenie, per użytkownik, per CPU itp.). W SaaS kluczowe są:

• master service agreement (MSA) lub umowa o świadczenie usług,
• regulamin/usługi (terms of service),
• załączniki opisujące plany taryfowe i modele rozliczeń,
• data processing agreement (DPA) – jeśli w grę wchodzą dane osobowe.

Choć nazwy paragrafów bywają podobne („Prawa i obowiązki stron”, „Odpowiedzialność”, „Ograniczenia korzystania”), ich treść odpowiada zupełnie innym realiom. W on premise koncentrujemy się na tym, co wolno zrobić z kopią oprogramowania. W SaaS – co wolno zrobić z usługą i kontem, a także w jakim zakresie klient może delegować dostęp dalej.

Kluczowe klauzule odpowiedzialności po stronie klienta

Przy przeglądzie umów SaaS powtarzają się pewne charakterystyczne fragmenty, które przesądzają o odpowiedzialności za zgodność. Po stronie klienta są to zwłaszcza klauzule dotyczące:

• dozwolonego korzystania – zakaz odsprzedaży, sublicencjonowania, udostępniania kont poza organizacją (chyba że umowa na to pozwala),
• kont użytkowników – obowiązek utrzymywania poufności haseł, zakaz współdzielenia kont, informowanie o nieuprawnionym dostępie,
• zakresu użytkowników uprawnionych – np. tylko pracownicy i współpracownicy na określonej podstawie prawnej,

Kluczowe klauzule odpowiedzialności po stronie dostawcy

Podczas jednego z przetargów dział IT był zachwycony funkcjami, a prawnik zaledwie uniósł brwi przy paragrafie „Odpowiedzialność”. Okazało się, że przy awarii miesiąca dostawca SaaS miałby zwrócić równowartość dwóch tygodni abonamentu – i nic więcej. To typowy moment, gdy wychodzi, jak wiele (lub jak mało) za bezpieczeństwo i zgodność bierze na siebie dostawca.

W dokumentach licencyjnych i regulaminach SaaS powtarzają się elementy, które kształtują zakres odpowiedzialności dostawcy:

• gwarancje dotyczące usługi – np. że system będzie zasadniczo działał zgodnie z dokumentacją, zastrzeżenia co do braku gwarancji błędów, które nie wpływają istotnie na funkcjonalność,
• SLA (service level agreement) – deklarowany poziom dostępności, czas reakcji na zgłoszenia, klasyfikacja incydentów, katalog wyłączeń (planowane prace, siła wyższa, awarie dostawców chmurowych),
• odszkodowania i kredyty serwisowe – zasady, kiedy i w jakiej wysokości klient może liczyć na rekompensatę za niedostępność lub naruszenie parametrów usługi,
• ograniczenie odpowiedzialności – maksymalna wysokość roszczeń (np. suma opłat z ostatnich 12 miesięcy), wyłączenia za utracone korzyści, dane, przerwy w działalności,
• zapewnienie posiadania praw – oświadczenia dostawcy, że ma licencje i prawa do komponentów, które udostępnia w ramach usługi oraz że ich używanie przez klienta nie narusza praw osób trzecich,
• indemnifikacja IP – zobowiązanie dostawcy do obrony klienta i pokrycia roszczeń, gdy osoba trzecia zarzuca naruszenie praw własności intelektualnej przez samą usługę (kod, interfejs, rozwiązania techniczne).

W modelu SaaS odpowiedzialność dostawcy jest więc mocno skoncentrowana wokół jakości i legalności samej usługi, a także wokół parametrów jej świadczenia. To on odpowiada za to, że „pudełko działa i nie jest kradzione”, ale niekoniecznie za to, co klient w tym pudełku trzyma i jak z niego korzysta.

Indemnifikacja: kiedy dostawca faktycznie „bierze kulę” na siebie

Spór o własność intelektualną najczęściej wybucha nie w momencie zakupu, tylko gdy system już działa, a konkurent lub organizacja zbiorowego zarządzania zgłasza zastrzeżenia. W jednej ze spraw producent oprogramowania zarzucił dostawcy SaaS, że jego mechanizm integracji kopiuje fragmenty chronionego rozwiązania. Klient był w środku, korzystał z usługi od lat i nie miał pojęcia o trwającym konflikcie.

Kwestie tego typu reguluje zwykle klauzula indemnifikacyjna (IP indemnity). Jej treść decyduje, czy klient może oczekiwać realnej ochrony, czy dostawca tylko symbolicznie „wyraża chęć współpracy”. Dobrze napisana klauzula obejmuje:

• zakres ochrony – dostawca broni klienta przed roszczeniami osób trzecich, że samo korzystanie z usługi SaaS (w zgodzie z dokumentacją) narusza patenty, prawa autorskie lub znaki towarowe,
• koszty obrony – jasno określone, że dostawca pokrywa koszty obsługi prawnej, ugód i zasądzonych odszkodowań w granicach odpowiedzialności,
• warunki skorzystania – np. wymóg niezwłocznego zawiadomienia dostawcy, przekazania mu kontroli nad postępowaniem i współpracy w obronie,
• środki zaradcze – prawo dostawcy do modyfikacji usługi, zastąpienia spornego komponentu innym lub zakończenia świadczenia z odpowiednią rekompensatą.

Granica tej ochrony zazwyczaj pada dokładnie tam, gdzie zaczyna się odpowiedzialność klienta: indemnifikacja nie obejmuje roszczeń wynikających z niezgodnego z umową używania systemu ani z treści i danych wprowadzonych przez klienta. Jeśli organizacja narusza cudze licencje, integrując SaaS z wewnętrznymi systemami w sposób niezatwierdzony lub łamiąc warunki sublicencji, dostawca co do zasady nie będzie stroną, która „płaci rachunek”.

W praktyce negocjacyjnej klauzula indemnifikacyjna jest jednym z niewielu miejsc, gdzie większy klient może realnie przesunąć ciężar ryzyka na dostawcę SaaS – w zamian za dłuższy kontrakt lub wyższą stawkę.

Zmiany regulaminów SaaS a odpowiedzialność za dalsze korzystanie

Scenariusz powtarza się regularnie: dział operacyjny dostaje e-mail „Zmieniamy regulamin z dniem…”, klika „akceptuj”, bo inaczej system przestanie działać, a prawnik dowiaduje się o zmianie po kilku miesiącach. W międzyczasie pojawiły się nowe ograniczenia licencyjne, które de facto zmieniają zakres odpowiedzialności klienta.

Mechanizm zmiany regulaminu jest jednym z kluczowych punktów z perspektywy zgodności. Typowo dostawca SaaS zastrzega sobie prawo do:

• jednostronnego modyfikowania warunków świadczenia usług i cennika,
• informowania o zmianach poprzez komunikat w systemie lub e-mail,
• uznania, że dalsze korzystanie z usługi po wejściu zmian w życie oznacza ich akceptację.

Po stronie klienta konsekwencje są bardzo praktyczne: może nagle okazać się, że dopuszczalne wcześniej scenariusze użycia (np. dostęp dla partnerów, określone formy integracji) zostały ograniczone albo objęte dodatkowymi opłatami. Jeśli organizacja nie ma procedury weryfikowania zmian regulaminów, łatwo wejść w obszar naruszenia licencji „z rozpędu”.

w umowach ramowych (MSA) coraz częściej pojawiają się mechanizmy hamujące zbyt daleko idące zmiany, np.:

• rozróżnienie zmian istotnych i nieistotnych,
• obowiązek wcześniejszego powiadomienia o zmianach wpływających na modele licencjonowania,
• prawo klienta do wypowiedzenia lub renegocjacji umowy przy zmianie kluczowych warunków,
• zamrożenie wybranych parametrów (np. sposobu licencjonowania) na czas obowiązywania konkretnego zamówienia.

W połączeniu z wewnętrzną polityką zakupów SaaS daje to minimalny „bezpiecznik”: jeżeli nowy regulamin zwiększa odpowiedzialność klienta za zgodność, przynajmniej ktoś ma szansę to wychwycić, zanim dostawca rozpocznie audyt licencyjny w oparciu o nowe zasady.

Kontrole licencyjne i audyty: jak są opisane w umowach

Podczas jednego z audytów licencyjnych przedstawiciel dostawcy zaskoczył klienta szczegółowością żądań: logi systemowe, listy kont, historię integracji. Zespół compliance był przekonany, że audyt ograniczy się do oświadczeń i eksportu z panelu admina. Okazało się, że w regulaminie SaaS znajdował się szeroki paragraf „Audit rights”, którego nikt wcześniej nie przeanalizował.

Uprawnienia audytowe to miejsce, w którym bardzo wyraźnie widać, jak rozkłada się odpowiedzialność za licencje między stronami. W umowach pojawiają się najczęściej następujące elementy:

• prawo dostawcy do przeprowadzenia audytu – samodzielnie lub przez wyznaczonego audytora, w określonych odstępach czasu albo „z uzasadnioną przyczyną”,
• zakres audytu – dostęp do raportów z systemu, logów użycia, dokumentów potwierdzających liczbę użytkowników, czasem do środowisk integracyjnych,
• miejsce i forma – na miejscu u klienta, zdalnie, z użyciem narzędzi monitorujących, na podstawie samodzielnie sporządzonych raportów,
• obowiązki klienta – współpraca, udostępnienie informacji w rozsądnym zakresie, utrzymywanie odpowiednich logów, przechowywanie danych o użytkownikach,
• skutki niezgodności – dopłata opłat licencyjnych z wyrównaniem wstecz, odsetki, możliwość naliczenia opłat karnych, a w skrajnych przypadkach prawo do wypowiedzenia umowy przez dostawcę.

W SaaS często stosuje się „miękki” audyt – polegający na analizie danych już dostępnych po stronie dostawcy (logowania, API, liczba aktywnych kont). W on premise audyt licencyjny wymaga zazwyczaj aktywnego udziału klienta: instalacji narzędzi skanujących, udostępnienia stacji roboczych czy serwerowni. Z tego względu klienci częściej negocjują ograniczenia audytu on premise (częstotliwość, zakres, obowiązek zachowania poufności), a audyty SaaS bywają przyjmowane „z rozpędu”.

Mini-wniosek z praktyki: jeżeli umowa przewiduje prawo dostawcy do audytu, po stronie klienta musi ktoś realnie odpowiadać za utrzymanie danych, które będą potrzebne do obrony swojej wersji zdarzeń (np. kto i kiedy miał dostęp, na jakiej podstawie). Bez tego każda rozbieżność w raportach dostawcy będzie trudna do podważenia.

Granice odpowiedzialności w łańcuchu: resellerzy, partnerzy, grupy kapitałowe

Gdy SaaS trafia do organizacji przez pośrednika, układ odpowiedzialności komplikuje się o kolejny poziom. Przykładowy scenariusz: spółka z grupy kapitałowej kupuje subskrypcję przez lokalnego resellera, a korzystać mają trzy inne spółki w różnych krajach. Każda ma inne procesy, inną kulturę compliance, a dostawca widzi w systemie jednego „klienta kontraktowego”.

W takich układach licencyjnych zwykle pojawiają się następujące konfiguracje:

• umowa główna z dostawcą, wykonanie przez resellera – odpowiedzialność licencyjna i za zgodność spoczywa głównie na kliencie i dostawcy, reseller odpowiada za wdrożenie/obsługę, chyba że umowa stanowi inaczej,
• umowa tylko z resellerem – klient akceptuje regulamin dostawcy „pośrednio” (np. jako załącznik), ale formalnie odpowiada wobec resellera; ten z kolei ponosi odpowiedzialność wobec dostawcy,
• multi-tenant w grupie – jedna spółka jest formalnym klientem (licencjobiorcą / właścicielem konta master), a inne spółki korzystają jako „affiliates” na mocy odpowiednich klauzul.

Z perspektywy odpowiedzialności za licencje krytyczne jest, czy umowa wprost dopuszcza korzystanie przez podmioty powiązane, oraz kto ma obowiązek monitorować użytkowników w całej grupie. Brak jasnego uregulowania prowadzi do sytuacji, w której:

• dostawca kieruje roszczenia do „klienta głównego”,
• ten próbuje podzielić koszty i odpowiedzialność między spółki z grupy na podstawie wewnętrznych porozumień (lub maili sprzed lat),
• reseller twierdzi, że tylko „sprzedał licencje” i nie odpowiada za ich dalsze wykorzystanie.

Przed wdrożeniem SaaS „dla całej grupy” dobrze działa prosta praktyka: jasny dokument wewnętrzny określający, która spółka jest właścicielem relacji z dostawcą, jak rozdzielone są koszty i kto po stronie grupy odpowiada za łączną liczbę użytkowników i przestrzeganie ograniczeń. W przeciwnym razie przy pierwszym większym audycie trudno będzie ustalić, gdzie kończy się odpowiedzialność prawnika w spółce-matce, a zaczyna odpowiedzialność dyrektora oddziału, który „tylko dołożył kilka kont”.

Konsekwencje naruszenia licencji w SaaS i on premise – różne ścieżki, inne ryzyka

W sporze z producentem on premise jedna z firm produkcyjnych stanęła przed wizją unieruchomienia kluczowego systemu MES. Licencje były naruszone, ale odcięcie oprogramowania uderzałoby w bezpieczeństwo procesów. Ostatecznie skończyło się na dopłacie i planie wymiany licencji. W SaaS taki „komfort” manewru jest dużo mniejszy – dostawca może w praktyce jednym ruchem ograniczyć dostęp do systemu.

Konsekwencje naruszenia licencji w obu modelach układają się trochę inaczej:

• on premise – producent zwykle sięga po:
  • roszczenia o zapłatę za niedolicencjonowane instalacje (często z dopłatą za okres wsteczny),
  • kary umowne, jeśli zostały przewidziane,
  • żądanie zaprzestania naruszeń (np. deinstalacji nadmiarowych kopii),
  • w skrajnych przypadkach – działania prawne związane z naruszeniem praw autorskich.
• SaaS – dostawca ma dodatkowo w ręku dźwignię operacyjną:
  • może zawiesić lub ograniczyć usługę klientowi naruszającemu licencję (często po uprzednim wezwaniu),
  • łatwiej egzekwuje dopłaty, bo klient jest mocno uzależniony od bieżącego działania systemu,
  • może blokować możliwość zwiększania zakresu usługi do czasu uregulowania zaległości,
  • w skrajnym razie – rozwiązać umowę z winy klienta, powołując się na istotne naruszenie.

W efekcie zarządzanie zgodnością licencyjną w SaaS jest bardziej „czasoczułe”: spóźnione reakcje na ostrzeżenia czy nieprawidłowości szybciej przekładają się na ryzyko operacyjne. Z kolei w on premise większe ryzyko dotyczy kumulacji naruszeń niezauważanych latami, co przy audycie skutkuje wysokim jednorazowym rachunkiem.

Najczęściej zadawane pytania (FAQ)

Kto odpowiada za legalność licencji w modelu on premise – producent czy firma korzystająca?

Typowy scenariusz: integrator wdraża system, wszystko działa, przez lata dokładacie użytkowników, aż pewnego dnia przychodzi pismo o audycie. Wszyscy rozglądają się po pokoju, szukając „winnego”, a producent wyciąga licencję, w której od początku było napisane, że to klient pilnuje zgodności.

W klasycznym on premise odpowiedzialność za legalność instalacji spoczywa przede wszystkim na kliencie. Producent udziela licencji i ma prawo skontrolować jej przestrzeganie, ale nie zarządza tym, ile kopii systemu instalujecie, ilu użytkowników faktycznie korzysta ani jakie środowiska stworzyliście. To firma korzystająca z oprogramowania musi mieć ewidencję licencji, kontrolować liczbę użytkowników i instalacji (także testowych i deweloperskich) oraz reagować, gdy realne użycie zbliża się do limitów z umowy.

Czy za zgodność licencji w SaaS odpowiada dostawca usługi, czy klient końcowy?

W SaaS często pojawia się myślenie: „przecież to usługa, więc wszystko jest po stronie dostawcy”. Dopóki nie wyjdzie, że handlowcy dzielą jedno konto na pięć osób, a partnerzy zewnętrzni logują się na prywatne loginy pracowników – wbrew regulaminowi platformy.

Dostawca SaaS odpowiada za legalność własnych licencji wobec producentów oprogramowania, z którego korzysta w tle (system operacyjny, baza danych itp.). Natomiast klient końcowy ponosi odpowiedzialność za to, jak używa samej usługi: ilu użytkowników posiada, czy nie udostępnia kont osobom trzecim, czy nie obchodzi ograniczeń pakietu (np. limitu użytkowników, transakcji, API). Złamanie regulaminu dostawcy (np. współdzielenie kont, nieuprawnione udostępnianie dostępu) to zazwyczaj ryzyko i konsekwencje po stronie klienta – od dopłat po wypowiedzenie usługi.

Czy w SaaS muszę przejmować się licencjami systemu operacyjnego, bazy danych itp.?

W przypadku lokalnego ERP dział IT kupuje serwer, system operacyjny, bazę danych i każdą z tych warstw musi licencjonować osobno. W SaaS wielu menedżerów odetchnęło z ulgą, bo „chmura wszystko załatwia” – co jest prawdą tylko częściowo.

W modelu SaaS klient co do zasady nie kupuje licencji na poszczególne komponenty techniczne. To dostawca usługi musi legalnie licencjonować system operacyjny, bazę danych, middleware czy inne elementy, a ich koszt jest zaszyty w abonamencie. Klient odpowiada jednak za to, by nie próbować „rozszerzać” usługi poza to, co wynika z umowy, np. przez nieautoryzowane integracje lub modyfikacje, które naruszają prawa autorskie lub regulamin platformy.

Kto odpowiada za nielegalne kopie testowe i środowiska deweloperskie on premise?

Najczęściej problem pojawia się przy rozwoju systemu: integrator robi dodatkową instancję „na szybko”, programiści klonują maszynę produkcyjną jako testową, a po roku nikt już nie pamięta, ile jest kopii i gdzie. Do czasu audytu producenta.

W modelu on premise to klient odpowiada za każdą kopię programu – także testową, deweloperską, szkoleniową czy zapasową. Część licencji dopuszcza takie środowiska w określonym zakresie, inne wymagają osobnych uprawnień. Integrator może doradzić i technicznie stworzyć instancję, ale odpowiedzialność za to, że każda z nich ma podstawę licencyjną, spoczywa na firmie, która korzysta z oprogramowania i ma je u siebie zainstalowane. Mini-wniosek: katalog środowisk (prod/test/dev/DR) powinien być elementem waszej ewidencji licencji, a nie „pamięcią działu IT”.

Czy integrator lub reseller odpowiada za błędy w liczbie licencji, które mi doradził?

Częsta sytuacja: partner wdrożeniowy uspokaja, że „macie zapas licencji, proszę się nie martwić”, a kilka lat później audyt pokazuje wyraźny niedobór. Zarząd zaczyna się zastanawiać, czy może przerzucić odpowiedzialność na integratora.

Z prawnego punktu widzenia integrator czy reseller odpowiada głównie za to, co sam zobowiązał się zrobić w umowie: doradztwo, konfigurację, wdrożenie, czasem utrzymanie. Jeśli błędnie oszacował liczbę licencji, możliwe są roszczenia kontraktowe, ale producent zwykle i tak żąda wyrównania braków od klienta, bo to z nim zawarł umowę licencyjną. Dlatego kluczowe jest:

• precyzyjne opisanie w umowie z integratorem zakresu jego odpowiedzialności za dobór modelu licencjonowania i liczbę licencji,
• posiadanie własnej, niezależnej ewidencji licencji i użytkowników, zamiast polegania wyłącznie na „ustnych zapewnieniach partnera”.

Czy mogę udostępniać dostęp do systemu (on premise lub SaaS) partnerom i podwykonawcom?

Wiele firm ma podobny scenariusz: partner handlowy dostaje login do CRM, podwykonawca loguje się do systemu produkcyjnego, a agencja HR korzysta z waszego systemu kadrowego. Wszystko „na szybko”, bo biznes goni, a o licencjach nikt nie myśli.

Możliwość udostępniania systemu podmiotom trzecim jest zawsze opisana w umowie licencyjnej lub regulaminie usługi. W on premise licencje często ograniczają użycie do „własnych potrzeb biznesowych” klienta i jego pracowników – partnerzy czy kontraktorzy mogą wymagać osobnych licencji albo specjalnego typu uprawnienia (np. „external users”). W SaaS zazwyczaj zabronione jest współdzielenie kont między różne osoby lub podmioty, a dostęp dla partnerów bywa dopuszczony tylko w określonych planach lub za dodatkową opłatą. Bez sprawdzenia konkretnych zapisów w umowie każdy taki dostęp jest ryzykiem naruszenia licencji.

Co warto zapamiętać

• Za licencje i zgodność w obu modelach – SaaS i on premise – ostatecznie odpowiada klient, nawet jeśli „wszyscy myśleli, że integrator lub dostawca ma to pod kontrolą”.
• Model dostarczania (SaaS vs on premise) nie przesądza o zasadach licencjonowania; to umowa definiuje, ilu użytkowników, ile instancji i jakie środowiska (test, dev, backup) są legalnie objęte licencją.
• W on premise klient zarządza kopiami programu u siebie (instalacje, klonowanie maszyn, dostęp użytkowników), więc musi samodzielnie pilnować limitów licencji i dokumentacji – producent widzi to dopiero przy audycie.
• W SaaS klient nie dostaje kopii programu, tylko dostęp do usługi w abonamencie; licencje na oprogramowanie „pod spodem” są po stronie dostawcy, ale zgodność sposobu korzystania (np. komu udostępniamy loginy) nadal spoczywa na kliencie.
• Przekazywanie kont i haseł w usługach SaaS (np. loginy do CRM dla partnerów) jest typowym naruszeniem regulaminu – dostawcy traktują to tak samo poważnie, jak producenci on premise traktują nadmiar instalacji.
• Brak aktualnej ewidencji licencji i jasnego podziału odpowiedzialności między IT, biznesem, integratorem i dostawcą prowadzi wprost do dopłat po audycie, kar umownych i napięć z zarządem.
• „Stare” licencje on premise nie są uniwersalnym zabezpieczeniem – zmiana wersji, środowiska lub sposobu wirtualizacji potrafi całkowicie zmienić warunki licencyjne i wygenerować nieoczekiwane ryzyka.