Ograniczenie odpowiedzialności dewelopera oprogramowania: jakie ryzyka można uregulować w EULA

Użytkownik utracił dane po aktualizacji aplikacji, nie mógł dokończyć płatności z powodu awarii albo wykorzystał wynik działania programu przy podejmowaniu decyzji finansowej. Nawet jeżeli EULA zawiera całkowite wyłączenie gwarancji i odpowiedzialności, nie oznacza to, że deweloper jest chroniony przed roszczeniami.

Umowa licencyjna pozwala rozdzielić część ryzyk pomiędzy strony, opisać przeznaczenie produktu i ustalić limit odszkodowania. Skuteczność takich postanowień zależy jednak od ich brzmienia, modelu dystrybucji i prawa właściwego. Postanowienie, zgodnie z którym deweloper nie ponosi żadnej odpowiedzialności, może zostać uznane za nieuczciwe lub nieważne, szczególnie w umowie z konsumentem. Skuteczna EULA wyznacza przewidywalne granice odpowiedzialności i wiąże je z tym, w jaki sposób program jest faktycznie używany.

Ograniczenie odpowiedzialności nie znosi obowiązków dewelopera

Deweloper odpowiada za własne zobowiązania umowne, bezwzględnie obowiązujące wymogi prawa oraz szkody, za które odpowiedzialności nie można wyłączyć w drodze umowy. EULA może wpływać na wysokość i rodzaje odpowiedzialności umownej, ale nie zwalnia firmy ze wszystkich konsekwencji wad programu.

W relacjach z konsumentami swoboda umów jest bardziej ograniczona. Użytkownik może zachować prawo do usunięcia wady, obniżenia ceny, rozwiązania umowy lub zwrotu środków niezależnie od treści licencji. Nieuczciwe postanowienia nie stają się wiążące wyłącznie dlatego, że użytkownik kliknął przycisk akceptacji.

W przypadku produktu B2B strony zazwyczaj mają większą swobodę w podziale ryzyk. Klient korporacyjny często proponuje jednak własną umowę, w której gwarancje, indemnity i limit odpowiedzialności istotnie różnią się od publicznej EULA. W takiej sytuacji należy wyraźnie określić pierwszeństwo poszczególnych dokumentów.

Jakie ryzyka można rozdzielić w EULA

Jeden rozdział dotyczący odpowiedzialności nie rozwiązuje wszystkich kwestii. Każde ryzyko wymaga odpowiedniego mechanizmu umownego.

Taki podział pozwala powiązać konkretne ryzyko z odpowiednim postanowieniem. Ogólne stwierdzenie, że użytkownik korzysta z programu na własne ryzyko, nie wyjaśnia, co wydarzy się w przypadku awarii subskrypcji, utraty danych lub zakończenia wsparcia.

Jak ustalić limit odpowiedzialności

Liability cap określa maksymalną kwotę, której użytkownik może dochodzić na podstawie umowy. Limit można wyrazić jako stałą kwotę, wysokość płatności dokonanych w określonym okresie albo wartość licencji.

W przypadku bezpłatnej aplikacji ograniczenie odpowiedzialności do wysokości dokonanych płatności faktycznie prowadzi do zerowego limitu. W umowie z konsumentem taki rezultat może zostać uznany za całkowite wyłączenie odpowiedzialności i nie znaleźć zastosowania. Rozsądniejszym rozwiązaniem może być ustalenie odrębnej stałej kwoty albo określenie kategorii roszczeń, do których limit ma zastosowanie.

Przy płatnej subskrypcji często wykorzystuje się wysokość płatności użytkownika z ostatnich 6 lub 12 miesięcy. W przypadku jednorazowej licencji punktem odniesienia może być cena zakupionej wersji. Wybór powinien uwzględniać cenę produktu i prawdopodobną wysokość szkody. Limit w wysokości 10 euro dla programu obsługującego operacje finansowe trudno uznać za proporcjonalny.

Określić podstawę obliczenia

Sformułowanie „płatności na podstawie umowy” powinno wyjaśniać, czy obejmuje subskrypcję, zakupy w aplikacji, podatki, zwroty oraz prowizje platformy. Jeżeli płatność jest dokonywana za pośrednictwem sklepu z aplikacjami, deweloper i użytkownik mogą inaczej rozumieć kwotę uznawaną za otrzymaną.

W przypadku licencji rodzinnej lub korporacyjnej należy określić, czy limit jest obliczany dla jednego konta, konkretnego użytkownika czy całej organizacji.

Wybrać okres

