Prawa autorskie a utrzymanie systemu informatycznego – co powinien wiedzieć zamawiający? Cz. 1: Dlaczego zamawiający tracą wpływ na swoje systemy IT?

Jak wynika z Raportu eGovernment Benchmark 2024, który ocenia cyfrowe usługi publiczne w Europie, Polska mocno nadgania zaległości w dostępności usług cyfrowych (jesteśmy w pierwszej czwórce państw z największym współczynnikiem poprawy w okresie ostatnich 4 lat). Proces informatyzacji administracji publicznej trwa już od około 20 lat. Ilość postępowań, mających na celu budowę i wdrożenie kompleksowych systemów informatycznych w instytucjach publicznych, maleje. Ich miejsce zajmują postępowania, których celem jest wyłonienie wykonawcy utrzymującego już wdrożony i eksploatowany przez instytucję publiczną system. I, jak się okazuje, wcale nie jest łatwiej. 

Trochę historii – dlaczego to takie skomplikowane

Systemy informatyczne w dużych instytucjach publicznych często powstawały w sposób przyrostowy. Najpierw informatyzowano określony obszar działalności podmiotu, potem następny, i kolejny. Poszczególne umowy, których przedmiotem była budowa takiego systemu, zawierane były w odstępach czasowych, realizowane przez różnych wykonawców, w różnych metodykach, miały różną treść, często wypracowywaną w drodze negocjacji albo odwołań wobec treści dokumentacji postępowania. 

W efekcie zamawiający obecnie często eksploatują systemy składające się z wielu różnych mniejszych systemów albo oparte na core, do którego dobudowywane były poszczególne moduły dziedzinowe. Zakres uprawnień zamawiającego do korzystania z każdego z tych elementów również często jest inny. 

W 2005 roku, w chwili wejścia w życie ustawy o informatyzacji działalności podmiotów realizujących zadania publiczne, prawo zamówień publicznych było w zupełnie innym miejscu niż obecnie. O ile same wdrożenia systemów ze względu na wartość postępowania odbywały się w trybie konkurencyjnym, o tyle liczba wykonawców zdolnych do realizacji takich wdrożeń była zdecydowanie mniejsza, a przez kilka lat rynek wdrożeniowy mocno się zmonopolizował. Na dodatek konsekwencją wdrożenia pierwotnego była często sytuacja „vendor lock-in”, bo wykonawca wykorzystywał swoją przewagę rynkową i narzucał zamawiającemu korzystne dla siebie warunki korzystania z systemu, wiążące zamawiającego z tym wykonawcą na kolejne lata eksploatacji systemu. 

Od 2009 r. Urząd Zamówień Publicznych dość skutecznie walczył z tym negatywnym zjawiskiem, co z czasem prowadziło do równie negatywnego zjawiska odwrotnego – żądania przez zamawiających przeniesienia wszelkich możliwych praw do zamawianego systemu. W konsekwencji takich wymagań możliwość złożenia oferty w postępowaniu mieli tylko ci wykonawcy, którzy nie mieli gotowego produktu. Nie zależało im na ochronie swoich praw do systemu, który budowali latami i który stabilizował się metodą prób i błędów w praktyce korzystania przez wielu użytkowników. Przeniesienie na zamawiającego majątkowych praw autorskich do systemu tworzonego w zamyśle jako system do szerokiego licencjonowania oznaczałoby bowiem pozbycie się przez dostawcę możliwości licencjonowania go innym podmiotom – czyli utratę możliwości zarabiania na tym, co budował przez lata. Kto zatem mógł złożyć ofertę? Mniejsi wykonawcy, gotowi podjąć ryzyko pisania w krótkim czasie systemu „od zera”. Z oczywistych względów, koniec końców zamawiający wcale nie był szczęśliwy z konieczności wyboru oferty niesprawdzonego wcześniej systemu od wykonawcy, od którego trudno było czasem egzekwować niewykonanie umowy. 

Od kilku lat, w związku z opublikowanymi przez Urząd Zamówień Publicznych w 2020 r. nowymi Rekomendacjami, najczęściej zamawiający wymagają wyłącznie udzielenia licencji na korzystanie z oprogramowania z opisanymi szeroko uprawnieniami do jego modyfikacji i z zapewnieniem zamawiającemu dostępu do kodów źródłowych. 

Tak czy inaczej, przez te wszystkie lata „patchworkowej” i opartej o skrajności wymagań prawnoautorskich informatyzacji, udzielenie zamówienia na utrzymanie systemu informatycznego często jest wyzwaniem niełatwym i wymagającym znajomości nie tylko przepisów prawa zamówień publicznych, lecz również regulacji prawa autorskiego. Zamawiający często stoją bowiem przed zadaniem udzielenia zamówienia na utrzymanie systemu składającego się z niejednorodnej struktury nie tylko pod względem architektury i technologii informatycznej, lecz również skomplikowanego pod względem prawnym. Do różnych elementów systemu, nabywanych w różnym czasie, często przysługują bowiem zamawiającemu niejednorodne uprawnienia autorskie. 

Praktyczne problemy z prawami autorskimi

