KIO 1043/17
-
Data orzeczenia:
-
Organ orzekający:
-
Skład sędziowski:
-
Protokolanci:Adam Skowroński
Powołane przepisy:
Dodatkowe informacje:
-
Sprawy przywołane w treści orzeczenia:
Pełny tekst orzeczenia
Sygn. akt: KIO 1043/17
WYROK
z dnia 7 czerwca 2017 roku
Krajowa Izba Odwoławcza - w składzie:
Przewodniczący: Justyna Tomkowska
Protokolant: Adam Skowroński
po rozpoznaniu na rozprawie w dniu 7 czerwca 2017 roku w Warszawie odwołania
wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 26 maja 2017 roku przez
Odwołującego – INTERGRAPH Polska Sp. z o.o. z siedzibą w Warszawie,
w postępowaniu prowadzonym przez Zamawiającego – Skarb Państwa, Komendanta
Głównego Państwowej Straży Pożarnej z siedzibą w Warszawie
przy udziale wykonawcy ubiegającego się o udzielenie zamówienia S&T Services Polska
Sp. z o.o. z siedzibą w Warszawie zgłaszającego przystąpienie do postępowania
odwoławczego po stronie zamawiającego
orzeka:
1. oddala odwołanie,
2. kosztami postępowania obciąża Odwołującego i:
2.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000,00 zł
(słownie: piętnastu tysięcy złotych 00/100) uiszczoną przez Odwołującego INTERGRAPH
Polska Sp. z o.o. z siedzibą w Warszawie tytułem wpisu od odwołania
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. Prawo zamówień
publicznych (Dz.U.2015.2164 j.t. ze zm.) na niniejszy wyrok – w terminie 7 dni od dnia jego
doręczenia – przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do
Sądu Okręgowego w Warszawie
Przewodniczący:
sygn. akt KIO 1043/17
UZASADNIENIE
W dniu 26 maja 2017 roku do Prezesa Krajowej Izby Odwoławczej w Warszawie, na
podstawie art. 179 ust. 1 i art. 180 ust. 1, a także art. 182 ust. 2 pkt 1 ustawy z dnia 29
stycznia 2004 roku - Prawo zamówień publicznych (t.j. Dz. U. z 2015 r., poz. 2164 ze zm.),
zwanej dalej „ustawą Pzp”, odwołanie złożył wykonawca Intergraph Polska Sp. z o.o.
z siedzibą w Warszawie, zwany dalej „Odwołującym”.
Postępowanie o udzielenie zamówienia publicznego w trybie przetargu
nieograniczonego „Budowa Systemu Wspomagania Decyzji Państwowej Straży Pożarnej”
prowadzi Zamawiający: Skarb Państwa - Komendant Główny Państwowej Straży
Pożarnej z siedzibą w Warszawie. Ogłoszenie o zamówieniu zostało opublikowane
w Dzienniku Urzędowym Unii Europejskiej w dniu 16 maja 2017 r., pod numerem 2017/S
093-182525.
Odwołanie wniesiono wobec treści ogłoszenia o zamówieniu oraz Specyfikacji
Istotnych Warunków Zamówienia (dalej SIWZ) wraz z załącznikami, w tym Załącznikiem nr 2
Projekt umowy, zarzucając Zamawiającemu naruszenie art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2
ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób, który utrudnia
przestrzeganie zasad uczciwej konkurencji i równego traktowania wykonawców oraz bez
zachowania zasad proporcjonalności i przejrzystości, na skutek wprowadzenia przez
Zamawiającego żądań udostępnienia kodów źródłowych do oprogramowania
standardowego, a także wyrażenia zgody na wykonywanie praw zależnych do
oprogramowania standardowego, które to kryteria znacząco i bezzasadnie zawężając krąg
Wykonawców zdolnych do złożenie ofert w przetargu.
Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji treści ogłoszenia
o zamówieniu oraz SIWZ poprzez doprowadzenie jej postanowień do zgodności z ustawą
Pzp, w szczególności poprzez zmianę treści ogłoszenia o zamówieniu oraz SIWZ w sposób
opisany w uzasadnieniu odwołania.
Odwołujący wskazała, iż posiada interes w uzyskaniu zamówienia, a także w złożeniu
odwołania, bowiem zamierza ubiegać się o udzielenie zamówienia. Postanowienia
ogłoszenia o zamówieniu oraz SIWZ uniemożliwiają mu złożenie oferty. W konsekwencji,
Odwołujący się może ponieść szkodę wynikającą z braku możliwości uzyskania zamówienia,
a w konsekwencji tego narażony jest on na szkodę w postaci utraty zysku, który mógłby
osiągnąć w wypadku wyboru jego oferty, jako oferty najkorzystniejszej.
Odwołanie zostało wniesione z zachowaniem ustawowego terminu przewidzianego
w art. 182 ust. 1 pkt 1 ustawy Pzp. Kopia odwołania została przekazana Zamawiającemu.
Odwołujący uiścił wpis w wymaganej wysokości na rachunek UZP.
W uzasadnieniu zauważono, że przedmiotem zamówienia jest wykonanie i wdrożenie
Systemu Wspomagania Decyzji Państwowej Straży Pożarnej wspierającego:
— wykonywanie zadań krajowego systemu ratowniczo-gaśniczego przez wszystkie
jednostki organizacyjne Państwowej Straży Pożarnej,
— przyjmowanie zgłoszeń i rejestrację zdarzeń,
— alarmowanie i powiadamianie sił i środków,
— dysponowanie siłami i środkami,
— nadzorowanie i koordynację działań podczas zdarzeń,
— wymianę informacji i danych między wszystkimi jednostkami organizacyjnymi
Państwowej Straży Pożarnej oraz innymi partnerami,
— prowadzenie ewidencji podmiotów, sił i środków Państwowej Straży Pożarnej,
Ochotniczej Straży Pożarnej, Zakładowych Straży Pożarnych i Zakładowych Służb
Ratowniczych, oraz innych jednostek i podmiotów współpracujących,
— ewidencjonowanie dostępnych dla Państwowej Straży Pożarnej sił i środków innych
zasobów pochodzących z instytucji i organizacji współpracujących z Państwową Strażą
Pożarną,
— współpracę z urządzeniami łączności oraz urządzeniami umożliwiającymi śledzenie
pojazdów, nadzór, alarmowanie i powiadamianie sił i środków, a także sterowanie
automatyką przemysłową,
— sporządzanie dokumentacji z prowadzonych działań operacyjnych,
— generowanie analiz, raportów, zestawień i statystyk na podstawie wszystkich danych
wprowadzonych do systemu,
— korzystanie z usług danych przestrzennych, udostępnionych za pośrednictwem
Uniwersalnego Modułu Mapowego,
— wymianę informacji z Centrami Powiadamiania Ratunkowego za pośrednictwem
interfejsu komunikacyjnego,
— pozyskiwanie i prezentację danych dotyczących lokalizacji zakończenia sieci
telekomunikacyjnej, z których zostało wykonane połączenie do numeru alarmowego.
Zamawiający w swoich wymaganiach przyjął, że system między innymi obsługiwać ma:
— minimum 1000 równoczesnych użytkowników w przypadku obsługi zgłoszeń/zdarzeń,
— minimum 1000 równoczesnych użytkowników dla pozostałych funkcjonalności
systemu, z liczbą kont użytkowników szacowaną na 30000 sztuk.
System ten jest więc systemem krytycznym dla bezpieczeństwa kraju. Zamawiający
mając tego świadomość postawił ostre kryteria warunków udziału dotyczących zdolności
technicznej Wykonawcy, który zobowiązany jest wykazać się doświadczeniem polegającym
na stworzeniu ogólnokrajowego systemu klasy C2 (system o wzmocnionej kategorii
bezpieczeństwa izolujący użytkowników i dane) lub inny ogólnokrajowy system o wartości
min. 10 mln zł z łączną liczbą użytkowników na poziomie min. 30 tys. w tym min. 2 tys.
aktywnych użytkowników, jego dostawie wraz z montażem urządzeń i wykonaniu instalacji
wraz z wdrożeniem. Podobnie jest, jeśli chodzi o dysponowanie odpowiednim personelem.
Od Wykonawcy wymaga się by zapewnił rozbudowany zespół projektowy składający się
z zarówno z architektów systemu jak i inżynierów z zakresu wdrożenia systemów,
programowania, routingu i switchingu, bezpieczeństwa systemów informatycznych, data
center, kontroli jakości czy metody waterfall. Od wszystkich tych osób oczekuje się
odpowiednich certyfikatów oraz kilku lat doświadczenia przy podobnych projektach
wdrożeniowych.
Zakres i waga zadania znajduje odzwierciedlenie w przedmiocie Umowy. Zgodnie
z definicją § 1 pkt 35 Umowy System stanowi Oprogramowanie i Urządzenia dostosowane
do wymagań Umowy, w tym w szczególności do wymagań funkcjonalnych
i niefunkcjonalnych zdefiniowanych w załączniku nr 1 do Umowy, zainstalowane
i skonfigurowane na Infrastrukturze Technicznej i Infrastrukturze Zamawiającego w OK
i Lokalizacjach. System stanowi dzieło w rozumieniu przepisów kodeksu cywilnego, zaś pod
pojęciem Oprogramowanie zgodnie z § 1 pkt 24 Umowy rozumiemy całość lub dowolny
element oprogramowania dostarczanego lub wykonywanego w ramach realizacji Umowy.
W skład Oprogramowania wchodzi:
a) Standardowe Oprogramowanie Systemowe - oprogramowanie tworzące środowisko,
w którym uruchamiane jest Oprogramowanie, w tym oprogramowanie systemowe lub
bazodanowe,
b) Standardowe Oprogramowanie Aplikacyjne - oprogramowanie będące podstawą do
stworzenia Systemu, istniejące i dystrybuowane przed zawarciem Umowy,
c) Oprogramowanie Dedykowane - oprogramowanie tworzone na potrzeby Umowy,
w tym rozbudowa lub modyfikacja Standardowego Oprogramowania Aplikacyjnego. Jeżeli
dane Oprogramowanie nie zostało przypisane do Standardowego Oprogramowania
Systemowego lub Standardowego Oprogramowania Aplikacyjnego uważa się je za
Oprogramowanie Dedykowane,
d) Oprogramowanie Open Source - oprogramowanie dystrybuowane na warunkach tzw.
licencji otwartych.
Bezspornie zatem przedmiotem zamówienia jest skomplikowany, wymagający
specjalistycznej wiedzy, doświadczenia i sprawności organizacyjnej system informatyczny,
o szacowanym budżecie wykonawczym kontraktu ok. 16 mln zł. Jest to także system
autorski, przeznaczony do konkretnych zadań wykonywanych wyłącznie przez ściśle
określone podmioty publiczne, skutkiem czego nie jest dostępny w standardowej ofercie firm
informatycznych. Oznacza to, że trzeba go zaprojektować, zbudować i wdrożyć od podstaw,
co przy wielowątkowym i wielopłaszczyznowym charakterze zadania wymaga znacznego
nakładu pracy oraz zaangażowania dużych środków finansowych. Już sama analiza
postanowień Umowy świadczy o tym, że planowany System będzie zawierał środowisko
pracy, główne oprogramowanie (bazę/silnik) uzupełnioną o dedykowane moduły, a także
może składać się z komponentów na licencjach open source.
Zamawiający oczekuje, że System zostanie zbudowany na bazie Standardowego
Oprogramowania Aplikacyjnego (dalej SOA), które już istnieje i jest dystrybuowane, a więc
jest tzw. pudełkowym oprogramowaniem (COTS - commercial off - the - shelf). Zgodnie
z SIWZ by dostosować SOA jako oprogramowanie typu COTS do wytycznych, zostanie ono
zaadaptowane do specyfiki procedur biznesowych stosowanych przez Zamawiającego,
rozszerzone o brakujące w SOA funkcjonalności i warstwę integracyjną z systemami
znajdującymi się w otoczeniu systemu SWD. Analizując dokumentację techniczną gotowe
oprogramowanie SOA powinno posiadać konstrukcję modułową, która w połączeniu
z Oprogramowaniem Aplikacyjnym Dedykowanym umożliwi dostarczenie modułów aplikacji
realizujących wymagania Zamawiającego związane z następującymi grupami
funkcjonalności: Stanowisko kierowania, Informacje o zdarzeniach, Sztab, Odwody
operacyjne, Czasy operacyjne, Siły i środki, Wspomaganie decyzji, Moduł analityczno-
statystyczny, Ewidencja czasu służby i dane kadrowe oraz Moduł administrowania
systemem. Oprogramowanie oferowane przez Wykonawców jako SOA musi spełniać
powyższe założenia, tym samym istnieć już obecnie na zaawansowanych poziomie zarówno
jeśli chodzi o wewnętrzną architekturę, jak i strukturę samego kodu.
Założenia techniczne w ocenie Odwołującego są poprawne. Działanie polegające na
dostosowywaniu oprogramowania standardowego do potrzeb klienta, tzw. kastomizacja
oprogramowania, jest normalną praktyką rynkową w branży IT, znacząco przyspieszającą
i ograniczającą koszty wdrożenia nowych systemów informatycznych. Bezspornie koncepcja
bazy na gotowym oprogramowaniu COTS, które zostanie dostosowane do wymagań
Zamawiającego usprawni proces wdrożeniowy Systemu Wspomagania Decyzji Państwowej
Straży Pożarnej i jest pochodną faktu, że współczesne metasystemy to połączone struktury
wielu systemów operacyjnych, środowisk deweloperskich, systemów baz danych,
frameworków, aplikacji, bibliotek, komponentów i modułów. Z tym że w praktyce rynkowej
właściwie wszystkie wdrożeniowe kontrakty informatyczne zawierane w ramach zamówień
publicznych posługują się konstrukcją, w której do komponentów gotowych udziela się
licencji standardowych, zaś majątkowe prawa autorskie przenosi się jedynie do
dedykowanego oprogramowania. Konstruowanie w ten sposób zapisów umów z obszarze IT
wynika ze znajomości przez zamawiających specyfiki branży, gdyż strony umów
wdrożeniowych zdają sobie sprawę, że przeniesienie praw autorskich do oprogramowania
standardowego, nierzadko stanowiącego rezultat wieloletniej pracy firmy, będzie bardzo
kosztowe bądź wręcz niemożliwe.
O ile więc bez wątpienia Zamawiający mógł zgodnie z dobrą praktyką zaprojektować
System jako kompilacje oprogramowania gotowego i dedykowanego, to żądanie
udostępnienia kodów źródłowych do oprogramowania standardowego wraz z uprawnieniem
do wykonywania praw zależnych w ocenie Odwołującego narusza normy ustawy Pzp. Zarzut
opisania przedmiotu zamówienia w sposób, który utrudnia uczciwą konkurencję, narusza
równe traktowania wykonawców oraz zasady proporcjonalności i przejrzystości sprowadza
się do tego, że przy tak skonstruowanych postanowieniach prawnoautorskich oferta może
zostać złożona tylko przez producenta oprogramowania, który w dodatku zdecyduje się
udostępnić do niego kody źródłowe, a także zezwoli na dalszą swobodną dystrybucję
opracowań. Oznacza to, że Zamawiający przyznaje uprzywilejowaną pozycję producentom
oprogramowania z pokrzywdzeniem podmiotów, które dystrybuują i zapewniają opiekę
techniczną produktów w pełni zdolnych do wykonania założeń Umowy. Ponadto żądanie
przekazania kodów źródłowych i udzielnie zgody na wykonywania praw zależnych nie jest
także uzasadnione, ani przedmiotem zamówienia, ani w żaden sposób nie przystaje do
praktyki rynkowej.
Zgodnie z § 18 ust. 4 Umowy Licencja na Standardowe Oprogramowanie Aplikacyjne
obejmuje:
1) tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie jakichkolwiek
innych zmian w Standardowym Oprogramowaniu Aplikacyjnym;
2) zezwolenie na wykonywanie zależnych praw autorskich do wszelkich opracowań
Standardowego Oprogramowania Aplikacyjnego, to jest rozporządzanie i korzystanie
z takich opracowań w zakresie wszystkich uprawnień nabytych przez Zamawiającego
stosownie do postanowień niniejszego paragrafu.
Uzupełnia to § 20 Umowy:
12. Ilekroć zgodnie z postanowieniami Umowy Zamawiający nabywa na jakiejkolwiek
podstawie prawnej uprawnienie do tłumaczenia, przystosowywania, zmiany układu lub
wprowadzania jakichkolwiek innych zmian do określonego Oprogramowania lub korzystania
i rozporządzania autorskimi prawami zależnymi do opracowań Oprogramowania,
Wykonawca dostarczy Zamawiającemu Oprogramowanie również w formie kodu
źródłowego.
13. Kod źródłowy, o którym mowa w ust. 12, zostanie dostarczony na informatycznym
nośniku danych, w formie umożliwiającej Zamawiającemu swobodny odczyt kodu
źródłowego, a także zapisanie kodu na innym nośniku i doprowadzenie tego kodu
źródłowego do formy wykonywalnej, w szczególności w drodze kompilacji, na odpowiednio
wyposażonym stanowisku komputerowym. Wraz z kodem źródłowym Wykonawca dostarczy
kompletny wykaz narzędzi programistycznych, bibliotek i innych elementów niezbędnych do
doprowadzenia takiego Oprogramowania do formy wykonywalnej. Wykonawca nie jest
uprawniony do stosowania jakichkolwiek technik lub ograniczeń, które uniemożliwiłyby lub
istotnie utrudniły Zamawiającemu odczyt lub zapisywanie kodu, w szczególności
szyfrowania.
14. Kod źródłowy zostanie przekazany Zamawiającemu wraz z danym
Oprogramowaniem, w każdym przypadku nie później niż na 10 Dni Roboczych przed datą
Odbioru.
Zatem Zamawiający żąda udzielenia na SOA licencji, która jednak będzie zezwalała
na modyfikacje standardowego oprogramowania i jej dalszą dystrybucję, a także
przekazania wszystkich kodów źródłowych. O takiej intencji Zamawiającego świadczy też
zapis § 21 Umowy: Ilekroć Umowa przewiduje udzielnie przez Wykonawcę, intencją Stron
jest zbliżenie takiego upoważnienia na korzystanie ze Standardowego Oprogramowania
Aplikacyjnego do umowy o charakterze jednorazowej transakcji podobnej do sprzedaży -
w związku z tym w zamian za uiszczoną opłatę licencyjną (stanowiącą w przypadku Umowy
element Wynagrodzenia) Zamawiający otrzymuje ciągłe, stałe i niewypowiadalne prawo do
korzystania z takiego Oprogramowania w zakresie określonym w Umowie.
Zamawiający konstruując Umowę posiłkował się dokumentem udostępnionym na
stronie Ministerstwa Cyfryzacji Umowa wdrożeniowa z usługami utrzymania. Wzorcowe
klauzule (opracowanie: Marcin Maruta, Bartłomiej Wachta, zespół kancelarii Maruta Wachta
sp. j.). Przedmiotowe opracowanie w odniesieniu do oprogramowania SOA zawiera kilka
opcji, różniących się znacznie podejściem do praw zależnych i kodów źródłowych.
Zamawiający wybrał najbardziej restrykcyjne rozwiązanie, stosując jedną z opcjonalnych
klauzul bezkrytycznie, zupełnie pomijając istotne uwagi i wytyczne. W komentarzu do klauzul
związanych ze Standardowym Oprogramowaniem Aplikacyjnym (Opracowanie: str. 75-76)
możemy wyczytać „Standardowe oprogramowanie aplikacyjne to oprogramowanie, które
oferowane jest na rynku jako standardowe rozwiązanie wykonawcy lub zewnętrznego
producenta takiego oprogramowania, będące podstawą do stworzenia systemu.
Oprogramowanie to jest kluczowym elementem systemu, a czasem jedynym przedmiotem
zamówienia. Nabycie praw majątkowych do takiego oprogramowania wiązałoby się z bardzo
dużymi kosztami lub wręcz byłoby niemożliwe. Jednocześnie w odniesieniu do
standardowego oprogramowania aplikacyjnego zazwyczaj są większe możliwości zmiany
warunków licencyjnych niż w odniesieniu do oprogramowania systemowego, z reguły też
zamawiający ma inne wymagania w stosunku do aplikacji (np. przewiduje konieczność jej
modyfikacji). Konieczne jest dokładne opisanie takich wymagań w SIWZ.
W proponowanych klauzulach zrezygnowano z podziału, pojawiającego się
w rekomendacjach, skupionego na tzw. oprogramowaniu standardowym wykonawcy. Taka
kategoria opisywała standardowe oprogramowania aplikacyjne, ale tylko takie, do którego
prawa miał wykonawca. W tej sytuacji wykonawca mógł swobodnie kształtować swoje
uprawnienia. Z punktu widzenia zamawiającego taki podział ma mniejsze uzasadnienie - dla
zamawiającego istotne jest, aby aplikacja, będąca podstawą systemu, była objęta warunkami
SIWZ. W przeciwnym razie może dojść do niepożądanej sytuacji, kiedy oprogramowanie
oferowane przez wykonawcę - polski podmiot - byłoby traktowane jako standardowe
oprogramowanie wykonawcy w rozumieniu rekomendacji (a więc np. z prawem do
modyfikacji), a funkcjonalnie równoważne oprogramowanie dostawcy zagranicznego - jako
oprogramowanie systemowe (narzędziowe) czy „oprogramowanie osób trzecich”, jak to
opisano w rekomendacjach. Co więcej, to samo oprogramowanie byłoby różnie traktowane w
zależności od tego, czy ofertę złożyłby jego producent, czy partner producenta - w tym
drugim przypadku ponownie byłoby kwalifikowane jako „ oprogramowanie osób trzecich ”
w rozumieniu rekomendacji.
Kluczową decyzją - w dużej mierze uzależnioną od charakteru oprogramowania - jest
ewentualne wymaganie uzyskania prawa modyfikacji kodu. Mimo że taka praktyka jest
często rekomendowana w celu uniknięcia uzależnienia od wykonawcy (tzw. vendor lock-in),
zależy ona od wielu uwarunkowań. W części przypadków żądanie takie nie będzie możliwe,
biorąc pod uwagę skalę projektu (kluczowi dostawcy oprogramowania nieujawniający kodu),
lub nie będzie miało uzasadnienia ze względu na architekturę aplikacji (np. takiej, która
dostarcza wbudowane narzędzia do konfiguracji i rozbudowy, bez możliwości i potrzeby
ingerencji w kod źródłowy lub w ogóle nie posiada kodu źródłowego jako takiego).
W niektórych przypadkach może też nie mieć uzasadnienia ze względu na specyfikę
rozwiązania i brak zasobów do ewentualnej modyfikacji po stronie zamawiającego
(specjalistyczne rozwiązania autorskie wymagające know-how znanego wyłącznie autorom).
Przy uwzględnieniu zastrzeżenia, że warunki OPZ nie mogą być uznane za
dyskryminacyjne, jeżeli będą z nich wynikały wymagania niemożliwe do spełnienia przez
danego wykonawcę, kwestia ta powinna być dokładnie zweryfikowana przez zamawiającego
na etapie przygotowania SIWZ.
Szczegółowe warunki licencji mogą być określone na dwa sposoby - po pierwsze,
przez odesłanie do standardowych warunków licencyjnych producenta standardowego
oprogramowania aplikacyjnego; po drugie, przez wskazanie warunków licencji na
standardowe oprogramowanie aplikacyjne wprost w umowie. W wariancie drugim warunki te
zapewniają z reguły szerszy i bardziej dostosowany do specyfiki zamawiającego zakres
licencji. Z tego powodu wariant ten jest rekomendowany, ale wymaga dokładnego opisania
w umowie. Wzorcowa klauzula jest dość szeroka i może wymagać korekty (np. co do liczby
stanowisk, jeżeli może mieć to wpływ na cenę).
Wśród postanowień opcjonalnych podano przykład postanowień zezwalających
zamawiającemu na modyfikację standardowego oprogramowania aplikacyjnego. Zwracamy
uwagę, że faktyczna możliwość wykonania modyfikacji uzależniona jest od dostępu
zamawiającego do kodu źródłowego. Dostęp zamawiającego do kodu źródłowego powinien
zostać zapewniony na podstawie odrębnych postanowień umowy.
Zaakcentowania wymaga zwłaszcza fragment komentarza do Opracowania, mówiący
o tym, Zamawiający na etapie przygotowywania zamówienia powinien dokładnie
zweryfikować czy zastosowanie restrykcyjnych warunków prawnoautorskich nie zamknie
drogi większości, jeżeli nie wszystkim Wykonawcom do złożenia ofert oraz, że warunki w
pewnych przypadkach mogą być uznane za dyskryminacyjne, jeżeli będą z nich wynikały
wymagania niemożliwe do spełnienia.
Odwołujący jako spółka grupy kapitałowej Hexagon dysponuje prawami autorskimi do
oprogramowania, które spełnia podobne zadania jak System w postępowaniu i które
z sukcesem zostało wdrożone w ponad 40 lokalizacjach, w tym w ponad 20 krajach Europy.
Odwołujący jest więc w stanie wykonać przedmiot zamówienia w oparciu o swoje know-how
oferując produkt typu COTS - I/CAD. Jednocześnie nie jest producentem I/CAD, stąd nie
może udostępnić kodów źródłowych ani zezwolić na wykonywanie praw zależnych.
Ponownie zaznaczono, że żądanie przekazania dostępu do kodów źródłowych
narusza konkurencję, albowiem SOA ma być rozwiązaniem pudełkowym typu COTS, a więc
na udostępnienie kodów źródłowych może zgodzić się wyłącznie producent takiego
oprogramowania - co stawia go w pozycji uprzywilejowanej w stosunku do wykonawcy nie
będącego takim producentem. Zamawiający decydując się bezkrytycznie na restrykcyjną
klauzulę prawnoautorską w stosunku do SOA przez pozornie poprawne rozwiązanie prawne
wyeliminował z zamówienia wszystkich nieproducentów (dystrybutorów i dostawców
oprogramowania), a także wszystkich producentów, dla których oprogramowanie SOA jest
produktem dedykowanym szczególnie chronionym ze względu na jego cenę i wartość dla
firmy. Zamawiający musiał mieć świadomość, że ze względu na stopień skomplikowania
Systemu, a tym stopień złożoności SOA nie da się użyć oprogramowania open source oraz,
że żadnej z mniejszych podmiotów rynkowych nie będzie w stanie wypełnić rozbudowanych
wszystkie oczekiwania funkcjonalne i merytoryczne Zamawiającego. Podobnie jako
kryterium dyskryminujące należy potraktować przekazanie uprawnień do wykonywania praw
zależnych, co będzie właściwie jest równoważne z utratą kontroli nad oprogramowaniem,
wykonanym w oparciu o gromadzony latami potencjał i doświadczenie, które jest zasadniczą
podstawą działalności firmy.
Aktualnie brzmienie praw autorskich do SOA oznacza, że na przekazanie kodów
źródłowych może zdecydować się jedynie podmiot, który ma małe doświadczenie, krótko
działała na rynku i ma produkt, który nie był przedmiotem wielokrotnych wdrożeń na
przestrzeni wielu lat, gdyż tacy wykonawcy nie będą ponosić ryzyka związanego
z wyzbyciem się kodów źródłowych do produktu, lub ryzyka z tym związane będą
wielokrotnie mniejsze, pomijalne z punktu widzenia korzyści jakie uzyskają ubiegając się
o zamówienie. Trzeba jednak podkreślić, że taki producent nie będzie w stanie spełnić
kryteriów związanych z wykazaniem doświadczenia i potencjału osobowego, a więc nie
będzie zainteresowany przedmiotowym przetargiem.
Podsumowując, w ocenie Odwołującego, postawione wymagania co do praw
autorskich SOA są nieracjonalne i rażąco zawyżają koszty realizacji zamówienia. Krąg
podmiotów mogących złożyć ofertę został zawężony, bez żadnych obiektywnych przesłanek,
jedynie do producentów. W realiach rynku polskiego automatycznie oznacza to skierowanie
przetargu do dwóch, może trzech firm. Wątpliwym jest jednak to, czy zdecydują się one na
wzięcie udziału w postępowaniu, gdyż praktyka rynkowa pokazuje, że każda firma
informatyczna o ustalonej renomie szczególnie chroni swoje prawa autorskie i nie decyduje
się na przekazanie kodów źródłowych do swojego oprogramowania standardowego.
Niezrozumiałym jest zatem podjęcie przez Zamawiającego decyzji o takim ukształtowaniu
postanowień prawnoautorskich do SOA, gdyż w sposób oczywisty ograniczają one
konkurencję i naruszają zasadę równego traktowania wykonawców. Przedmiotowe żądania
są nieuzasadnione także z uwagi na potencjalne potrzeby Zamawiającego, gdyż
Zamawiający nie ma ani wiedzy ani potencjału osobowego, by dokonywać samodzielnym
zmian w kodach źródłowych, musi więc wspierać się zewnętrznym podmiotem, który otrzyma
nieautoryzowany dostęp do oprogramowania istotnego ze względu na bezpieczeństwo kraju.
Zmiany w kodzie źródłowym oprogramowania SOA będą wymagać wiedzy programistycznej
jak jest zbudowany dany kod, dostępu do środowiska deweloperskiego i odpowiednich
certyfikatów. Zamawiający nie wyjaśnił zresztą dlaczego oczekuje dostępu do kodów
źródłowych SOA, skoro nawet w trakcie wdrożenia Systemu modyfikacje będą dokonywane
poprzez tworzenie komponentów traktowanych jako Oprogramowanie Dedykowane, bez
ingerencji w SOA. Po wdrożeniu takie oprogramowanie jakie oferowałby Odwołujący jako
SOA, co jest zresztą standardem rynkowym, ma wbudowane odpowiednie narzędzia tzw.
API, które nie wymagają znajomości całego kodu źródłowego oprogramowania a pozwalają
na dostosowanie oprogramowania do nowych funkcjonalności. Tym samym Zamawiający nie
zastosował się do zasad Ustawy Pzp w zakresie zasad proporcjonalności i przejrzystości
oczekując dostarczenia rozwiązań i uprawnień, które właściwie uniemożliwiają złożenie
oferty w tym przetargu większości firm informatycznym.
Reasumując - prawidłowe, nieograniczające konkurencji żądanie od Wykonawcy
przekazania Zamawiającemu kodów źródłowych winno być ograniczone do Oprogramowania
Dedykowanego, wykonanego na potrzeby tego zamówienia.
Przepis art. 29 ust. 1 Pzp zobowiązuje Zamawiającego do opisania przedmiotu
zamówienia w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych
i zrozumiałych informacji, uwzględniając wszystkie wymagania i okoliczności mogące mieć
wpływ na sporządzenie oferty. Istota tego przepisu sprowadza się więc do określenia przez
zamawiającego wymagań dotyczących przedmiotu zamówienia w taki sposób, aby każdy
wykonawca był w stanie zidentyfikować czego zamawiający oczekuje oraz móc przygotować
prawidłowo oszacowaną ofertę. Nadto Zamawiający nie może opisywać przedmiotu
zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję, lub chociaż potencjalnie
zagrozić uczciwej konkurencji. Zatem bezwzględnym obowiązkiem Zamawiającego jest taki
opis przedmiotu zamówienia, który prowadzi do złożenia ofert porównywalnych,
obejmujących rozwiązania lub produkty spełniające identyczne wymagania techniczne
i jakościowe z uwzględnieniem wszystkich elementów niezbędnych do prawidłowego
skalkulowania oferty przez wykonawcę. Jednocześnie, zgodnie z art. 7 Pzp treść
sformułowanych wymagań musi zachować równowagę stron.
Na istotne znaczenie zasady uczciwej konkurencji oraz jej realizacji poprzez
dokonanie opisu przedmiotu zamówienia z uwzględnieniem zachowania równości
wykonawców, proporcjonalności i przejrzystości wskazuje bogate orzecznictwo sądów
i Krajowej Izby Odwoławczej. Krajowa Izba Odwoławcza wielokrotnie podkreślała, iż zbytnie
dookreślenie wymagań przedmiotu zamówienia, w sposób który nie znajduje uzasadnienia
w potrzebach Zamawiającego jest dokonaniem opisu przedmiotu zamówienia z naruszeniem
zasady uczciwej konkurencji.
W świetle powyższego, sformułowanie przez Zamawiającego warunku konieczności
przekazania kodów źródłowych do SOA oraz udzielenie zgody na realizowanie do niego
praw zależnych nie znajduje odzwierciedlenia w obiektywnych potrzebach i interesach
Zamawiającego i jest zapisem ograniczającym konkurencję w przedmiotowym postępowaniu
wskutek czego został naruszony art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2 Ustawy Pzp.
W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu dokonania
zmiany treści Załącznikiem nr 2 do SIWZ Projekt umowy poprzez usunięcie treści § 18 ust. 4
Umowy w brzmieniu „Licencja na Standardowe Oprogramowanie Aplikacyjne obejmuje:
1) tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie jakichkolwiek
innych zmian w Standardowym Oprogramowaniu Aplikacyjnym;
2) zezwolenie na wykonywanie zależnych praw autorskich do wszelkich opracowań
Standardowego Oprogramowania Aplikacyjnego, to jest rozporządzanie i korzystanie
z takich opracowań w zakresie wszystkich uprawnień nabytych przez Zamawiającego
stosownie do postanowień niniejszego paragrafu ”
oraz § 18 ust 5. „Tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie
jakichkolwiek innych zmian w Standardowym Oprogramowaniu Aplikacyjnym może być
dokonane przez Zamawiającego lub osobę trzecią działającą na jego rzecz”.
a także dodanie do § 20 ust 12 Umowy w brzmieniu „Ilekroć zgodnie z postanowieniami
Umowy Zamawiający nabywa na jakiejkolwiek podstawie prawnej uprawnienie do
tłumaczenia, przystosowywania, zmiany układu lub wprowadzania jakichkolwiek innych
zmian do określonego Oprogramowania lub korzystania i rozporządzania autorskimi prawami
zależnymi do opracowań Oprogramowania, Wykonawca dostarczy Zamawiającemu
Oprogramowanie również w formie kodu źródłowego zdania „ W celu uniknięcia wątpliwości
obowiązek dostarczenia kodu źródłowego nie obejmuje Standardowego Oprogramowania
Aplikacyjnego”.
Na podstawie dokumentacji przedmiotowego postępowania oraz biorąc pod
uwagę stanowiska Stron i Uczestnika postępowania odwoławczego, Izba ustaliła i
zważyła, co następuje:
Skład orzekający Izby ustalił że nie została wypełniona żadna z przesłanek
skutkujących odrzuceniem odwołania na podstawie art. 189 ust. 2 ustawy Pzp,
a Wykonawca wnoszący odwołanie posiadał interes w rozumieniu art. 179 ust. 1 Pzp,
uprawniający do jego złożenia. Należy bowiem wskazać, że środki ochrony prawnej
określone w ustawie Pzp przysługują wykonawcy, uczestnikowi konkursu, a także innemu
podmiotowi, jeżeli ma lub miał interes w uzyskaniu danego zamówienia oraz poniósł lub
może ponieść szkodę w wyniku naruszenia przez zamawiającego przepisów ustawy. Na
etapie postępowania o udzielenie zamówienia przed otwarciem ofert, np. w przypadku
odwołań czy skarg dotyczących postanowień ogłoszenia i SIWZ przyjąć należy, iż każdy
wykonawca deklarujący zainteresowanie uzyskaniem danego zamówienia posiada
jednocześnie interes w jego uzyskaniu, a szkodą jest niemożliwość złożenia oferty
i podpisania ważnej umowy (za wyrokiem KIO z dnia 04.10.2010 r., sygn. akt KIO 2036/10).
Wykonawca jest zdolny do wykonania zamówienia, deklaruje zainteresowanie
postępowaniem, ma więc szanse na uzyskanie zamówienia, natomiast sposób
ukształtowania zapisów SIWZ, w tym opisu przedmiotu zamówienia i przyszłych warunków
wykonywania umowy przekłada się na sytuację Wykonawcy w postępowaniu i możliwość
złożenia konkurencyjnej oferty.
Izba ustaliła, że w przedmiotowej sprawie do postępowania odwoławczego zgłoszenie
przystąpienia po stronie zamawiającego złożył wykonawca S&T Services Polska Sp. z o.o.
z siedzibą w Warszawie. Przystąpienie uznano za skuteczne.
Zamawiający złożył pisemną odpowiedź na odwołanie, w której wnosił o oddalenie
odwołania w całości.
Odwołujący w odwołaniu prawidłowo przytoczył zapisy SIWZ i warunków umownych
mające znaczenie dla rozstrzygnięcia przedmiotu sporu.
Biorąc powyższe ustalenia pod uwagę, Izba uznała, że odwołanie nie mogło zostać
uwzględnione, bowiem Odwołujący nie wykazał przede wszystkim, iż działania
Zamawiającego są niezgodne z przepisami ustawy Pzp oraz ustawy Prawo autorskie.
Z uwag natury ogólnej dostrzeżenia wymaga w ślad za orzecznictwem, że: "(…)
zasada wyrażona w przepisie art. 7 Pzp nie może być interpretowana w taki sposób, że
wymaga dopuszczenia wszystkich zainteresowanych zamówieniem a wybór produktu, który
należy zaoferować w ramach danego zamówienia, pozostawiony jest wykonawcom" (tak
wyrok KIO z 22.03.2012 r., sygn. akt: KIO 471/12). Zaś: "Obowiązek przestrzegania reguł
określonych w art. 29 ust. 1 i 2 Pzp nie oznacza, że zamawiający nie ma prawa określić
przedmiotu zamówienia w sposób uwzględniający jego potrzeby i aby uzyskać oczekiwany
efekt, nawet jeśli wyklucza to możliwość dopuszczenia do realizacji zamówienia wszystkich
wykonawców działających na rynku. Prawem zamawiającego jest takie opisanie przedmiotu
zamówienia, którego realizacja zaspokoi w najszerszym kontekście określone potrzeby
społeczne" (tak wyrok KIO z 28.03.2014 r., sygn. akt: KIO 486/14). Niewątpliwie granicę
dozwolonych działań Zamawiającego w zakresie opisu przedmiotu zamówienia oraz
przyszłych postanowień kontraktowych stanowią wspomniane wyżej zasady uczciwej
konkurencji oraz równego traktowania wykonawców.
Zasada równego traktowania sprowadza się do konieczności identycznego
traktowania takich wykonawców, których sytuacja jest taka sama lub bardzo podobna, nie
oznacza to natomiast konieczności identycznego traktowania wszystkich wykonawców
znajdujących się na rynku lub aspirujących do wejścia na rynek. Opis przedmiotu
zamówienia nie może preferować jedynie niektórych podmiotów. Wszyscy wykonawcy
powinni mieć zapewniony równy dostęp do istotnych dla postępowania informacji
w jednakowym czasie, dokonywanie oceny warunków oraz ofert powinno następować wedle
wcześniej sprecyzowanych i znanych wykonawcom kryteriów, na podstawie przedłożonych
dokumentów, a nie wiedzy zamawiającego. W ocenie Izby nie oznacza to jednak, że
zamawiający tylko wówczas działa w granicach uczciwej konkurencji oraz z zachowaniem
wymogu proporcjonalności przy opisie przedmiotu zamówienia, gdy jego działania pozwalają
na uczestnictwo w postępowaniu o udzielenie zamówienia publicznego wszystkim
podmiotom występującym na rynku. Jeżeli zatem zamawiający, określając warunki udziału
w postępowaniu, w tym warunki kontraktowe, nie czyni tego w sposób, który wskazuje na
konkretny produkt lub wykonawcę, nie można uznać, iż narusza zasady uczciwej konkurencji
poprzez odniesienie się do przedmiotu zamówienia. Nie jest obowiązkiem Zamawiającego
uwzględnianie doświadczenia zawodowego i polityki prowadzenia działalności komercyjnej
wszystkich podmiotów działających na rynku ale uwzględnienie wymagań gwarantującej
sprawne wykonanie danej usługi, co pozwoli na stworzenie sprawnie działającego systemu,
istotnego z punktu widzenia bezpieczeństwa państwa.
Nie można również zapominać, że obowiązkiem Zamawiającego jest uwzględnienie
jego potrzeb związanych z należytą realizacją zamówienia, które w obiektywny sposób
doprowadzą do wyboru wykonawcy gwarantującego należyte wykonanie zamówienia. Tezy,
iż nie jest możliwe zaoferowanie takiego oprogramowania, gdzie w ramach realizacji
wykonawca nie będzie mógł udzielić Zamawiającemu licencji na wykorzystanie kodów
źródłowych w określonych polach eksploatacji Odwołujący nie udowodnił. Dla Izby znaczący
jest również fakt, iż jak twierdzi sam Odwołujący, postępowanie skierowane jest do dużych
podmiotów działających na rynku IT, jednak żaden z podmiotów nie przystąpił po stronie
Odwołującego do sporu. Jak wynika również z ustaleń Zamawiającego, na ponad 600
zadanych w postępowaniu pytań, żadne nie odnosiło się do kwestii związanych z prawami
autorskimi i niemożliwością udzielenia licencji na wykorzystanie kodów źródłowych.
Przechodząc do wspominanej przez Odwołującego zasady proporcjonalności,
dostrzeżenia wymaga, iż w wyroku z dnia 6 grudnia 2016 r. (sygn. akt KIO 2180/16) Izba
odwołała się do orzecznictwa TSUE wskazując, że proporcjonalność polega na określeniu
przez zamawiającego wyłącznie takich wymagań, które są konieczne do osiągnięcia
zakładanego celu. Wyrażono również pogląd w zakresie rozkładu ciężaru dowodu przy tak
rozumianej zasadzie proporcjonalności. Izba uznała, że to od odwołującego się wykonawcy
należy oczekiwać argumentacji wskazującej, że postawione przez zamawiającego
wymagania są oderwane od zasadniczego celu prowadzenia postępowania i w konsekwencji
realizacji zamierzenia inwestycyjnego, stanowiącego jego przedmiot, jak również że nie są
one konieczne do osiągnięcia zakładanych celów lub pozostają z nimi w wyraźnej
dysproporcji. Takiej argumentacji Odwołujący w ocenie składu orzekającego Izby nie
przedstawił. Niezmiennie, zarówno w odwołaniu, jak też na rozprawie, Odwołujący
wskazywał na praktykę własnej firmy, odwoływał się do specyfiki swoich relacji między
producentem oprogramowania o jego dystrybutorem. Zamawiający podkreślał, iż jego celem
jest zbudowanie systemu, którym w przyszłości swobodnie, bez uzależnienia od monopolu
jednego wykonawcy będzie mógł dysponować, dokonywać jego modyfikacji, ulepszeń.
Odwołujący nie podał w jaki sposób cel ten może być osiągnięty przy przyjęciu założeń
strony odwołującej.
Nie można nie dostrzec, iż Odwołujący w odwołaniu koncentruje się na dowodzeniu,
że przeniesienie praw autorskich do oprogramowania standardowego będzie bardzo
kosztowne bądź wręcz niemożliwe. Tym samym Odwołujący nieproporcjonalności upatruje w
okoliczności, iż nie będzie mógł złożyć konkurencyjnej cenowo oferty, ponieważ nie jest
producentem oprogramowania, które chce zaoferować. Dowodzi to, iż Zamawiający swym
postępowaniem nie narusza przepisów ustawy Pzp wymienionych w odwołaniu, samo zaś
ustalenie warunków kontraktowych na wysokim poziomie wymagań nie stanowi jeszcze
przekroczenia uprawnień strony zamawiającej. Poza tym zauważyć należy, iż Zamawiający
wymaga jedynie udzielenia licencji o rozszerzonym charakterze, nie zaś przeniesienia
autorskich praw majątkowych do oprogramowania. Słusznie zauważył Przystępujący, iż
udzielenie licencji na określonych polach eksploatacji nie spowoduje uszczuplenia
przysługujących wykonawcy majątkowych praw autorskich. Poza tym Zamawiający nie
będzie mógł posiadanymi kodami źródłowymi swobodnie obracać i udostępniać je osobom
trzecim, ale będzie mógł używać ich zgodnie z przeznaczeniem w ściśle określonych
sytuacjach. Zdaniem Izby Zamawiający dąży jedynie do zapewnienia sobie możliwości
dalszej eksploatacji i rozwoju zakupionego sytemu przy możliwości stosowania postępowań o
charakterze konkurencyjnym.
Z zakwestionowanych przez Odwołującego postanowień umownych nie wynika, aby
wskazane w odwołaniu przepisu ustawy Pzp zostały naruszone. Co do zaś dodatkowego
stanowiska pisemnego Odwołującego, złożonego na rozprawie, to stosowanie do art. 192 ust
7 ustawy Pzp, Izba przy orzekaniu związana jest zarzutami odwołania. Stanowisko to
natomiast zawiera w ocenie Izby dodatkowe zarzuty, nie wymienione w odwołaniu,
odnoszące się do innych nieprawidłowości w opisie przedmiotu zamówienia, czy też
preferowaniu przez ten opis konkretnych producentów. Takie kwestie nie były w ustawowym
terminie 10 dni od zamieszczenia ogłoszenia i SIWZ poruszone, więc Izba pozostawiła je bez
rozpoznania.
O kosztach postępowania odwoławczego orzeczono stosownie do jego wyniku,
na podstawie art. 192 ust. 9 i 10 ustawy Pzp oraz w oparciu o przepisy § 5 ust. 3 pkt 1) oraz
ust. 4 w zw. z § 3 pkt 2) rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r.
w sprawie wysokości i sposobu pobierania wpisu od odwołania oraz rodzajów kosztów
w postępowaniu odwoławczym i sposobu ich rozliczania (Dz. U. Nr 41, poz. 238 ze
zmianami) obciążając nimi Odwołującego.
Przewodniczący:
WYROK
z dnia 7 czerwca 2017 roku
Krajowa Izba Odwoławcza - w składzie:
Przewodniczący: Justyna Tomkowska
Protokolant: Adam Skowroński
po rozpoznaniu na rozprawie w dniu 7 czerwca 2017 roku w Warszawie odwołania
wniesionego do Prezesa Krajowej Izby Odwoławczej w dniu 26 maja 2017 roku przez
Odwołującego – INTERGRAPH Polska Sp. z o.o. z siedzibą w Warszawie,
w postępowaniu prowadzonym przez Zamawiającego – Skarb Państwa, Komendanta
Głównego Państwowej Straży Pożarnej z siedzibą w Warszawie
przy udziale wykonawcy ubiegającego się o udzielenie zamówienia S&T Services Polska
Sp. z o.o. z siedzibą w Warszawie zgłaszającego przystąpienie do postępowania
odwoławczego po stronie zamawiającego
orzeka:
1. oddala odwołanie,
2. kosztami postępowania obciąża Odwołującego i:
2.1. zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000,00 zł
(słownie: piętnastu tysięcy złotych 00/100) uiszczoną przez Odwołującego INTERGRAPH
Polska Sp. z o.o. z siedzibą w Warszawie tytułem wpisu od odwołania
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. Prawo zamówień
publicznych (Dz.U.2015.2164 j.t. ze zm.) na niniejszy wyrok – w terminie 7 dni od dnia jego
doręczenia – przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do
Sądu Okręgowego w Warszawie
Przewodniczący:
sygn. akt KIO 1043/17
UZASADNIENIE
W dniu 26 maja 2017 roku do Prezesa Krajowej Izby Odwoławczej w Warszawie, na
podstawie art. 179 ust. 1 i art. 180 ust. 1, a także art. 182 ust. 2 pkt 1 ustawy z dnia 29
stycznia 2004 roku - Prawo zamówień publicznych (t.j. Dz. U. z 2015 r., poz. 2164 ze zm.),
zwanej dalej „ustawą Pzp”, odwołanie złożył wykonawca Intergraph Polska Sp. z o.o.
z siedzibą w Warszawie, zwany dalej „Odwołującym”.
Postępowanie o udzielenie zamówienia publicznego w trybie przetargu
nieograniczonego „Budowa Systemu Wspomagania Decyzji Państwowej Straży Pożarnej”
prowadzi Zamawiający: Skarb Państwa - Komendant Główny Państwowej Straży
Pożarnej z siedzibą w Warszawie. Ogłoszenie o zamówieniu zostało opublikowane
w Dzienniku Urzędowym Unii Europejskiej w dniu 16 maja 2017 r., pod numerem 2017/S
093-182525.
Odwołanie wniesiono wobec treści ogłoszenia o zamówieniu oraz Specyfikacji
Istotnych Warunków Zamówienia (dalej SIWZ) wraz z załącznikami, w tym Załącznikiem nr 2
Projekt umowy, zarzucając Zamawiającemu naruszenie art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2
ustawy Pzp poprzez opisanie przedmiotu zamówienia w sposób, który utrudnia
przestrzeganie zasad uczciwej konkurencji i równego traktowania wykonawców oraz bez
zachowania zasad proporcjonalności i przejrzystości, na skutek wprowadzenia przez
Zamawiającego żądań udostępnienia kodów źródłowych do oprogramowania
standardowego, a także wyrażenia zgody na wykonywanie praw zależnych do
oprogramowania standardowego, które to kryteria znacząco i bezzasadnie zawężając krąg
Wykonawców zdolnych do złożenie ofert w przetargu.
Odwołujący wnosił o nakazanie Zamawiającemu modyfikacji treści ogłoszenia
o zamówieniu oraz SIWZ poprzez doprowadzenie jej postanowień do zgodności z ustawą
Pzp, w szczególności poprzez zmianę treści ogłoszenia o zamówieniu oraz SIWZ w sposób
opisany w uzasadnieniu odwołania.
Odwołujący wskazała, iż posiada interes w uzyskaniu zamówienia, a także w złożeniu
odwołania, bowiem zamierza ubiegać się o udzielenie zamówienia. Postanowienia
ogłoszenia o zamówieniu oraz SIWZ uniemożliwiają mu złożenie oferty. W konsekwencji,
Odwołujący się może ponieść szkodę wynikającą z braku możliwości uzyskania zamówienia,
a w konsekwencji tego narażony jest on na szkodę w postaci utraty zysku, który mógłby
osiągnąć w wypadku wyboru jego oferty, jako oferty najkorzystniejszej.
Odwołanie zostało wniesione z zachowaniem ustawowego terminu przewidzianego
w art. 182 ust. 1 pkt 1 ustawy Pzp. Kopia odwołania została przekazana Zamawiającemu.
Odwołujący uiścił wpis w wymaganej wysokości na rachunek UZP.
W uzasadnieniu zauważono, że przedmiotem zamówienia jest wykonanie i wdrożenie
Systemu Wspomagania Decyzji Państwowej Straży Pożarnej wspierającego:
— wykonywanie zadań krajowego systemu ratowniczo-gaśniczego przez wszystkie
jednostki organizacyjne Państwowej Straży Pożarnej,
— przyjmowanie zgłoszeń i rejestrację zdarzeń,
— alarmowanie i powiadamianie sił i środków,
— dysponowanie siłami i środkami,
— nadzorowanie i koordynację działań podczas zdarzeń,
— wymianę informacji i danych między wszystkimi jednostkami organizacyjnymi
Państwowej Straży Pożarnej oraz innymi partnerami,
— prowadzenie ewidencji podmiotów, sił i środków Państwowej Straży Pożarnej,
Ochotniczej Straży Pożarnej, Zakładowych Straży Pożarnych i Zakładowych Służb
Ratowniczych, oraz innych jednostek i podmiotów współpracujących,
— ewidencjonowanie dostępnych dla Państwowej Straży Pożarnej sił i środków innych
zasobów pochodzących z instytucji i organizacji współpracujących z Państwową Strażą
Pożarną,
— współpracę z urządzeniami łączności oraz urządzeniami umożliwiającymi śledzenie
pojazdów, nadzór, alarmowanie i powiadamianie sił i środków, a także sterowanie
automatyką przemysłową,
— sporządzanie dokumentacji z prowadzonych działań operacyjnych,
— generowanie analiz, raportów, zestawień i statystyk na podstawie wszystkich danych
wprowadzonych do systemu,
— korzystanie z usług danych przestrzennych, udostępnionych za pośrednictwem
Uniwersalnego Modułu Mapowego,
— wymianę informacji z Centrami Powiadamiania Ratunkowego za pośrednictwem
interfejsu komunikacyjnego,
— pozyskiwanie i prezentację danych dotyczących lokalizacji zakończenia sieci
telekomunikacyjnej, z których zostało wykonane połączenie do numeru alarmowego.
Zamawiający w swoich wymaganiach przyjął, że system między innymi obsługiwać ma:
— minimum 1000 równoczesnych użytkowników w przypadku obsługi zgłoszeń/zdarzeń,
— minimum 1000 równoczesnych użytkowników dla pozostałych funkcjonalności
systemu, z liczbą kont użytkowników szacowaną na 30000 sztuk.
System ten jest więc systemem krytycznym dla bezpieczeństwa kraju. Zamawiający
mając tego świadomość postawił ostre kryteria warunków udziału dotyczących zdolności
technicznej Wykonawcy, który zobowiązany jest wykazać się doświadczeniem polegającym
na stworzeniu ogólnokrajowego systemu klasy C2 (system o wzmocnionej kategorii
bezpieczeństwa izolujący użytkowników i dane) lub inny ogólnokrajowy system o wartości
min. 10 mln zł z łączną liczbą użytkowników na poziomie min. 30 tys. w tym min. 2 tys.
aktywnych użytkowników, jego dostawie wraz z montażem urządzeń i wykonaniu instalacji
wraz z wdrożeniem. Podobnie jest, jeśli chodzi o dysponowanie odpowiednim personelem.
Od Wykonawcy wymaga się by zapewnił rozbudowany zespół projektowy składający się
z zarówno z architektów systemu jak i inżynierów z zakresu wdrożenia systemów,
programowania, routingu i switchingu, bezpieczeństwa systemów informatycznych, data
center, kontroli jakości czy metody waterfall. Od wszystkich tych osób oczekuje się
odpowiednich certyfikatów oraz kilku lat doświadczenia przy podobnych projektach
wdrożeniowych.
Zakres i waga zadania znajduje odzwierciedlenie w przedmiocie Umowy. Zgodnie
z definicją § 1 pkt 35 Umowy System stanowi Oprogramowanie i Urządzenia dostosowane
do wymagań Umowy, w tym w szczególności do wymagań funkcjonalnych
i niefunkcjonalnych zdefiniowanych w załączniku nr 1 do Umowy, zainstalowane
i skonfigurowane na Infrastrukturze Technicznej i Infrastrukturze Zamawiającego w OK
i Lokalizacjach. System stanowi dzieło w rozumieniu przepisów kodeksu cywilnego, zaś pod
pojęciem Oprogramowanie zgodnie z § 1 pkt 24 Umowy rozumiemy całość lub dowolny
element oprogramowania dostarczanego lub wykonywanego w ramach realizacji Umowy.
W skład Oprogramowania wchodzi:
a) Standardowe Oprogramowanie Systemowe - oprogramowanie tworzące środowisko,
w którym uruchamiane jest Oprogramowanie, w tym oprogramowanie systemowe lub
bazodanowe,
b) Standardowe Oprogramowanie Aplikacyjne - oprogramowanie będące podstawą do
stworzenia Systemu, istniejące i dystrybuowane przed zawarciem Umowy,
c) Oprogramowanie Dedykowane - oprogramowanie tworzone na potrzeby Umowy,
w tym rozbudowa lub modyfikacja Standardowego Oprogramowania Aplikacyjnego. Jeżeli
dane Oprogramowanie nie zostało przypisane do Standardowego Oprogramowania
Systemowego lub Standardowego Oprogramowania Aplikacyjnego uważa się je za
Oprogramowanie Dedykowane,
d) Oprogramowanie Open Source - oprogramowanie dystrybuowane na warunkach tzw.
licencji otwartych.
Bezspornie zatem przedmiotem zamówienia jest skomplikowany, wymagający
specjalistycznej wiedzy, doświadczenia i sprawności organizacyjnej system informatyczny,
o szacowanym budżecie wykonawczym kontraktu ok. 16 mln zł. Jest to także system
autorski, przeznaczony do konkretnych zadań wykonywanych wyłącznie przez ściśle
określone podmioty publiczne, skutkiem czego nie jest dostępny w standardowej ofercie firm
informatycznych. Oznacza to, że trzeba go zaprojektować, zbudować i wdrożyć od podstaw,
co przy wielowątkowym i wielopłaszczyznowym charakterze zadania wymaga znacznego
nakładu pracy oraz zaangażowania dużych środków finansowych. Już sama analiza
postanowień Umowy świadczy o tym, że planowany System będzie zawierał środowisko
pracy, główne oprogramowanie (bazę/silnik) uzupełnioną o dedykowane moduły, a także
może składać się z komponentów na licencjach open source.
Zamawiający oczekuje, że System zostanie zbudowany na bazie Standardowego
Oprogramowania Aplikacyjnego (dalej SOA), które już istnieje i jest dystrybuowane, a więc
jest tzw. pudełkowym oprogramowaniem (COTS - commercial off - the - shelf). Zgodnie
z SIWZ by dostosować SOA jako oprogramowanie typu COTS do wytycznych, zostanie ono
zaadaptowane do specyfiki procedur biznesowych stosowanych przez Zamawiającego,
rozszerzone o brakujące w SOA funkcjonalności i warstwę integracyjną z systemami
znajdującymi się w otoczeniu systemu SWD. Analizując dokumentację techniczną gotowe
oprogramowanie SOA powinno posiadać konstrukcję modułową, która w połączeniu
z Oprogramowaniem Aplikacyjnym Dedykowanym umożliwi dostarczenie modułów aplikacji
realizujących wymagania Zamawiającego związane z następującymi grupami
funkcjonalności: Stanowisko kierowania, Informacje o zdarzeniach, Sztab, Odwody
operacyjne, Czasy operacyjne, Siły i środki, Wspomaganie decyzji, Moduł analityczno-
statystyczny, Ewidencja czasu służby i dane kadrowe oraz Moduł administrowania
systemem. Oprogramowanie oferowane przez Wykonawców jako SOA musi spełniać
powyższe założenia, tym samym istnieć już obecnie na zaawansowanych poziomie zarówno
jeśli chodzi o wewnętrzną architekturę, jak i strukturę samego kodu.
Założenia techniczne w ocenie Odwołującego są poprawne. Działanie polegające na
dostosowywaniu oprogramowania standardowego do potrzeb klienta, tzw. kastomizacja
oprogramowania, jest normalną praktyką rynkową w branży IT, znacząco przyspieszającą
i ograniczającą koszty wdrożenia nowych systemów informatycznych. Bezspornie koncepcja
bazy na gotowym oprogramowaniu COTS, które zostanie dostosowane do wymagań
Zamawiającego usprawni proces wdrożeniowy Systemu Wspomagania Decyzji Państwowej
Straży Pożarnej i jest pochodną faktu, że współczesne metasystemy to połączone struktury
wielu systemów operacyjnych, środowisk deweloperskich, systemów baz danych,
frameworków, aplikacji, bibliotek, komponentów i modułów. Z tym że w praktyce rynkowej
właściwie wszystkie wdrożeniowe kontrakty informatyczne zawierane w ramach zamówień
publicznych posługują się konstrukcją, w której do komponentów gotowych udziela się
licencji standardowych, zaś majątkowe prawa autorskie przenosi się jedynie do
dedykowanego oprogramowania. Konstruowanie w ten sposób zapisów umów z obszarze IT
wynika ze znajomości przez zamawiających specyfiki branży, gdyż strony umów
wdrożeniowych zdają sobie sprawę, że przeniesienie praw autorskich do oprogramowania
standardowego, nierzadko stanowiącego rezultat wieloletniej pracy firmy, będzie bardzo
kosztowe bądź wręcz niemożliwe.
O ile więc bez wątpienia Zamawiający mógł zgodnie z dobrą praktyką zaprojektować
System jako kompilacje oprogramowania gotowego i dedykowanego, to żądanie
udostępnienia kodów źródłowych do oprogramowania standardowego wraz z uprawnieniem
do wykonywania praw zależnych w ocenie Odwołującego narusza normy ustawy Pzp. Zarzut
opisania przedmiotu zamówienia w sposób, który utrudnia uczciwą konkurencję, narusza
równe traktowania wykonawców oraz zasady proporcjonalności i przejrzystości sprowadza
się do tego, że przy tak skonstruowanych postanowieniach prawnoautorskich oferta może
zostać złożona tylko przez producenta oprogramowania, który w dodatku zdecyduje się
udostępnić do niego kody źródłowe, a także zezwoli na dalszą swobodną dystrybucję
opracowań. Oznacza to, że Zamawiający przyznaje uprzywilejowaną pozycję producentom
oprogramowania z pokrzywdzeniem podmiotów, które dystrybuują i zapewniają opiekę
techniczną produktów w pełni zdolnych do wykonania założeń Umowy. Ponadto żądanie
przekazania kodów źródłowych i udzielnie zgody na wykonywania praw zależnych nie jest
także uzasadnione, ani przedmiotem zamówienia, ani w żaden sposób nie przystaje do
praktyki rynkowej.
Zgodnie z § 18 ust. 4 Umowy Licencja na Standardowe Oprogramowanie Aplikacyjne
obejmuje:
1) tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie jakichkolwiek
innych zmian w Standardowym Oprogramowaniu Aplikacyjnym;
2) zezwolenie na wykonywanie zależnych praw autorskich do wszelkich opracowań
Standardowego Oprogramowania Aplikacyjnego, to jest rozporządzanie i korzystanie
z takich opracowań w zakresie wszystkich uprawnień nabytych przez Zamawiającego
stosownie do postanowień niniejszego paragrafu.
Uzupełnia to § 20 Umowy:
12. Ilekroć zgodnie z postanowieniami Umowy Zamawiający nabywa na jakiejkolwiek
podstawie prawnej uprawnienie do tłumaczenia, przystosowywania, zmiany układu lub
wprowadzania jakichkolwiek innych zmian do określonego Oprogramowania lub korzystania
i rozporządzania autorskimi prawami zależnymi do opracowań Oprogramowania,
Wykonawca dostarczy Zamawiającemu Oprogramowanie również w formie kodu
źródłowego.
13. Kod źródłowy, o którym mowa w ust. 12, zostanie dostarczony na informatycznym
nośniku danych, w formie umożliwiającej Zamawiającemu swobodny odczyt kodu
źródłowego, a także zapisanie kodu na innym nośniku i doprowadzenie tego kodu
źródłowego do formy wykonywalnej, w szczególności w drodze kompilacji, na odpowiednio
wyposażonym stanowisku komputerowym. Wraz z kodem źródłowym Wykonawca dostarczy
kompletny wykaz narzędzi programistycznych, bibliotek i innych elementów niezbędnych do
doprowadzenia takiego Oprogramowania do formy wykonywalnej. Wykonawca nie jest
uprawniony do stosowania jakichkolwiek technik lub ograniczeń, które uniemożliwiłyby lub
istotnie utrudniły Zamawiającemu odczyt lub zapisywanie kodu, w szczególności
szyfrowania.
14. Kod źródłowy zostanie przekazany Zamawiającemu wraz z danym
Oprogramowaniem, w każdym przypadku nie później niż na 10 Dni Roboczych przed datą
Odbioru.
Zatem Zamawiający żąda udzielenia na SOA licencji, która jednak będzie zezwalała
na modyfikacje standardowego oprogramowania i jej dalszą dystrybucję, a także
przekazania wszystkich kodów źródłowych. O takiej intencji Zamawiającego świadczy też
zapis § 21 Umowy: Ilekroć Umowa przewiduje udzielnie przez Wykonawcę, intencją Stron
jest zbliżenie takiego upoważnienia na korzystanie ze Standardowego Oprogramowania
Aplikacyjnego do umowy o charakterze jednorazowej transakcji podobnej do sprzedaży -
w związku z tym w zamian za uiszczoną opłatę licencyjną (stanowiącą w przypadku Umowy
element Wynagrodzenia) Zamawiający otrzymuje ciągłe, stałe i niewypowiadalne prawo do
korzystania z takiego Oprogramowania w zakresie określonym w Umowie.
Zamawiający konstruując Umowę posiłkował się dokumentem udostępnionym na
stronie Ministerstwa Cyfryzacji Umowa wdrożeniowa z usługami utrzymania. Wzorcowe
klauzule (opracowanie: Marcin Maruta, Bartłomiej Wachta, zespół kancelarii Maruta Wachta
sp. j.). Przedmiotowe opracowanie w odniesieniu do oprogramowania SOA zawiera kilka
opcji, różniących się znacznie podejściem do praw zależnych i kodów źródłowych.
Zamawiający wybrał najbardziej restrykcyjne rozwiązanie, stosując jedną z opcjonalnych
klauzul bezkrytycznie, zupełnie pomijając istotne uwagi i wytyczne. W komentarzu do klauzul
związanych ze Standardowym Oprogramowaniem Aplikacyjnym (Opracowanie: str. 75-76)
możemy wyczytać „Standardowe oprogramowanie aplikacyjne to oprogramowanie, które
oferowane jest na rynku jako standardowe rozwiązanie wykonawcy lub zewnętrznego
producenta takiego oprogramowania, będące podstawą do stworzenia systemu.
Oprogramowanie to jest kluczowym elementem systemu, a czasem jedynym przedmiotem
zamówienia. Nabycie praw majątkowych do takiego oprogramowania wiązałoby się z bardzo
dużymi kosztami lub wręcz byłoby niemożliwe. Jednocześnie w odniesieniu do
standardowego oprogramowania aplikacyjnego zazwyczaj są większe możliwości zmiany
warunków licencyjnych niż w odniesieniu do oprogramowania systemowego, z reguły też
zamawiający ma inne wymagania w stosunku do aplikacji (np. przewiduje konieczność jej
modyfikacji). Konieczne jest dokładne opisanie takich wymagań w SIWZ.
W proponowanych klauzulach zrezygnowano z podziału, pojawiającego się
w rekomendacjach, skupionego na tzw. oprogramowaniu standardowym wykonawcy. Taka
kategoria opisywała standardowe oprogramowania aplikacyjne, ale tylko takie, do którego
prawa miał wykonawca. W tej sytuacji wykonawca mógł swobodnie kształtować swoje
uprawnienia. Z punktu widzenia zamawiającego taki podział ma mniejsze uzasadnienie - dla
zamawiającego istotne jest, aby aplikacja, będąca podstawą systemu, była objęta warunkami
SIWZ. W przeciwnym razie może dojść do niepożądanej sytuacji, kiedy oprogramowanie
oferowane przez wykonawcę - polski podmiot - byłoby traktowane jako standardowe
oprogramowanie wykonawcy w rozumieniu rekomendacji (a więc np. z prawem do
modyfikacji), a funkcjonalnie równoważne oprogramowanie dostawcy zagranicznego - jako
oprogramowanie systemowe (narzędziowe) czy „oprogramowanie osób trzecich”, jak to
opisano w rekomendacjach. Co więcej, to samo oprogramowanie byłoby różnie traktowane w
zależności od tego, czy ofertę złożyłby jego producent, czy partner producenta - w tym
drugim przypadku ponownie byłoby kwalifikowane jako „ oprogramowanie osób trzecich ”
w rozumieniu rekomendacji.
Kluczową decyzją - w dużej mierze uzależnioną od charakteru oprogramowania - jest
ewentualne wymaganie uzyskania prawa modyfikacji kodu. Mimo że taka praktyka jest
często rekomendowana w celu uniknięcia uzależnienia od wykonawcy (tzw. vendor lock-in),
zależy ona od wielu uwarunkowań. W części przypadków żądanie takie nie będzie możliwe,
biorąc pod uwagę skalę projektu (kluczowi dostawcy oprogramowania nieujawniający kodu),
lub nie będzie miało uzasadnienia ze względu na architekturę aplikacji (np. takiej, która
dostarcza wbudowane narzędzia do konfiguracji i rozbudowy, bez możliwości i potrzeby
ingerencji w kod źródłowy lub w ogóle nie posiada kodu źródłowego jako takiego).
W niektórych przypadkach może też nie mieć uzasadnienia ze względu na specyfikę
rozwiązania i brak zasobów do ewentualnej modyfikacji po stronie zamawiającego
(specjalistyczne rozwiązania autorskie wymagające know-how znanego wyłącznie autorom).
Przy uwzględnieniu zastrzeżenia, że warunki OPZ nie mogą być uznane za
dyskryminacyjne, jeżeli będą z nich wynikały wymagania niemożliwe do spełnienia przez
danego wykonawcę, kwestia ta powinna być dokładnie zweryfikowana przez zamawiającego
na etapie przygotowania SIWZ.
Szczegółowe warunki licencji mogą być określone na dwa sposoby - po pierwsze,
przez odesłanie do standardowych warunków licencyjnych producenta standardowego
oprogramowania aplikacyjnego; po drugie, przez wskazanie warunków licencji na
standardowe oprogramowanie aplikacyjne wprost w umowie. W wariancie drugim warunki te
zapewniają z reguły szerszy i bardziej dostosowany do specyfiki zamawiającego zakres
licencji. Z tego powodu wariant ten jest rekomendowany, ale wymaga dokładnego opisania
w umowie. Wzorcowa klauzula jest dość szeroka i może wymagać korekty (np. co do liczby
stanowisk, jeżeli może mieć to wpływ na cenę).
Wśród postanowień opcjonalnych podano przykład postanowień zezwalających
zamawiającemu na modyfikację standardowego oprogramowania aplikacyjnego. Zwracamy
uwagę, że faktyczna możliwość wykonania modyfikacji uzależniona jest od dostępu
zamawiającego do kodu źródłowego. Dostęp zamawiającego do kodu źródłowego powinien
zostać zapewniony na podstawie odrębnych postanowień umowy.
Zaakcentowania wymaga zwłaszcza fragment komentarza do Opracowania, mówiący
o tym, Zamawiający na etapie przygotowywania zamówienia powinien dokładnie
zweryfikować czy zastosowanie restrykcyjnych warunków prawnoautorskich nie zamknie
drogi większości, jeżeli nie wszystkim Wykonawcom do złożenia ofert oraz, że warunki w
pewnych przypadkach mogą być uznane za dyskryminacyjne, jeżeli będą z nich wynikały
wymagania niemożliwe do spełnienia.
Odwołujący jako spółka grupy kapitałowej Hexagon dysponuje prawami autorskimi do
oprogramowania, które spełnia podobne zadania jak System w postępowaniu i które
z sukcesem zostało wdrożone w ponad 40 lokalizacjach, w tym w ponad 20 krajach Europy.
Odwołujący jest więc w stanie wykonać przedmiot zamówienia w oparciu o swoje know-how
oferując produkt typu COTS - I/CAD. Jednocześnie nie jest producentem I/CAD, stąd nie
może udostępnić kodów źródłowych ani zezwolić na wykonywanie praw zależnych.
Ponownie zaznaczono, że żądanie przekazania dostępu do kodów źródłowych
narusza konkurencję, albowiem SOA ma być rozwiązaniem pudełkowym typu COTS, a więc
na udostępnienie kodów źródłowych może zgodzić się wyłącznie producent takiego
oprogramowania - co stawia go w pozycji uprzywilejowanej w stosunku do wykonawcy nie
będącego takim producentem. Zamawiający decydując się bezkrytycznie na restrykcyjną
klauzulę prawnoautorską w stosunku do SOA przez pozornie poprawne rozwiązanie prawne
wyeliminował z zamówienia wszystkich nieproducentów (dystrybutorów i dostawców
oprogramowania), a także wszystkich producentów, dla których oprogramowanie SOA jest
produktem dedykowanym szczególnie chronionym ze względu na jego cenę i wartość dla
firmy. Zamawiający musiał mieć świadomość, że ze względu na stopień skomplikowania
Systemu, a tym stopień złożoności SOA nie da się użyć oprogramowania open source oraz,
że żadnej z mniejszych podmiotów rynkowych nie będzie w stanie wypełnić rozbudowanych
wszystkie oczekiwania funkcjonalne i merytoryczne Zamawiającego. Podobnie jako
kryterium dyskryminujące należy potraktować przekazanie uprawnień do wykonywania praw
zależnych, co będzie właściwie jest równoważne z utratą kontroli nad oprogramowaniem,
wykonanym w oparciu o gromadzony latami potencjał i doświadczenie, które jest zasadniczą
podstawą działalności firmy.
Aktualnie brzmienie praw autorskich do SOA oznacza, że na przekazanie kodów
źródłowych może zdecydować się jedynie podmiot, który ma małe doświadczenie, krótko
działała na rynku i ma produkt, który nie był przedmiotem wielokrotnych wdrożeń na
przestrzeni wielu lat, gdyż tacy wykonawcy nie będą ponosić ryzyka związanego
z wyzbyciem się kodów źródłowych do produktu, lub ryzyka z tym związane będą
wielokrotnie mniejsze, pomijalne z punktu widzenia korzyści jakie uzyskają ubiegając się
o zamówienie. Trzeba jednak podkreślić, że taki producent nie będzie w stanie spełnić
kryteriów związanych z wykazaniem doświadczenia i potencjału osobowego, a więc nie
będzie zainteresowany przedmiotowym przetargiem.
Podsumowując, w ocenie Odwołującego, postawione wymagania co do praw
autorskich SOA są nieracjonalne i rażąco zawyżają koszty realizacji zamówienia. Krąg
podmiotów mogących złożyć ofertę został zawężony, bez żadnych obiektywnych przesłanek,
jedynie do producentów. W realiach rynku polskiego automatycznie oznacza to skierowanie
przetargu do dwóch, może trzech firm. Wątpliwym jest jednak to, czy zdecydują się one na
wzięcie udziału w postępowaniu, gdyż praktyka rynkowa pokazuje, że każda firma
informatyczna o ustalonej renomie szczególnie chroni swoje prawa autorskie i nie decyduje
się na przekazanie kodów źródłowych do swojego oprogramowania standardowego.
Niezrozumiałym jest zatem podjęcie przez Zamawiającego decyzji o takim ukształtowaniu
postanowień prawnoautorskich do SOA, gdyż w sposób oczywisty ograniczają one
konkurencję i naruszają zasadę równego traktowania wykonawców. Przedmiotowe żądania
są nieuzasadnione także z uwagi na potencjalne potrzeby Zamawiającego, gdyż
Zamawiający nie ma ani wiedzy ani potencjału osobowego, by dokonywać samodzielnym
zmian w kodach źródłowych, musi więc wspierać się zewnętrznym podmiotem, który otrzyma
nieautoryzowany dostęp do oprogramowania istotnego ze względu na bezpieczeństwo kraju.
Zmiany w kodzie źródłowym oprogramowania SOA będą wymagać wiedzy programistycznej
jak jest zbudowany dany kod, dostępu do środowiska deweloperskiego i odpowiednich
certyfikatów. Zamawiający nie wyjaśnił zresztą dlaczego oczekuje dostępu do kodów
źródłowych SOA, skoro nawet w trakcie wdrożenia Systemu modyfikacje będą dokonywane
poprzez tworzenie komponentów traktowanych jako Oprogramowanie Dedykowane, bez
ingerencji w SOA. Po wdrożeniu takie oprogramowanie jakie oferowałby Odwołujący jako
SOA, co jest zresztą standardem rynkowym, ma wbudowane odpowiednie narzędzia tzw.
API, które nie wymagają znajomości całego kodu źródłowego oprogramowania a pozwalają
na dostosowanie oprogramowania do nowych funkcjonalności. Tym samym Zamawiający nie
zastosował się do zasad Ustawy Pzp w zakresie zasad proporcjonalności i przejrzystości
oczekując dostarczenia rozwiązań i uprawnień, które właściwie uniemożliwiają złożenie
oferty w tym przetargu większości firm informatycznym.
Reasumując - prawidłowe, nieograniczające konkurencji żądanie od Wykonawcy
przekazania Zamawiającemu kodów źródłowych winno być ograniczone do Oprogramowania
Dedykowanego, wykonanego na potrzeby tego zamówienia.
Przepis art. 29 ust. 1 Pzp zobowiązuje Zamawiającego do opisania przedmiotu
zamówienia w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych
i zrozumiałych informacji, uwzględniając wszystkie wymagania i okoliczności mogące mieć
wpływ na sporządzenie oferty. Istota tego przepisu sprowadza się więc do określenia przez
zamawiającego wymagań dotyczących przedmiotu zamówienia w taki sposób, aby każdy
wykonawca był w stanie zidentyfikować czego zamawiający oczekuje oraz móc przygotować
prawidłowo oszacowaną ofertę. Nadto Zamawiający nie może opisywać przedmiotu
zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję, lub chociaż potencjalnie
zagrozić uczciwej konkurencji. Zatem bezwzględnym obowiązkiem Zamawiającego jest taki
opis przedmiotu zamówienia, który prowadzi do złożenia ofert porównywalnych,
obejmujących rozwiązania lub produkty spełniające identyczne wymagania techniczne
i jakościowe z uwzględnieniem wszystkich elementów niezbędnych do prawidłowego
skalkulowania oferty przez wykonawcę. Jednocześnie, zgodnie z art. 7 Pzp treść
sformułowanych wymagań musi zachować równowagę stron.
Na istotne znaczenie zasady uczciwej konkurencji oraz jej realizacji poprzez
dokonanie opisu przedmiotu zamówienia z uwzględnieniem zachowania równości
wykonawców, proporcjonalności i przejrzystości wskazuje bogate orzecznictwo sądów
i Krajowej Izby Odwoławczej. Krajowa Izba Odwoławcza wielokrotnie podkreślała, iż zbytnie
dookreślenie wymagań przedmiotu zamówienia, w sposób który nie znajduje uzasadnienia
w potrzebach Zamawiającego jest dokonaniem opisu przedmiotu zamówienia z naruszeniem
zasady uczciwej konkurencji.
W świetle powyższego, sformułowanie przez Zamawiającego warunku konieczności
przekazania kodów źródłowych do SOA oraz udzielenie zgody na realizowanie do niego
praw zależnych nie znajduje odzwierciedlenia w obiektywnych potrzebach i interesach
Zamawiającego i jest zapisem ograniczającym konkurencję w przedmiotowym postępowaniu
wskutek czego został naruszony art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2 Ustawy Pzp.
W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu dokonania
zmiany treści Załącznikiem nr 2 do SIWZ Projekt umowy poprzez usunięcie treści § 18 ust. 4
Umowy w brzmieniu „Licencja na Standardowe Oprogramowanie Aplikacyjne obejmuje:
1) tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie jakichkolwiek
innych zmian w Standardowym Oprogramowaniu Aplikacyjnym;
2) zezwolenie na wykonywanie zależnych praw autorskich do wszelkich opracowań
Standardowego Oprogramowania Aplikacyjnego, to jest rozporządzanie i korzystanie
z takich opracowań w zakresie wszystkich uprawnień nabytych przez Zamawiającego
stosownie do postanowień niniejszego paragrafu ”
oraz § 18 ust 5. „Tłumaczenie, przystosowywanie, zmiany układu lub wprowadzanie
jakichkolwiek innych zmian w Standardowym Oprogramowaniu Aplikacyjnym może być
dokonane przez Zamawiającego lub osobę trzecią działającą na jego rzecz”.
a także dodanie do § 20 ust 12 Umowy w brzmieniu „Ilekroć zgodnie z postanowieniami
Umowy Zamawiający nabywa na jakiejkolwiek podstawie prawnej uprawnienie do
tłumaczenia, przystosowywania, zmiany układu lub wprowadzania jakichkolwiek innych
zmian do określonego Oprogramowania lub korzystania i rozporządzania autorskimi prawami
zależnymi do opracowań Oprogramowania, Wykonawca dostarczy Zamawiającemu
Oprogramowanie również w formie kodu źródłowego zdania „ W celu uniknięcia wątpliwości
obowiązek dostarczenia kodu źródłowego nie obejmuje Standardowego Oprogramowania
Aplikacyjnego”.
Na podstawie dokumentacji przedmiotowego postępowania oraz biorąc pod
uwagę stanowiska Stron i Uczestnika postępowania odwoławczego, Izba ustaliła i
zważyła, co następuje:
Skład orzekający Izby ustalił że nie została wypełniona żadna z przesłanek
skutkujących odrzuceniem odwołania na podstawie art. 189 ust. 2 ustawy Pzp,
a Wykonawca wnoszący odwołanie posiadał interes w rozumieniu art. 179 ust. 1 Pzp,
uprawniający do jego złożenia. Należy bowiem wskazać, że środki ochrony prawnej
określone w ustawie Pzp przysługują wykonawcy, uczestnikowi konkursu, a także innemu
podmiotowi, jeżeli ma lub miał interes w uzyskaniu danego zamówienia oraz poniósł lub
może ponieść szkodę w wyniku naruszenia przez zamawiającego przepisów ustawy. Na
etapie postępowania o udzielenie zamówienia przed otwarciem ofert, np. w przypadku
odwołań czy skarg dotyczących postanowień ogłoszenia i SIWZ przyjąć należy, iż każdy
wykonawca deklarujący zainteresowanie uzyskaniem danego zamówienia posiada
jednocześnie interes w jego uzyskaniu, a szkodą jest niemożliwość złożenia oferty
i podpisania ważnej umowy (za wyrokiem KIO z dnia 04.10.2010 r., sygn. akt KIO 2036/10).
Wykonawca jest zdolny do wykonania zamówienia, deklaruje zainteresowanie
postępowaniem, ma więc szanse na uzyskanie zamówienia, natomiast sposób
ukształtowania zapisów SIWZ, w tym opisu przedmiotu zamówienia i przyszłych warunków
wykonywania umowy przekłada się na sytuację Wykonawcy w postępowaniu i możliwość
złożenia konkurencyjnej oferty.
Izba ustaliła, że w przedmiotowej sprawie do postępowania odwoławczego zgłoszenie
przystąpienia po stronie zamawiającego złożył wykonawca S&T Services Polska Sp. z o.o.
z siedzibą w Warszawie. Przystąpienie uznano za skuteczne.
Zamawiający złożył pisemną odpowiedź na odwołanie, w której wnosił o oddalenie
odwołania w całości.
Odwołujący w odwołaniu prawidłowo przytoczył zapisy SIWZ i warunków umownych
mające znaczenie dla rozstrzygnięcia przedmiotu sporu.
Biorąc powyższe ustalenia pod uwagę, Izba uznała, że odwołanie nie mogło zostać
uwzględnione, bowiem Odwołujący nie wykazał przede wszystkim, iż działania
Zamawiającego są niezgodne z przepisami ustawy Pzp oraz ustawy Prawo autorskie.
Z uwag natury ogólnej dostrzeżenia wymaga w ślad za orzecznictwem, że: "(…)
zasada wyrażona w przepisie art. 7 Pzp nie może być interpretowana w taki sposób, że
wymaga dopuszczenia wszystkich zainteresowanych zamówieniem a wybór produktu, który
należy zaoferować w ramach danego zamówienia, pozostawiony jest wykonawcom" (tak
wyrok KIO z 22.03.2012 r., sygn. akt: KIO 471/12). Zaś: "Obowiązek przestrzegania reguł
określonych w art. 29 ust. 1 i 2 Pzp nie oznacza, że zamawiający nie ma prawa określić
przedmiotu zamówienia w sposób uwzględniający jego potrzeby i aby uzyskać oczekiwany
efekt, nawet jeśli wyklucza to możliwość dopuszczenia do realizacji zamówienia wszystkich
wykonawców działających na rynku. Prawem zamawiającego jest takie opisanie przedmiotu
zamówienia, którego realizacja zaspokoi w najszerszym kontekście określone potrzeby
społeczne" (tak wyrok KIO z 28.03.2014 r., sygn. akt: KIO 486/14). Niewątpliwie granicę
dozwolonych działań Zamawiającego w zakresie opisu przedmiotu zamówienia oraz
przyszłych postanowień kontraktowych stanowią wspomniane wyżej zasady uczciwej
konkurencji oraz równego traktowania wykonawców.
Zasada równego traktowania sprowadza się do konieczności identycznego
traktowania takich wykonawców, których sytuacja jest taka sama lub bardzo podobna, nie
oznacza to natomiast konieczności identycznego traktowania wszystkich wykonawców
znajdujących się na rynku lub aspirujących do wejścia na rynek. Opis przedmiotu
zamówienia nie może preferować jedynie niektórych podmiotów. Wszyscy wykonawcy
powinni mieć zapewniony równy dostęp do istotnych dla postępowania informacji
w jednakowym czasie, dokonywanie oceny warunków oraz ofert powinno następować wedle
wcześniej sprecyzowanych i znanych wykonawcom kryteriów, na podstawie przedłożonych
dokumentów, a nie wiedzy zamawiającego. W ocenie Izby nie oznacza to jednak, że
zamawiający tylko wówczas działa w granicach uczciwej konkurencji oraz z zachowaniem
wymogu proporcjonalności przy opisie przedmiotu zamówienia, gdy jego działania pozwalają
na uczestnictwo w postępowaniu o udzielenie zamówienia publicznego wszystkim
podmiotom występującym na rynku. Jeżeli zatem zamawiający, określając warunki udziału
w postępowaniu, w tym warunki kontraktowe, nie czyni tego w sposób, który wskazuje na
konkretny produkt lub wykonawcę, nie można uznać, iż narusza zasady uczciwej konkurencji
poprzez odniesienie się do przedmiotu zamówienia. Nie jest obowiązkiem Zamawiającego
uwzględnianie doświadczenia zawodowego i polityki prowadzenia działalności komercyjnej
wszystkich podmiotów działających na rynku ale uwzględnienie wymagań gwarantującej
sprawne wykonanie danej usługi, co pozwoli na stworzenie sprawnie działającego systemu,
istotnego z punktu widzenia bezpieczeństwa państwa.
Nie można również zapominać, że obowiązkiem Zamawiającego jest uwzględnienie
jego potrzeb związanych z należytą realizacją zamówienia, które w obiektywny sposób
doprowadzą do wyboru wykonawcy gwarantującego należyte wykonanie zamówienia. Tezy,
iż nie jest możliwe zaoferowanie takiego oprogramowania, gdzie w ramach realizacji
wykonawca nie będzie mógł udzielić Zamawiającemu licencji na wykorzystanie kodów
źródłowych w określonych polach eksploatacji Odwołujący nie udowodnił. Dla Izby znaczący
jest również fakt, iż jak twierdzi sam Odwołujący, postępowanie skierowane jest do dużych
podmiotów działających na rynku IT, jednak żaden z podmiotów nie przystąpił po stronie
Odwołującego do sporu. Jak wynika również z ustaleń Zamawiającego, na ponad 600
zadanych w postępowaniu pytań, żadne nie odnosiło się do kwestii związanych z prawami
autorskimi i niemożliwością udzielenia licencji na wykorzystanie kodów źródłowych.
Przechodząc do wspominanej przez Odwołującego zasady proporcjonalności,
dostrzeżenia wymaga, iż w wyroku z dnia 6 grudnia 2016 r. (sygn. akt KIO 2180/16) Izba
odwołała się do orzecznictwa TSUE wskazując, że proporcjonalność polega na określeniu
przez zamawiającego wyłącznie takich wymagań, które są konieczne do osiągnięcia
zakładanego celu. Wyrażono również pogląd w zakresie rozkładu ciężaru dowodu przy tak
rozumianej zasadzie proporcjonalności. Izba uznała, że to od odwołującego się wykonawcy
należy oczekiwać argumentacji wskazującej, że postawione przez zamawiającego
wymagania są oderwane od zasadniczego celu prowadzenia postępowania i w konsekwencji
realizacji zamierzenia inwestycyjnego, stanowiącego jego przedmiot, jak również że nie są
one konieczne do osiągnięcia zakładanych celów lub pozostają z nimi w wyraźnej
dysproporcji. Takiej argumentacji Odwołujący w ocenie składu orzekającego Izby nie
przedstawił. Niezmiennie, zarówno w odwołaniu, jak też na rozprawie, Odwołujący
wskazywał na praktykę własnej firmy, odwoływał się do specyfiki swoich relacji między
producentem oprogramowania o jego dystrybutorem. Zamawiający podkreślał, iż jego celem
jest zbudowanie systemu, którym w przyszłości swobodnie, bez uzależnienia od monopolu
jednego wykonawcy będzie mógł dysponować, dokonywać jego modyfikacji, ulepszeń.
Odwołujący nie podał w jaki sposób cel ten może być osiągnięty przy przyjęciu założeń
strony odwołującej.
Nie można nie dostrzec, iż Odwołujący w odwołaniu koncentruje się na dowodzeniu,
że przeniesienie praw autorskich do oprogramowania standardowego będzie bardzo
kosztowne bądź wręcz niemożliwe. Tym samym Odwołujący nieproporcjonalności upatruje w
okoliczności, iż nie będzie mógł złożyć konkurencyjnej cenowo oferty, ponieważ nie jest
producentem oprogramowania, które chce zaoferować. Dowodzi to, iż Zamawiający swym
postępowaniem nie narusza przepisów ustawy Pzp wymienionych w odwołaniu, samo zaś
ustalenie warunków kontraktowych na wysokim poziomie wymagań nie stanowi jeszcze
przekroczenia uprawnień strony zamawiającej. Poza tym zauważyć należy, iż Zamawiający
wymaga jedynie udzielenia licencji o rozszerzonym charakterze, nie zaś przeniesienia
autorskich praw majątkowych do oprogramowania. Słusznie zauważył Przystępujący, iż
udzielenie licencji na określonych polach eksploatacji nie spowoduje uszczuplenia
przysługujących wykonawcy majątkowych praw autorskich. Poza tym Zamawiający nie
będzie mógł posiadanymi kodami źródłowymi swobodnie obracać i udostępniać je osobom
trzecim, ale będzie mógł używać ich zgodnie z przeznaczeniem w ściśle określonych
sytuacjach. Zdaniem Izby Zamawiający dąży jedynie do zapewnienia sobie możliwości
dalszej eksploatacji i rozwoju zakupionego sytemu przy możliwości stosowania postępowań o
charakterze konkurencyjnym.
Z zakwestionowanych przez Odwołującego postanowień umownych nie wynika, aby
wskazane w odwołaniu przepisu ustawy Pzp zostały naruszone. Co do zaś dodatkowego
stanowiska pisemnego Odwołującego, złożonego na rozprawie, to stosowanie do art. 192 ust
7 ustawy Pzp, Izba przy orzekaniu związana jest zarzutami odwołania. Stanowisko to
natomiast zawiera w ocenie Izby dodatkowe zarzuty, nie wymienione w odwołaniu,
odnoszące się do innych nieprawidłowości w opisie przedmiotu zamówienia, czy też
preferowaniu przez ten opis konkretnych producentów. Takie kwestie nie były w ustawowym
terminie 10 dni od zamieszczenia ogłoszenia i SIWZ poruszone, więc Izba pozostawiła je bez
rozpoznania.
O kosztach postępowania odwoławczego orzeczono stosownie do jego wyniku,
na podstawie art. 192 ust. 9 i 10 ustawy Pzp oraz w oparciu o przepisy § 5 ust. 3 pkt 1) oraz
ust. 4 w zw. z § 3 pkt 2) rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r.
w sprawie wysokości i sposobu pobierania wpisu od odwołania oraz rodzajów kosztów
w postępowaniu odwoławczym i sposobu ich rozliczania (Dz. U. Nr 41, poz. 238 ze
zmianami) obciążając nimi Odwołującego.
Przewodniczący: