Wyrok KIO KIO 1724/21

WYROK

z dnia 30 lipca 2021 r.

Krajowa Izba Odwoławcza – w składzie:

Przewodniczący: Piotr Kozłowski

Emil Kuriata

Bartosz Stankiewicz 

Protokolant: Piotr Cegłowski

po rozpoznaniu na rozprawie 26 lipca 2021 r. w Warszawie odwołania wniesionego 7 czerwca 2021 r.r. do Prezesa Krajowej Izby Odwoławczej

przez wykonawcę: Linux Polska sp. z o.o. z siedzibą w Warszawie

w postępowaniu pn.Zakup sprzętu i oprogramowania wirtualizacyjnego wraz z usługami wsparcia i gwarancji (6 części) (nr postępowania COI-ZAK.262.5.2021)

prowadzonym przez zamawiającego: Skarb Państwa – Centralny Ośrodek Informatyki z siedzibą w Warszawie

przy udziale wykonawców zgłaszających swoje przystąpienie do postępowania odwoławczego:

A.Advatech sp. z o.o. z siedzibą we Wrocławiu

– po stronie Odwołującego

B.Eskom IT sp. z o.o. z siedzibą w Warszawie

C.Integrated Solutions sp. z o.o. z siedzibą w Warszawie

D.Symmetry sp. z o.o. z siedzibą w Warszawie

– po stronie Zamawiającego

orzeka:

1.Uwzględnia odwołanie w taki sposób, że nakazuje Zamawiającemu usunięcie w odniesieniu do Części 3. wymagania, aby wszystkie komponenty oprogramowania musiały pochodzić od jednego producenta i musiały posiadać wspólne wsparcie realizowane przez jednego producenta.

2.Oddala odwołanie w pozostałym zakresie.

3.Kosztami postępowania obciąża Zamawiającego i Odwołującego po połowie i:

3.1.zalicza w poczet kosztów postępowania odwoławczego kwotę 15000 zł 00 gr (słownie: piętnaście tysięcy złotych zero groszy) uiszczoną przez Odwołującegotytułem wpisu od odwołania;

3.2.zasądza od Zamawiającego na rzecz Odwołującego kwotę 9300 zł 00 gr (słownie: dziewięć tysięcy trzysta złotych zero groszy) – odpowiadającą połowie kosztów postępowania odwoławczego poniesionych przez Odwołującego z tytułu uiszczonego wpisu od odwołania oraz jego uzasadnionych kosztów z tytułu wynagrodzenia pełnomocnika.

Stosownie do art. 579 i 580 ustawy z dnia 11 września 2019 r. – Prawo zamówień publicznych (t.j. Dz. U. z 2021 r. poz. 1129) na niniejszy wyrok – w terminie 14 dni od dnia jego doręczenia – przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie.

U z a s a d n i e n i e

Skarb Państwa – Centralny Ośrodek Informatyki z siedzibą w Warszawie {dalej: „Zamawiający”} prowadzi na podstawie ustawy z dnia 11 września 2019 r. – Prawo zamówień publicznych (t.j. Dz. U. z 2021 r. poz. 1129) {dalej również: „ustawa pzp”, „pzp”, „PZP” lub „Pzp”} w trybie przetargu nieograniczonego postępowanie o udzielenie zamówienia na dostawy pn. Zakup sprzętu i oprogramowania wizualizacyjnego wraz z usługami wsparcia i gwarancji (6 części) (nr postępowania COI-ZAK.262.5.2021).

Ogłoszenie o tym zamówieniu 26 maja 2021 r. zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej nr 2021/S_100 pod poz. 264269.

Wartość tego zamówienia jest powyżej progów unijnych.

7 czerwca 2021 r. Linux Polska sp. z o.o. z siedzibą w Warszawie{dalej również: „Linux” lub „Odwołujący”} wniósł do Prezesa Krajowej Izby Odwoławczej odwołanie wobec postanowień ogłoszenia o zamówieniu i treści Specyfikacji Warunków Zamówienia {dalej: „SWZ” lub „specyfikacja”} w zakresie objętym poniższymi zarzutami.

Odwołanie zawierało następujące zarzuty naruszenia przepisów ustawy pzp i zgłoszone w związku z nimi żądania.

I.Brak dopuszczenia rozwiązania równoważnego do rozwiązania producenta Red Hat [Zarzut #1]

1.OPZ – III. Wykaz Oprogramowania Chmury prywatne] (oprogramowanie referencyjne lub równoważne), tabela „Cześć 3 - Wirtualizator C”, kolumna „Informacje dodatkowe” „Licencje muszę zostać dostarczone w ramach aktualnej umowy EA" w zakresie w jakim prowadzi do uprzywilejowania wykonawców mających aktualnie zawarte umowy EA z Zamawiającym i wyklucza pozostałych wykonawców, mających możliwość zaoferowania rozwiązań równoważnych w oparciu o warunki korzystniejsze zgodnie z zasadą konkurencyjności postępowania i uzasadnionymi potrzebami Zamawiającego.

2.OPZ – IV. Wymagania ogólne dla Części 1, 2 i 3, ust. 14 „Zamawiający nie dopuszcza dostarczenia licencji dla produktów równoważnych w formie upgradu, licencji czasowej, OEM, 2 wyłączeniem, w której Zamawiający określił taki warunek w opisie Oprogramowania w zakresie w jakim Zamawiający nie dopuszcza możliwości zaoferowania licencji OEM, nie wskazując przy tym merytorycznego uzasadnienia w tym zakresie oraz wymagań stawianych w zakresie licencji, czym wyklucza wykonawców mających możliwość zaoferowania rozwiązań równoważnych zgodnych z uzasadnionymi potrzebami i zapewniających uzyskanie przez Zamawiającego odpowiedniej jakości dostaw i usług w ramach zamówienia oraz uzyskanie odpowiednich efektów zamówienia przy niższych kosztach niż rozwiązanie referencyjne.

3.OPZ – IV. Wymagania ogólne dla Części 1, 2 i 3, ust. 17 „Wszystkie komponenty Oprogramowania w ramach każdej Części zamówienia muszą pochodzić od jednego producenta i muszą posiadać wspólne wsparcie realizowane przez jednego producenta" w połączeniu z OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WlRTUALIZATOR C w tabelach "Oprogramowanie równoważne do 'Red Hat Virtualization'. Oprogramowanie równoważne do 'Red Hat OpenStack Platform' w zakresie w jakim Zamawiający nie dopuścił możliwości zaoferowania rozwiązania równoważnego w oparciu o komponenty pochodzące od różnych producentów.

4.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, Oprogramowanie równoważne do „Red Hat Virtualization” (str. 99), Oprogramowanie równoważne do "Red Hat OpenStack Platform" (str. 100) – Licencja typu Without guest OS, 2 Sockets - 1 licencja obejmująca węzeł hyperwizor do 2 fizycznych procesorów" oraz "Oprogramowanie równoważne do 'Red Hat Ansible Automation Platform" (str. 103) – Licencja – 100 zarządzanych nodów” w zakresie w jakim Zamawiający dokonując opisu równoważności w zakresie modelu, sposobu licencjonowania wskazuje na możliwość zaoferowania rozwiązania Red Hat i tylko pozornie dopuścił rozwiązania równoważne.

5.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej Części. Część 3 - WIRTUALIZATOR C, w tabelach „Red Hat Virtualization: oraz „Red Hat OpenStack Platform” wiersz „Cechy oprogramowania równoważnego": „zapewniać wsparcie dla następujących systemów operacyjnych gości: RH EL 4\5\6/7/8, SLES 10\11\12\15, Microsoft Windows Server 2008\2012\2016\2019, Microsoft Windows 7\8\8.1\10” w zakresie w jakim Zamawiający opisując kryteria równoważności postawił wymagania nadmiarowe, nieproporcjonalne w stosunku do rozwiązania równoważnego, podczas gdy producent oprogramowania referencyjnego Red Hat nie wspiera wszystkich wersji wyspecyfikowanych systemów.

6.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” „Oferowane równoważne rozwiązanie musi: być oparte na wersji OpenStack nie starszej niż "Rocky" składającej się co najmniej z Aodh, Ceilometer, Cinder, Designate, Glance, Gnocchi, Heat, Horizon, Ironic, Keystone, Manila, Neutron, Nova, Octavia, OpenDaylight, Panko, Rally, Sahara, Swift, Tempest, Trove” w zakresie w jakim Zamawiający opisując kryteria równoważności postawił wymagania nadmiarowe, nieproporcjonalne w stosunku do rozwiązania równoważnego, bowiem wskazany w OPZ zestaw komponentów dla rozwiązania równoważnego nie może zostać zapewniony przez żadną ze wspieranych wersji rozwiązania referencyjnego Red Hat, z uwagi, że są to już komponenty przestarzałe.

7.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 - WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” „wykorzystywać TripleO (OpenStack On OpenStack) oraz rozwiązanie wybrane w punkcie „Oprogramowanie równoważne do 'Red Hat Ansible Automation Platform'” do instalacji, aktualizacji / zarządzania wykorzystywanym oprogramowaniem" w zakresie w jakim Zamawiający opisując kryteria równoważności dopuścił jedynie możliwość zastosowania jednego rozwiązania TripleO, co w rzeczywistości powoduje pozorność dopuszczenia zaoferowania rozwiązania równoważnego i jedynie możliwość zaoferowania rozwiązania producenta Red Hat.

8.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” „umożliwiać instalację na serwerach: z 64 bitowymi procesorami rodziny x86 procesorami o architekturze ppc64le (Power 8 lub Power 9 w serwerach z zainstalowanym firm warem OPAL)” w zakresie w jakim Zamawiający opisuje sposób działania rozwiązania i wykorzystania platformy Power, podczas gdy istnieją inne sposoby wykorzystania węzłów obliczeniowych z procesorami Power, a nie jedynie poprzez zaoferowanie rozwiązania producenta Red Hat, tj. instalacji rozwiązania na platformie Power, co powoduje, że możliwość zaoferowania rozwiązania równoważnego jest jedynie pozorna.

9.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform” oraz „Red Hat Ansible Automation Platform”, wiersz „Cechy oprogramowania równoważnego” „Oferowane równoważne rozwiązanie musi posiadać możliwość integracji z rozwiązaniami do zarządzania chmurą analogiczne jak Red Hat OpenStack Platform” oraz „Oferowane równoważne rozwiązanie musi posiadać możliwość integracji z rozwiązaniami do zarządzania chmurą analogiczne jak Red Hat Ansible Automation Platform” w zakresie w jakim Zamawiający nie dokonuje opisu kryteriów równoważności, cech funkcjonalnych rozwiązania równoważnego, ale odnosi się bezpośrednio do wszystkich cech funkcjonalnych konkretnego rozwiązania referencyjnego Red Hat, a tym samym oczekuje i umożliwia jedynie zaoferowanie rozwiązania tego producenta.

10.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Informacja” oraz tabela „Red Hat Ansible Automation Platform" wiersz „Informacja” „oprogramowanie równoważne musi być kompatybilne z wymienionym typem Oprogramowania oraz posiadać wszystkie jego cechy funkcjonalne” w zakresie w jakim Zamawiający nie dokonuje opisu kryteriów równoważności, cech funkcjonalnych rozwiązania równoważnego, ale odnosi się bezpośrednio do wszystkich cech funkcjonalnych konkretnego rozwiązania referencyjnego Red Hat, a tym samym oczekuje i umożliwia jedynie zaoferowanie rozwiązania tego producenta.

11.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat Ansible Automation Platform”, wiersz „Cechy oprogramowania równoważnego” „umożliwiać automatyzację administracji rozwiązaniami wybranymi w punktach: - Oprogramowanie równoważne do 'Red Hat OpenStack Platform - Oprogramowanie równoważne do 'Red Hat Ceph Storage', - Oprogramowanie równoważne do 'Red Hat Virtualization', - Oprogramowanie równoważne do 'Win Server Datcr', - Oprogramowanie równoważne do 'VMware vSphere 7 Enterprise Plus'” w zakresie w jakim Zamawiający dokonuje opisu kryteriów równoważności sposób niejednoznaczny wskazując na obowiązek spełnienia wymagań co do automatyzacji w stosunku do rozwiązań równoważnych, które nie będą jeszcze znane wykonawcom na dzień składania ofert, co uniemożliwia wykonawcom ocenę spełnienia wymagań, a tym samym przygotowanie treści ofert.

12.OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat Ansible Automation Platform”, wiersz „Cechy oprogramowania równoważnego” „posiadać centralną konsolę Web umożliwiającą: - tworzenie i zarządzanie konfigurację elementów infrastruktury Informatycznej tworzących rozwiązania wskazane w poprzednim punkcie, - przydział dostępu w oparciu o role i grupy; - harmonogramowania zadań; - wysyłanie powiadomień o ich realizacji” w zakresie w jakim Zamawiający stawiając powyższe wymaganie łącznie z treścią wymagania OPZ – IV. Wymagania ogólne dla Części 1, 2 i 3, ust. 17 „Wszystkie komponenty Oprogramowania w ramach każdej Części zamówienia muszą pochodzić od jednego producenta i muszą posiadać wspólne wsparcie realizowane przez jednego producenta” dokonuje opisu kryteriów równoważności, w taki sposób, że możliwość zaoferowania rozwiązania równoważnego jest jedynie pozorna, a w rzeczywistości nadal możliwe jest zaoferowanie jedynie rozwiązania producenta Red Hat

w zakresie powyższych postanowień Zamawiającemu zarzucam naruszenie następujących przepisów:

1)art. 99 ust. 2 i ust. 4-6 w zw. z art. 16 pkt 1 ustawy PZP poprzez opisanie przedmiotu zamówienia w sposób nieproporcjonalny, nadmiarowy, nieuzasadniony obiektywnymi potrzebami Zamawiającego oraz w sposób uniemożliwiający uczciwą konkurencję i naruszający zasadę równego traktowania wykonawców, poprzez dopuszczenie możliwości zaoferowania rozwiązania konkretnego producenta Red Hat co prowadzi do uprzywilejowania rozwiązań i produktów tego producenta oraz wykonawców oferujących rozwiązania tego producenta, a jednocześnie niedopuszczenie rozwiązań równoważnych w tym zakresie poprzez wskazanie kryteriów oceny równoważności pozwalających w rzeczywistości na zaoferowanie jedynie rozwiązania producenta Red Hat lub odnoszących się bezpośrednio do wszystkich cech funkcjonalnych rozwiązania producenta Red Hat, podczas gdy możliwe jest zrealizowanie wymagań postawionych przez Zamawiającego także w inny sposób, poprzez dostarczenie zaawansowanego technologicznie rozwiązania równoważnego, bez konieczności dostarczania konkretnego rozwiązania producenta Red Hat

