Prawa autorskie a utrzymanie systemu informatycznego – co powinien wiedzieć zamawiający? Cz. 3: Jak odzyskać swobodę zarządzania systemem – dostępne strategie i ich konsekwencje

Wolna ręka

W przypadku, gdy zamawiający boryka się z problemem uzależnienia od jednego wykonawcy (ze względu na brak uprawnień do modyfikacji oprogramowania albo kodów źródłowych czy też dokumentacji), najbardziej oczywiste rozwiązanie to udzielenie zamówienia na utrzymanie wykonawcy, który może zrealizować zamówienie. Będzie to oznaczało udzielenie temu wykonawcy zamówienia w trybie z wolnej ręki na podstawie art. 214 ust. 1 pkt. 1 lit. b PZP (dostawy, usługi lub roboty budowlane mogą być świadczone tylko przez jednego wykonawcę z przyczyn związanych z ochroną praw wyłącznych wynikających z odrębnych przepisów, jeżeli nie istnieje rozsądne rozwiązanie alternatywne lub rozwiązanie zastępcze, a brak konkurencji nie jest wynikiem celowego zawężenia parametrów zamówienia). Nazwijmy je roboczo rozwiązaniem „1A”.

Nie zawsze będzie to jednak rozwiązanie bezpieczne. Spełnienie wszystkich warunków wymienionych w powołanej przesłance udzielenia zamówienia z wolnej ręki po 15 latach uświadamiania zamawiającym przez UZP, że muszą unikać „vendor lock-in” i powinni wymagać od wykonawców praw do modyfikacji oprogramowania, jest dość trudne. Na gruncie prawa unijnego przypomniał o tym ostatnio Trybunał Sprawiedliwości Unii Europejskiej w wyroku z dnia 9 stycznia 2025, C-578/23

Tym samym bezpieczne skorzystanie z trybu wolnej ręki na podstawie art. 214 ust. 1 pkt. 1 lit. b PZP będzie dziś sytuacją stosunkowo rzadką. Mogłoby dotyczyć jednorodnych systemów informatycznych, które nie były budowane w sposób „patchworkowy” przez różnych wykonawców, lecz pierwotnie i w sposób ciągły przez jednego wykonawcę, a wdrożone zostały przed upowszechnieniem się Rekomendacji z 2009 r. Choć i w tym przypadku wymagałoby spełnienia dodatkowych warunków – zamawiający przed udzieleniem zamówienia z wolnej ręki na podstawie art. 214 ust. 1 pkt. 1 lit. b PZP powinien bowiem przeprowadzić analizę, czy istnieje rozsądne rozwiązanie alternatywne lub rozwiązanie zastępcze. 

Wdrożenie nowego systemu

Takim rozwiązaniem zastępczym (nazwijmy je rozwiązaniem 1B) zazwyczaj będzie wdrożenie nowego systemu informatycznego i tym razem uzyskanie wymaganych praw do jego modyfikacji/zapewnienie przekazania kodów źródłowych i dokumentacji. Inne, teoretycznie możliwe rozwiązanie alternatywne (1C), to nabycie od uprawnionego wykonawcy uprawnień do modyfikacji (uzyskanie kodów, dokumentacji). Biorąc jednak pod uwagę dość słabą pozycję negocjacyjną zamawiającego w tej sytuacji, raczej rzadko będzie to „rozsądne rozwiązanie alternatywne”, bo wykonawca zazwyczaj podyktuje za takie świadczenia cenę, która będzie rekompensować mu utratę gwarantowanego zamówienia na utrzymanie systemu w przyszłych latach. A więc zapewne cenę nierozsądną w rozumieniu art. 214 ust. 1 pkt. 1 lit. b PZP.

Jeśli zatem pierwotny wykonawca systemu nie w trybie umownym pozwolić na uniezależnienie się zamawiającego od prawnoautorskiego monopolu, albo oferuje nieracjonalną dla zamawiającego cenę, zamawiającemu pozostaje wybór pomiędzy dalszym udzielaniem zamówienia na utrzymanie takiego systemu dotychczasowemu wykonawcy w trybie z wolnej ręki (1A), lub też wdrożenie nowego systemu i nabycie tym razem wszystkich elementów niezbędnych do jego modyfikacji (1B). 

W trochę innej sytuacji będzie zamawiający, który eksploatuje system „składany” z różnych podsystemów, modułów itp., budowanych przez różnych wykonawców, z różnymi zakresami posiadanych uprawnień do modyfikowania. 

Zdarza się, że do części systemu zamawiający posiada uprawnienia do modyfikacji, a do części nie (to samo oczywiście może dotyczyć kodów źródłowych i dokumentacji). W tej sytuacji najprostsze byłoby nabycie uprawnień do modyfikacji części oprogramowania od uprawnionego wykonawcy (1C) i udzielenie zamówienia na utrzymanie całości systemu w przetargu otwartym. Nie zawsze jest to jednak możliwe – uprawniony podmiot nie ma żadnego obowiązku zawierania umowy z zamawiającym. 

Przetarg otwarty

Alternatywnym rozwiązaniem będzie zatem udzielenie zamówienia na utrzymanie systemu w tej części, do której zamawiający posiada pełne uprawnienia, w trybie przetargu otwartego, a do pozostałej części przyjęcie rozwiązania 1A (udzielenie zamówienia z wolnej ręki uprawnionemu twórcy tej części systemu). Często jednak zamawiający nie chcą w ten sposób „rozczłonkowywać” procesu utrzymania systemu informatycznego. Multiplikowanie podmiotów serwisujących jest nie tylko kłopotliwe z administracyjnego punktu widzenia, lecz często utrudnia dochodzenie, kto jest odpowiedzialny za dany błąd. Systemy informatyczne to najczęściej zbiór oprogramowania przenikającego się wzajemnie i oddziałującego na siebie wzajemnie. Jest więc prawdopodobne, że wykonawcy będą poszukiwać winnego pojawienia się błędu w tej części systemu, którego sami nie utrzymują. Z punktu widzenia zamawiającego nie jest to więc rozwiązanie optymalne. 

