Oprogramowanie w zamówieniach publicznych

Jakie uprawnienia w zakresie modyfikacji oprogramowania powinien otrzymać zamawiający, ?aby prawidłowo zabezpieczyć swoje interesy?– analizuje Bogusława Garczyńska-Wąs.

Publikacja: 19.02.2014 08:49

Red

Pytanie to pojawia się przy każdym postępowaniu o udzielenie zamówienia publicznego na wdrożenie systemu albo na utrzymanie/serwisowanie oprogramowania. Nie jest to zatem pytanie nowe – zamówienia dotyczące systemów informatycznych są stałym i od dawna funkcjonującym zjawiskiem w procedurze zamówień publicznych. Z czego więc wynika potrzeba wypowiedzi na ten temat? Analiza kilkuletniej praktyki, która ukształtowała się po publikacji w 2009 r. „słynnych" Rekomendacji Urzędu Zamówień Publicznych, dotyczących udzielania zamówień na systemy informatyczne, świadczy o tym, że zamawiający w dalszym ciągu mają problemy z ich prawidłową interpretacją i stosowaniem.

Cel rekomendacji

W zamierzeniu Rekomendacje miały stanowić remedium na niepokojąco dużą skalę umów zawieranych w trybie z wolnej ręki, wynikającą z uzależnienia się przez zamawiającego od dostawcy systemu (udzielania na jego rzecz zamówień na serwis i rozwój oprogramowania). Cel ten w znacznym stopniu został osiągnięty – liczba zamówień udzielonych w trybie z wolnej ręki zmniejszyła się od 2009 r. o prawie połowę. W związku ze stosowaniem Rekomendacji pojawiły się jednak problemy bardziej subtelne i przez to mniej zauważane i komentowane przez UZP, a w praktyce mogące powodować negatywne konsekwencje dla budżetu. Warto więc powiedzieć to, co w Rekomendacjach nie zostało jednoznacznie wyrażone, a powinno być uwzględnione przez zamawiających przy tworzeniu dobrej umowy na wdrożenie. Jedną z bardziej problematycznych kwestii jest prawidłowe określenie zakresu uprawnień do modyfikacji oprogramowania przekazywanego w ramach realizacji umowy. Zakres ten jest ważny zarówno dla zamawiających, jak i wykonawców.

Przeniesienie czy licencja

Po pierwsze, zamawiający nie powinni wymagać od wykonawców przeniesienia majątkowych praw autorskich do oprogramowania, jeśli jedynym uzasadnieniem tego wymagania jest obawa przed ryzykiem związania się dostawcą systemu. Pomimo wielu wypowiedzi przedstawicieli branży IT często zamawiający nie mają świadomości, że udzielenie licencji na odpowiednio opisanych polach eksploatacji (w szczególności obejmującym uprawnienie do modyfikacji oprogramowania i udzielania w tym zakresie sublicencji) umożliwia udzielanie zamówień na utrzymanie systemu w trybie konkurencyjnym. Przeniesienie majątkowych praw autorskich przez wykonawcę oznacza ponadto utratę uprawnień do korzystania przez niego z wykonanego oprogramowania w innych wdrożeniach, wymaganie takie zazwyczaj spowoduje zatem wzrost cen złożonych w postępowaniu ofert.

Oczywiście są sytuacje, w których przeniesienie majątkowych praw autorskich do oprogramowania jest uzasadnione (dotyczy to szczególnie systemów budowanych w celu zapewnienia bardzo specyficznych potrzeb konkretnego podmiotu). Jednak wybór takiego rozwiązania powinien być świadomą decyzją zamawiającego, poprzedzoną analizą rozwiązania alternatywnego, czyli uzyskania uprawnień do korzystania z oprogramowania na podstawie odpowiednio sformułowanej umowy licencyjnej. Decyzja ta wymaga wyważenia pomiędzy dwoma sposobami zabezpieczenia interesów majątkowych zamawiającego: pełnego bezpieczeństwa w zakresie praw do oprogramowania (przeniesienie praw autorskich nie wiąże się z ryzykiem, jakie niesie ze sobą udzielenie licencji, która może być przez wykonawcę wypowiedziana) oraz dążeniem do obniżania kosztów zamówienia.