2)art. 99 ust. 2 i ust. 4-6 w zw. z art. 16 pkt 3 w zw. z art. 17 piet 1 i piet 2 ustawy PZP poprzez opisanie cech przedmiotu zamówienia w sposób nadmiarowy, nieproporcjonalny do wartości i celów jakie zamierza osiągnąć Zamawiający realizując zamówienie, a jednocześnie niezapewniający uzyskania najlepszej jakości usług i najlepszych efektów zamówienia poprzez dopuszczenie rozwiązań konkretnego producenta Red Hat, podczas gdy możliwe jest zrealizowanie wymagań postawionych przez Zamawiającego, w tym osiągniecie najlepszej jakości usług i najlepszych efektów zamówienia w stosunku do ceny oferowanych na rynku innych rozwiązań także w inny sposób, bez konieczności dostarczania rozwiązań tego konkretnego producenta.

stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:

3) dokonania odpowiedniej modyfikacji treści Ogłoszenia i treści SWZ poprzez

a)dopuszczenie rozwiązań równoważnych do rozwiązania oferowanego przez producenta Red Hat poprzez określenie jednoznacznych i proporcjonalnych do przedmiotu zamówienia kryteriów i warunków stosowanych w celu oceny ich równoważności, w celu umożliwienia wykonawcom realnego konkurowania z wykonawcami oferującymi rozwiązanie producenta Red Hat

b)usunięcie z treści OPZ – IIII. Wykaz Oprogramowania Chmury prywatnej {oprogramowanie referencyjne lub równoważne), tabela „Cześć 3 – Wirtualizator C”, kolumna „Informacje dodatkowe” wymagania „Licencje muszą zostać dostarczone w ramach aktualnej umowy EA” ewentualnie nadanie mu następującego brzmienia: „W przypadku dostawy oprogramowania referencyjnego licencje muszą zostać dostarczane w ramach aktualnej umowy EA”

c)usunięcie z treści OPZ – IV. Wymagania ogólne dla Części 1, 2 i 3, ust. 14 „Zamawiający nie dopuszcza dostarczenia licencji dla produktów równoważnych w formie upgradu, licencji czasowej, OEM, z wyłączeniem, w której Zamawiający określił taki warunek w opisie Oprogramowania" ewentualnie nadanie mu następującego brzmienia: „Zamawiający nie dopuszcza dostarczenia licencji dla produktów równoważnych w formie upgradu, licencji czasowej, z wyłączeniem, w której Zamawiający określił taki warunek w opisie Oprogramowania"

d)usunięcie z treści OPZ IV. Wymagania ogólne dla Części 1, 2 i 3, ust, 17 „Wszystkie komponenty Oprogramowania w ramach każdej Części zamówienia muszą pochodzić od jednego producenta i muszą posiadać wspólne wsparcie realizowane przez jednego producenta” oraz modyfikację OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUAL1ZAT0R C w tabelach „Oprogramowanie równoważne do 'Red Hat Virtualization'. Oprogramowanie równoważne do 'Red Hat OpenStack Platform' poprzez podzielenie Części C zamówienia na odrębnie części: 1. wirtualizator Red Hat Virtualization lub równoważny 2. narzędzia przeznaczone do budowy Chmury laaS: - Red Hat OpenStack lub równoważny - Red Hat Storage CEPH lub równoważny - Red Hat Ansible lub równoważny.

e)w zakresie OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części poprzez zmianę wymagania i nadanie mu następującego brzmienia „Zapewnienie liczby licencji Oprogramowania dla specyfikacji ilościowej sprzętu wskazanej w OPZ w Rodź. I. Opis przedmiotu zamówienia dla Części 1, 2 i 3, ust 3.”

f)w zakresie OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usiugi wsparcia technicznego odpowiednio dla każdej Części. Część 3 - WIRTUALIZATOR C, w tabelach "Red Hat Virtualization: oraz „Red Hat OpenStack Platform” wiersz „Cechy oprogramowania równoważnego” poprzez nadanie wymaganiu następującego brzmienia: „zapewniać wsparcie dla następujących systemów operacyjnych gości: RHEL 6/7/8, SLES 11\12\15, Microsoft Windows Server 2008\2012\2016\2019, Microsoft Windows 7\8\8.1\10”

g)w zakresie OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” poprzez nadanie wymaganiu następującego brzmienia: „Oferowane równoważne rozwiązanie musi: być oparte na wersji OpenStack nie starszej niż "Rocky" składającej się co najmniej z: Ceilometer, Cinder; G lance, Heat, Horizon, ironie, Keystone, Manila, Neutron, Nova, Octavia, Swift”

h)w zakresie OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” poprzez nadanie wymaganiu następującego brzmienia: „wykorzystywać odpowiednik funkcjonalny TripleO (OpenStack On OpenStack) oraz rozwiązanie wybrane w punkcie „Oprogramowanie równoważne do 'Red Hat Ansible Automation Platform'” do instalacji, aktualizacji i zarządzania wykorzystywanym oprogramowaniem"

i)usunięcie wymagania „umożliwiać instalację na serwerach: z 64 bitowymi procesorami rodziny x86 procesorami o architekturze ppc64le (Power 8 lub Power 9 w serwerach z zainstalowanym firmwarem OPAL)" z treści OPZ - VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela "Red Hat OpenStack Platform", wiersz „Cechy oprogramowania równoważnego” ewentualnie poprzez modyfikację wymagania poprzez nadanie mu następującego brzmienia: „umożliwiać instalację na serwerach z: 64 bitowymi procesorami rodziny x86 z procesorami o architekturze ppc64ie (Power 8 lub Power 9 w serwerach z zainstalowanym firmwarem OPAL, pełniącymi funkcję węzłów obliczeniowych. W celu spełnienia wymogów równoważności, dopuszcza się także użycie mechanizmu PowerVM NovaLink w celu wykorzystania węzłów obliczeniowych z procesorami Power”

j)usunięcie wymagania „Oferowane równoważne rozwiązanie musi posiadać możliwość integracji z rozwiązaniami do zarządzania chmurą analogiczne jak Red Hat Open5tock Platform" oraz „Oferowane równoważne rozwiązanie musi posiadać możliwość integracji z rozwiązaniami do zarządzania chmurą analogiczne jak Red Hat Ansible Automation Platform" z treści OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform” oraz „Red Hat Ansible Automation Platform”, wiersz „Cechy oprogramowania równoważnego” ewentualnie poprzez opisanie jednoznacznych i proporcjonalnych do przedmiotu zamówienia kryteriów i warunków stosowanych w celu oceny ich równoważności w powyższym zakresie, w celu umożliwienia wykonawcom zaoferowania rozwiązania równoważnego do rozwiązania producenta Red Hat

k)usunięcie wymagania „oprogramowanie równoważne musi posiadać wszystkie jego cechy funkcjonalne" z treści OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Informacja” oraz tabela „Red Hat Ansible Automation Platform” wiersz „Informacja” oraz poprzez opisanie jednoznacznych i proporcjonalnych do przedmiotu zamówienia kryteriów i warunków stosowanych w celu oceny ich równoważności w powyższym zakresie, w celu umożliwienia wykonawcom zaoferowania rozwiązania równoważnego do rozwiązania producenta Red Hat

l)usunięcie wymagania „umożliwiać automatyzację administracji rozwiązaniami wybranymi w punktach: - Oprogramowanie równoważne do 'Red Hat OpenStack Platform- Oprogramowanie równoważne do 'Red Hat Ceph Storage', - Oprogramowanie równoważne do 'Red Hat Virtualization', - Oprogramowanie równoważne do 'Win Server Datcr', - Oprogramowanie równoważne do 'VMware i/Sphere 7 Enterprise Plus" w treści OPZ - VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat Ansible Automation Platform”, wiersz „Cechy oprogramowania równoważnego”

m)usunięcie wymagania „posiadać centralną konsolę Web umożliwiającą: - tworzenie i zarządzanie konfigurację elementów infrastruktury informatycznej tworzących rozwiązania wskazane w poprzednim punkcie, - przydział dostępu w oparciu o role i grupy; - harmonogramowania zadań; - wysyłanie powiadomień o ich realizacji" z-treści OPZ-VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat Ansible Automation Platform”, wiersz „Cechy oprogramowania równoważnego”.

II.Termin należytego wykonania umowy liczony od wezwania przez Zamawiającego [Zarzut #2]

1.ROZDZIAŁ III - ISTOTNE POSTANOWIENIA UMOWY – Część III § 11 ust 1: „Wykonawca zapłaci Zamawiającemu kary umowne w okolicznościach i wysokościach ustalonych poniżej: (...) pkt 4) w przypadku odstąpienia od Umowy lub jej wypowiedzenia przez Stronę z przyczyn leżących po stronie Wykonawcy, w wysokości 20% maksymalnego łącznego wynagrodzenia netto, o którym mowa w §  9 ust 1 Umowy"

2.§ 12 Wypowiedzenie i odstąpienie od Umowy (...) ust. 2. „Zamawiający może: pkt 1). wypowiedzieć Umowę lub od niej odstąpić w przypadku niewykonania lub nienależytego wykonania jakiegokolwiek zobowiązania przez Wykonawcę. W takim przypadku Zamawiający wezwie Wykonawcę do wykonania lub należytego wykonania Umowy wyznaczając mu termin 3 dni u po upływie tego terminu ma prawo wypowiedzieć Umowę w trybie natychmiastowym lub od niej odstąpić”

w zakresie powyższych postanowień Zamawiającemu zarzucam naruszenie następujących

przepisów:

1)art. 99 ust. 1 PZP w zw. art. 3531 Kodeksu cywilnego (dalej: „KC”) w zw. z art. 5 KC zw. z art. 8 ust. 1 PZP poprzez sformułowanie klauzul umownych uprawniających Zamawiającego do wezwania wykonawcy do należytego wykonania umowy wyznaczając mu przy tym bardzo krótki termin liczony w dniach kalendarzowych, anastępnie po upływie tego terminu uprawniające Zamawiającego do wypowiedzenia umowy w trybie natychmiastowym lub odstąpienia od umowy i nałożenia kary umownej w wysokości 20% maksymalnego łącznego wynagrodzenia netto, które to jednostronne uprawnienia w sposób rażący naruszają zasadę swobody umów, równowagę stron poprzez obciążenie wykonawcy nadmiernym ryzykiem realizacji Zamówienia oraz naruszają zasady współżycia społecznego, a dodatkowo nie uwzględniają okoliczności mogących mieć wpływ na sporządzenie oferty, tj. nierealnego terminu na należyte wykonanie umowy w terminie 3 dni kalendarzowych od wezwania przez Zamawiającego

stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:

1)dokonania odpowiedniej modyfikacji treści SWZ (ROZDZIAŁ III – ISTOTNE POSTANOWIENIA UMOWY – część III) poprzez usunięcie zapisu „W takim przypadku Zamawiający wezwie Wykonawcę do wykonania lub należytego wykonania Umowy wyznaczając mu termin 3 dni; a po upływie tego terminu ma prawo wypowiedzieć Umowę w trybie natychmiastowym lub od niej odstąpić" ewentualnie poprzez wydłużenie terminu należytego wykonania umowy od wezwania Zamawiającego liczącego co najmniej .15 dni roboczych, aby umożliwić wykonawcom, zwłaszcza oferującym rozwiązania równoważne realnej możliwości zastosowania się do wezwania Zamawiającego, tj. należytego wykonania umowy, bez potrzeby nieuzasadnionego i przedwczesnego wypowiedzenia lub odstąpienia od umowy przez Zamawiającego.

III.Termin odstąpienia od umowy przez Zamawiającego [Zarzut #3

3.§12 ust. 3 ROZDZIAŁ III - ISTOTNE POSTANOWIENIA UMOWY – część III w zakresie wprowadzenia zastrzeżenia, że Zamawiający „ma prawo odstąpić od Umowy w terminie 60 (słownie: sześćdziesięciu) dni od chwili gdy powziął wiadomość o przyczynie uzasadniającej odstąpienie; z zastrzeżeniem postanowień ust. 2 pkt 5) powyżej Umowy”.

w zakresie powyższych postanowień Zamawiającemu zarzucam naruszenie następujących przepisów:

1)art. 395 § 1 Kodeksu cywilnego (dalej: „KC") w zw. z art. 8 ust. 1 PZP poprzez sformułowanie klauzuli umownej uprawniającej Zamawiającego do odstąpienia od umowy w sposób wadliwy, która nie przewiduje oznaczenia terminu na odstąpienie od umowy, tj. uzależnia początek biegu 60-dniowego okresu od wydarzenia przyszłego i niepewnego oraz obiektywnie nieweryfikowalnego przez wykonawców

stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:

1)dokonania odpowiedniej modyfikacji treści SWZ (ROZDZIAŁ III – ISTOTNE POSTANOWIENIA UMOWY – część III) poprzez zastrzeżenia terminu odstąpienia od umowy rozpoczynającego swój bieg od momentu wystąpienia okoliczności uprawniającej do odstąpienia od umowy przez Zamawiającego lub zmianę postanowień w taki sposób, aby bieg terminu rozpoczynał się od wydarzenia, którego datę wykonawca jest w stanie w sposób obiektywny zweryfikować, zamiast uzależniania biegu terminu na odstąpienie od umowy od wydarzenia przyszłego i niepewnego, a ponadto obiektywnie nieweryfikowalnego przez wykonawców, tj. od chwili, gdy Zamawiający powziął wiadomość o przyczynie uzasadniającej odstąpienie.

W uzasadnieniu odwołania dla dodatkowego sprecyzowania zarzutów, które następnie nie zostały uwzględnione przez Zamawiającego lub wycofane przez Odwołującego, podano dodatkowo następujące okoliczności faktyczne i prawne.

