Ryzyko ujawnienia się wad prawnych oprogramowania może dotyczyć każdego projektu informatycznego. Wady prawne mogą mieć przy tym różny charakter, dotyczyć różnych rodzajów praw, jednak najpowszechniejsze i najistotniejsze są wady prawne dotyczące praw autorskich. A właściwie ich braku.

Wady prawne mogą ujawnić się zarówno w odniesieniu do oprogramowania standardowego dostawcy, oprogramowania osób trzecich (w tym komponentów open source), jak również oprogramowania dedykowanego. Powodem takiego stanu rzeczy są:

• to, że liczne elementy dostarczanych klientom rozwiązań nie są tworzone „od zera”, lecz bazują na rozwiązaniach już wcześniej dostępnych i stosowanych na rynku,
• formalny dostawca z reguły nie jest ich rzeczywistym twórcą, ani nawet podmiotem, który nabył prawa autorskie do programu pierwotnie, tj. w momencie jego powstania.

Już te dwie zasadnicze przyczyny sprawiają, że ryzyko wystąpienia wad prawnych w klasycznym modelu tworzenia i dostarczania oprogramowania wzrasta, a krąg podmiotów, których prawa można naruszyć, korzystając z niego, jest potencjalnie bardzo szeroki.

Proces tworzenia oprogramowania niejednokrotnie angażuje liczne zespoły twórców: programistów, projektantów, grafików, a na każdym z jego etapów do rozwiązania mogą zostać dodane komponenty (kod źródłowy, biblioteki, prace graficzne, tekstowe lub inne), do których prawa przysługują osobom trzecim. Z drugiej strony prawo autorskie oparte jest na fundamentalnej zasadzie „automatycznego” nabywania osobistych i majątkowych praw autorskich przez każdego indywidualnego twórcę, w całości i wyłącznie na własną rzecz, jedynie w ograniczonym zakresie przewidując odstępstwa od tej zasady (np. względnie obowiązująca reguła nabywania przez pracodawcę praw autorskich do programów komputerowych stworzonych przez jego pracowników – art. 74 ust 5 pr. aut.). Reszta jest… umową.

Efekt może być więc taki, że na koniec procesu tworzenia lub dostosowywania oprogramowania dla potrzeb danego projektu prawa autorskie mogą zostać mocno „rozproszone”. Co więcej, automatyczne ich nabycie przez uprawnionych, bez dodatkowych „formalności” (tj. z mocy samego prawa), może spowodować brak świadomości takiego stanu rzeczy po stronie podmiotu organizującego i zlecającego takie prace, a nawet w gronie samych twórców. Jednak w zdecydowanie najgorszej i najbardziej ryzykownej sytuacji znajduje się w takim przypadku odbiorca – użytkownik produktu, w większości przypadków nieuczestniczący aktywnie w procesie jego wytworzenia (co potencjalnie sprzyjałoby lepszemu rozeznaniu sytuacji w zakresie praw autorskich), a jedynie wykorzystujący rezultaty tego procesu – oprogramowanie – w swojej działalności. Wspomniany brak „formalizmów” w celu powstania lub nabycia praw, wobec jednoczesnego braku mechanizmów i narzędzi weryfikacji, powoduje, że użytkownik produktu jest więc praktycznie pozbawiony jakiejkolwiek możliwości oszacowania ryzyka. A ryzyko jest niebagatelne, ponieważ polega przede wszystkim na możliwości naruszenia praw autorskich innych osób w wyniku korzystania z oprogramowania obarczonego wadą prawną.

W niniejszym opracowaniu wskażemy, kiedy zwiększa się ryzyko wystąpienia wady prawnej oprogramowania, omawiamy metody zabezpieczenia się przed jego skutkami – w postaci wprowadzenia stosownych klauzul w kontraktach na korzystanie z oprogramowania, jak i podpowiadamy możliwości skorzystania z ustawowych środków ochrony. Skupiamy się przy tym przede wszystkim na sytuacji podmiotu zamawiającego oprogramowanie u zewnętrznego dostawcy w celu późniejszego korzystania z niego w ramach własnej działalności lub jako produktu komercyjnie udostępnianego innym podmiotom. Ryzyko roszczeń osób trzecich skierowane jest więc głównie przeciwko temu podmiotowi, aczkolwiek należy pamiętać, że wystąpienie wady prawnej oprogramowania może się wiązać (i często będzie się wiązać) także z odpowiedzialnością po stronie dostawcy, zgodnie z określonymi reżimami ustawowymi (rękojmia) lub przewidzianymi w umowie na dostarczenie oprogramowania zasadami indemnifikacji.

