Standardowa umowa IT prawie nigdy nie reguluje wprost kwestii open source. Konsekwencja jest prosta: gdy klient lub inwestor wykryje w produkcie problematyczną licencję, nie wiadomo kto za to odpowiada, kto pokrywa szkodę i czy w ogóle masz jak udowodnić należytą staranność. Warto zatem dodać do umowy klauzule kontraktowe, które adresują ten problem – w ich trafnym sformułowaniu pomoże wyspecjalizowany prawnik nowe technologie i prawnik do spraw praw autorskich.
- Bez klauzul open source w umowie nie wiadomo, kto odpowiada za naruszenie licencji, czy jes to: software house, kontraktor czy klient.
- Dostawca powinien zagwarantować w umowie to z jakich komponentów korzysta w projekcie, wskazać kryteria ich doboru oraz prowadzenia rejestru komponentów i narzędzi wykorzystanych w projekcie.
- Klauzule odszkodowawcze – w polskim prawie mogą być rozdzielone na gwarancję dostawcy, kwotowe ograniczenie odpowiedzialności, karę umowną oraz sposób naprawienia szkody.
- Prawo do audytu dostawcy: pozwala zweryfikować, czy oświadczenia złożone w umowie są przestrzegane przez dostawcę, czy w produkcie IT nie znalazły się zakazane licencje.
- Typowy limit odpowiedzialności w umowach IT to 80–100% wynagrodzenia umownego netto. Wyższy próg (tzw. supercap, np. 200%) negocjowany jest dla projektów wysokiego ryzyka lub newralgicznych obszarów jak wyciek danych.
- Naruszenie licencji open source skutkuje roszczeniami z art. 79 ust. 1 ustawy o prawie autorskim i prawach pokrewnych, w tym żądaniem zaniechania naruszania, naprawienia szkody i wydania bezprawnie uzyskanych korzyści.
Przykładowy scenariusz
Wyobraź sobie taką sytuację: potencjalny klient zamierza kupić udziały w firmie technologicznej. Przed transakcją chce się upewnić – zlecając na przykład audyt prawny umów IT – że główna wartość firmy, jaką jest produkt IT, stanowi jej własność. Produkt był rozwijany nie tylko przez spółkę, ale korzystała ona także ze wsparcia innej firmy technologicznej. Kupujący zażądał rejestru wszystkich komponentów i narzędzi wykorzystanych w projekcie. Pierwsza myśl: „Skąd teraz wyciągnąć listę pięćdziesięciu bibliotek z kilku lat developmentu?”. Druga myśl: „A jeśli kupujący znajdzie tam coś, czego nie powinien? Technologicznie wszystko działa tak jak powinno, ale formalnościami za bardzo nikt się nie przejmował, były ważniejsze sprawy”.
Dlaczego standardowa umowa IT nie wystarcza dla open source
Standardowa umowa IT w ogromnej większości przypadków w ogóle nie wspomina o open source. Reguluje zakres prac, terminy, wynagrodzenie, prawa autorskie do dostarczonego utworu, gwarancje i kary umowne. Open source pojawia się co najwyżej jako jedno zdanie w ogólnej klauzuli o prawach własności intelektualnej.
Problem pojawia się dopiero w momencie, gdy klient lub potencjalny nabywca zorientuje się, że produkt zawiera bibliotekę na licencji np. AGPL. Kto za to odpowiada? Software house, bo dostarczył produkt? Twój developer-kontraktor, bo wniósł kod? A może sam klient, bo zmodyfikował produkt wewnętrznie? Bez wyraźnych reguł w umowie rodzi się ryzyko sporu, w tym przed sądem, który jest kosztowny i niepewny.
Trzy klauzule, które zostały omówione poniżej mają jeden wspólny cel: określić z góry, kto za co odpowiada w łańcuchu dostaw oprogramowania. Lepiej ustalić to w umowie niż w sądzie, który prawdę mówiąc nie zna się za bardzo na takiej niszowej problematyce jak licencje Open Source.
Trzy umowy w software house, w których OSS musi być uregulowany
Twój software house jest stroną co najmniej trzech rodzajów umów, w których kwestia open source powinna być wprost rozstrzygnięta:
- Umowy B2B z developerami-kontraktorami (współpracownicy, podwykonawcy, freelancerzy). W trakcie wykonywanych prac rozwijają kod produktu IT. Dlatego należy wymagać od nich, aby to, co dostarczają, nie zawierało komponentów na restrykcyjnych licencjach OSS takich jak: AGPL lub GPL. Ważne jest również to, aby na bieżąco aktualizowali rejestr narzędzi i bibliotek, z których korzystają w projekcie, w tym podawali wszystkie informacje identyfikujące dany komponent, który został użyty.
- Umowy B2B z klientami. W tej sytuacji to firma technologiczna jest dostawcą i odpowiada za to, co znalazło się w produkcie oraz czy klient może z tego korzystać w sposób umówiony. Na pewno trzeba pamiętać, aby zabezpieczyć się przed konsekwencjami modyfikacji wprowadzonych samodzielnie przez klienta. Ponadto, ważne jest również to, aby ustalić z klientem wymagania związane z produktem IT. To będzie determinować możliwość wykorzystania konkretnych licencji w dostarczanych rezultatach usług.
- Regulamin SaaS lub umowa licencyjna z użytkownikiem końcowym (konsumenci lub mali przedsiębiorcy korzystający z Twojej platformy). Tutaj zazwyczaj wystarczy klauzula informująca o użytych komponentach OSS i wyłączenie odpowiedzialności za niezgodne z umową lub prawem korzystanie z produktu przez klienta.
Poniżej trzy klauzule umowne, nad którymi warto się zastanowić.
Klauzula 1 – oświadczenie dostawcy i obowiązek dostarczenia rejestru narzędzi
Przykładowe brzmienie:
„Dostawca oświadcza, że dostarczone Oprogramowanie:
(1) nie zawiera komponentów objętych licencjami typu silne copyleft – w szczególności GPL v2, GPL v3, AGPL v3 – w sposób mogący skutkować rozszerzeniem obowiązków licencyjnych na pozostałe części Oprogramowania ani na inne oprogramowanie Odbiorcy;
(2) jest wolne od roszczeń osób trzecich z tytułu praw autorskich, w tym wynikających z naruszenia warunków licencji open source.
W terminie 14 dni Dostawca przekaże Zamawiającemu zestawienie komponentów i narzędzi wykorzystanych do tworzenia Oprogramowania, zawierające dla każdego komponentu: nazwę, wersję, identyfikator licencji oraz źródło pobrania (URL repozytorium lub menedżera pakietów). Dostawca zobowiązuje się aktualizować rejestr przy każdej zmianie składu komponentów Oprogramowania.”
Na co zwracać uwagę w tej klauzuli:
- Lista zakazanych licencji – warto wpisać konkretne nazwy licencji OSS, ale również określić, jakiego efektu przez to chcemy uniknąć, czyli skutku „silnego copyleft”.
- Format rejestru – warto szczegółowo określić to, z czego taki rejestr ma się składać. To w przyszłości pozwoli na pełne udokumentowanie komponentów, z których składa się produkt.
- Obowiązek aktualizacji – bez tego zapisu rejestr staje się dokumentem historycznym po pierwszej zmianie.
Klauzula 2 – zakres odszkodowania
Klauzula odszkodowawcza – w zależności od tego, czy jesteś dostawcą, czy zamawiającym – może przyjmować inny kształt. Zamawiający najchętniej widziałby ją w takim kształcie, który pozwala mu przerzucić wszystkie koszty na dostawcę. Ten ostatni wolałby jednak, aby jego odpowiedzialność była ograniczona, a naprawienie szkody mogłoby zostać zredukowane np. do wymienienia wadliwego komponentu.
Niezależnie od powyższego, zgodnie z polskimi przepisami (art. 471 KC), uzyskanie odszkodowania wymaga od poszkodowanego udowodnienia szkody i jej wysokości, jak i winy dostawcy oraz związku przyczynowego. W takim przypadku zamawiający często próbują dodać w umowie karę umowną za określone naruszenie dostawcy. To upraszcza dochodzenie odszkodowania, bo w tym przypadku dostawca będzie musiał wykazać, że nałożona na niego kara jest wygórowana w stosunku do powstałej szkody.
Przykładowe brzmienie:
„Dostawca gwarantuje, że dostarczone przez niego rezultaty usług będą wolne od roszczeń osób trzecich, a korzystanie z nich zgodnie z Umową przez Zamawiającego, nie będzie powodować wystąpienia przez osoby trzecie z roszczeniami. W przypadku, gdy osoba trzecia zgłosiła się z roszczeniami do Zamawiającego, Dostawca pokryje uzasadnione koszty obsługi prawnej, zasądzone odszkodowania, koszty zawartych ugód.”
Klauzula kwotowego ograniczenia odpowiedzialności dostawcy:
„Łączna odpowiedzialność dostawcy nie może przekroczyć wysokości 100% wynagrodzenia umownego, a odpowiedzialność za utracone korzyści została wyłączona.”
Klauzula rozszerzenia odpowiedzialności dostawcy – kara umowna:
„W przypadku wystąpienia przez osobę trzecią z roszczeniami, Dostawca zapłaci na rzecz Zamawiającego karę umowną w wysokości 10% wynagrodzenia wskazanego w umowie, za każdy przypadek naruszenia. Zapłata kary umownej nie wyłącza możliwości dochodzenia odszkodowania uzupełniającego.”
Klauzula ograniczenia odpowiedzialności dostawcy – wymiana komponentu:
„Dostawca gwarantuje, że dostarczone przez niego rezultaty usług będą wolne od roszczeń osób trzecich, a korzystanie z nich zgodnie z Umową przez Zamawiającego, nie będzie powodować wystąpienia przez osoby trzecie z roszczeniami. W przypadku, gdy osoba trzecia zgłosiła się z roszczeniami do Zamawiającego, Dostawca naprawi powstałą szkodę w ten sposób, że wymieni wadliwy komponent na wolny od wad, który umożliwi Zamawiającemu dalsze korzystanie z rezultatów usług.”
Trzy elementy, na które trzeba zwrócić szczególną uwagę:
- Limit kwotowy – typowo 80-100% wynagrodzenia umownego netto. W projektach wysokiego ryzyka (sektor regulowany jak np. finansowy) można negocjować wyższy limit, choć zamawiający bardzo rzadko wyraża na to zgodę.
- Modyfikacje Zamawiającego jako ograniczenie odpowiedzialności – często dostawca nie bierze odpowiedzialności za przypadki, gdy to zamawiający zmodyfikuje produkt lub gdy Zamawiający wykracza poza licencję. Warunkiem pociągnięcia dostawcy do odpowiedzialności jest korzystanie z produktu w sposób ściśle określony w umowie.
- Kara umowna – oprócz wysokości, jeśli jesteś zamawiającym, ważne, aby zwrócić uwagę na to, żeby móc dochodzić pełnego odszkodowania. Inaczej dostawca zapłaci karę umowną, która może nie pokryć całości szkód. Jako dostawca „walczyłbym” o osobny, a przez to i większy, limit w przypadku kar umownych. Tytułem przykładu: łączna odpowiedzialność umowna to 100% wartości kontraktu, ale sama wysokość kar nie może przekroczyć 30% wartości umowy.
Klauzula 3 – prawo do audytu dostawcy
Prawo do audytu pozwala sprawdzać, czy dostawca rzeczywiście trzyma się oświadczeń, które złożył w umowie. Bez tego oświadczenia dostawcy są tylko deklaracjami, których nie da się zweryfikować w trakcie współpracy.
Audyt w praktyce sprowadza się do tego, czy to, co ujawniono w rejestrze komponentów odpowiada faktycznemu ich składowi. Należy pamiętać, że w każdej firmie pracują ludzie, którzy mimo deklaracji dostawcy w umowie mogą umieścić w kodzie coś niedozwolonego. Oczywiście taka sytuacja to problem dostawcy, ale zamawiający powinien mieć narzędzia weryfikacji deklaracji z rzeczywistością.
Przykładowe brzmienie:
„Zamawiający ma prawo do przeprowadzenia audytu komponentów open source zawartych w Oprogramowaniu. Audyt może być przeprowadzony nie częściej niż raz w roku kalendarzowym, w terminie nie krótszym niż 14 dni od pisemnego zawiadomienia Dostawcy.
Zakres audytu obejmuje:
(a) weryfikację aktualności zestawienia komponentów dostarczonego przez Dostawcę;
(b) sprawdzenie przestrzegania umowy przez Dostawcę w zakresie wymagań wykorzystania elementów Open Source w projekcie.
Wszystkie informacje uzyskane w trakcie audytu będą traktowane jako poufne. W przypadku wykrycia naruszeń Dostawca jest zobowiązany niezwłocznie do ich usunięcia oraz pokryje koszty audytu.”
Bez prawa do audytu zamawiający jest praktycznie pozbawiony mechanizmu egzekwowania swoich uprawnień. Warto też zadbać o to, aby to dostawca pokrył koszt audytu, jeśli wynik okaże się negatywny.
Sprawdź również: Licencje open source
Podsumowanie, czyli jakie klauzule wpisać do nowych umów IT
Open source w umowach IT nie jest dziś tematem opcjonalnym. Trzy klauzule – oświadczenie dostawcy w zakresie korzystania z OSS i prowadzenia rejestru komponentów, klauzule odszkodowawcze oraz prawo do audytu – są minimalnym standardem i stanowią dobrą praktykę. Bez nich pracujesz na ryzyku, którego nawet nie wycenisz, a które ujawni się dopiero przy sporze z klientem albo przy sprzedaży spółki.
FAQ – klauzule open source w umowach IT
Czy mogę użyć szablonu klauzul open source z internetu?
Co do zasady tak, jako punkt wyjścia, ale szablon zawsze wymaga dopasowania do realiów. Najczęstsze błędy szablonów to: zbyt szeroka lista zakazanych licencji, niedostosowane do konkretnej sytuacji klauzule odpowiedzialności.
Jaki limit zabezpieczenia odszkodowawczego jest typowy?
W typowych umowach B2B w sektorze IT limit jest ustawiany zazwyczaj na poziomie 100% wynagrodzenia umownego. Przy czym 200%, tzw. supercap, jest dziś standardem dla projektów większego ryzyka lub newralgicznych obszarów jak np. wyciek danych.
Czy potrzebuję klauzul OSS w regulaminie SaaS dla użytkowników końcowych?
Tak, ale w znacznie prostszej formie. W regulaminie B2C lub B2B-małym wystarczy: informacja o tym, że produkt zawiera komponenty na różnych licencjach i wyłączenie odpowiedzialności za używanie produktu niezgodnie z umową.