Okoliczności faktyczne:

{ad pkt I.3. listy zarzutów}

1. Brak dopuszczenia rozwiązania równoważnego do rozwiązania producenta Red Hat [Zarzut #1]

1.1. Przedmiotem niniejszego Postępowania jest zakup sprzętu i oprogramowania wirtualizacyjnego wraz z usługami wsparcia i gwarancji. Zamawiający w treści dokumentacji przetargowej dotyczącej Części III Postępowania wskazał, że oczekuje dostarczenia rozwiązanie referencyjnego producenta Red Hat oraz dopuścił możliwość zaoferowania rozwiązań równoważnych. Jednakże z analizy wymagań postawionych przez Zamawiającego w zakresie rozwiązania równoważnego wynika, że w rzeczywistości wykonawca nie jest w stanie spełnić tych wymagań jeżeli nie zaoferuje rozwiązania producenta Red Hat lub ma obowiązek spełnić wymagania dodatkowe, nadmiarowe, nieproporcjonalne do przedmiotu zamówienia, a których to wymagań Zamawiający nie postawił w stosunku do rozwiązania referencyjnego. W związku z powyższym Zamawiający jedynie pozornie dopuścił możliwość zaoferowania rozwiązań równoważnych. Poniżej Odwołujący przedstawi wymagania znajdujące się w treści SWZ/OPZ i innych dokumentach przetargowych warunkujące w istocie obowiązek zaoferowania rozwiązania jednego konkretnego producenta Red Hat.

{ad pkt I.8. listy zarzutów}

Obowiązek zaoferowania wszystkich komponentów oprogramowania pochodzących od jednego producenta i wspólnego wsparcia realizowanego przez jednego producenta/Wirtualizator C

1.10. Zamawiający w treści OPZ – IV. Wymagania ogólne dla Części 1, 2 i 3, ust. 17 wskazał, że „Wszystkie komponenty Oprogramowania w ramach każdej Części zamówienia muszą pochodzić od jednego producenta i muszą posiadać wspólne wsparcie realizowane przez jednego producenta”. Natomiast w OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części, Część 3 – WIRTUAL1ZATOR C w tabelach „Oprogramowanie równoważne do 'Red Hat Virtualization'. Oprogramowanie równoważne do 'Red Hat OpenStack Platform' określił kryteria równoważności.

1.11. Wymaganie to prowadzi do znacznego i nieuzasadnionego ograniczenia konkurencyjności Postępowania oraz w praktyce powoduje brak możliwości zaoferowania rozwiązania równoważnego.

1.12. W ocenie Odwołującego za uzasadniony można uznać wymóg pochodzenia części A i części B od jednego producenta ze względu na przedmiot zamówienia (wirtualizatory), natomiast w przypadku Części C takie wymaganie jest zupełnie nieuzasadnione merytorycznie i funkcjonalnie. W części C Zamawiający wskazał wiele narzędzi, z których tylko jedno Red Hat Virtualization zgodnie z deklaracją producenta jest faktycznie wirtualizatorem, pozostałe produkty referencyjne zgodnie z deklaracją producenta Red Hat mają zupełnie inne przeznaczenie W części C oprócz wirtualizatora (Red Hat Virtualization) wskazane jest również rozwiązanie do pamięci masowej (rozwiązanie do składowania danych – Red Hat Ceph), rozwiązanie do tworzenia platform chmury typu laaS (platforma chmury obliczeniowej – Red Hat OpenStack) oraz rozwiązanie do automatyzacji zadań administracyjnych (platforma do budowania rozwiązań automatyzacji IT Red Hat Ansible Automation).

1.13. Możliwe jest dopuszczanie wielu producentów mogących zaoferować rozwiązania do wirtualizacji KVM, platformy do budowy chmury prywatnej OpenStack, storage CEPH, automatyzacji Ansible, co Zamawiający uniemożliwił poprzez wprowadzenie powyższego zastrzeżenia o obowiązku pochodzenia wszystkich komponentów od jednego producenta i wsparcia realizowanego przez jednego producenta.

1.14. Oprogramowanie referencyjne (Red Hat Virtualization, Red Hat OpenStack, Red Hat CEPH, Red Hat Ansible Automation) dla Części 3 „Wirtualizator C” oferuje funkcjonalności, które mogą być realizowane przez rozwiązania równoważne, z tym, że większość producentów takich rozwiązań może dostarczyć rozwiązanie równoważne w postaci czterech odrębnych produktów (wirtualizator, OpenStack, CEPH, Ansible), co automatycznie wyklucza możliwość złożenia oferty w oparciu o rozwiązania oferowane przez tych producentów, a tym samym znacznie ogranicza konkurencyjność postępowania. Odwołujący na rozprawie przedstawi dowody w tym zakresie. W ocenie Odwołującego, warunki równoważności określone w OPZ str. 99-104 jak i wzór Formularza Ofertowego potwierdzają, że niemożliwe jest złożenie oferty w oparciu o rozwiązania równoważne w sytuacji, kiedy liczba producentów danych komponentów rozwiązania będzie większa.

1.15. Dodatkowo wskazane ilości produktów referencyjnych wskazują, że koszt Wirtualizatora w części C stanowi niewielką część planowanych kosztów dla części C co pozwala wnioskować, że część C nie dotyczy zakupu wirtualizatora, a bardziej zakupu narzędzi do budowy chmury prywatnej.

1.16. W związku z tym, Zamawiający powinien wyraźnie oddzielić to co jest faktycznie wirtualizatorem (i taką funkcję pełni) od narzędzi, których nie można w ten sposób zaklasyfikować. Wirtualizatorem jest jedynie Red Hat Virtualization. Na oficjalnej stronie producent rozwiązania referencyjnego wskazuje, że Red Hat OpenStack nie jest wirtualizatorem, bowiem nie jest przeznaczony do wirtualizacji, fhttps://www.redhat.com/ en/topics/cloud-cornputing/cloud-vs--virtualization). W taki sposób został jednak zakwalifikowany, i opisany przez Zamawiającego, co należy uznać za nieprawidłowe. W związku z tym wszystkie narzędzia nie będące wirtualizatorem (poza Red Hat Virtualization) należy wydzielić do osobnej części.

1.17. Dodatkowo, w ocenie Odwołującego pochodzenie komponentów w części C od jednego producenta nie jest właściwą metodą zapewnienia ich kompatybilności i poprawnej integracji np. rozwiązanie Red Hat Virtualization oraz Red Hat Storage CEPH nie są ze sobą kompatybilne. Dowód w tym zakresie Odwołujący przedstawi na rozprawie.

1.18. W związku z powyższym w celu zachowania zasady uczciwej konkurencji i równego traktowania wykonawców oraz umożliwienia realnego zaoferowania rozwiązań równoważnych zasadne jest usunięcie zastrzeżenia, że „Wszystkie, komponenty Oprogramowania w ramach każdej Części zamówienia muszą pochodzić od jednego producenta / muszą posiadać wspólne wsparcie realizowane przez jednego producenta” oraz rozbicie Części C zamówienia na odrębnie części: 1. wirtualizator Red Hat Virtualization lub równoważny 2. narzędzia przeznaczone do budowy Chmury laaS: - Red Hat OpenStack lub równoważny - Red Hat Storage CEPH lub równoważny - Red Hat Ansible lub równoważny. Wydzielenie Wirtualizatora do osobnej części, nie będzie w ten sposób nakładało zupełnie nieuzasadnionego funkcjonalnie i merytorycznie obowiązku zastosowania i zaoferowania rozwiązania jednego producenta w zakresie wszystkich narzędzi sklasyfikowanych przez Zamawiającego w sposób nieuprawniony jako „wirtualizator”.

(…)

Wykorzystanie Power 8 lub Power 9

1.34. Zamawiający w treści OPZ - VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 - WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” wskazał, że w przypadku zaoferowania rozwiązania równoważnego należy „umożliwiać instalację na serwerach: z 64 bitowymi procesorami rodziny x86 procesorami o architekturze ppc64le (Power 8 lub Power 9 w serwerach z zainstalowanym firmwarem OPAL)”

1.35. Analogicznie jak wymaganiu dotyczącym obowiązku wykorzystania TripleO, Zamawiający w przypadku powyższego wymagania zamiast dokonać opisu kryteriów równoważności poprzez wskazanie na wymagane cechy funkcjonalne wymaga, aby wykonawca oferujący rozwiązanie równoważne dostarczył rozwiązanie o wskazanym sposobie działania z konkretnym wykorzystaniem platformy Power, pomimo, że na rynku dostępne są alternatywne sposoby spełnienia tego wymagania, w tym wykorzystania platformy Power, odmiennie niż wskazał Zamawiający w OPZ. Na rozprawie Odwołujący przestawi dowody, że istnieje możliwość wykorzystania węzłów obliczeniowych z procesorami Power w oparciu o rozwiązanie OpenStack pochodzące od różnych producentów (mechanizm PowerVM Novalink).

1.36. Aktualnie istnieje zatem tylko jeden producent, który jest w stanie spełnić powyższe wymaganie, bowiem ma możliwość instalacji swojego rozwiązania na platformie Power. Tym samym możliwość zaoferowania rozwiązania równoważnego jest jedynie pozorna.

1.37. Odwołujący wskazuje, że rozwiązania producenta Red Hat i producent IBM są ze sobą powiązane. IBM produkuje serwery z procesorem Power (procesory Power). Z dokumentacji producenta Red Hat wynika, że istnieje możliwość instalacji Red Hat Open Stack na platformie Power, ale ograniczona tylko do węzłów obliczeniowych (compute), a nie wszystkich komponentów tego oprogramowania. Pozostałe komponenty wymagane do wdrożenia nadal muszą być zainstalowane na 64 bitowych procesorach z rodziny x86. Wynika z tego, że celem Zamawiającego jest użycie serwerów z procesorem Power jedynie w zakresie węzłów obliczeniowych. Aktualna treść wymagania wskazuje jednak, że  wykonawca dostarczający rozwiązanie równoważne musi je całościowo zainstalować (w zakresie wszystkich komponentów) na platformie Power, co powoduje, że wymaganie to jest nadmiarowe w stosunku do wymagań stawianych wobec rozwiązania referencyjnego Red Hat.

1.38. Co więcej, producent IBM wiedząc, że producenci nie oferują instalacji na serwerach z procesorami Power stworzył specjalny mechanizm, sterownik PowerVM Novalink, który został przez producenta IBM przeznaczony do tego, żeby umożliwiać sterowanie serwerami i funkcją wirtualizacji, bez konieczności instalacji. Jest to rozwiązanie zalecane przez producenta IBM.

1.39. W związku z powyższym w celu umożliwienia zaoferowania rozwiązania równoważnego Zamawiający powinien: 1. ograniczyć wymagania tylko do węzłów OpenStack pełniących rolę węzła obliczeniowego (compute node) oraz 2. rozszerzyć możliwość instalacji o alternatywny wymóg integracji z pomocą mechanizmu PowerVM Novalink.

1.40. Odwołujący wnosi zatem o usunięcie wymagania „umożliwiać instalację na serwerach: z 64 bitowymi procesorami rodziny x86 procesorami o architekturze ppc64le (Power 8 lub Power 9 w serwerach z zainstalowanym firmwarem OPAL)” z treści OPZ – VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela „Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” ewentualnie poprzez modyfikację wymagania poprzez nadanie mu następującego brzmienia: „umożliwiać instalację na serwerach z: 64 bitowymi procesorami rodziny x86 z procesorami o architekturze. ppc64ie (Power 8 tub Power 9 w serwerach z zainstalowanym firmwarem OPAL, pełniącymi funkcję węzłów obliczeniowych. W celu spełnienia wymogów równoważności, dopuszcza się także użycie mechanizmu PowerVM NovaLink w celu wykorzystania węzłów obliczeniowych z procesorami Power”.

Okoliczności prawne {wspólne dla wszystkich zarzutów z pkt I}:

1.57. W praktyce zamówień publicznych często spotyka się sytuacje, gdy zamawiający wskazują w opisie przedmiotu zamówienia na konieczność oparcia oferty o konkretne rozwiązania tj. materiały, urządzenia, technologię dopuszczając przy tym zastosowanie rozwiązań równoważnych w oparciu o wskazane w SIWZ parametry. Niejednokrotnie jest to działanie pozorne gdyż analiza kryteriów równoważności pokazuje, iż spełnia je wyłącznie jedno, opisane pierwotnie w SWZ rozwiązanie. Z taką właśnie sytuacją mamy do czynienia w niniejszym Postępowaniu. Tak skonstruowany przez Zamawiającego opis przedmiotu zamówienia w rażący sposób narusza art 99 ust. ust. 4-6 oraz art. 16 pkt 1 PZP zakazujące Zamawiającemu opisywania przedmiotu zamówienia w sposób, który mógłby utrudnić uczciwą konkurencję i jednocześnie nakazujące realne dopuszczenie rozwiązań równoważnych, Posłużenie się jedynie sformułowaniem „lub równoważne”, gdy analiza opisu równoważności prowadzi do wniosku, że brak jest możliwości zaoferowania rozwiązania równoważnego w żaden sposób nie można uznać za działanie zgodne z powyższymi przepisami ustawy PZP.

1.58. Jak wskazała Krajowa Izba Odwoławcza w wyroku z dnia 30 kwietnia 2014 r. (sygn. KIO 738/14) „Opisując sposób spełnienia równoważności danego produktu, zamawiający powinien określić dopuszczalne odstępstwa zaoferowanego urządzenia czy przedmiotu równoważnego od przedmiotu czy urządzenia referencyjnego, przy użyciu wartości stanowiących katalog zamknięty (...) Dopiero przy tak opisanych wymogach wykonawca ma obowiązek udowodnienia, że oferowany przez niego produkt mieści się w tych ściśle określonych zakresach równoważności. Aby móc to wykazać, dopuszczenie rozwiązań równoważnych nie może być pozorne lecz musi dawać wykonawcą realną możliwość zaoferowania produktu równoważnego”,

1.59. Nadto, należy wskazać, że w uchwale z dnia 17 lipca 2015 r. (KIO/KD 38/15) Krajowa Izba Odwoławcza rozpatrując wyniki kontroli .postępowania przeprowadzonej przez Prezesa Urzędu Zamówień Publicznych stwierdziła zasadność zarzucenia przez Prezesa UZP zamawiającemu naruszenia art. 29 ust. 2 i ust. 3 ustawy poprzednio obowiązującej PZP (odpowiednika aktualnego art. 99 ust. 41 5 ustawy PZP), który opisał wymaganie dotyczące oprogramowania wskazując wprost na produkt firmy Microsoft. Uzasadniając swoje stanowisko Krajowa Izba Odwoławcza wskazała, że „opis przedmiotu zamówienia jaki zawarł zamawiający w siwz przyczynia się do umacniania monopolu firmy Microsoft. Podkreślić należy, że zgodnie z opinią biegłego istnieje duża ilość pakietów konkurencyjnych oraz współpracującego z nimi oprogramowania, które po skonfigurowaniu mogą w sposób spełniający wszystkie uzasadnione oczekiwania zamawiającego zastąpić pakiety firmy Microsoft Sposób przygotowania siwz wyklucza je jednak w sposób nieuzasadniony z technicznego punktu widzenia z kręgu oprogramowania możliwego do zaoferowania. (...) Wskazane przez zamawiającego wymogi związane z oprogramowaniem antywirusowym w sposób jednoznaczny wskazują na jego współpracę z oprogramowaniem firmy Microsoft, a więc wymuszają stosowanie oprogramowania tego producenta. Tym samym sposób formułowania wymogów zastosowany przez zamawiającego ma niewątpliwie bardzo duży wpływ na monopolizację rynku oprogramowania”.

1.60. W niniejszym stanie faktycznym mamy do czynienia z analogiczną sytuacją, jak opisana we wskazanej powyżej uchwale Krajowej Izby Odwoławczej. Nie można uznać, że przedmiot zamówienia w Postępowaniu został opisany przez Zamawiającego w sposób neutralny, który nie naruszałby zasad uczciwej konkurencji i równego traktowania wykonawców. Skoro Zamawiający w rzeczywistości zawęża możliwość złożenia oferty tylko do jednego konkretnego rozwiązania producenta Red Hat i wprost, wskazuje to rozwiązanie to oznacza, że dokonuje opisu przedmiotu zamówienia na podstawie art. 99 ust, 4-6 ustawy PZP, który może być stosowany wyjątkowo, tylko w ściśle określonych przypadkach i z jednoczesnym faktycznym dopuszczeniem rozwiązań równoważnych. Zamawiający w takim przypadku jest zobowiązany dopuścić możliwość złożenia ofert w oparciu o rozwiązania równoważne i w sposób jednoznaczny określić wymagania jakim ma odpowiadać zaoferowane rozwiązanie równoważne, przy czym określenie wymagań i opis kryteriów rozwiązania równoważnego nie może powodować jedynie pozornej możliwości zaoferowania rozwiązania równoważnego lub odniesienia się. ogólnie do wszystkich cech funkcjonalnych rozwiązania referencyjnego.

1.61. Istotnym jest bowiem fakt, że rozwiązanie równoważnie nie jest i nie może być rozwiązaniem identycznym do referencyjnego. W tym zakresie istnieje ugruntowane stanowisko Krajowej Izby Odwoławczej, m.in.;

1.61.1. w wyroku z dnia 5 stycznia 2012 r. (sygn. akt KIO 2734/11) „istotne jest to, że produkt równoważny to produkt, który nie jest identyczny, tożsamy z produktem referencyjnym, ale posiada pewne, istotne dla zamawiającego, zbliżone do produktu referencyjnego cechy i parametry”.

1.61.2. w wyroku z dnia 22 stycznia 2013 r. (sygn. KIO 20/13) „Pojęcie równoważności nie może oznaczać tożsamości produktów, ponieważ przeczyłoby to istocie oferowania produktów równoważnych”

1.61.3. w wyroku z dnia 16 lutego 2016 r.. (sygn. KIO 142/16) „obowiązkiem zamawiającego jest opisanie, w jaki sposób będzie oceniał taką równoważność, gdyż wiadome jest, że produkt równoważny nie będzie identyczny, tożsamy z produktem referencyjnym, ale ma posiadać pewne zbliżone do niego cechy i parametry, które winien wskazać zamawiający.”

1.61.4. w wyroku z dnia 28 lutego 2012 r. (sygn. KIO 229/12) „Oferta równoważna to taka, która przedstawia produkt, który nie jest identyczny, tożsamy z produktem referencyjnym, ale  posiada pewne, istotne dla zamawiającego, zbliżone do produktu referencyjnego cechy 7 parametry. Pojęcie równoważności nie może oznaczać tożsamości produktów, ponieważ przeczyłoby to istocie oferowania produktów równoważnych, i czyniłoby możliwość oferowania produktów równoważnych pozorną i. w praktyce niemożliwą do spełnienia. Zaś rozwiązanie równoważne nie może oznaczać, że inne zaproponowane w ramach tej równoważności urządzenie ma spełniać wszystkie parametry konkretnego urządzenia, określonego producenta, przyjętego przez projektanta, gdyż naruszałoby to zasadę równego traktowania wykonawców i uczciwej konkurencji”

1.61.5. w wyroku z dnia 24 lutego 2014 r. (sygn. KIO 256/14), „Oferta równoważna to taka, która przedstawia przedmiot zamówienia o właściwościach funkcjonalnych i jakościowych takich samych lub zbliżonych do tych, które zostały zamieszczone w SIWZ. istotne jest przy tym to, że produkt równoważny do produkt, który nie jest identyczny, tożsamy z produktem referencyjnym, ale posiada pewne, istotne dla zamawiającego, zbliżone do produktu referencyjnego funkcjonalności i parametry, które bezwzględnie powinny zostać określone w treści SIWZ”.

1.62. Pojęcie równoważności nie może zatem oznaczać tożsamości rozwiązań, ponieważ przeczyłoby to istocie oferowania produktów i rozwiązań równoważnych, czyniłoby pozornym oferowanie takich produktów równoważnych, a sam art. 99 ust. 4-6 PZP przepisem martwym. Zamawiający w niniejszym Postępowaniu, jak wskazał powyżej Odwołujący, niejednokrotnie wskazuje na obowiązek zaoferowania rozwiązania równoważnego posiadającego „wszystkie cechy funkcjonalne" rozwiązania referencyjnego lub opisuje kryteria równoważności w taki sposób, że wykonawca nie jest w rzeczywistości w stanie spełnić wszystkich tych wymagań Zamawiającego inaczej niż poprzez zaoferowanie rozwiązania referencyjnego producenta Red Hat.

1.63. Zdaniem Odwołującego nie ma natomiast żadnych przesłanek merytorycznych dla wynikającego z SWZ wyłączenia możliwości zaoferowania innego, równoważnego rozwiązania spełniającego wymagania określone w SWZ równie zaawansowanego technologicznie jak preferowane, konkretne rozwiązanie producenta Red Hat Nie jest to także w żaden sposób podyktowane uzasadnionymi potrzebami Zamawiającego. Narzuconą konieczność spełnienia wymagań Zamawiającego tylko w określony sposób ma natomiast charakter dyskryminacyjny, bowiem świadczy o preferowaniu konkretnych rozwiązań jednego producenta, którego rozwiązania Zamawiający aktualnie posiada, a tym samym zmuszeniu wykonawców, do zaoferowania konkretnej technologii jednego producenta.

1.64. Nie sposób także nie zaznaczyć, że ustawodawca nowelizacją ustawy PZP, która obowiązuje od dnia 1 stycznia 2021 r., wprowadził nowy obowiązek po stronie zamawiających dotyczący przygotowania postępowania i udzielenia zamówienia określony w art. 17 ust. 1 pkt 1 i pkt 2 ustawy PZP. Z przepisu tego jednoznacznie wynika, jaki efekt ma osiągnąć zamawiający udzielając zamówienia. Ustawodawca wskazał, że „Zamawiający udziela zamówienia w sposób zapewniający: 1) najlepszą jakość dostaw, usług, oraz robót budowlanych, uzasadnioną charakterem zamówienia, w ramach środków, które zamawiający może przeznaczyć na jego realizację, oraz 2) uzyskanie najlepszych efektów zamówienia, w tym efektów społecznych, środowiskowych oraz gospodarczych, o ile którykolwiek z tych efektów jest możliwy do uzyskania w danym zamówieniu, w stosunku do poniesionych nakładów". W związku z tym ukształtowanie treści SWZ, w którym Zamawiający dopuszcza, a wręcz wymaga zaoferowania rozwiązania konkretnego producenta Red Hat, gdy na rynku dostępne są inne, zaawansowane technologicznie rozwiązania i jedynie pozornie wskazuje na dopuszczenie rozwiązań równoważnych stoi zupełnie w sprzeczności także z zasadą, określoną w art. 17 ust. 1 pkt 1 i pkt 2 ustawy PZP, tj. określającą, że zamówienie ma zapewnić Zamawiającemu najlepszą jakość usług oraz uzyskanie najlepszych efektów zamówienia. Odwołujący jest w stanie zaoferować, dostarczyć i zapewnić Zamawiającemu rozwiązanie spełniające jego uzasadnione potrzeby, w tym określone cele i wymagania opisane w treści SWZ, które to rozwiązanie jest jednocześnie zaawansowane technologicznie w równym stopniu jak rozwiązanie oferowane przez producenta Red Hat.