Po drugie, wymaganie przeniesienia majątkowych praw autorskich nie może dotyczyć każdego rodzaju oprogramowania. Systemy informatyczne składają się z różnych warstw – od aplikacyjnej , poprzez warstwę oprogramowania logiki biznesowej, w której skład wchodzą często biblioteki programistyczne („podprogramy", zawierające zbiór gotowych funkcji, z których korzysta oprogramowanie wyższego rzędu), aż do warstwy bazodanowej i systemowej (standardowe oprogramowanie podmiotów trzecich, biblioteki niższego rzędu), przy czym niejednokrotnie do obsługi systemu potrzebne jest także oprogramowanie narzędziowe (pomocnicze oprogramowanie standardowe, najczęściej także podmiotów trzecich). Wymaganie od wykonawców, aby przenieśli na zamawiającego majątkowe prawa autorskie do całego systemu, jest co najmniej nieracjonalne, przede wszystkim zaś niewykonalne. W odniesieniu do np. oprogramowania osób trzecich, potrzebnego do budowy systemu, z którego sam wykonawca korzysta na podstawie umowy licencyjnej, wymaganie to jest niemożliwe do spełnienia. Wykonawca nie może bowiem przenieść na zamawiającego praw, których sam nie posiada. W przypadku standardowych produktów wykonawcy jest to teoretycznie możliwe, lecz najczęściej biznesowo wykluczone ze względu na skutek przeniesienia praw na zamawiającego (utratę przez wykonawcę uprawnień do korzystania z oprogramowania).

Po trzecie, niezależnie od przyjętego modelu (przeniesienie praw/licencja) nieracjonalne jest wymaganie przekazania uprawnień do modyfikacji każdego rodzaju oprogramowania składającego się na system. Wykonawca zazwyczaj uprawniony jest do dokonywania modyfikacji tylko tego oprogramowania, które tworzy. Nie może więc zapewnić zamawiającemu uzyskania uprawnień, których sam nie posiada.

Powstaje oczywiście trudne pytanie, jak w takim razie powinny brzmieć postanowienia umowy, aby zamawiający zapewnił sobie możliwość utrzymania systemu, a jednocześnie nie wprowadzał do umowy postanowień wykluczających lub znacznie ograniczających możliwość złożenia sensownej oferty. Nie ma niestety jednej, dobrej odpowiedzi na to pytanie, ponieważ nie ma dwóch takich samych zamówień obejmujących przekazanie oprogramowania. W każdym przypadku zakres uprawnień zamawiającego powinien być określany w zależności od jego specyfiki, branży i celu, który ma być osiągnięty. Inaczej powinno się opisać zakres uprawnień do korzystania z zamawianego standardowego edytora tekstu, a inaczej – do systemu budowanego w celu obsługi specyficznych, niepowtarzalnych procesów biznesowych zamawiającego. Samo opisanie zakresu uprawnień może być ponadto niewystarczające, jeśli nie będzie powiązane z opisem wymaganej architektury systemu (określenia, jakie oprogramowanie może być oprogramowaniem standardowym lub oprogramowaniem osób trzecich, a jakie oprogramowaniem dedykowanym). Konieczne jest ponadto prawidłowe określenie definicji poszczególnych rodzajów oprogramowania. W umowach w sprawie zamówień publicznych często definicje nie są spójne z postanowieniami dotyczącymi praw autorskich bądź też z załącznikami technicznymi, określającymi wymagania dla architektury systemu. Konsekwencją są oczywiście spory co do zakresu uprawnień, jakie mają być przekazane zamawiającemu, przy czym ze względu na sprzeczność równorzędnych postanowień umownych trudno obiektywnie określić, po czyjej stronie jest racja, a tym bardziej – jak w takiej sytuacji orzeknie sąd.

Spór o kody źródłowe

Po czwarte wreszcie – zamawiający powinni jednoznacznie określić w umowie, czy wymagają od wykonawcy wydania kodów źródłowych do oprogramowania, a jeśli tak – do jakiego rodzaju oprogramowania. Posiadanie przez zamawiającego kodów źródłowych jest celowe w przypadku, gdy ma on uzyskać uprawnienie do modyfikacji oprogramowania. W pozostałych sytuacjach kody źródłowe zasadniczo nie będą zamawiającemu potrzebne. Brak uregulowania tej kwestii może prowadzić do sporu, ponieważ zgodnie z przeważającym w doktrynie prawa autorskiego stanowiskiem sam fakt zawarcia umowy licencyjnej nie stanowi podstawy do formułowania przez zamawiającego roszczenia o wydanie kodów źródłowych.

Przedstawione zagadnienia nie wyczerpują oczywiście zakresu elementów, które powinny być uwzględniane przez zamawiających podczas tworzenia umów dotyczących oprogramowania. Niemniej w praktyce sprawiają one największe problemy – także w trakcie realizacji umowy. Warto pamiętać, że nie ma czegoś takiego jak powszechnie obowiązujące, jednorodne „uprawnienie do rozwoju systemu", które zamawiający powinien sobie zapewnić w świetle Rekomendacji UZP. W zależności od przypadku uprawnienie to powinno być zabezpieczone w sposób szerszy lub węższy, a przekroczenie racjonalnej granicy może skutkować z jednej strony zarzutem niezabezpieczenia odpowiedniej niezależności od wykonawcy, z drugiej – dyskryminującym lub nieproporcjonalnym do potrzeb zamawiającego opisem przedmiotu zamówienia.

CV

Autorka jest prawnikiem. ?Specjalistą z zakresu prawa ?zamówień publicznych. ?Konsultantem w zespole radców prawnych krakowskiej kancelarii.

Pytanie to pojawia się przy każdym postępowaniu o udzielenie zamówienia publicznego na wdrożenie systemu albo na utrzymanie/serwisowanie oprogramowania. Nie jest to zatem pytanie nowe – zamówienia dotyczące systemów informatycznych są stałym i od dawna funkcjonującym zjawiskiem w procedurze zamówień publicznych. Z czego więc wynika potrzeba wypowiedzi na ten temat? Analiza kilkuletniej praktyki, która ukształtowała się po publikacji w 2009 r. „słynnych" Rekomendacji Urzędu Zamówień Publicznych, dotyczących udzielania zamówień na systemy informatyczne, świadczy o tym, że zamawiający w dalszym ciągu mają problemy z ich prawidłową interpretacją i stosowaniem.

Pozostało 92% artykułu
Opinie Prawne
Marek Isański: Można przyspieszyć orzekanie NSA w sprawach podatkowych zwykłych obywateli
https://track.adform.net/adfserve/?bn=77855207;1x1inv=1;srctype=3;gdpr=${gdpr};gdpr_consent=${gdpr_consent_50};ord=[timestamp]
Opinie Prawne
Maciej Gawroński: Za 30 mln zł rocznie Komisja będzie nakładać makijaż sztucznej inteligencji
Opinie Prawne
Wojciech Bochenek: Sankcja kredytu darmowego to kolejny koszmar sektora bankowego?
Opinie Prawne
Tomasz Pietryga: Sędziowie 13 grudnia, krótka refleksja
Materiał Promocyjny
Bank Pekao wchodzi w świat gamingu ze swoją planszą w Fortnite
Opinie Prawne
Rok rządu Donalda Tuska. "Zero sukcesów Adama Bodnara"