> CZYM JEST WADA PRAWNA?

Do pojęcia wady prawnej odwołują się zarówno przepisy ustawy o prawie autorskim i prawach pokrewnych (art. 55 pr. aut.), jak i przepisy Kodeksu cywilnego dotyczące rękojmi przy sprzedaży (art. 556[3] kc), które znajdą zastosowanie także do umowy o dzieło, znacznie częściej występującej w przypadku tworzenia lub wdrażania oprogramowania na zamówienie klienta.

Istotny jest zwłaszcza ten ostatni przepis, zawierający definicję ustawową wady prawnej sprzedanej „rzeczy”. Zgodnie z nim wada prawna wystąpi, „jeżeli rzecz sprzedana stanowi własność osoby trzeciej albo jeżeli jest obciążona prawem osoby trzeciej, a także jeżeli ograniczenie w korzystaniu lub rozporządzaniu rzeczą wynika z decyzji lub orzeczenia właściwego organu; w razie sprzedaży prawa sprzedawca jest odpowiedzialny także za istnienie prawa (wada prawna)”.

Oprogramowanie to oczywiście dobro niematerialne (a więc „nie-rzecz”), jednak zgodnie z art. 555 kc „przepisy o sprzedaży rzeczy [a wiec i rękojmi – przyp. aut.] stosuje się odpowiednio do sprzedaży (…) praw”, a także, jak już wskazano, do dzieła, które rozumiane jest znacznie szerzej niż rzecz niematerialna (dziełem może być aplikacja, wdrożony system, konfiguracja itp.).

Z wadą prawną oprogramowania będziemy mieć zatem do czynienia, gdy:

• prawa autorskie do oprogramowania przysługują osobie trzeciej,
• prawa do oprogramowania obciążone są prawem osoby trzeciej,
• ograniczenie w korzystaniu lub rozporządzaniu z praw do oprogramowania wynika z decyzji lub orzeczenia właściwego organu,

Oczywiście jednak tylko w takim zakresie, w jakim da się to pogodzić z zakresem praw podlegających przeniesieniu lub zakresem udzielanej licencji. Co ciekawe, wada prawna wystąpi także w (dosyć rzadkim) przypadku, gdy umowa przewiduje licencje lub przeniesienie praw, a prawa do oprogramowania po prostu nie istnieją.

Czy kodeksowa odpowiedzialność z tytułu rękojmi obejmuje inne niż sprzedaż praw autorskich / wykonanie dzieła sytuacje związane z umożliwieniem korzystania z oprogramowania, takie jak np. samo udzielenie licencji na „gotowy” produkt (bez wykonywania dzieła) lub udostępnienie oprogramowania do korzystania w modelu chmurowym (Software-as-a-Service)? Wydaje się, że nie.

W pewnym stopniu tę „lukę” można jednak wypełnić poprzez odwołanie się do drugiej ze wspomnianych regulacji, tj. art. 55 ust. 2 pr. aut., zgodnie z którą „jeżeli utwór ma wady prawne, zamawiający może od umowy odstąpić i żądać naprawienia szkody”. Pomimo kontrowersji w doktrynie uzasadniony wydaje się wniosek, że przepis ten ma szeroki zakres zastosowania, obejmujący każdą umowę, której przedmiotem jest dostarczenie utworu przez jakikolwiek podmiot – niezależnie od podstawy prawnej lub typu umowy (większe wątpliwości wiążą się natomiast z możliwością stosowania tego przepisu w zależności od tego, kto jest stroną takiej umowy, o czym piszemy dalej).

> NAJCZĘSTSZE PRZYPADKI UJAWNIENIA WADY PRAWNEJ