1.65. Zamawiający bez wyraźnego uzasadnienia nie ma możliwości ograniczania konkurencyjności w Postępowaniu i dostępu do zamówienia określonej grupie wykonawców, tj. chcących zaoferować inne, zaawansowane technologicznie rozwiązanie. Jak wskazała Krajowa Izba Odwoławcza w przywołanym już wyżej wyroku (sygn. KIO 2184/13) „Uzasadnione potrzeby podmiotu zamawiającego mogą zatem usprawiedliwiać ograniczenie kręgu potencjalnych wykonawców oraz wpływać na zakres oferowanych przez nich usług, dostaw i robot budowlanych, o ile wynikają one z celu, dla którego podmiot zamawiający wszczyna określone postępowanie, a cel ten jest nakierowany na realizację tychże potrzeb i w żaden inny sposób nie może zostać osiągnięty (zasada proporcjonalności), zaś wymagania zamawiającego związane są z istotą przedmiotu zamówienia i jego indywidualnymi właściwościami pozwalającymi na osiągnięcie wskazanego wyżej celu”.

1.66. Argumentacja Odwołującego potwierdza, że ograniczenie konkurencji w Postępowaniu nie ma nic wspólnego z faktycznymi celami jakie Zamawiający zamierza osiągnąć realizując Zamówienie, a tym samym takie działanie stanowi naruszenie przepisów ustawy PZP. Potwierdza także stanowisko Odwołującego, co do tego, że treść SWZ była w rzeczywistości formułowana przez Zamawiającego w taki sposób, aby zapewnić uprzywilejowaną pozycję w Postępowaniu wykonawcom oferującym rozwiązania producenta Red Hat i jedynie pozornemu dopuszczeniu rozwiązań równoważnych stwarzając tylko wrażenie zachowania zasady uczciwej konkurencji i równego traktowania wykonawców w Postępowaniu.

W odpowiedzi na odwołanie przesłanej 11 lipca 2021 r. Zamawiający w pierwszej kolejności oświadczył, że częściowo uwzględnia odwołanie tj. w zakresie zarzutów wynikających z następujących pkt na wstępie odwołania: I.1., I.4., I.5., I.6., I.7., I.10., I.11., II.1. i II.2. Zamawiający poinformował również o zmianach SWZ, które w związku z tym wprowadził (jako zmiany nr 3).

W pozostałym zakresie Zamawiający wniósł o oddalenie odwołania, w szczególności następująco odnosząc się do zarzutów, które nie również wycofane przez Odwołującego (o czym mowa poniżej).

{rozważania wspólne dla zarzutów z pkt I}

1.22 Na wstępie Zamawiający pragnie wskazać, że zarzuty odwołania sprowadzają się do dokonania zmian umożliwiających złożenie oferty przez odwołującego. Zgodnie z tym co wskazał Zamawiający w pkt 1.1 niniejszego pisma w obrocie prawnym funkcjonuje ugruntowana linia orzecznicza zgodnie, z którą zamawiający jako gospodarz postępowania o  udzielenie zamówienia jest uprawniony do postawienia wymagań, które spełniać będzie wyłącznie krąg wybranych dostawców lub nawet wyłącznie jeden dostawca. Warunkiem jest, aby wspomniane wymagania wynikały z uzasadnionych potrzeb zamawiającego – jak w niniejszym Postępowaniu. Zamawiający wskazał powyżej na przykładowe orzeczenia, które wpisują się w tę linię orzeczniczą. Zatem nie można czynić Zamawiającemu zarzutu z tego tytułu, że Odwołujący nie spełnia wszystkich wymagań postawionych przez Zamawiającego.

1.23 Zamawiający stoi na stanowisku, że żądania wykonawców oferujących rozwiązania równoważne nie powinny powodować obniżania wymogów jakościowych oraz rezygnacji z założeń, które legły u podstaw danych wymogów technicznych. Zamawiający nie ma również obowiązku zakupu gotowych już rozwiązań. W rezultacie, wykonawcy mogą dostosować swoje produkty do postawionych wymagań. W Postępowaniu, Zamawiający wskazał trzy technologie referencyjne zgodne z technologiami systemów IT przyszłych klientów (szczegóły poniżej).

Zamawiający zobowiązany jest do zapewnienia kompatybilności tworzonego środowiska z

przedmiotowymi technologiami. W innym wypadku, tworzone środowisko nie byłoby dostosowane do potrzeb klientów, a realizacja wskaźników projektu w ramach którego ogłoszono Postępowanie zagrożona. Zamawiający zaznacza również, że zgodnie z orzecznictwem KIO uchwała KIO/KD 110/14 „(…) o ile zamawiający dopuści rozwiązania równoważne (…), nie może przesądzać o naruszeniu powołanych wcześniej przepisów Pzp okoliczność, że jedynym producentem danego systemu jest określony podmiot. (…) W ocenie Izby Zamawiający nie może ponosić negatywnych konsekwencji w sytuacji, gdy pomimo prawidłowego sporządzenia opisu przedmiotu zamówienia, w postępowaniu o udzielenie zamówienia publicznego weźmie udział ograniczona liczba wykonawców (bądź jeden podmiot)”. Zamawiający dopuścił rozwiązania równoważne w zakresie wszystkich wirtualizatorów, a zgodnie z powyższy nie może przesądzać o naruszeniu przepisów Pzp. okoliczność, że jedynym producentem danego rozwiązania jest określony podmiot.

