Prawa autorskie a utrzymanie systemu informatycznego – co powinien wiedzieć zamawiający? Cz. 2: Jak sprawdzić swoją sytuację prawną i techniczną?

Prawo do modyfikacji – objęte monopolem

Zakres majątkowych praw autorskich twórcy systemu informatycznego , a więc i wyłączności uprawnień twórcy w tym zakresie, jest bardzo szeroki. Obejmuje prawo do „tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian w programie komputerowym, z zachowaniem praw osoby, która tych zmian dokonała” (art. 74 ust 4 pkt 2 PrAut). W praktyce oznacza to, że każda ingerencja zamawiającego w program, bez względu na jej zakres, trwałość lub charakter co do zasady wymagałaby zgody uprawnionego (twórcy). Co ciekawe, w przypadku innych rodzajów utworów, a więc np. dokumentacji tego samego systemu IT, modyfikacje nie zostały zastrzeżone w ramach praw wyłącznych, tym samym czynności takie (np. skróty, tłumaczenia dokumentacji) mogą być dokonywane swobodnie, niezależnie od treści udzielonej na nie licencji. 

Ponadto, zgodnie z treścią art. 41 ust. 2 PrAut, umowa przenosząca autorskie prawa majątkowe, a także licencja, obejmują pola eksploatacji „wyraźnie w nich wymienione”. Tym samym wykazywanie przez zamawiającego prawa do modyfikacji, pomimo braku literalnego odzwierciedlenia takiego uprawnienia w umowie, byłoby bardzo utrudnione, a dokonywanie lub powierzenie innym podmiotom takich działań – prawnie ryzykowne. 

Prawo do zlecania wykonania modyfikacji innym podmiotom

W praktyce zamawiający z reguły nie może także poprzestać li tylko na zagwarantowaniu sobie samego prawa modyfikacji programu komputerowego, gdyż niezmiernie rzadko będzie chciał dokonywać takich działań samodzielnie. Z reguły charakter lub struktura organizacji zamawiającego, poziom przygotowania i kompetencji personelu, ograniczenia w dostępie do innych zasobów będą wymagały, aby takie prace zostały powierzone zewnętrznemu kontrahentowi. W efekcie przy zawieraniu umowy niezmiernie istotne jest zapewnienie przez odpowiedni zakres i treść postanowień dotyczących praw autorskich, aby uprawnienie do modyfikacji programu komputerowego mogło być w przyszłości przyznane innemu podmiotowi – zewnętrznemu dostawcy usługi utrzymania lub rozwoju IT. Tak naprawdę to ten podmiot, wykonując umowę zawartą z zamawiającym, będzie dokonywał działań wkraczających w zakres praw wyłącznych podmiotu uprawnionego. 

Prawo wynikające z umowy

Jeśli zamawiający posiada licencję upoważniającą go do korzystania z oprogramowania składającego się na system, możliwość dokonywania modyfikacji oprogramowania przez wykonawcę innego niż podmiot uprawniony będzie najczęściej opierała się na udzieleniu przez zamawiającego dalszej licencji (sublicencji) na rzecz świadczącego usługę IT. O taką możliwość również należy więc zadbać w umowie (licencyjnej) zawartej uprzednio z podmiotem uprawnionym (twórcą lub producentem oprogramowania). Zgodnie bowiem z treścią art. 67 ust. 3 PrAut: „Jeżeli umowa nie stanowi inaczej, licencjobiorca nie może upoważnić innej osoby do korzystania z utworu w zakresie uzyskanej licencji”. Prawo do udzielania innym podmiotom sublicencji zakresie posiadanych uprawnień, w tym prawa do modyfikacji, powinno być więc wyraźnie przyznane zamawiającemu w umowie określającej przysługujące mu uprawnienia. 

Co należy jednak zrobić w sytuacji, gdy umowa (np. licencyjna) „milczy” na temat prawa wprowadzania zmian w dostarczanym software, a zamawiający nie jest w stanie skutecznie i jednoznacznie wykazać upoważnienia go przez podmiot uprawniony do dokonywania modyfikacji lub powierzania ich podmiotom zewnętrznym? Jak wskazaliśmy wyżej, w takich przypadkach pozostaje jedynie poszukiwanie przepisu prawa, który mógłby „zalegalizować” wkroczenie przez zamawiającego w zakres autorskiego monopolu eksploatacyjnego. 

Prawo wynikające z ustawy

Analizując ustawę autorską i praktykę obrotu (w tym oparte na tej praktyce orzecznictwo), w zasadzie jedynym takim przepisem jest art. 75 ust. 1 PrAut. Przepis ten przyznaje legalnemu posiadaczowi programu komputerowego, z mocy samej ustawy, określone uprawnienia związane z korzystaniem z software’u. Uprawnienia obejmują prawo dokonywania zwielokrotnień (art. 74 ust. 4 pkt 1 PrAut), ale i modyfikacji (art. 74 ust. 4 pkt 2 PrAut), nie obejmując jednak rozpowszechniania (art. 74 ust. 4 pkt 3 PrAut). 