Inne możliwe rozwiązanie to udzielenie zamówienia na utrzymanie całości systemu w przetargu otwartym, z tym, że zamawiający przyjmuje rolę gwaranta współpracy pomiędzy wykonawcą uprawnionym do modyfikacji części systemu a wykonawcą wybranym w przetargu otwartym (rozwiązanie 1D). Przy czym, co ważne, współpraca taka musi być przez zamawiającego zagwarantowana na równych warunkach wszystkim potencjalnym wykonawcom już na etapie prowadzenia postępowania przetargowego. Tylko w takiej sytuacji zamawiający zapewnia prowadzenie postępowania z zachowaniem zasady równego traktowania wykonawców. W praktyce będzie to oznaczało konieczność zawarcia porozumienia (umowy) pomiędzy zamawiającym a uprawnionym do modyfikacji części systemu podmiotem, na podstawie którego podmiot ten zobowiąże się złożyć ofertę wykonanie prac objętych monopolem autorskim na takich samych zasadach każdemu wykonawcy, który się o taką ofertę zwróci. Zamawiający może od razu uzgodnić cenę takiej uzgodnionej współpracy i ujawnić ją w SWZ – w takiej sytuacji wykonawcy po prostu doliczą ten koszt do swojej oferty. Jeśli takiego uzgodnienia w SWZ nie ma, wykonawcy zobowiązani będą uzyskać od uprawnionego podmiotu ofertę na podwykonawstwo samodzielnie i koszt współpracy doliczyć do kosztów realizacji zamówienia. 

Jeszcze inne możliwe rozwiązanie to połączenie przetargu otwartego i różnego rodzaju odmiany rozwiązania 1B, 1C i 1D. Zamawiający w takiej sytuacji udziela zamówienia na utrzymanie całości systemu, lecz umożliwia wykonawcom wybór pomiędzy uzyskaniem od uprawnionego podmiotu praw do modyfikacji części systemu lub zapewnieniem sobie współpracy tego podmiotu jako podwykonawcy, a zastąpieniem problematycznej części systemu – nowym oprogramowaniem. W tym ostatnim przypadku oczywiście już z zapewnieniem zamawiającemu praw do jego modyfikacji. Dla zamawiającego jest to o tyle wygodne, że w wyniku rozstrzygnięcia postępowania jest jeden podmiot odpowiedzialny za utrzymanie całości systemu. Dla wykonawców – również może być wygodne, ponieważ jeśli nie dojdą do porozumienia z podmiotem uprawnionym do modyfikacji części systemu, mogą zaoferować w zamian własne oprogramowanie, co często jest tańsze, niż zlecenie wykonania prac naturalnemu monopoliście. Proceduralnie wymagać to będzie dopuszczenia możliwości złożenia oferty wariantowej. Oczywiście to, czy taka konstrukcja będzie zadowalała wszystkich, i czy faktycznie będzie gwarantować równe szanse dla wszystkich wykonawców, będzie uzależnione od konkretnego przypadku, w szczególności tego, jak duża jest „zamknięta” część systemu, czy jest standardowa, czy raczej jest rozwiązaniem unikatowym, trudnym do szybkiego zastąpienia, a w szczególności – jak zamawiający opisze wymagania dotyczące czasu wykonania takiego mikro-wdrożenia zastępczego i zintegrowania go z pozostałą częścią systemu. 

Podsumowanie, wnioski, rekomendacje

Po pierwsze – przed ogłoszeniem postępowania na utrzymanie systemu informatycznego zamawiający musi wiedzieć, czym dysponuje. Czyli jakie konkretnie ma uprawnienia do eksploatacji danego systemu informatycznego, nabyte na podstawie jakich umów, z jakimi postanowieniami prawnoautorskimi. 

Po drugie – zamawiający musi wiedzieć, czym dysponuje fizycznie. Czyli – czy dysponuje dostępem do kodów źródłowych i dokumentacją (aktualną) oprogramowania składającego się na dany system informatyczny. 

Po trzecie – jeśli w określonych elementach systemu zamawiający dostrzega problemy uzależnienia od jednego, konkretnego dostawcy (brak uprawnień do modyfikacji, brak dostępu do kodów źródłowych, brak aktualnej dokumentacji) – powinien przeanalizować, czy da radę w akceptowalny kosztowo sposób wycofać się z tego uzależnienia. Jeśli nie ma takiej możliwości – powinien przeprowadzić analizę rozwiązań alternatywnych, czyli wdrożenia nowego systemu w miejsce systemu objętego monopolem jednego dostawcy. W zależności od wyników tej analizy – albo iść dotychczasową ścieżką (zamówienie z wolnej ręki na utrzymanie całości systemu albo tej części systemu, która jest objęta monopolem), albo dążyć do uzyskania rozwiązania alternatywnego. I cały czas pamiętać o tym, że czas działa na jego niekorzyść, tzn. im dłużej trwa proceder udzielania zamówienia na utrzymanie systemu w trybie z wolnej ręki z powołaniem się na prawa wyłączne, tym trudniej będzie się z tego zamawiającemu wytłumaczyć organom przeprowadzającym kontrolę legalności procedur. 

Wszystkie trzy części naszego cyklu o prawach autorskich w zamówieniach IT są dostępne na stronie internetowej naszej kancelarii.