1.24 Jednym z głównych założeń SW jest minimalizacja vendor lock-in. W związku z tym całość rozwiązania zawartego w ramach wirtualizatora „C”, którego udział w realizacji projektu WIIP jest zdecydowanie największy m.in. z uwagi na fakt, że na nim opierać się RChO poprzez komponent OpenStack stanowiący bezpłatną platformę do przetwarzania w chmurze, bazuje na tzw. kodzie open source. Przez termin „open source” rozumie się ruch programistów i użytkowników komputerów zaangażowanych w działania na rzecz swobodnego dostępu do oprogramowania przez ogół użytkowników. W znaczeniu ścisłym oprogramowanie open source to programy, których kod jest swobodnie i publicznie dostępny. Zatem, oprogramowanie open source to oprogramowanie, którego licencja pozwala na kopiowane oraz modyfikowanie kodu. Społeczność informatyczna ma więc prawo dowolnie modyfikować taki kod i wprowadzać na rynek wiele jego wersji. Sformułowanie oprogramowanie open source obejmuje swym zakresem bardzo dużą grupę różnorodnych programów, rożnych producentów. W żadnym wypadku nie można więc przyjąć, iż użycie takiego sformułowania wskazuje na konkretnego wykonawcę (zob. wyrok SO w Lublinie II Ca 587/05 „Przyjęty przez zamawiającego wymóg wykorzystania (…) oprogramowania typu open source nie wskazuje bowiem w żaden sposób na konkretnego producenta lub dostawcę programu”). Technologia Red Hat została wskazana w OPZ wyłącznie jako rozwiązanie referencyjne, co nie zmienia faktu, że opiera się ona na otwartym kodzie źródłowym. Zatem, wedle najlepszej wiedzy Zamawiającego, zarówno wirtualizator „C” jak i pozostałe komponenty nabywane w ramach tego środowiska, może dostarczyć każdy producent poprzez odpowiednie dostosowanie kodu do postawionych wymagań. Twierdzenie więc, że wymogi w zakresie wirtualizatora „C” może spełnić wyłącznie technologia Red Hat jest całkowicie niezasadne w świetle tego, że jest to technologia open source. W przypadku technologii open surce nie można natomiast twierdzić, że są oferowane wyłącznie przez jednego producenta, ponieważ jak sama definicja wskazuje jest to tzw. system otwarty. Poniżej Zamawiający wskazuje komponenty nabywane w ramach wirtualizatora „C”:

1) „Ansible® to otwarte oprogramowanie do zarządzania stanem infrastruktury oraz do automatyzacji procesów administracyjnych w przedsiębiorstwie”;

2) „Ceph™ jest otwarto źródłowym rozwiązaniem typu SDS opartym o ideę przechowywania danych jako obiekty”;

3) „OpenStack to bezpłatna platforma do przetwarzania w chmurze o otwartym standardzie.

Jest on najczęściej wdrażany jako infrastruktura jako usługa (IaaS) zarówno w chmurach publicznych, jak i prywatnych, gdzie wirtualne serwery i inne zasoby są udostępniane użytkownikom”;

4) „Wirtualizator KVM” to oprogramowanie typu open source. Komponent jądra KVM jest zawarty w głównym systemie Linux od 2.6.20. Komponent przestrzeni użytkownika KVM jest

zawarty w głównej linii QEMU od 1.3.

(…)

{ad pkt I.3. listy zarzutów}

1.30 Następnie, odwołujący kwestionuje wymóg zgodnie z którym „Wszystkie komponenty Oprogramowania w ramach każdej Części zamówienia muszą pochodzić od jednego producenta i muszą posiadać wspólne wsparcie realizowane przez jednego producenta”, w zakresie w jakim Zamawiający w przypadku wirtualizatora „C” nie dopuścił możliwości zaoferowania rozwiązania równoważnego w oparciu o komponenty pochodzące od różnych producentów.

Zamawiający wskazuje, że nie sformułował żądania w ten sposób, aby ww. komponenty pochodziły od konkretnego producenta. W związku z tym wykonawcy posiadają równe szanse i są zobowiązani aby komponenty oprogramowania wchodzącego w skład wirtualizatora „C” oraz zasady wsparcia tego oprogramowania pochodziły od tego producenta, którego rozwiązanie zaoferują.

1.31 Zamawiający wskazuje, że zgodnie z pkt I.1.a) OPZ przedmiotem zamówienia jest dostarczenie oprogramowania do wirtualizacji na potrzeby uruchomienia i administrowania przez Zamawiającego środowiska chmury prywatnej powstającej w ramach Wspólnej Infrastruktury Informatycznej Państwa. Następnie, zgodnie z opisem zawartym w pkt II OPZ Zamawiający zamawia oprogramowanie do zarządzania i wirtualizacji, które musi umożliwiać zarządzanie, administrowanie i obsługę rozwiązań serwerowych w środowisku chmurowym z  funkcjonalnością pozwalającą na obsługę, w tym udostępnienia środowiska, a docelowo usług, wielu odrębnych podmiotów, ich systemów informatycznych oraz instalowanego oprogramowania w dostępnych na rynku technologiach. Zatem, Zamawiający nie wskazał w OPZ, że przedmiotem zamówienia jest dostawa wyłącznie samego wirtualizatora. Niezasadny jest w związku z tym zarzut, że w zakresie wirtaulizatora „C” Zamawiający oprócz faktycznego wirtualizatora zamawia również inne narzędzia. Zamawiający wskazuje, że zabieg ten jest celowy. Zamawiający podnosi, że przedmiotem zamówienia w ramach wirtaulizatora „C” jest oprogramowanie służącego do wirtualizacji oraz narzędzia, które pełnią istotne funkcje związane z pracą wirtualizatora, tzn.:

1) rozwiązanie do pamięci masowej (rozwiązanie do składowania danych Ceph) – otwarto źródłowe rozwiązanie typu SDS bazujące na przechowywaniu danych jako obiekty. Ceph umożliwia dostarczanie kilku różnych typów pamięci masowej. Dostarcza również różne typy pamięci masowej równocześnie przez jeden klaster;

2) rozwiązanie do tworzenia platform chmury typu IaaS (platforma chmury obliczeniowej

OpenStack) – zapewnia możliwość zbudowania na bazie posiadanego zestawu narzędzi

prywatną oraz publiczną chmurę obliczeniową;

3) rozwiązanie do automatyzacji zadań administracyjnych (platforma do budowania rozwiązań automatyzacji IT Ansible Automation) – zapewnia wsparcie dla procesów automatyzacji, ułatwia pracę operatorom i administratorom. Rozwiązanie to usprawnia procesy wstępnej konfiguracji systemów fizycznych i wirtualnych. Zastosowane mechanizmy umożliwiają integrację rozwiązania z innymi elementami infrastruktury.

Zamawiający zamawia kompleksowe środowisko składające się z wirtulizatora oraz odrębnych komponentów realizujących funkcje związane z pracą wirtualizatora stąd też konieczne jest zapewnienie jednorodności przedmiotowego środowiska. Zamawiający wyklucza sytuację, w której w ramach wirtulizatora „C” każdy komponent, tj. wirtualizator oraz ww. narzędzia pochodzić będą od różnych producentów. Przedmiotowe rozwiązanie niesie za sobą zbyt wysokie ryzyko z punktu widzenia prawidłowej oraz niezakłóconej pracy środowiska jak również obsługi ewentualnych awarii i problemów w działaniu takiego środowiska (niezbędna jest diagnoza, który z komponentów zawinił i czyja jest wina).

1.32 Wniosek Odwołującego zmierza do dokonania całkowitej zmiany podstawowych założeń które legły u podstaw OPZ. Zgodnie z pkt I.2. OPZ w celu zaspokojenia potrzeb infrastrukturalnych systemów informatycznych lokowanych docelowo w Chmurze prywatnej, Zamawiający musi mieć do dyspozycji, z uwagi na potrzebę zachowania zgodności migrowanych istniejących systemów informatycznych użytkowników końcowych do Chmury i w oparciu o wyniki badania popytu w tym zakresie, trzy odmienne (różne) technologie wirtualizacji (dalej: „Wirtualizatory”).

Żądanie Odwołującego zmierza do zaburzenia niniejszego założenia, ponieważ chce aby w ramach wirtualizatora „C” zamiast jednej technologii funkcjonowały nawet cztery różne technologie, inna w zakresie wirtualizatora oraz inne w zakresie ww. narzędzi. Zamawiający zaznacza, że po przeprowadzeniu kompleksowej analizy w ramach SW architektura RChO została oparta na trzech odrębnych technologiach, każda o jednolitym charakterze. Wprowadzenie zmiany zgodnie z żądaniem odwołania stanowi zbyt wysokie ryzyko z punktu widzenia migrowania z istniejących środowisk on-premise do RChO systemów państwowych w oparciu o współdzieloną infrastrukturę dostępną w formie usługi świadczonej przez Zamawiającego. Oprogramowanie do wirtualizacji musi być również przetestowane pod kątem współpracy i integracji z zamawianymi komponentami. Producent musi zapewniać wsparcie nie tylko wyłącznie w zakresie działania pojedynczego modułu, ale także ich interakcji. Ważne jest, aby wszystkie komponenty objęte były wsparciem tego samego producenta. Brak pełnej odpowiedzialności jednego producenta za całość rozwiązania może skutkować kwestionowaniem zakresu odpowiedzialności lub wydłużeniem czasu naprawy awarii, a w konsekwencji stanowić poważne zagrożenie dla sprawności działania oraz utrzymania RChO. W przypadku wymogu Zamawiającego, działanie RChO podlega pod jednolite zasady wsparcia jednego producenta, który przyjmuje całość odpowiedzialności.

Propozycja Odwołującego wprowadza różne zasady wsparcia, które mogą być ze sobą sprzeczne. W ten sposób dojdzie do rozmycia odpowiedzialność za prawidłowość działania całego środowiska w ramach wirtualizatora C. Kompatybilność oraz niezawodność działania przedmiotowego środowiska zapewni pochodzenie jego poszczególnych elementów od tego samego producenta.

Budowane środowisko jest podstawą do działania krytycznych systemów. Stąd zastosowanie

komponentów pochodzących od różnych producentów może powodować niezgodności w realizacji wybranych funkcji, a także powodować błędne działanie całości środowiska.

1.33 Dodatkowo, biorąc pod uwagę rolę Zamawiającego w projekcie WIIP, który jest zobowiązany do utrzymania usługi RChO na docelowym 98,75% poziomie dostępności, wymóg aby wsparcie techniczne było świadczone przez jednego producenta należy uznać za uzasadniony.

Dodatkowo, zgodnie z pkt 8.2 Tabele 11 SW, średni poziom dostępności świadczonych usług na poziomie 98,75% jest jednym ze wskaźników realizacji projektu WIIP.

1.34 Należy również zaznaczyć, że środowisko wirtualizatora C, tj. wirtualizator oraz pozostałe komponenty są oparte na modelu open source, tj. na kodzie źródłowym do którego dostęp jest otwarty. Tym samym, brak jest przeciwskazań, aby dany producent stworzył na potrzeby niniejszego zamówienia rozwiązanie, które będzie zgodne z przedmiotowym wymogiem.

Należy bowiem zaznaczyć, że Zamawiający nie jest zobowiązany do zamawiania gotowych już produktów.

1.35 Zamawiający wskazuje, że ww. wymóg jest stosowany i znajduje aprobatę w orzecznictwie KIO.

Przykładowo, zgodnie z wyrokiem KIO/UZP 799/08 „Opis przedmiotu zamówienia w zakresie

żądania tego samego producenta jednostki centralnej i płyty głównej nie utrudnia uczciwej

konkurencji (art. 7 ust. 1 ustawy), bowiem Zamawiający nie wskazał w postanowieniach SIWZ na konieczność dostarczenia przez wykonawców urządzenia (jednostki centralnej, czy też płyty głównej) konkretnego producenta. Na tym etapie postępowania wszyscy wykonawcy mają równe szanse na złożenie oferty w postępowaniu - jedni dysponując już sprzętem (jednostkami centralnymi komputera) z tożsamym producentem płyty głównej, inni zaś, przygotowując się do wypełnienia tego wymogu funkcjonalnego SIWZ, zlecając zaprojektowanie płyty głównej producentowi jednostki centralnej. Przekonującym jest argument Zamawiającego odnośnie chęci ograniczenia współpracy z większą ilością producentów w okresie gwarancji, przy takim samym producencie zarówno jednostki centralnej, jak i płyty głównej, a tym samym usprawnienia pracy Zamawiającego”, KIO 2164/13 „(…) Dlatego też niezwykle istotnym jest zapewnienie ciągłości funkcjonowania infrastruktury oraz systemu zarządzania i monitorowania jej pracy. A to jest możliwe jedynie w przypadku uzyskania pełnej kompatybilności elementów wchodzących w skład tego systemu. Taką kompatybilność, a tym samym niezawodność systemu zapewni jedynie pochodzenie jego poszczególnych elementów od tego samego producenta. Budowana infrastruktura jest bowiem podstawą do działania krytycznych systemów (obsługi pacjenta, jak i systemów zapewniających sprawne działanie obiektu). Dlatego też zastosowanie oprogramowania pochodzącego od różnych producentów może powodować niezgodności w realizacji wybranych funkcji zarządzania i monitoringu, a także powodować błędne działanie całości oprogramowania. Taki opis przedmiotu zamówienia, jakiego dokonał zamawiający nie ogranicza konkurencji, gdyż producentów, którzy mogą dostarczyć taki system (oprogramowanie) jest wielu. Wykonawca będący integratorem także może złożyć taką ofertę. Każdy z integratorów ma możliwość zaoferowania oprogramowania pochodzącego od dowolnego producenta. Istnieje co najmniej kilku producentów mogących zrealizować to zamówienie. Wykonawca nie może być bowiem utożsamiany z jednym producentem. Rynek producentów ani wykonawców nie jest więc zamknięty. Sama okoliczność, iż opis przedmiotu zamówienia uniemożliwia złożenie oferty przez odwołującego nie wskazuje na naruszenie podstawowych zasad udzielania zamówień publicznych, skoro na rynku istnieje szereg podmiotów mogących brać udział w przedmiotowym postępowaniu. Zamawiający ma bowiem prawo tak opisać swoje potrzeby aby przedmiot zamówienia spełniał jego wymagania i zaspokajał potrzeby. Zamawiający jest uprawniony zabezpieczyć swój uzasadniony interes w uzyskaniu produktu zintegrowanego w możliwie jak największym zakresie, który w najwyższym stopniu uwzględni jego potrzeby, a przede wszystkim cel jakiemu ma służyć przedmiot zamówienia. Dookreślenie, że ma to być system jednego producenta, służy niewątpliwie temu celowi, zabezpieczając uzyskanie integracji i możliwość wymiany danych pomiędzy poszczególnymi elementami systemu, a w konsekwencji ma zapewnić uzyskanie produktu, który faktycznie odpowiada uzasadnionym potrzebom zamawiającego”.