Sięganie po ten przepis w praktyce nie jest jednak łatwe – aby go zastosować, trzeba bowiem spełnić następujące warunki: 

• po pierwsze, trzeba być w ogóle „legalnym posiadaczem”, czyli legalnie (za zgodą uprawnionego) wejść w posiadanie programu komputerowego; zakładamy, że w przypadku zamawiających publicznych co do zaistnienia tej przesłanki zazwyczaj nie będzie wątpliwości;
• po drugie – działania, które podejmuje użytkownik (zwielokrotniania, modyfikacje), muszą być realnie niezbędne do zapewnienia mu możliwości korzystania z programu komputerowego zgodnie z jego przeznaczeniem, co w większości przypadków wyklucza skorzystanie z tego przepisu w celu prowadzenia rozwoju oprogramowania; 
• po trzecie, umowa nie może regulować inaczej (wyłączać, ograniczać) tych uprawnień.  

Jak widać, zakres stanów faktycznych, w których zamawiający mógłby się powołać na przepis art. 75 ust. 1 PrAut jako „ucieczkę” od ryzyka „vendor lock in”, jest mocno ograniczony, a dodatkowo obwarowany ryzykiem wyłączenia nawet tych stosunkowo wąskich uprawnień w całości lub w znacznej części postanowieniami umowy zawartej z podmiotem uprawnionym (np. umowy lub klauzuli licencyjnej). 

Z punktu widzenia praktyki obrotu powoływanie się na tę podstawę prawną w ramach działań służących utrzymaniu systemu IT będzie miało więc z reguły bardzo wyjątkowy, można by rzec jedynie „awaryjny”, charakter. Powoływanie się na nią w celu prowadzenia rozwoju, niezależnie od sytuacji i treści zawartych umów, w praktyce będzie wyłączone, poza bardzo szczególnymi przypadkami (np. adaptacja do zmian w prawie ściśle związanych z jego pierwotnym przeznaczeniem i funkcjonalnością przy jednoczesnym braku wsparcia ze strony producenta).

Tym samym, jeśli zamawiający chce udzielić zamówienia na utrzymanie systemu w całości jednemu wykonawcy, a co do niektórych elementów systemu nie ma uprawnienia do modyfikowania oprogramowania, wykonawca może nie być w stanie realizować umowy w odniesieniu do tych elementów, do których nie ma prawa ingerencji w monopol twórcy. Wykonawcy zazwyczaj są świadomi, że praca na cudzym systemie wymaga ostrożności, bo może skutkować naruszeniem praw twórcy systemu. Już na etapie publikacji dokumentacji przetargowej dopytują więc zamawiającego o zakres posiadanych przez niego uprawnień prawnoautorskich. 

Co istotne, zamawiający ma obowiązek opisać przedmiot zamówienia w sposób jednoznaczny i precyzyjny, z uwzględnieniem wymagań i okoliczności mogących mieć wpływ na sporządzenie oferty (art. 99 ust. 1 PZP). Nie może również opisywać przedmiotu zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów (art. 99 ust. 4 PZP). Tymczasem wymaganie poprawiania błędów i rozwijania systemu, co do którego prawa do modyfikacji przysługują jednemu podmiotowi, stawia ten podmiot jako potencjalnego wykonawcę w zdecydowanie preferowanej sytuacji. Nawet jeśli ograniczenie uprawnień dotyczy wyłącznie części systemu – de facto blokuje możliwość innym wykonawcom całego zamówienia. 

Nie ma też istotnego znaczenia czy podmiot posiadający prawa do modyfikacji systemu chce, czy też nie chce ubiegać się o zamówienie. O wadliwości tej sytuacji świadczy sam fakt, że określony podmiot jest w stanie dyktować warunki realizacji zamówienia. Jeśli podmiot ten nie będzie ubiegał się samodzielnie o zamówienie, to wykonawcy muszą uzyskać od niego ofertę na wykonanie części prac w ramach zamówienia (jako podwykonawcy). Tylko od woli tego podmiotu zależy, czy, z jakim wykonawcą, i na jakich warunkach finansowych będzie współpracował. Nie ma przy tym żadnego prawnego przymusu do zaproponowania współpracy wszystkim wykonawcom, a tym bardziej – na takich samych zasadach. Trudno uznać taką sytuację za zagwarantowanie zasady równego traktowania wykonawców. Jak rozwiązać ten problem (i kolejne, wymienione niżej)? O tym będziemy pisać w kolejnej części artykułu. 

Brak prawa do wykonywania praw zależnych do oprogramowania