Jakie praktyczne problemy mogą spotkać zamawiającego, który zamierza udzielić zamówienia na utrzymanie systemu informatycznego? Na początku trzeba wspomnieć, co zazwyczaj jest przedmiotem takiego zamówienia. W zdecydowanej większości przypadków w zakresie obowiązków wykonawcy będzie nie tylko usuwanie błędów oprogramowania, lecz również jego rozwój – czy to wynikający z konieczności dostosowywania się do zmieniających się przepisów prawa, czy to z ewolucji organizacji samego zamawiającego. 

Aby zatem skutecznie udzielić zamówienia w trybie otwartym na utrzymanie systemu informatycznego, zamawiający powinien mieć takie uprawnienia do korzystania z oprogramowania składającego się na system, które 

• zapewnią mu możliwość modyfikowania oprogramowania w celu usuwania błędów oraz
• w celu jego rozwijania, z także 
• zapewnią zamawiającemu możliwość skorzystania z takich uprawnień w celu umożliwienia wybranemu w przetargu wykonawcy realizacji zamówienia. 

Do tego dochodzi problem praktyczny, związany z dostępem do kodu źródłowego lub dokumentacji, bez którego – nawet posiadając odpowiednie uprawniania – zamawiający nie będzie w stanie skutecznie skorzystać z uprawnień i zrealizować celu, jakim jest dokonanie zmian (serwisowych, rozwojowych) w posiadanym systemie IT.

Aby móc efektywnie realizować takie działania, a jednocześnie uniknąć „vendor lock-in” trzeba więc odpowiednio wcześnie, najlepiej na etapie nabywania rozwiązania, zadbać zarówno o aspekt formalny (prawa), jak i faktyczny (kody, dokumentacja). 

Monopol twórcy

Zacząć należy od tego, jak w ogóle „działa” prawo autorskie. Jest to monopol – prawnie usankcjonowana wyłączność na dokonywanie określonych działań związanych z tzw. eksploatacją utworu (zwielokrotnienia, modyfikacje, rozpowszechnianie). Monopol przysługuje twórcy co do zasady rozumianemu bardzo ściśle – jako osoba lub grupa osób fizycznych (współtwórczość). Z monopolu przyznanego tym osobom wynika z kolei, że co do zasady tylko twórca (twórcy) może (mogą) korzystać z utworu. Inne osoby (fizyczne, prawne) mogą to czynić jedynie wówczas, gdy wystąpi jedna z dwóch sytuacji: 

• zawrą z twórcą odpowiednią umowę (umowa przenoszącą prawa lub licencja) lub
• znajdą podstawę prawną dla takich działań w przepisie prawa.

W odniesieniu do utworów, zwłaszcza programów komputerowych, zakres uprawnień do korzystania określa umowa licencyjna lub umowa o przeniesienie majątkowych praw autorskich (a w praktyce – postanowienia licencyjne albo postanowienia o przeniesieniu majątkowych praw autorskich zawarte w umowie zamówieniowo-publicznej). Wynika to głównie z faktu, że przyjęty w dyrektywie 2009/24, a w konsekwencji także w polskiej ustawie autorskiej (przepisy Rozdziału 7 PrAut) prawny model ochrony ma charakter bardzo „własnościowy”. Przyjrzyjmy się zatem zakresowi praw wyłącznych – tak jak go opisuje ustawa autorska, bo właśnie przyjęte w tym zakresie rozwiązanie ma kluczowe znaczenie dla zamówień na usługi utrzymania i rozwoju systemu IT. 

Ponieważ interesują nas przede wszystkim prawne uwarunkowania korzystania z software’u, szczególnie istotne jest wyłączne prawo twórcy programu komputerowego do dokonywania jego modyfikacji. 

Brak uprawnień licencyjnych do modyfikacji oprogramowania

Brak odpowiednio szerokich uprawnień licencyjnych zamawiającego do modyfikowania oprogramowania dotyczy zazwyczaj „starych” elementów systemu, bo od kilku dobrych lat zamawiający korzystają z opracowanych przez UZP wzorów umów, w których zawarte są postanowienia gwarantujące zamawiającemu uzyskanie odpowiednich uprawnień. 

Dla porządku trzeba nadmienić, że problem nie musi ograniczać się wyłącznie do umów, w ramach których zamawiający uzyskuje licencję do korzystania z programu komputerowego. Teoretycznie sytuacja zbyt wąskich uprawnień może dotyczyć również umów, których przedmiotem jest przeniesienie majątkowych praw autorskich do programu. Zamawiający, korzystając z konstrukcji przeniesienia praw, zmierzają jednak w większości przypadków do uzyskania maksymalnie kompletnego monopolu eksploatacyjnego. Zazwyczaj więc umowy przenoszące majątkowe prawa autorskie na zamawiających opisują zakres nabywanych przez nich uprawnień kompleksowo, a braki i ograniczenia w takich umowach dotyczące uprawnień niezbędnych dla swobodnego prowadzenia lub powierzania innym utrzymania systemu lub rozwoju – jeśli się zdarzają, to są raczej sporadyczne. Oczywiście nawet w takiej sytuacji w dalszym ciągu często aktualny pozostaje opisany wyżej problem posiadania przez zamawiającego szerokich majątkowych praw autorskich tylko do części systemu. A co za tym idzie, wyłączenie problemu z uprawnieniami tylko w odniesieniu do tej części. 