Wada prawna w praktyce bardzo rzadko jest rezultatem umyślnych działań, a najczęściej wynika z braku zachowania wymaganej staranności na etapie nabywania uprawnień przez samego dostawcę lub braku dostatecznego rozeznania, wiedzy co do statusu prawnego oprogramowania, w tym wszystkich podmiotów uprawnionych do niego z tytułu autorskich praw majątkowych lub po prostu nieznajomości zasad prawa autorskiego.

W praktyce do najczęstszych sytuacji ujawnienia w projekcie wady prawnej oprogramowania można zaliczyć takie, w których dostawca nieskutecznie „przenosi” na zamawiającego autorskie prawa majątkowe do oprogramowania lub udziela mu licencji na korzystanie z tego oprogramowania, podczas gdy:

• umowa podwykonawcza nie zawiera postanowień w zakresie przeniesienia na dostawcę autorskich praw majątkowych do systemu lub udzielenia licencji w wystarczającym zakresie, wskutek czego dostawca w ogóle nie stał się dysponentem praw autorskich do takiego systemu – majątkowe prawa autorskie w całości lub w części istotnej dla wykonania umowy z klientem przysługują nadal osobie trzeciej;
• umowa podwykonawcza, której przedmiotem było przeniesienie praw autorskich majątkowych do systemu lub udzielenie licencji wyłącznej, została zawarta bez zachowania formy pisemnej pod rygorem nieważności;
• umowa podwykonawcza przyznaje dostawcy węższy zakres uprawnień niż ten, który wynika z umowy pomiędzy dostawcą a zamawiającym (np. węższy katalog pól eksploatacji, węższy zakres terytorialny lub czasowy korzystania z oprogramowania) – w zakresie wykraczającym poza wskazany w umowie podwykonawczej, zamawiający nie ma podstaw do korzystania z takiego oprogramowania (zgodnie z zasadą nemo plus iuris, tj. nikt nie może przenieść na drugą osobę więcej praw, niż sam posiada);
• umowa podwykonawcza, na mocy której dostawca nabył licencję na korzystanie z systemu, nie zawiera uprawnienia dostawcy do udzielenia sublicencji, tj. upoważnienia innej osoby do korzystania z utworu (takie uprawnienie dostawcy powinno wprost wynikać z treści umowy podwykonawczej, zgodnie z art. 67 ust. 3 pr. aut.), a mimo to dostawca udziela sublicencji;
• w modelu przewidującym udzielenie zamawiającemu sublicencji, w trakcie trwania umowy pomiędzy dostawcą a zamawiającym, licencja udzielona dostawcy wygasa i tym samym dochodzi do wygaśnięcia sublicencji udzielonej zamawiającemu, mimo trwającego zobowiązania dostawcy do zapewnienia zamawiającemu możliwości legalnego korzystania z oprogramowania;
• w modelu umowy sublicencyjnej dostawca ustala z zamawiającym odstępstwa od standardowych warunków licencyjnych (np. w zakresie metryk licencyjnych „per device” lub liczby środowisk, na których można uruchomić oprogramowanie), do czego jednak nie jest umocowany przez dysponenta lub dysponentów praw autorskich, wskutek czego zamawiający korzystając z systemu w sposób uzgodniony z dostawcą, jednocześnie narusza prawa autorskie producenta.

Warto zauważyć, że w zakresie, w jakim powyżej wskazana została umowa podwykonawcza, chodzić będzie nie tylko o umowy zawierane przez dostawcę z innymi firmami IT, ale także o umowy ze współpracownikami dostawcy (w tym w ramach kontraktów B2B), a także – w pewnych przypadkach – pracownikami, których warunki zostały specyficznie ukształtowane w obszarze praw autorskich.

[...]

Damian Łapka – radca prawny w kancelarii Barta & Kaliński sp. j. Specjalizuje się w projektach związanych z umowami licencyjnymi, R&D, prawem własności przemysłowej i innych z zakresu prawa własności intelektualnej.
Adrianna Żyrek – aplikantka radcowska, prawnik w kancelarii Barta & Kaliński sp. j. Specjalizuje się w projektach związanych z problematyką nowych technologii, w szczególności prawa autorskiego, a także prawa ochrony danych osobowych.