Sygn. akt 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 Warsz
awie 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:
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.
Oddala odwołanie w pozostałym zakresie.
Sygn. akt KIO 1724/21
3. K
osztami postępowania obciąża Zamawiającego i Odwołującego po połowie i:
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ącego
tytułem wpisu od odwołania;
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.
Sygn. akt KIO 1724/21
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 z
godnie 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
Sygn. akt KIO 1724/21
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 dl
a 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.
, 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
Platfor
m” 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
Sygn. akt KIO 1724/21
– 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, Tr
ove” 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 Automa
tion 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
Sygn. akt KIO 1724/21
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 po
siadać 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 - Oprogram
owanie 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
Sygn. akt KIO 1724/21
– 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
reali
zowane 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
Sygn. akt KIO 1724/21
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:
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 lu
b 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 aktual
nej 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 upgr
adu, 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 O
programowania oraz warunki usługi wsparcia technicznego odpowiednio dla każdej
Sygn. akt KIO 1724/21
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 Ans
ible 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
odpowiedni
o dla każdej z Części. Część 3 – WIRTUALIZATOR C, tabela "Red Hat
OpenSt
ack 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
Sygn. akt KIO 1724/21
PowerVM Nov
aLink 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
Sygn. akt KIO 1724/21
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
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"
§ 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 zakresi
e powyższych postanowień Zamawiającemu zarzucam naruszenie następujących
przepisów:
1) art. 99 ust. 1 PZP w zw. art. 3531 Kod
eksu 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,
a
nastę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:
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
Sygn. akt KIO 1724/21
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 wypowiedze
nia lub odstąpienia od umowy przez Zamawiającego.
III.
Termin odstąpienia od umowy przez Zamawiającego [Zarzut #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:
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 nieweryfikowal
nego przez wykonawców
stawiając powyższe zarzuty wnoszę o nakazanie Zamawiającemu:
1) dokonania odpowiedniej modyfi
kacji 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 nieweryfikowaln
ego 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:
Sygn. akt KIO 1724/21
{ad pkt I.3. listy zarzutów}
Brak dopuszczenia rozwiązania równoważnego do rozwiązania producenta Red Hat
[Zarzut #1]
1.1. Przedmiotem niniejszego P
ostępowania jest zakup sprzętu i oprogramowania
wirtualizacyj
nego 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
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
odpowiedni
o 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.
Sygn. akt KIO 1724/21
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).
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 An
sible 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.
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.
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
Sygn. akt KIO 1724/21
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 Zama
wiają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.
Dodatkowo, w ocenie Odwołującego pochodzenie komponentów w części C
od jedne
go 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
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)”
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
Sygn. akt KIO 1724/21
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 istniej
e 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.
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 ogr
aniczona 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.
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.
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.
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 odpowiedni
o 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ć
Sygn. akt KIO 1724/21
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}:
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 rozw
ią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”,
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
Sygn. akt KIO 1724/21
oprogramowania wskazu
ją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 nini
ejszym 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.
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.;
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”.
w wyroku z dnia 22 stycznia 2013 r. (sygn. KIO 20/13) „Pojęcie równoważności nie
Sygn. akt KIO 1724/21
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.”
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 wy
konawców i uczciwej konkurencji”
1.61.5. w wyroku z dnia 24 lutego 2014 r. (sy
gn. 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”.
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.
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
Sygn. akt KIO 1724/21
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.
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.
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”.
Sygn. akt KIO 1724/21
Argumentacja Odwołującego potwierdza, że ograniczenie konkurencji w Postępowaniu
ni
e 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 ucz
ciwej 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}
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 z
amó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
tyt
ułu, że Odwołujący nie spełnia wszystkich wymagań postawionych przez Zamawiającego.
1.23 Zamawi
ają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
Sygn. akt KIO 1724/21
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 oc
enie 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 za
mó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 zd
ecydowanie 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
swobod
nego 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 modyfi
kować 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 wy
magań. Twierdzenie
Sygn. akt KIO 1724/21
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
te
chnologii 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}
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
wirtuali
zatora „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ć
Sygn. akt KIO 1724/21
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
oprog
ramowania 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 Wn
iosek 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
Sygn. akt KIO 1724/21
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
widz
enia 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.
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
Sygn. akt KIO 1724/21
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ą
pr
oducentów w okresie gwarancji, przy takim samym producencie zarówno jednostki
cent
ralnej, 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
infrastrukt
ury 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
p
ochodzenie jego poszczególnych elementów od tego samego producenta. Budowana
infrastr
uktura 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ą
o
fertę. 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
produ
centó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
podstawo
wych zasad udzielania zamówień publicznych, skoro na rynku istnieje szereg
podmiotów mogących brać udział w przedmiotowym postępowaniu. Zamawiający ma
Sygn. akt KIO 1724/21
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 zintegrowane
go w możliwie jak największym
zakresi
e, 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ść
wymi
any 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}
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 odpowiedni
o 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 zakres
ie w jakim Zamawiający opisuje sposób działania rozwiązania i wykorzystania
platformy Power, pod
czas gdy istnieją inne sposoby wykorzystania węzłów obliczeniowych
z procesorami P
ower. 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 zw
ią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:
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.
Sygn. akt KIO 1724/21
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.
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.
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
dotychcz
asowe stanowiska i argumentację.
Po przeprowadzeniu rozp
rawy z udziałem Stron i Przystępujących, uwzględniając
zgr
omadzony 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:
Sygn. akt KIO 1724/21
Z art. 505 ust. 1 n
pzp 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
I-
III” {dalej również: „OPZ”},
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 Oprogramowani
a 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 syste
mó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
Sygn. akt KIO 1724/21
(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 zos
tał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
obejmuj
e 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,
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 za
rzą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), implementu
jącej pamięć obiektową
w jednym rozproszonym klastrze komputerowym (pkt 3.), Ansible
– automatyzacji wdrażania,
konfiguracji i
zarządzania na serwerach.
Sygn. akt KIO 1724/21
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
oprogramo
wania łatwość dostarczenia oprogramowania równoważnego
do referencyjnego oprogramowania Red Hat jes
t 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.
Zam
awiają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
Sygn. akt KIO 1724/21
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
Od
woł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. 5
33 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.
Z
amawiają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 wirtu
alizacji, 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.].
Sygn. akt KIO 1724/21
W
edług Słownika języka polskiego PWN technologia oznacza metodę
przeprowadzania procesu produkcyjnego lub przetwórczego [patrz https://sjp.pwn.pl/
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.:
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 http://il.pw.edu.pl/~vine/inf/pl_13.htm#_
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 kompu
terami, ś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 oprogramowanie
m 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.
Sygn. akt KIO 1724/21
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
Sygn. akt KIO 1724/21
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 ek
sperta, 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 oprogramowan
ia 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
Sygn. akt KIO 1724/21
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 64-bitowymi 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 a
kapitu 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
Sygn. akt KIO 1724/21
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
proce
sowym 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 potrze
b 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 zamaw
iają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] Z
amawiają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 inne
go etapu ich cyklu życia, nawet jeżeli
te czynniki n
ie 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
utrudni
ać 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.
Sygn. akt KIO 1724/21
[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
zama
wiają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.
Rozpoznaw
ane 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 s
pecyfika 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
instytucj
i 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
Sygn. akt KIO 1724/21
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
prze
jawia 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
wy
konawcó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 po
winien 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ść.
Przedmi
ot 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 administrac
ji 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.
Sygn. akt KIO 1724/21
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.
Otrzymuj raz w tygodniu aktualne informacje
o zmianach w prawie oraz komentarzach ekspertów
Otrzymasz darmowy e-book w prezencie!
„6 pytań o znowelizowane przepisy Pzp"