{ad pkt I.8. listy zarzutów}

1.36 Odwołujący kwestionuje również wymóg zgodnie z którym „OPZ - VII. Kryteria stosowane w celu oceny równoważności dla Oprogramowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela :Red Hat OpenStack Platform”, wiersz „Cechy oprogramowania równoważnego” „umożliwiać instalację na serwerach: z 64 bitowymi procesorami rodziny x86 procesorami o architekturze ppc64le (Power 8 lub Power 9) w serwerach z zainstalowanym firmwarem OPAL)”, w zakresie w jakim Zamawiający opisuje sposób działania rozwiązania i wykorzystania platformy Power, podczas gdy istnieją inne sposoby wykorzystania węzłów obliczeniowych z procesorami Power. Zamawiający wskazuje, że Postępowanie zostało ogłoszone na potrzeby budowy RChO, do której migrowane będą systemy administracji publicznej. Aby zrealizować zakładany cel konieczne jest zapewnienie pełnej kompatybilności z obecnie eksploatowanymi platformami. W związku z wykorzystywaną obecnie przez Zamawiającego architekturą oraz z zaplanowanym sposobem budowy docelowego rozwiązania jakie zostanie dostarczone w efekcie realizacji projektu WIIP nie jest możliwe wykorzystanie zaproponowanego przez wykonawcę rozwiązania. Dodatkowo, Zamawiający podnosi, że wymóg może być spełniony przez technologie niż Red Hat: SUSE Linux Enterprise Server for IBM Power, Red Hat Enterprise Linux, Ubuntu Server.10:41 20.08.2021

W dalszym toku postępowania odwoławczego:

1.W piśmie procesowym z 16 lipca 2021 r. Odwołujący oświadczył, że wycofuje zarzut z pkt I.12. listy zarzutów, a w zakresie nieuwzględnionych i podtrzymanych zarzutów odniósł się do argumentacji i dowodów przedstawionych przez Zamawiającego w odpowiedzi na odwołanie.

2.W piśmie procesowym z 22 lipca 2021 r. Zamawiający oświadczył, że uwzględnia również zarzut z pkt I.9. listy zarzutów oraz dodatkowo odniósł się do zarzutów, które pozostały sporne, i zgłosił w tym zakresie kolejne wnioski dowodowe.

3.Przystępujący po stronie Zamawiającego nie zgłosili sprzeciwu co do uwzględnienia przez niego odwołania w zakresie powyżej wskazanych zarzutów.

4.Odwołujący na posiedzeniu przed Izbą wycofał odwołanie w zakresie zarzutu z pkt I.2. listy zarzutów.

Zgodnie z art. 522 ust. 4 pzp w przypadku uwzględnienia przez zamawiającego części zarzutów przedstawionych w odwołaniu, Izba może umorzyć postępowanie odwoławcze w części dotyczącej tych zarzutów, pod warunkiem że w postępowaniu odwoławczym po stronie zamawiającego nie przystąpił w terminie żaden wykonawca albo wykonawca, który przystąpił po stronie zamawiającego, nie wniósł sprzeciwu wobec uwzględnienia tych zarzutów. W takim przypadku Izba rozpoznaje pozostałe zarzuty odwołania. Zamawiający wykonuje, powtarza lub unieważnia czynności w postępowaniu o udzielenie zamówienia, zgodnie z żądaniem zawartym w odwołaniu w zakresie uwzględnionych zarzutów.

Z kolei według art. 520 pzp odwołujący może cofnąć odwołanie do czasu zamknięcia rozprawy (ust. 1). Cofnięte odwołanie nie wywołuje skutków prawnych, jakie ustawa wiąże z wniesieniem odwołania do Prezesa Izby (ust. 2). Przy czym za oczywiste uznać należy, że skoro odwołujący może wycofać w całości odwołanie, tym bardziej może cofnąć odwołanie częściowo, które w tym zakresie nie wywołuje skutków prawnych.

Reasumując, postępowanie odwoławcze w zakresie zarzutów uwzględnionych i wycofanych należało uznać za podlegające umorzeniu.

W rezultacie sporne w sprawie pozostały zarzuty z pkt I.3. i I.8. listy zarzutów.

Z uwagi na brak podstaw do odrzucenia odwołania lub umorzenia postępowania odwoławczego w całości, sprawa w zakresie zarzutów, które pozostały sporne, została skierowana do rozpoznania na rozprawie, podczas której Strony i Przystępujący podtrzymali dotychczasowe stanowiska i argumentację.

Po przeprowadzeniu rozprawy z udziałem Stron i Przystępujących, uwzględniając zgromadzony materiał dowodowy, jak również biorąc pod uwagę oświadczenia i stanowiska wyrażone ustnie na rozprawie i odnotowane w protokole, Izba ustaliła i zważyła, co następuje:

Z art. 505 ust. 1 npzp wynika, że legitymacja do wniesienia odwołania przysługuje wykonawcy, jeżeli ma lub miał interes w uzyskaniu zamówienia oraz poniósł lub może ponieść szkodę w wyniku naruszenia przez zamawiającego przepisów ustawy.

W ocenie Izby Odwołujący wykazał, że ma interes w uzyskaniu przedmiotowego zamówienia, skoro jest zainteresowany udziałem w postępowaniu ogłoszonym przez Zamawiającego. Jednocześnie może ponieść szkodę w związku z zarzucanymi Zamawiającemu naruszeniami przepisów ustawy pzp, skoro powodują one, że nie będzie mógł w ogóle lub skutecznie ubiegać się o uzyskanie tego zamówienia.

Izba ustaliła następujące okoliczności jako istotne:

Co prawda wymaganie ogólne, aby oprogramowanie zaoferowane w ramach danej części zamówienia pochodziło od jednego producenta, który zapewnia dla nich – jak to określono – „wspólne wsparcie”, dotyczy nie tylko części 3., ale wyłącznie w odniesieniu do tej części zostało wniesione odwołanie, co przekłada się na zakres kognicji Izby.

Brzmienie pkt 1. i 2. rozdziału III SWZ pn. „Opis przedmiotu zamówienia dla części IIII” {dalej również: „OPZ”},

1. Przedmiotem zamówienia jest:

a) dostarczenie oprogramowania do wirtualizacji, zwanego dalej: „Oprogramowaniem”, wraz z licencjami na potrzeby uruchomienia i administrowania przez Zamawiającego (w trybie in-house w stosunku do Ministra Cyfryzacji) środowiska chmury prywatnej powstającej w ramach Wspólnej Infrastruktury Informatycznej Państwa, zgodnie z Uchwałą nr 97 Rady Ministrów z dnia 11 września 2019 r. (Dz. Urz. R.P. z dnia 24 września 2019 r., poz. 862) (zwanej dalej: „Chmurą prywatną”).

b) udzielenie wsparcia technicznego dla Oprogramowania na okres 36 miesięcy od dnia dostawy Oprogramowania zgodnie z zestawieniem wskazanym w rozdziale III oraz na warunkach opisanych w rozdziale V.

c) świadczenie usługi tzw. godzin eksperckich w ramach prawa opcji na warunkach określonych w rozdziale VI OPZ.

Zamawiający w ramach zamawianej infrastruktury buduje Chmurę prywatną w skład, której będzie wchodziło Oprogramowanie.

2. W celu zaspokojenia potrzeb infrastrukturalnych systemów informatycznych lokowanych docelowo w Chmurze prywatnej, Zamawiający musi mieć do dyspozycji, z uwagi na potrzebę zachowania zgodności migrowanych istniejących systemów informatycznych użytkowników końcowych do Chmury i w oparciu o wyniki badania popytu w tym zakresie, trzy odmienne (różne) technologie wirtualizacji (dalej: „Wirtualizatory”), których funkcjonalności oraz wymagania dotyczące uprawnień licencyjnych dla Zamawiającego, jako administrującego Chmurą prywatną; Skarbu Państwa reprezentowanego przez Ministra Cyfryzacji, jako licencjobiorcy udostępniającego środowisko oraz użytkowników końcowych opisane zostały poniżej.

Jak wynika z tabeli zamieszczonej w pkt III pn. „Wykaz Oprogramowania Chmury prywatnej (oprogramowanie referencyjne lub równoważne)” OPZ, część 3. zamówienia obejmuje następujące oprogramowanie:

1)Ret Hat Virtualization (wersja dla węzła dwuprocesorowego) lub oprogramowanie równoważne – 14 licencji,

2)Red Hat OpenStack Platform (wersja dla węzła dwuprocesorowego, bez dodatkowego systemu operacyjnego) lub równoważne – 136 licencji,

3)Red Hat Ceph Storage (w wersji obsługującej do 2 PB na maksymalnie 100 węzłach) – 2 licencje,

4)Red Hat Ansible Automation Platform (w wersji do zarządzania 100 węzłami) lub równoważne – 4 licencje

– przy czym dla każdego oprogramowania licencja ma być udzielona na 36 miesięcy i na taki okres ma być również zapewnione wsparcie techniczne na poziomie standardowym lub równoważnym.

Niesporne były przy tym następujące okoliczności.

Po pierwsze, że spośród tych czterech komponentów {według terminologii OPZ} stricte oprogramowaniem wirtualizacyjnym jest tylko to wymienione w 1. pkt, a w pozostałych pkt ujęto oprogramowanie narzędziowe służące odpowiednio do: przetwarzania danych w chmurze (pkt 2.), platforma do przechowywania danych jako obiekty (pkt 3.), automatyzacji konfiguracji i zarządzania infrastrukturą serwerową.

Po drugie, że każdy z tych komponentów oparty jest o otwartoźródłowe oprogramowanie [tzn. funkcjonujące na takich licencjach jak np. licencja General Public License (w skrócie „GPL”), GNU Lesser General Public License (w skrócie „LGPL”), Apache License], przeznaczone odpowiednio do tworzenia: KVM [skrót od ang. Kernel-based Virtual Machine – maszyna wirtualna bazująca na jądrze] – środowiska wirtualizacyjnego dla systemów linuksowych (pkt 1.), Open Stack – chmury obliczeniowej w modelu IaaS [skrót od ang. Infrastructure as a Service – infrastruktura jako usługa] (pkt 2.), Ceph – platformy do przechowywania danych typu SDS (skrót od ang. Software-definied Storage – przechowywanie zorientowane na oprogramowanie), implementującej pamięć obiektową w jednym rozproszonym klastrze komputerowym (pkt 3.), Ansible – automatyzacji wdrażania, konfiguracji i zarządzania na serwerach.

Natomiast półprawdą jest zawarte w odpowiedzi na odwołanie stwierdzenie, jakoby w ramach części 3. przedmiotem zamówienia był Wirtualizator KVM, Open Stack, Ceph czy Ansible. Gdyby tak było, OPZ sprowadzałby się do wskazania tych nazw i dopisku „lub równoważne” oraz podania kryteriów dla oceny równoważności w odniesieniu do tego oprogramowania, a nie do oprogramowania opracowanego na jego bazie przez producenta Red Hat.

Co istotne, Zamawiający zawarł w OPZ następujące zastrzeżenie: Wymagane jest aby Oprogramowanie było przeznaczone do modelu chmurowego. Nie dopuszcza się rozwiązań tzw. „szytych na miarę”. Wszystkie funkcjonalności oprogramowania muszą być dostępne z tzw. „pudełka”, tj. nie może to być oprogramowanie dedykowane, przez które Zamawiający rozumie oprogramowanie komputerowe (kod wynikowy oraz kod źródłowy) lub jego fragmenty dostarczone Zamawiającemu przez Wykonawcę (lub jego podwykonawców) w związku z realizacją Umowy, inne niż oprogramowanie standardowe [trzeci akapit od końca w pkt III. pn. „Scenariusz uruchomienia Chmury prywatnej i wymagania w zakresie Oprogramowania – dotyczy Części 1, 2 i 3”].

Z powyższego wynika, że wyprowadzana w odpowiedzi na odwołanie z istoty otwartego oprogramowania łatwość dostarczenia oprogramowania równoważnego do referencyjnego oprogramowania Red Hat jest wyłącznie teoretyczna, choć jednoczesne wskazywanie [w 2. zd. pkt 1.23.], że „Zamawiający nie ma (…) obowiązku zakupu gotowych rozwiązań”, sugeruje coś dokładnie odwrotnego. Innymi słowy parafrazując inne stwierdzenie Zamawiającego, wcale nie jest tak, że każdy z komponentów może dostarczyć każdy producent dzięki odpowiedniemu dostosowaniu kodu KVM, OpenStack, Ceph czy Ansible do wymagań OPZ, gdyż zaoferowanie takiego oprogramowania na potrzeby tego zamówienia będzie wprost stało w sprzeczności z przywołanym powyżej postanowieniem opisu przedmiotu zamówienia.