W przypadku subskrypcji limit można powiązać z płatnościami dokonanymi w określonym okresie poprzedzającym zdarzenie będące podstawą roszczenia. Jeżeli umowa obowiązuje przez kilka lat, ograniczenie odpowiedzialności do łącznej wysokości wszystkich płatności może prowadzić do odpowiedzialności niewspółmiernej do aktualnej wartości usługi. Dla nowego użytkownika, który nie dokonał jeszcze pełnej płatności, warto przewidzieć minimalny limit. W przeciwnym razie obliczenie może ponownie prowadzić do faktycznego zwolnienia z odpowiedzialności.

Rozdzielić pojedyncze zdarzenie i łączne roszczenia

Umowa powinna wskazywać, czy limit ma zastosowanie osobno do każdego roszczenia, czy łącznie do wszystkich roszczeń w określonym okresie.

Kilka awarii może wynikać z jednej przyczyny technicznej, a jeden błąd może prowadzić do roszczeń opartych jednocześnie na kilku podstawach.

Jeżeli stosowany jest łączny limit, należy określić okres jego obowiązywania oraz zasady łączenia powiązanych zdarzeń. Bez tego strony będą spierać się o wysokość odpowiedzialności dopiero po wystąpieniu incydentu.

Ustalić wyjątki od limitu

Niektóre roszczenia mogą podlegać odrębnemu limitowi albo w ogóle nie być nim objęte. W praktyce osobno rozpatruje się umyślne naruszenia, rażące niedbalstwo, szkody na życiu i zdrowiu, naruszenia poufności oraz roszczenia dotyczące własności intelektualnej.

Zakres wyjątków zależy od prawa właściwego i modelu produktu. EULA nie powinna mechanicznie powielać umowy B2B, w której strony uzgodniły rozszerzone indemnity i odrębny podwyższony limit.

Uzgodnić limit z innymi środkami ochrony

Liability cap należy analizować łącznie ze zwrotami środków, service credits, gwarancjami i prawem do rozwiązania umowy. Jeżeli użytkownik otrzymał już zwrot, EULA powinna wyjaśniać, czy kwota ta jest uwzględniana przy obliczaniu dalszego odszkodowania. Deweloper powinien również określić, czy dany środek ochrony ma charakter wyłączny. Takie zastrzeżenie obowiązuje wyłącznie w zakresie dozwolonym przez prawo.

Czy można wyłączyć szkody pośrednie i utracone korzyści

EULA często wyłącza indirect, incidental, special i consequential damages, a także loss of profits, revenue, data i business opportunities. Przeniesienie tej anglojęzycznej formuły do umowy podlegającej innemu prawu właściwemu nie gwarantuje oczekiwanego rezultatu.

Poszczególne systemy prawne w różny sposób definiują szkody bezpośrednie i pośrednie. Utrata zysku w jednej sytuacji może zostać uznana za odległą konsekwencję, a w innej za bezpośredni skutek naruszenia. Dlatego samo wyliczenie terminów nie jest wystarczające.

W umowie warto wskazać konkretne kategorie strat i powiązać je z przewidywalnymi scenariuszami. Deweloper może na przykład wyłączyć odpowiedzialność za decyzję użytkownika podjętą na podstawie automatycznie wygenerowanego raportu, jeżeli produkt nie jest wyraźnie przeznaczony do świadczenia profesjonalnego doradztwa finansowego, medycznego lub prawnego.

Takie ograniczenie musi być zgodne z przekazem marketingowym. Jeżeli strona internetowa obiecuje precyzyjne rekomendacje inwestycyjne, EULA nie będzie mogła wiarygodnie przedstawiać tego samego produktu jako narzędzia informacyjnego, na którego wynikach nie należy polegać.

Jak rozdzielić odpowiedzialność za utratę danych

Stwierdzenie, że deweloper nie odpowiada za dane użytkownika, jest zbyt szerokie, jeżeli sam program przechowuje, synchronizuje lub tworzy kopie zapasowe informacji. W EULA można określić, które dane są przechowywane lokalnie, które są przesyłane do chmury oraz jak długo dostępne są kopie zapasowe. Użytkownika można zobowiązać do samodzielnego eksportowania krytycznych materiałów, jeżeli taka funkcja rzeczywiście istnieje i jest łatwa do znalezienia.

Deweloper może ograniczyć odpowiedzialność za utratę danych spowodowaną działaniami użytkownika, awarią jego urządzenia lub działaniem zewnętrznej usługi. Takie zastrzeżenie nie eliminuje jednak odpowiedzialności za własny błąd synchronizacji, deklarowane tworzenie kopii zapasowych lub niewystarczające zabezpieczenie infrastruktury. Obowiązków wynikających z GDPR i innych przepisów dotyczących danych osobowych nie można wyłączyć w drodze umowy z użytkownikiem. EULA reguluje roszczenia umowne, natomiast organ nadzorczy stosuje środki publicznoprawne niezależnie od ustalonego liability cap.