Inną przeszkodą, na którą mogą trafić zamawiający udzielający zamówienia na utrzymanie systemu informatycznego, jest brak prawa do wykonywania praw zależnych do oprogramowania. 

Wyjaśnijmy zatem krótko, czym jest to prawo i jak ono „działa”. Podstawą normatywną jest tutaj art. 46 PrAut, który określa to prawo jako „wyłączne prawo zezwalania na wykonywanie zależnego prawa autorskiego”. Zależne prawo autorskie to z kolei nic innego jak majątkowe prawa autorskie do „opracowań” (tj. utworów zależnych w rozmienieniu art. 2 PrAut). Czyli – znów upraszczając nieco – wszelkich twórczych modyfikacji wcześniej istniejącego utworu. Będzie to więc np. zmodyfikowany w ramach developementu kod źródłowy programu komputerowego, czy dokumentacja systemu przetłumaczona na inny język. 

W przypadku software’u efektem skorzystania przez zamawiającego z prawa do jego modyfikacji może być (choć nie musi) powstanie „opracowania” w postaci nowego kodu istotnie opartego jednak na kodzie pierwotnym, jego treści i formie. „Opracowania” stanowią pod względem prawnym utwory odrębne od pierwowzorów, na podstawie których powstały, a twórcom opracowań przysługują do nich całkiem odrębne prawa autorskie (art. 2 ust 1 PrAut). 

Dlaczego więc, skoro mamy do czynienia z odrębnym utworem i prawami, może być to jednak problematyczne? Otóż prawa, o których mowa, nie bez powodu zostały nazwane „zależnymi”. W przeciwieństwie bowiem do „niezależnych” praw do utworów samoistnych, „rozporządzanie i korzystanie z opracowania zależy od zezwolenia twórcy utworu pierwotnego” (art. 2 ust 2 PrAut). 

I to właśnie przyjęta w tym przepisie konstrukcja stoi na przeszkodzie swobodnemu korzystaniu przez zamawiającego z twórczych modyfikacji „cudzych” utworów w ramach samodzielnego, czy też zlecanego innym podmiotom utrzymania lub rozwoju warstwy informatycznej posiadanego IT, także wówczas, gdy był kontraktowo upoważniony do dokonania lub powierzenia takich modyfikacji. Bez znaczenia pozostaje też fakt, że zamawiającemu lub działającemu na jego zlecenie dostawcy przysługują wyłączne prawa do powstałych w wyniku takich działań utworów zależnych (opracowań). 

Umowa z podmiotem uprawnionym, na podstawie której zamawiający nabywa prawa lub w ramach której zostaje upoważniony do korzystania (licencja), powinna więc uwzględnić nie tylko wskazane wcześniej prawo do modyfikacji, co w przypadku modyfikacji prowadzących do powstania opracowań może się okazać niewystarczające, ale również zawierać postanowienie przyznające zamawiającemu prawo do zezwalania na wykonywanie zależnych praw autorskich. 

W umowach przybiera to najczęściej postać udzielanego zamawiającemu upoważnienia (zezwolenia) na korzystanie przez zamawiającego z wykonanych przez niego lub na jego zlecenie opracowań lub – konstrukcja stosowana raczej w przypadku nabywania praw do pierwowzoru – definitywnego przeniesienia na zamawiającego, wraz z prawami z art. 50 lub art. 74 ust. 4 PrAut, prawa do zezwalania na wykonywanie praw zależnych. 

Warto też wskazać w tym kontekście na dwie dodatkowe kwestie: 

• po pierwsze, w przypadku zamiaru definitywnego nabycia takiego prawa trzeba tego dokonać wyraźnie, najlepiej odrębnym rozporządzeniem – postanowieniem umownym (z uwagi na treść art. 46 PrAut), 
• po drugie, w obydwu wariantach udzielenie uprawnienia powinno zostać dokonane z uwzględnieniem przepisu art. 41 ust. 2 PrAut, tj. na wyraźnie określonych w umowie polach eksploatacji opracowania.

Ponownie, problem może dotyczyć całości systemu albo niektórych jego elementów – i tak samo, jak w przypadku braku uprawnień licencyjnych do modyfikacji oprogramowania, może skutkować brakiem możliwości realizacji zamówienia przez wykonawcę, niebędącego twórcą problematycznych elementów systemu. A w konsekwencji oczywiście te same zarzuty wykonawców o brak gwarancji równego traktowania wykonawców przez zamawiającego. 

W ostatniej, trzeciej części naszego cyklu pokażemy, jakie konkretne rozwiązania prawne i praktyczne może zastosować zamawiający, by odzyskać swobodę zarządzania systemem i uniknąć pułapki vendor lock-in. Zachęcamy też do lektury pierwszej części cyklu – wszystkie artykuły są dostępne na stronie internetowej naszej kancelarii.

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.