Zamawiający w kolejnym piśmie procesowym pośrednio potwierdził taki stan rzeczy, gdyż w ramach próby wykazywania braku ograniczenia konkurencji przesunął punkt ciężkości na – jak to określił – „konkurencję wewnątrzmarkową” pomiędzy dystrybutorami produktów Red Hat, wychodząc z oczywiście błędnego założenie, że jakiekolwiek znaczenie dla sprawy może mieć okoliczność, jak wielu ich jest i czy Odwołujący jest jednym z nich.

Co prawda Zamawiający jednocześnie podtrzymał twierdzenie o łatwości zaoferowania – jak to tym razem określił – „technologii równoważnej do Red Hat”, z uwagi na możliwość wykorzystania otwartego kodu, jednak nie był w stanie wskazać żadnego innego producenta oprogramowania, który ma w swojej ofercie gotowe produkty odpowiadające wszystkim czterem komponentom objętym częścią 3. Nie dziwi to o tyle, o ile wydaje się mało prawdopodobne, aby znalazł się inny producent, który spośród możliwych wariantów modyfikacji niezliczonego oprogramowania o otwartym kodzie źródłowym służącego zaspokajaniu różnych potrzeb różnych użytkowników, zdecydował się na przystosowanie akurat KVM, OpenStack, Ceph, Ansible, i to w dokładnie taki sam sposób, jak uczynił to już uprzednio Red Hat.

Przede wszystkim taki stan rzeczy znalazł potwierdzenie w sporządzonej przez Odwołującego „Analizie rynku w zakresie dostępności produktów spełniających zapisy OPZ/SWZ” [załącznik nr 1 do pisma procesowego Odwołującego z 16 lipca 2021 r.], co wobec braku konkretnego odniesienia się do niej przez Zamawiającego, Izba na zasadzie art. 533 ust. 2 pzp uznała za fakt przyznany (również co do tego, że projektem open source najbardziej zbliżonym do Red Hat Virtualization jest oVirt, a nie KVM). W szczególności z analizy tej wynika, że spośród piętnastu producentów oprogramowania innych niż Red Hat tylko dwóch (Ultimum Technologies i H3C) oferuje trzy z czterech kategorii oprogramowania (jednak nierzadko nie spełniającego jednego ze szczegółowych wymagań OPZ), a znakomita większość pozostałych dysponuje gotowym oprogramowaniem tylko w zakresie jednego z komponentów wchodzących w zakres części 3. tego zamówienia.

Zamawiający chętnie i często w treści odpowiedzi na odwołanie i dalszego pisma procesowego używa terminu „technologia”, jednak niekonsekwentnie i na dużym poziomie ogólności. Deprecjonuje to jego argumentację odwołującą się do konieczności zapewnienia w ramach części 3. jednolitej czy jednorodnej technologii, gdyż nie sposób stwierdzić, co dokładnie przez to rozumie. Po pierwsze, w ramach próby wykazania, że opis przedmiotu zamówienia jest otwarty na konkurencję, jest to „technologia open source”, w której wykonane są Ansible, Ceph, OpenStack i KVM, czyli termin „technologia” został odniesiony do oprogramowania otwartoźródłówego jako takiego [patrz pkt 1.24., str. 17. odpowiedzi na odwołanie]. Po drugie, w ramach argumentacji wskazującej, że wystarczającym dla zapewnienia konkurencyjności jest podział tego zamówienia części 1.-3. tego zamówienia, podkreślone zostało, że zgodnie z pkt I.2. OPZ [który został powyżej przywołany w całości] przedmiotem każdej z nich są „trzy odmienne (różne) technologie wirtualizacji” [patrz pkt 1.32. zd. 2., str. 20. odpowiedzi na odwołanie] Po trzecie, przyznając de facto, że zakresem zamówienia w części 3. objęte jest nie tylko stricte oprogramowanie do wirtualizacji, wskazano, że uczynienie zadość żądaniu odwołania spowodowałoby, że „zamiast jednej technologii funkcjonowałby nawet cztery różne technologie, inna w zakresie wirtualizatora oraz inne w zakresie (…) narzędzi” [patrz pkt 1.32. zd. 3, str. 21. odpowiedzi na odwołanie]. W tym samym znaczeniu, jak się wydaje, dla uzasadnienia opisania przedmiotu zamówienia z odwołaniem się do konkretnego oprogramowania Red Hat pada w szczególności stwierdzenie, że „Red Hat oferuje cztery komponenty opierające się na tożsamej technologii” [patrz pkt 1.6. zd. 1. i 2. pisma procesowego z 22 lipca 2021 r.].

Według Słownika języka polskiego PWN technologia oznacza metodę przeprowadzania procesu produkcyjnego lub przetwórczego [patrz sjp/technologia;2577699.html]. Wydaje się że nie można uznać wszystkich czterech komponentów objętych częścią 3. zamówienia za jednorodne technologicznie w tym słownikowym znaczeniu, skoro poza wszelkim sporem jest okoliczność, że nie wszystkie zostały napisane w tym samym języku programowania, a nawet nie zawsze w całości zostały zaprogramowane przy użyciu jednego języka programowania – oVirt czy Red Hat Virtualization w Javie (KVM w C), OpenStack czy Red Hat OpenStack Platform oraz Ceph czy Red Hat Ceph Storage w C++ i Pythonie, a Ansible czy Red Hat Ansible Automation Platform w Pythonie, PowerShellu, Shellu i Ruby.

Z kolei pojęcie technologii informatycznej (informatics technology – IT) odnosi się głównie do zastosowania informatyki w społeczeństwie i oznacza naukowo uzasadniony sposób posługiwania się środkami informatycznymi [A. Rokicka-Broniatowska, Wstęp do informatyki gospodarczej, Wydawnictwo Hobbit, Warszawa 2002, str. 229]. W ramach technologii informatycznej wyróżnia się trzy podstawowe warstwy, które ją współtworzą, tj.: 1)  sprzęt – opisująca urządzenia informatyczne w aspekcie ich użyteczności w procesach informacyjnych, bez problemów budowy i konserwacji, 2) struktury danych – obejmująca problemy operowania danymi, 3) procedury przetwarzania danych – określająca warunki posługiwania się techniką informacyjną [patrz Toc530589283]. Przy czym zwraca się uwagę na występowanie różnego rodzaju technologii informatycznych, takich jak np.: 1) technologie przetwarzania danych, 2) technologie przetwarzania informacji, 3) technologie przetwarzania wiedzy, 4) technologie przetwarzania tekstów, 5) sztuczna inteligencja, 6) bazy danych, 7) hurtownie danych, 8) sieci komputerowe, 9) technologie multimedialne. Przy czym do środków informatycznych wykorzystywanych przy przetwarzaniu informacji w przypadku technologii informatycznych zalicza się: sprzęt komputerowy, masowe pamięci zewnętrzne, środki teletransmisji danych wraz z komputerami, środki multimedialne. [A. Rokicka-Broniatowska, Wstęp do informatyki gospodarczej, op. cit., str. 7]. Zatem również patrząc przez pryzmat pojęcia „technologii informatycznej” nie sposób stwierdzić, jakoby dla uznania oprogramowania za jednorodne technologicznie jakiekolwiek znaczenie miało jego pochodzenie od jednego producenta.

Zamawiający de facto oprogramowanie wykonane tej samej technologii utożsamia z oprogramowaniem pochodzącym od tego samego producenta. Takie podejście nie znajduje jednak oparcia w żadnym z przywołanych powyżej znaczeń terminów „technologia” czy „technologia informatyczna”, według których znaczenie mają konkretne aspekty techniczne. Stąd równie dobrze w tej samej technologii może być wytworzone oprogramowanie pochodzące od różnych producentów.

W treści skarżonego wymagania mowa jest również o wspólnym – dla wszystkich czterech komponentów objętych częścią 3. – wsparciu, które ma zapewnić ich producent. Z pkt V OPZ i § 5 wzoru umowy, określających łącznie kompleksowe uregulowanie wymagań odnośnie wsparcia technicznego (okres, zakres i sposób pełnienia), nie wynika, aby owo „wspólne wsparcie” było czymś więcej niż po prostu konsekwencją wymagania pochodzenia całości oprogramowania od tego samego producenta. Innymi słowy równie dobrze tak określone warunki wsparcia mogą być spełnione w sytuacji, gdy poszczególne komponenty będą pochodzić od różnych producentów.

To wykonawca jako strona umowy zobowiązuje się do zapewnienia wsparcia technicznego świadczonego z najwyższą starannością, zgodnie z najlepszymi standardami obowiązującymi w branży informatycznej [§ 4 ust. 6 wzoru umowy]. Stąd ponosi odpowiedzialność za świadczenie wsparcia na warunkach określonych przez Zamawiającego. W szczególności niezapewnienie, aby zgłoszenia w przeznaczonym do tego portalu producenta oprogramowania były przyjmowane 24 godziny na dobę, przez 7 dni w tygodniu, zagrożone jest naliczeniem wykonawcy kary umownej [§ 11 ust. 1 pkt 3 w zw. z § 4 ust. 2 wzoru umowy]. Z kolei na wypadek niewykonania jakiegokolwiek obowiązku umownego przez wykonawcę Zamawiający zastrzegł dla siebie umowne prawo odstąpienia, w tym odstąpienia w trybie natychmiastowym [§ 12 ust. 2 pkt 1 i 3 wzoru umowy].

Przede wszystkim w zakresie przez siebie nieuregulowanym Zamawiający zdał się na standardowe warunki wsparcia producenta oprogramowania, wymagając jedynie od wykonawcy ich doręczenia i to dopiero po zawarciu umowy [pkt V odpowiednio pkt 2 i 8 OPZ]. W ten sposób Zamawiający nie zagwarantował sobie jednolitości standardu „wspólnego wsparcia”, gdyż ten sam producent nie musi zapewniać takiego samego wsparcia dla każdego ze swoich produktów. Odmienny standard wsparcia dla poszczególnych kategorii oprogramowania może być również uwarunkowany ich odmienną specyfiką, która powoduje, że określone czynności w przypadku jednych są celowe, a dla innych zbędne. Niezależnie od tego różni producenci mogą oferować odmienny standard wsparcia dla tej samej kategorii oprogramowania.

Nie ma znaczenia, czy akurat w przypadku swoich produktów Red Hat zapewnia wsparcie na analogicznych warunkach, które satysfakcjonują Zamawiającego, gdyż w kontekście wymagania, aby niewymagające przystosowania oprogramowanie równoważne pochodziło od jednego producenta zapewniającego dla niego bliżej niesprecyzowane „wspólne wsparcie”, prowadzi to do wniosku, że przy takich warunkach w tym przetargu może być zaoferowane wyłącznie oprogramowanie referencyjne.

Nie zostało przy tym wykazane przez Zamawiającego, który nie przedstawił w tym zakresie żadnych dowodów, że osiągnięcie założonego w studium wykonalności wskaźnika 98,75% dostępności usługi Rządowej Chmury Obliczeniowej jest uwarunkowane świadczeniem wsparcia przez jednego producenta w zakresie oprogramowania objętego częścią 3. Przede wszystkim, jeżeli Zamawiający ma określone oczekiwania w zakresie poziomu niezawodności, które ma zapewniać wdrożenie zamawianego w ramach części 3. oprogramowania, czy co do niezakłóconego współdziałania tego oprogramowania, może i powinien wprowadzić w tym zakresie do opisu przedmiotu zamówienia stosowne wymagania.

Jak wynika z OPZ i wzoru umowy, Zamawiający w ramach opcjonalnej części zamówienia przewidział w odniesieniu do oprogramowania nabywanego w ramach części 3. świadczenie przez wykonawcę usługi tzw. godzin eksperckich, świadczonej przez inżyniera certyfikowanego przez producenta danego Wirtualizatora {jak to już powyżej ustalono – na potrzeby tego postępowania to określenie nie ogranicza się wyłącznie do oprogramowania do wirtualizacji} na poziomie eksperta, dotyczącej m.in. konsultacji, instruktażu, usuwania wątpliwości lub rozwiązywania bieżących problemów Zamawiającego związanych z obsługą, w tym instalacją, konfiguracją, utrzymaniem i administracją oprogramowania, jego integracją z aplikacjami i systemami, w miejscu zainstalowania oprogramowania lub zdalnie – zgodnie z wnioskiem Zamawiającego – realizowanej w dni robocze, w godzinach od 7:00 do 17:00 w maksymalnym zakresie 690 roboczogodzin [OPZ pkt VI.1].

Oznacza to, że Zamawiający ma świadomość, że również w sytuacji, gdy oprogramowanie objęte częścią 3. pochodziłoby od jednego producenta, nie ma gwarancji, że bez wsparcia ze strony wykonawcy będzie je w stanie samodzielnie wdrożyć. Z  kolei o tym, że skala antycypowanych w tym zakresie problemów jest z założenia większa dla oprogramowania z części 3. świadczy okoliczność, że dla oprogramowania zamawianego w ramach części 2. (referencyjne oprogramowanie korporacji Microsoft) przewidział świadczenie takiej usługi w wymiarze niemal siedmiokrotnie mniejszym (100 roboczogodzin) a dla części 1. (referencyjne oprogramowanie korporacji VMWare) uznał, że nie będzie ona potrzebna.

Reasumując, w zakresie drugiego zarzutu, który pozostał sporny, Izba ustaliła, że pochodzenia oprogramowania objętego częścią 3. od jednego producenta nie stanowi ani parametru technicznego, ani nawet funkcjonalnego, co przy wyłączeniu możliwości dostosowywania oprogramowania na potrzeby tego zamówienia powoduje, że pomimo formalnego dopuszczenia oprogramowania równoważnego, faktycznie zaoferowane może być tylko wskazane z nazwy oprogramowanie producenta Red Hat.

Odmiennie przedstawia się stan rzeczy w przypadku wymaganej w odniesieniu do równoważnego dla Red Hat OpenStack Platform oprogramowania cechy, aby możliwe było zainstalowanie tego oprogramowania również na opartych o procesory Power 8 lub Power 9 (czyli procesory w architekturze ppc64le) serwerach z zainstalowanym firmwarem OPAL (a nie tylko na serwerach z 64bitowymi procesorami w architekturze x86).