Natomiast niewystarczający zakres uprawnień zamawiającego w umowach licencyjnych w praktyce pojawia się zdecydowanie częściej, a wynika ze specyfiki prawa autorskiego.

Brak kodów źródłowych oprogramowania i brak dokumentacji oprogramowania

Trzecim głównym kłopotem (i chyba ostatnio najczęściej spotykanym) jest brak kodów źródłowych oprogramowania i brak dokumentacji oprogramowania. Aby skutecznie usuwać błędy systemu informatycznego, konieczne jest nie tylko samo prawo do modyfikowania oprogramowania, lecz również dostęp do kodów źródłowych oprogramowania i do jego dokumentacji. 

Wyjaśnijmy w tym miejscu, że zgodnie z art. 75 ust. 1 PrAut, a zwłaszcza interpretacją źródła tej regulacji tj. art. 5 dyrektywy Rady 91/250/EWG z dnia 14 maja 1991 r. w sprawie ochrony prawnej programów komputerowych, dokonaną w wyroku Trybunału Sprawiedliwości UE z 6.10.2021 r. w sprawie TOP System SA vs. État belge (C-13/20), wykonawca w pewnych sytuacjach może skorzystać z tzw. uprawnień legalnego posiadacza programu komputerowego w celu dezasemblacji kodu wynikowego (odtworzenia kodu źródłowego). Przypomnijmy, że zgodnie z treścią art. 75 ust. 1 PrAut, jeżeli umowa nie stanowi inaczej, czynności wymienione w art. 74 ust. 4 pkt 1 i 2 nie wymagają zgody uprawnionego, jeżeli są niezbędne do korzystania z programu komputerowego zgodnie z jego przeznaczeniem, w tym do poprawiania błędów przez osobę, która legalnie weszła w jego posiadanie. Tu jednak ponownie należy wskazać na ograniczony zakres stosowania tej regulacji – może ona być umownie wyłączona przez strony, a czynności te mogą być wykonywane tylko i wyłącznie w sytuacji, gdy okażą się niezbędne dla normalnego (zgodnego z przeznaczeniem) korzystania z programu komputerowego. 

W praktyce dekompilacja kodu w oparciu o przepis art. 75 ust 1 PrAut będzie możliwa co do zasady jedynie wówczas, gdy bez takiej czynności użytkownik (posiadacz) programu komputerowego nie może „normalnie” korzystać z programu do celów, do których program został przeznaczony, a podmiot uprawniony (np. producent oprogramowania) nie zapewnia wsparcia w przywróceniu takiej możliwości. Przekładając to na usługę utrzymania (serwisu) i rozwoju oprogramowania, w tym pierwszym przypadku dekompilacja z powołaniem się na art. 75 ust. 1 PrAut potencjalnie byłaby możliwa, jednak wymaga zaistnienia szeregu dodatkowych, wskazanych wyżej okoliczności, limitujących możliwości skorzystania z tych uprawnień, w drugim przypadku (rozwój) – praktycznie całkowicie pozostaje poza zakresem tej regulacji.

Poza tym pozostaje aspekt praktyczny – dekompilacja kodu jest pomocna wyłącznie wtedy, gdy potrzebne jest wprowadzenie stosunkowo prostej poprawki. Zdecydowanie nie może być traktowana jako remedium na brak dostępu do kodów w sytuacji, gdy zamawiający ma potrzebę stałego utrzymywania i rozwoju systemu. W wyniku dekompilacji kodu da się otrzymać określone informacje, pozwalające na doraźne rozwiązanie kłopotu, ale nie jest to w żadnym wypadku sensowne rozwiązanie na stałe i z pewnością nie dotyczy systemów o większym stopniu skomplikowania.

Nie ulega więc wątpliwości, że realny dostęp do kodów źródłowych i dokumentacji jest konieczny w celu realizacji usługi utrzymania systemu informatycznego. Tym bardziej, że zazwyczaj zamawiający wymaga określonego SLA dla usługi usuwania błędów, a niedotrzymanie SLA powoduje naliczenie wykonawcy kar umownych. Teoretyczna możliwość wykonania dezasemblacji kodu źródłowego zazwyczaj nie uchroni zatem wykonawcy od przekroczenia terminów zastrzeżonych dla usuwania wad systemu. W konsekwencji świadomy wykonawca zakwestionuje taką okoliczność już na etapie postępowania o udzielenie zamówienia na utrzymanie systemu (wnosząc odwołanie wobec treści SWZ). 

O tym, jak sprawdzić swoją sytuację prawną i techniczną – czyli co naprawdę wiemy o prawach do naszego systemu – napiszemy w kolejnym artykule cyklu.

Bogusława Garczyńska-Wąs, radca prawny, partner w kancelarii Barta & Partners.

Michał Barta, radca prawny, partner zarządzający w kancelarii Barta & Partners.