Awarie zewnętrznych usług i integracji

Aplikacja może być zależna od systemu płatności, map, przechowywania danych w chmurze, systemu operacyjnego lub zewnętrznego API. Deweloper nie kontroluje działania tych usług, dlatego EULA może informować o ich niezależności oraz możliwych zmianach.

Całkowite wyłączenie odpowiedzialności nie zawsze jest jednak właściwe. Jeżeli deweloper wybrał dostawcę, zintegrował jego usługę z produktem i sprzedaje powiązaną funkcję jako część aplikacji, użytkownik oczekuje prawidłowego działania całego rozwiązania. Należy rozróżnić awarię samej usługi zewnętrznej od błędu integracji, za który odpowiada deweloper.

Umowa powinna również uwzględniać zakończenie wsparcia zewnętrznego API. Deweloper może potrzebować prawa do zmiany lub usunięcia zależnej funkcji, jednak w przypadku płatnego produktu taka zmiana powinna być oceniana łącznie z bezwzględnie obowiązującymi prawami użytkownika i pierwotnym opisem produktu.

Co można uregulować za pomocą ostrzeżenia dotyczącego korzystania z produktu

Ostrzeżenia są szczególnie istotne w przypadku produktów, których wyniki mogą wpływać na zdrowie, finanse, bezpieczeństwo lub decyzje zawodowe. EULA powinna opisywać przeznaczenie programu, rozsądne ograniczenia jego dokładności oraz sytuacje, w których wymagana jest weryfikacja przez człowieka.

Sformułowanie „wyłącznie w celach informacyjnych” jest użyteczne, jeżeli odpowiada rzeczywistemu charakterowi produktu. Nie pomoże ono aplikacji medycznej, która faktycznie diagnozuje choroby, ani usłudze finansowej oferującej spersonalizowane decyzje inwestycyjne. Użytkownikowi można zakazać wykorzystywania zwykłego programu w systemach krytycznych, do sterowania transportem lub w innym środowisku, dla którego produkt nie był testowany. Takie ograniczenie powinno być wyraźnie widoczne i zgodne z opisem aplikacji.

Które postanowienia mogą okazać się nieskuteczne

Całkowite wyłączenie odpowiedzialności budzi największe wątpliwości w umowie z konsumentem. Postanowienie powinno być zrozumiałe, dostępne przed zawarciem umowy i nie może powodować istotnej nierównowagi ze szkodą dla użytkownika.

Wybór prawa innego państwa również nie zawsze pozbawia europejskiego konsumenta ochrony. Jeżeli firma kieruje swoją działalność do kraju jego miejsca zamieszkania, rozporządzenie Rzym I zachowuje zastosowanie bezwzględnie obowiązujących przepisów, które miałyby zastosowanie w przypadku braku wyboru prawa obcego.

Szczególne znaczenie ma również zaktualizowany system odpowiedzialności za wadliwe produkty w UE. Dyrektywa 2024/2853 wprost obejmuje oprogramowanie pojęciem produktu, niezależnie od sposobu jego dostarczenia lub wykorzystania. Takiej odpowiedzialności wobec osoby poszkodowanej nie można wyłączyć zwykłym postanowieniem umownym.

Ograniczenia nie chronią również dewelopera przed roszczeniami związanymi z brakiem praw do kodu, wprowadzającym w błąd opisem produktu, działaniem umyślnym lub obowiązkami wobec organu nadzorczego. Dokładny zakres wyjątków zależy od jurysdykcji, dlatego w przypadku aplikacji międzynarodowej jedna niezmienna formuła rzadko będzie odpowiednia dla wszystkich rynków.

Jak powiązać EULA z architekturą produktu

Rozdział dotyczący odpowiedzialności należy przygotować po przeanalizowaniu funkcji, danych i zależności produktu. Prawnik powinien wiedzieć, czy aplikacja przechowuje pliki użytkowników, korzysta z zewnętrznych API, generuje rekomendacje oraz czy użytkownik może wyeksportować swoje informacje.

Kolejny poziom weryfikacji dotyczy składanych obietnic. Opis w sklepie, ekran subskrypcji, centrum pomocy i materiały reklamowe powinny być zgodne z EULA. Gwarancja stałego dostępu w reklamie i wyłączenie jakiejkolwiek dostępności w umowie tworzą bezpośrednią sprzeczność.

W przypadku produktu chmurowego należy również sprawdzić Terms of Use, Privacy Policy, DPA i SLA. Jeżeli dokumenty przewidują różne okresy przechowywania, poziomy dostępności i zasady rekompensaty, liability cap nie wyeliminuje sporu.