W pierwszej kolejności należy odnotować, że w toku postępowania odwoławczego niesporne okazało się, że powyższe wymaganie może de facto odnosić się do wyłącznie do instalacji tego komponentu oprogramowania na serwerach zgodnych z modelem programowym ppc64le działających jako węzły obliczeniowe klastra. Okoliczność ta została podniesiona w odwołaniu i została potwierdzona przez Zamawiającego, nie ma znaczenia, że dopiero w piśmie procesowym z 22 lipca 2021 r. [w pkt 1.20. na str. 12.]

Za bezsporne należy również uznać, że dzięki wykorzystaniu opracowanego przez IBM (jako producenta platformy ppc64le) interfejsu programowego PowerVM NovaLink, służącego do zarządzania wirtualizacją, również możliwe jest wykorzystanie serwerów z procesorem Power 8 lub Power 9, jako węzłów obliczeniowych, w tym zarządzanie nimi z poziomu oprogramowania OpenStack różnych producentów, co akcentował Odwołujący, domagając się dopuszczenia takiego rozwiązania jako równoważnego do referencyjnego.

Jednakże w ramach zarzutu zawartego w odwołaniu Odwołujący przeszedł do porządku dziennego nad elementem wymagania, który wskazuje, że odnosi się ono do serwerów opartych o procesory Power 8 lub Power 9 z zainstalowanym firmwarem OPAL. W szczególności okoliczności faktyczne podniesione dla uzasadnienia tego zarzutu w ogóle nie odnoszą się do kwestii zgodności wnioskowanego rozwiązania z firmwarem OPAL.

Tymczasem Zamawiający udowodnił, że nie ma możliwości uruchomienia zwirtualizowanych węzłów obliczeniowych na serwerach Power 8 lub Power 9 z firmware OPAL w oparciu o PowerVM z modułem NovaLink [korespondencja mailowa z pracownikiem IBM Polska sp. z o.o. z siedzibą w Krakowie załączona do pisma z 22 lipca 2021 r. jako dowód 24.]. Jest to konsekwencją tego, że przy konfiguracji oprogramowania układowego (czyli firmware) należy wybrać albo PowerVM, albo OPAL [wydruk oficjalnej dokumentacji wsparcia udostępnianej przez IBM na jego stronie internetowej wraz z tłumaczeniem, załączone do pisma z 22 lipca 2021 r. jako dowód 25]. Przy czym za niesporne, bo wynikające wprost z dowodu wnioskowanego przez Odwołującego, należy uznać, że PowerVM NovaLink można zainstalować wyłącznie na serwerze z procesorem Power 8 lub Power9 wirtualizowanym przy użyciu technologii PowerVM [co wynika z zakreślonego w ramce jako istotny drugiego akapitu wydruku z oficjalnej strony wsparcia IBM złożonego na  rozprawie przez Odwołującego].

Niezależnie od powyższego Izba stwierdziła, że skoro przedmiotem wymagania są serwery oparte o procesory Power 8 lub Power 9, czyli rodziny procesorów dwóch generacji dostępne odpowiednio od 2014 r. i 2017 r., przy czym według powszechnie dostępnych informacji przed końcem 2021 r. ma być już dostępna kolejna generacja Power 10, oczywiste jest, że kwestionowane wymaganie co najmniej w części odnosi się do już posiadanych zasobów sprzętowych, a nie tylko serwerów platformy pc64le, które zostaną dopiero zakupione w przyszłości.

Tymczasem w odwołaniu nie uwzględniono tej okoliczności (a w późniejszym piśmie procesowym sugerowane jest wręcz, że wymaganie jest nieuzasadnione jako narzucanie rozwiązania w odniesieniu do serwerów, które zostaną dopiero zakupione), ani w aspekcie stawianego zarzutu, ani w aspekcie skorelowanego z nim żądania. Innymi słowy Odwołujący mógł i powinien w odwołaniu wskazać, w jaki sposób przy takich zobiektywizowanych uwarunkowaniach po stronie Zamawiającego miałoby nastąpić dopuszczenie jako równoważnego wnioskowanego rozwiązania.

Reasumując, w zakresie drugiego zarzutu, który pozostał sporny, Izba ustaliła, że w powyższych uwarunkowaniach Odwołujący – na którym z mocy art. 534 ust. 1 pzp spoczywał w tym zakresie ciężar – co najmniej nie uprawdopodobnił, że zaskarżone wymaganie opisu przedmiotu zamówienia jest nadmiernie rygorystyczne jako niewynikające z rzeczywistych i zobiektywizowanych potrzeb Zamawiającego.

W tych okolicznościach nie ma znaczenia dla sprawy, ile produktów dostępnych na rynku spełnia powyższe wymaganie techniczne.

Izba stwierdziła, że w tych okolicznościach odwołanie jest w połowie zasadne.

Zgodnie z art. 16 pkt 1 pzp zamawiający przygotowuje i przeprowadza postępowanie o udzielenie zamówienia w sposób zapewniający zachowanie uczciwej konkurencji oraz równe traktowanie wykonawców.

Art. 99 pzp zawiera w szczególności następujące uregulowania.

[W ust. 2] Zamawiający określa w opisie przedmiotu zamówienia wymagane cechy dostaw, usług lub robót budowlanych. Cechy te mogą odnosić się w szczególności do określonego procesu, metody produkcji, realizacji wymaganych dostaw, usług lub robót budowlanych, lub do konkretnego procesu innego etapu ich cyklu życia, nawet jeżeli te czynniki nie są ich istotnym elementem, pod warunkiem że są one związane z przedmiotem zamówienia oraz proporcjonalne do jego wartości i celów.

[W ust. 4] Przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów.

[W ust. 5] Przedmiot zamówienia można opisać przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli zamawiający nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”.

[W ust. 6] Jeżeli przedmiot zamówienia został opisany w sposób, o którym mowa w ust. 5, zamawiający wskazuje w opisie przedmiotu zamówienia kryteria stosowane w celu oceny równoważności.

W pierwszej kolejności zauważyć należy, że pomimo wskazania w petitum odwołania na naruszenie wszystkich z powyżej przywołanych przepisów, okoliczności podniesione w związku z zarzutami, które się ostały, dotyczą dokonania opisu przedmiotu zamówienia w sposób, który narusza konkurencję, gdyż zaskarżone kryteria równoważności de facto uniemożliwiają zaoferowanie oprogramowania równoważnego, a więc stanowią zarzuty naruszenia przez Zamawiającego art. 99 ust. 4 w zw. z art. 99 ust. 6 pzp.

Rozpoznawane zarzuty dotyczą jednego z najczęściej rozważanego w doktrynie i orzecznictwie zagadnienia prawnego na tle analogicznego przepisu poprzedniej ustawy pzp (różnica sprowadza się do braku w dawnym art. 29 ust. 2 części przepisu wskazującej na czym w szczególności może polegać dokonanie opisu przedmiotu zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję). Nie tylko z tego powodu, że wiele wypowiedzi doktryny i judykatury zostało zaprezentowanych przez obie strony rozpoznawanej sprawy, nie ma potrzeby ich powtórnego przytaczania czy przywoływania kolejnych. Przede wszystkim specyfika tego zagadnienia jest taka, że jego rozstrzygnięcie na korzyść którejś ze stron sporu wiąże się ściśle z poczynionymi w danej sprawie ustaleniami faktycznymi, które z kolei wynikają z zakresu zarzutów zawartych w odwołaniu i wyniku przeprowadzonego w tym zakresie w toku rozprawy postępowania dowodowego.

W uproszczeniu orzekanie w sporze, gdzie zarzucane jest dokonanie opisu przedmiotu zamówienia w sposób, który może utrudniać uczciwą konkurencję, sprowadza się bowiem do znalezienia złotego środka, pozwalającego uwzględnić zarówno interes instytucji zamawiającej w uzyskaniu świadczenia, które zaspokoi jej zobiektywizowane potrzeby, jak i interes wykonawcy w ubieganiu się o zawarcie z nim umowy na wykonanie tego świadczenia. Interesy te okazują się być sprzeczne w sytuacji, gdy instytucje zamawiające zmierzają do osiągnięcia celu w najprostszy możliwy sposób, przez takie opisanie przedmiotu zamówienia, który co prawda gwarantuje im uzyskanie pożądanego przedmiotu świadczenia, ale jednocześnie prowadzi do uniemożliwienia ubiegania się o udzielenie zamówienia wielu wykonawcom, którzy również uważają się za zdolnych do spełnienia świadczenia zaspokajającego uzasadnione potrzeby instytucji zamawiającej.

Generalnie każdy opis przedmiotu zamówienia prowadzi do ograniczenia konkurencji, gdyż nawet opisanie przez zamawiającego przedmiotu zamówienia zgodnie z zasadami wynikającymi z art. 99 ust. 1 pzp zawsze będzie prowadziło do przewagi niektórych spośród potencjalnych wykonawców nad innymi. Niemożliwe jest bowiem określenie wymagań dotyczących przedmiotu zamówienia w taki sposób, aby umożliwić złożenie oferty wszystkim wykonawcom działającym na danym rynku. Wynika to z tego, że zamawiający jest uprawniony i obowiązany do dokonania takiego opisu, który zapewni mu uzyskanie przedmiotu zamówienia zaspokającego jego potrzeby, a nie do zapewnienia w prowadzonym w tym celu postępowaniu absolutnej konkurencji.

Jednakże potrzeby zamawiającego muszą mieć charakter zobiektywizowany, gdyż tylko wtedy można je uznać za uzasadnione. W zamówieniach publicznych na dostawy przejawia się to w tym, że zamawiający (de facto z wyjątkiem trybu zamówienia z wolnej ręki) nie może wskazać wyłącznie na konkretny produkt, który uważa za najlepiej zaspokajający jego potrzeby, ale jednocześnie nie może wykluczyć (skoro nie stwierdził postaw do udzielenia zamówienia z wolnej ręki), że na rynku funkcjonują inne produkty różnych producentów, które w równym stopniu mogą te potrzeby zaspokajać. W takiej sytuacji niedopuszczenie możliwości zaoferowania tych produktów prowadzi do dyskryminowania wykonawców, gdyż nie jest uzasadnione zobiektywizowanymi potrzebami zamawiającego.

Stąd jak trafnie wskazano w uzasadnieniu wyroku Izby z 28 stycznia 2021 r. sygn. akt KIO 8/21: (…) zamawiający może dopasować zamówienie do swoich obiektywnych potrzeb, ale powinien umieć wykazać, że to zawężenie gwarantuje mu wyższą jakość, większą użyteczność czy trwałość. Zasada przejrzystości postępowania wymaga bowiem tego, aby wydatkując środki publiczne zamawiający był w stanie wykazać ich celowość i efektywność. Przedmiot zamówienia powinien odpowiadać potrzebom zamawiającego, jego możliwościom finansowym, brać pod uwagę bieżący stan wiedzy.

W ustalonych powyżej okolicznościach należało zatem stwierdzić, co następuje.

Zarzut 1. – Zamawiający nie był w stanie wykazać, że pochodzenie całości oprogramowania od jednego producenta, które to wymaganie nie ma charakteru technicznego, jest konieczne dla zaspokojenia jego potrzeby nabycia oprogramowania do wirtualizacji oraz stworzenia chmury obliczeniowej na potrzeby administracji rządowej.

Zarzut 2. – Zamawiający wykazał, że po jego stronie występuje potrzeba zainstalowania niektórych komponentów zamawianego oprogramowania również na serwerach opartych o procesory Power 8 lub Power 9 (czyli procesory w architekturze ppc64le) z zainstalowanym firmwarem OPAL, co stanowi wymaganie techniczne wynikające z dysponowaniem takim hardwarem.

O ile potwierdził się pierwszy z zarzutów, o tyle nie mogło zostać uwzględnione zgłoszone w związku z nim żądanie, aby Zamawiający dokonał podziału części 3. zamówienia na dwie odrębne części, z których pierwsza miałaby dotyczyć wirtualizatora Red Hat Virtualization lub równoważnego. Takie żądanie w oczywisty sposób wykracza poza składające się na zarzut okoliczności, które sprowadzały się do wykazania, że w sytuacji, gdy przedmiotem zamówienia w ramach 3. części zamówienia jest zarówno oprogramowanie do wirtualizacji, jak i oprogramowanie narzędziowe przeznaczone do budowy chmury obliczeniowej, wymaganie pochodzenia całości tego zróżnicowanego oprogramowania od jednego producenta de facto czyni fikcją formalną możliwość zaoferowania oprogramowania równoważnego. Innymi słowy usunięcie w odniesieniu do części 3. wymagania, aby wszystkie komponenty oprogramowania musiały pochodzić od jednego producenta i musiały posiadać wspólne wsparcie realizowane przez jednego producenta, usuwa podniesione w odwołaniu naruszenie art. 99 ust. 4 w zw. z art. 99 ust. 6 ustawy pzp.

Mając powyższe na uwadze, Izba stwierdziła, że naruszenie przez Zamawiającego art. 16 ust. 1 pkt 1 w zw. z art. 99 ust. 4 i 6 ustawy pzp może mieć istotny wpływ na wynik prowadzonego przez niego postępowania o udzielenie zamówienia – wobec czego – działając na podstawie art. 554 ust. 1 pkt 1, ust. 2 i ust. 3 pkt 1 lit. a oraz b nowej ustawy pzp – orzekła, jak w pkt 1. sentencji, w pozostałym zakresie oddalając odwołanie – jak to wskazano w pkt 2. sentencji.

O kosztach postępowania odwoławczego w tej sprawie, na które złożył się uiszczony wpis oraz koszty zastępstwa przez Izbą Odwołującego (potwierdzone złożonym do zamknięcia rozprawy rachunkiem), orzeczono stosownie do jej wyniku na podstawie art. 557 nowej ustawy pzp w zw. z § 5 pkt 1 i 2 lit. b oraz § 7 ust. 2 pkt 1, ust. 3 pkt 1 i 2, ust. rozporządzenia Prezesa Rady Ministrów z dnia 30 grudnia 2020 r. w sprawie szczegółowych rodzajów kosztów postępowania odwoławczego, ich rozliczania oraz wysokości i sposobu pobierania wpisu od odwołania (Dz. U. poz. 2437) – obciążając nimi po połowie Odwołującego i Zamawiającego, w szczególności uznając, że waga zarzutu uwzględnionego odpowiada wadze zarzutu nieuwzględnionego.