KIO 1043/17

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: