Sygn. akt: KIO 4777/24 WYROK Warszawa, dnia 15.01. 2025 r. Krajowa Izba Odwoławcza - w składzie: Przewodnicząca:Agata Mikołajczyk Protokolant: Tomasz Skowroński po rozpoznaniu na rozprawie w dniu 10 s
ust. 2 i 3, nie może zawierać ograniczeń polegających na tym, że dane oprogramowanie może być używane wyłącznie z innym oprogramowaniem lub może być wdrażane, serwisowane, rozwijane itp. wyłącznie przez określony podmiot lub grupę podmiotów. Błędnie wskazuje Zamawiający, iż zapis ten dotyczy licencji na bazę danych. Zapis ten odnosi się bowiem do licencji,
§ 6ust.
2 i 3, a więc do licencji na cały System i Rezultaty prac, nie zaś na poszczególne składniki Systemu (w tym oprogramowanie bazodanowe). Zatem to System jako całość nie może zawierać ograniczeń, o których mowa w § 6 ust. 12 PIPU. Przedmiotowy zapis nie reguluje natomiast relacji wewnętrznych pomiędzy danymi składnikami Systemu. I tak: 38.Wniosek taki w sposób oczywisty narzuca się po wykładni zapisów umowy. Przede wszystkim licencja dotyczy całego Systemu (którego tylko jednym z elementów są Komponenty techniczne, w tym baza danych) i Rezultatów prac: „Wykonawca (..) Udziela Zamawiającemu licencji niewyłącznej na System oraz na wszelkie Rezultaty prac” - § 6 ust. 2 PIPU. Gdyby licencja z § 6 ust. 2 PIPU (a w konsekwencji ograniczenie z § 6 ust. 12) dotyczyć miała każdego z elementów z Systemu z osobna (w tym bazy danych), Zamawiający winien zastrzec to wyraźnie w umowie (zob. pkt 16 i 17 powyżej). 39.Interpretacja Zamawiającego, jakoby § 6 ust. 2 i 3 PIPU (a w efekcie § 6 ust. 12 PIPU) dotyczy licencji na każdy składnik Systemu z osobna, a nie na System jako całość, prowadziłaby w konsekwencji do konieczności odrzucenia, jako niezgodnych z SW Z wszystkich ofert wykonawców posługujących się komercyjnym oprogramowaniem bazodanowym. 40.§ 6 ust. 3 PIPU przewiduje bowiem szereg pól eksploatacji, w tym m.in. prawo do tłumaczenia, przystosowywania, zmiany układu lub wprowadzania jakichkolwiek innych zmian. Dodatkowo zakres licencji winien uprawniać do zezwalania na wykonywanie praw zależnych. 41.Standardowe licencje komercyjnych produktów bazodanowych czy serwerów aplikacyjnych, takich jak Oracle czy Microsoft, zawierają fundamentalne ograniczenia dotyczące modyfikacji kodu źródłowego oraz redystrybucji oprogramowania. Te ograniczenia są nieodłącznym elementem modelu biznesowego dostawców komercyjnego oprogramowania i nie mogą być przedmiotem negocjacji. Żadna z powszechnie stosowanych licencji komercyjnych nie będzie zatem zgodna z polami eksploatacji, o których mowa w §6 ust. 3 i 4 PIPU. Dowód: Warunki udzielenia licencji Microsoft SQL język angielski – Stanowiąca załącznik nr 14 42.W konsekwencji takie rozumowanie zmusza Wykonawców do zastosowania oprogramowania typu open source. Takie rozwiązanie jest jednak znacząco ograniczone przez §6 ust. 18 PIPU, który stanowi, że wykorzystanie oprogramowania typu open source jest dopuszczalne jedynie wówczas, gdy "warunki licencji oprogramowania open source nie zawierają tzw. klauzuli copyleft". To eliminuje możliwość wykorzystania popularnych licencji open source, takich jak GPL czy LGPL. Prowadziłoby to do wniosku, że realizacja zamówienia byłaby możliwa wyłącznie przy wykorzystaniu bazy danych stworzonej od podstaw przez Wykonawcę lub wykorzystujących najbardziej permisywne licencje open source. Stoi to w oczywistej sprzeczności z praktyką rynkową i rodzi obawy co do stabilności Systemu opartego o takie komponenty, ale również naruszałoby zasadę uczciwej konkurencji, gdyż preferuje Wykonawców nie pracujących na komercyjnych rozwiązaniach bazodanowych i posiadających swoją własną bazę. 43.Zdaje się, że niezamierzoną przez Zamawiającego konsekwencją uznania, iż §6 ust. 2 i 3 PIPU (a w efekcie §6 ust. 12 PIPU) dotyczy licencji na każdy składnik Systemu z osobna, a nie na System jako całość, byłaby konieczność odrzucenia oferty Sygnity wybranej jako najkorzystniejszej. Zamawiający na podstawie art. 226 ust. 1 pkt 5 ustawy odrzuca ofertę, jeżeli jej treść jest niezgodna z warunkami zamówienia. 44.W świetle powyższych rozważań należy dojść do wniosku, iż albo licencja na oprogramowanie bazy danych nie jest licencją,
§6ust.
2 i 3 PIPU, a zatem licencja typu ASFU jest dopuszczalna (nie narusza wymagania „niezależności”), albo też taką licencją jest, co skutkuje tym, iż rozwiązanie bazodanowe Sygnity także naruszałoby wymogi licencyjne określone w §6 ust. 3 i 4 PIPU. Odnośnie zarzutu nr 2, tj. naruszenia art. 223 ust. 3 PZP w związku z art. 223 ust. 2 pkt 3 PZP - jego niezastosowanie, a w konsekwencji brak poprawy innej omyłki polegającej na niezgodności oferty z dokumentami zamówienia, niepowodujące istotnych zmian w treści oferty, przy zastosowaniu procedury pozyskania zgody Odwołującego na poprawienie w ofercie omyłki lub zakwestionowanie jej poprawienia. 45.Podkreślenia wymaga, że sam fakt zaistnienia w ofercie niezgodności z dokumentami zamówienia nie jest równoznaczny z obowiązkiem odrzucenia oferty na podstawie art. 226 ust. 1 pkt 5 ustawy PZP, przepis art. 223 ust. 2 pkt 3 ustawy PZP wyraźnie zezwala bowiem na poprawienie tego rodzaju błędów, pod warunkiem, że nie spowoduje to istotnych zmian w treści oferty. 46.Celem przepisu art. 223 ust. 2 pkt 3 PZP jest niedopuszczenie do wyeliminowania z postępowania ofert w przeważającym zakresie poprawnych, na skutek zaistnienia niezgodności z treścią SW Z, których poprawienie nie ma zasadniczego znaczenia dla przyszłej realizacji przedmiotu zamówienia i oczekiwań zamawiającego (zob. wyrok z KIO 1292/22). 47.Wykładania art. 223. ust. 2 pkt 3 PZP wymaga zbadania trzech okoliczności: a)Po pierwsze, należy stwierdzić, czy jest to omyłka, a więc nieintencjonalne, niecelowe działanie wykonawcy powodujące powstanie niezgodności w treści oferty, pomimo zamiaru dokonania poprawnego zapisu treści oferty. Argumenty o nieintencjonalnym i niecelowym działaniu Odwołującego obszernie wskazane zostały w pkt 18 Powyżej. Warunek ten został zatem spełniony. b)Po drugie, trzeba stwierdzić, czy omyłka ta polega na niezgodności oferty z dokumentami zamówienia. Bez uszczerbku dla argumentacji Odwołującego wskazanego w ewentualnym zarzucie nr 3, zgodnie z informacją Zamawiającego z 06.12.2024 r., warunek ten został spełniony. c)Po trzecie, zamawiający musi ocenić, czy poprawienie innej omyłki nie spowoduje istotnych zmian w treści oferty. Analizując istotność zmian w ofercie Odwołującego oprzeć się należy na tym, iż zaoferowanie licencji Oracle Enterprise zamiast pierwotnie omyłkowo Standard Edition nie spowodowała rozbieżności w kalkulacji ceny. Obydwa modele bazy danych (wskazane omyłkowo i prawidłowe, które oferuje Odwołujący) zostałyby nabyte przez Odwołującego po cenie zawierającej się w cenie wskazanej w kalkulacji. Omyłka w zakresie modelu licencji bazy danych nie przełożyła się w jakikolwiek sposób na prawidłowość kalkulacji - w wyniku wyjaśnienia tej omyłki nie doszło do zmiany założeń kalkulacyjnych przedstawionych przez Odwołującego. Uznać zatem należy, iż przedmiotowy warunek również został spełniony. 48.Co istotne inna omyłka,
art. 223 ust. 2 pkt 3 PZP, nie musi mieć charakteru oczywistego. Dopuszczalne jest również poprawienie omyłek niemających takiego charakteru, pod warunkiem, że poprawienie innej omyłki nie spowoduje istotnej zmiany treści oferty (N.J., W.P., Prawo zamówień publicznych. Komentarz, wyd. V, W KP 2023). 49.W orzecznictwie KIO podkreślano, iż aby zastosować art. 223 ust. 2 pkt 3 PZP Zamawiający winien dysponować instrumentami umożliwiającymi samodzielne przeprowadzenie takiej czynności. Co istotne, w niniejszym stanie faktycznym Zamawiający takie informacje posiadał. Był on bowiem w posiadaniu oferty producenta bazy danych (Oracle), na bazie której to oferty sporządzona została oferta Odwołującego, która zawierała także cenę za licencję Enterprise Edition. Co więcej, Odwołujący w piśmie z dnia 01.10.2024 r. zwrócił Zamawiającemu uwagę na przedmiotową omyłkę. Zamawiający miał zatem i wiedzę i instrumenty, aby samodzielnie tą omyłkę poprawić. Wskazuje na to zarówno judykatura jak i piśmiennictwo. I tak: a)Jak wynika z wyroku KIO z 21.10.2011 r., KIO 2152/11: „Fakt, iż wykonawca w drodze wyjaśnień udzielonych zamawiającemu wskazał na potrzebę poprawienia omyłki nie oznacza, że strony prowadziły niedopuszczalne, w świetle art. 87 ust. 1 ustawy Prawo zamówień publicznych [aktualnie art. 223 ust. 2 pkt 3 PZP negocjacje dotyczące złożonej oferty”. b)W wyroku z 5.08.2009 r., KIO/UZP 959/09, Krajowa Izba Odwoławcza uznała, że „zastosowanie art. 87 ust. 2 pkt 3 PZP [aktualnie art. 223 ust. 2 pkt 3 PZP] jak najbardziej może zostać poprzedzone wyjaśnieniami, o których stanowi ust. 1 przywołanego przepisu, zmierzającymi do ustalenia rzeczywistej treści oferty oraz charakteru i rodzaju, czy samej potrzeby wprowadzenia ewentualnych zmian w jej treści”. c)Niewyrażoną wprost, ale wyprowadzaną z treści art. 223 ust. 2 pkt 3 PZP przesłanką poprawienia oferty jest też wiedza zamawiającego, na którym obowiązek poprawiania ofert na podstawie tego przepisu spoczywa. Przyjąć należy, że wiedza tego typu powinna wynikać z treści samej oferty (np. porównania sprzeczności w ofercie zawartych, oceny charakteru niezgodności, ustalenia i wykorzystania części prawidłowych danych w ofercie zawartych), ewentualnie, jednakże w ograniczonym zakresie, może pochodzić z wyjaśnień, które zamawiający może uzyskać od wykonawcy na podstawie art. 223 ust. 1 PZP - N.J., W.P., Prawo zamówień publicznych. Komentarz, wyd. V, WKP 2023 50.W świetle powyższego, wobec dowodów i wiedzy Zamawiającego, pochodzącej z udzielonych mu przez Odwołującego wyjaśnień, poprawa innej omyłki w trybie 223 ust. 2 pkt 3 PZP, poprzez zastąpienie licencji Oracle Database Standard Edition2 na Oracle Database Enterprise Edition (przy – co istotne – zachowaniu nadal tej samej ceny ofertowej) pozostawało zasadne i konieczne. Odnośnie zarzutu nr 3, tj. naruszenia art. 226 ust. 1 pkt 5 PZP w związku z art. 16 pkt 1) PZP - odrzucenie oferty Odwołującego wobec uznania, iż zaoferowanie oprogramowania bazodanowego „ORACLE DB STANDARD EDITION 2” pozostaje niezgodne z warunkami zamówienia - pkt 1.2.25 [TECH_BAZA_024] załącznika nr 3 do SOPZ w zakresie funkcjonalności równoległego wykonywania zapytań, podczas gdy licencja Oracle Database Standard Edition, w połączeniu z innymi funkcjonalnościami oferowanego systemu wymaganie takie spełnia. 51.Z daleko idącej ostrożności, na wypadek nie podzielenia przez Izbę argumentacji Odwołującego, iż zaoferował on licencję na bazę danych w wersji Oracle Database Enterprise Edition (zarzut nr 1 i 2), Odwołujący wskazuje, iż nadal brak było podstaw do odrzucenia jego oferty. Licencja Oracle Database Standard Edition 2, w połączeniu z innymi funkcjonalnościami oferowanego systemu, spełnia bowiem Wymaganie nr 1.2.25. TECH_BAZA_024, w szczególności w zakresie równoległego wykonywania zapytań 52.Na wstępie podkreślić należy, że współczesne systemy informatyczne, w tym rozwiązania oferowane przez Odwołującego, odzwierciedlają powszechnie obowiązujące trendy rynkowe i technologiczne, które wprost wynikają z dynamiki rozwoju narzędzi, komponentów oraz systemów wspierających procesy wytwarzania oprogramowania. Charakterystyczną cechą współczesnych rozwiązań jest ich niejednorodność – projektowanie i wdrażanie systemów oparte jest na różnorodnych technologiach i narzędziach, które są wybierane w taki sposób, aby zapewnić maksymalną efektywność i najwyższy standard jakości oferowanych usług. 53.Dynamiczny rozwój technologii informatycznych powoduje, że żadne pojedyncze narzędzie czy platforma nie jest w stanie zaspokoić pełnego zakresu wymagań stawianych nowoczesnym systemom. Dzisiejsze rozwiązania integrują różnorodne technologie, zarówno w warstwie frontendowej, jak i backendowej, a także korzystają z otwartych i elastycznych stosów technologicznych, które pozwalają na szybkie adaptowanie się do zmieniających się potrzeb użytkowników oraz ewolucji technologicznej. Architektura oparta na mikrousługach, wykorzystanie API czy szeroka integracja z chmurowymi środowiskami obliczeniowymi to tylko niektóre z elementów, które czynią dzisiejsze systemy bardziej efektywnymi, skalowalnymi i odpornymi na przyszłe zmiany. 54.Trend niejednorodności technologicznej nie jest jedynie preferencją Wykonawców – jest to współcześnie standard w branży, promowany przez liderów technologicznych oraz wdrażany w projektach realizowanych przez największe instytucje na świecie. Taka strategia pozwala na optymalne wykorzystanie zasobów, zapewniając jednocześnie elastyczność, która jest kluczowa w kontekście długoterminowego utrzymania i rozwoju systemów. 55.Odwołujący, tworząc swoje rozwiązania, działa zgodnie z tymi najlepszymi praktykami, łącząc różnorodne technologie i narzędzia, aby zapewnić Zamawiającemu rozwiązanie najwyższej jakości. Niejednorodność stosowanych technologii nie jest więc słabością systemu, lecz jego zaletą, umożliwiającą osiągnięcie maksymalnej funkcjonalności oraz efektywności. Takie podejście gwarantuje również Zamawiającemu większą swobodę integracji systemu z innymi rozwiązaniami w przyszłości, co jest szczególnie istotne w kontekście uniknięcia uzależnienia od jednego dostawcy (tzw. vendor lock-in). 56.Wymagania techniczne określone w dokumentacji zamówienia, w tym w szczególności dotyczące funkcjonalności bazodanowych, należy w tym kontekście interpretować szeroko i całościowo, uwzględniając ogólną zdolność zaoferowanego środowiska do spełnienia stawianych warunków. Zamawiający w swoich postanowieniach nie wskazuje, iż konkretna funkcja musi być osiągnięta wyłącznie poprzez natywne cechy silnika bazodanowego. Przeciwnie, z analizy treści wymagań wynika, że istotne jest osiągnięcie określonego rezultatu funkcjonalnego – np. zapewnienie odpowiedniej wydajności, skalowalności, wysokiej dostępności czy też możliwości wykonywania zapytań równoległych – niezależnie od tego, czy zostanie to zrealizowane za pomocą wbudowanych możliwości silnika bazy, czy też z wykorzystaniem dedykowanych narzędzi programistycznych, frameworków analitycznych bądź mechanizmów wspomagających wdrażanych w warstwie integracyjnej lub aplikacyjnej. 57.Pojęcie „wymagań bazodanowych”, wskazane w pkt 1.2 „Z3SOPZ - Załącznik nr 3. Szczegółowy opis przedmiotu zamówienia w zakresie Komponentów technicznych”, stanowiących załącznik nr 17 do niniejszego odwołania, nie jest w treści dokumentacji sprowadzone do jednego, ściśle zdefiniowanego komponentu. Wręcz przeciwnie, przy tak istotnych i kompleksowych systemach, jak wdrażany System Kadrowo-Płacowy, naturalnym jest wykorzystywanie zestawu powiązanych rozwiązań technicznych. Można tu wskazać chociażby mechanizmy implementowane na poziomie środowisk zarządzania danymi, narzędzia do raportowania i analiz, moduły wspierające replikację czy dystrybucję obciążenia, a także pakiety oprogramowania pozwalające na równoległą egzekucję procesów przetwarzania danych. Jest to powszechna i akceptowalna praktyka, jeśli w efekcie pozwala osiągnąć wymagany poziom funkcjonalności i jakości usługi. 58.Poniżej przedstawiono przykładowe wymagania bazodanowe z Załącznika Z3SOPZ, które nie odnoszą się bezpośrednio do natywnych funkcjonalności silnika bazy danych, lecz do środowiska, narzędzi wspierających lub warunków licencyjnych i infrastrukturalnych: −TECH_BAZA_049 (1.2.4) Niezależność platformy systemowej oprogramowania klienckiego / serwera aplikacyjnego od platformy systemowej bazy danych. Wymaganie to dotyczy architektury i niezależności środowisk, a nie cech samego silnika bazy. −TECH_BAZA_055 (1.2.7) Dopuszczalność bazy danych open source. To wymaganie dotyczy dopuszczalności pewnego typu oprogramowania (open source) i jego warunków licencyjnych, a nie konkretnej cechy motoru bazy. −TECH_BAZA_007 (1.2.16) Udostępnienie narzędzia do definiowania, tworzenia raportów oraz tabularycznych lub wielowymiarowych modeli danych. Wymaganie to odnosi się do dodatkowego narzędzia wspomagającego analizy i raportowanie, nie zaś do wbudowanej funkcjonalności samego silnika bazy. −TECH_BAZA_008 (1.2.17) Udostępnienie narzędzia umożliwiającego obsługę bazy danych i jej funkcjonalności z poziomu interfejsu klienckiego. Mowa tu o zewnętrznym narzędziu do zarządzania i obsługi bazy, a nie o cechach wprost zakodowanych w silniku bazy danych. − TECH_BAZA_083 (1.2.33) Niezależność licencji na oprogramowanie bazodanowe od licencji na oprogramowanie aplikacyjne. Dotyczy to modelu licencjonowania i relacji pomiędzy różnymi elementami środowiska, a nie specyficznej funkcji silnika bazy. Dowód: „Z3SOPZ - Załącznik nr 3. Szczegółowy opis przedmiotu zamówienia w zakresie Komponentów technicznych – załącznik nr 17 59.Powyższe przykłady pokazują, że nie wszystkie wymagania bazodanowe sprowadzają się do funkcjonalności czy architektury samego silnika bazy danych. Niektóre odnoszą się do sposobu licencjonowania, niezależności środowiska czy konieczności dostarczenia dodatkowych narzędzi wspomagających zarządzanie i analizę danych. 60.W rezultacie, uznanie, że wszystkie wymagania bazodanowe wskazane w pkt 1.2 załącznika Z3SOPZ odnosić należy wyłącznie do samego silnika bazy, byłoby nadmiernie zawężające i pozostawałoby w sprzeczności z zasadami celowościowej i racjonalnej wykładni zapisów Specyfikacji. Zadaniem Wykonawcy jest dostarczyć finalne, w pełni działające rozwiązanie, zapewniające wskazane cechy funkcjonalne i wydajnościowe, a nie ograniczać się do wąskiego rozumienia poszczególnych wymagań. Ponieważ Odwołujący może zrealizować wskazane funkcjonalności również przy pomocy własnych narzędzi i mechanizmów, zgodnie z celem i duchem przedstawionych wymagań, oferta Odwołującego spełnia założone przez Zamawiającego kryteria. 61.Odwołujący podkreśla, iż nawet przy wykorzystaniu bazy danych Oracle Database Standard Edition jego rozwiązanie nadal spełnia wymaganie nr 1.2.25. TECH_BAZA_024, w szczególności w zakresie równoległego wykonywania zapytań. Odwołujący jest w stawnie osiągnąć to w następujący sposób:
- a)Realizacja równoległego wykonywania zapytań w bazie PostgreSQL (dopuszczalnej przez SW Z i wskazanej przez Odwołującego w wyjaśnieniach) 1.Wprowadzenie Funkcjonalność równoległych zapytań (parallel queries) została wprowadzona do PostgreSQL począwszy od wersji 9.6 i jest systematycznie rozwijana w kolejnych wydaniach. Zapytania równoległe pozwalają na rozbicie zadań obliczeniowych, takich jak skanowanie tabeli, tworzenie indeksów czy łączenie danych (joins), na wiele procesów wykonawczych (workerów) działających równolegle, co skutkuje skróceniem czasu odpowiedzi dla złożonych, operacji. 2.Podstawy działania Mechanizm realizacji zapytań równoległych w PostgreSQL opiera się na następujących elementach: Planista zapytań (Query Planner): Podczas tworzenia planu wykonania zapytania PostgreSQL ocenia, czy dane zapytanie może skorzystać z równoległego przetwarzania. Jeśli tak, plan jest dzielony na części równolegle wykonywane przez wielu workerów. Nody Gather i Gather Merge: W drzewie planu wykonania pojawiają się nody typu Gather lub Gather Merge, które koordynują równoległe wykonywanie. Gather: uruchamia kilka workerów równolegle i zbiera wyniki od każdego z nich. Gather Merge: oprócz zbierania wyników dba o ich posortowanie, jeśli jest wymagane. Workery równoległe (Parallel Workers): To samodzielne procesy powoływane przez serwer PostgreSQL do wykonywania części planu zapytania. Każdy worker przetwarza swój przydział danych niezależnie od innych, a następnie wyniki są łączone w ramach nody Gather/Gather Merge. 3.Przykładowy scenariusz Załóżmy, że wykonujemy zapytanie typu: SELECT SUM(kwota) FROM transakcje; Jeśli tabela transakcje jest duża, planista może zaplanować równoległy skan tabeli i sumowanie kwot. Wówczas serwer: Uruchomi pewną liczbę workerów (np. 4). Każdy worker wykona skan fragmentu tabeli transakcje i zsumuje wartości w swoim obszarze. Noda Gather zbierze wyniki częściowe od workerów i wykona ostateczną sumę. W efekcie operacja sumowania zostanie znacząco przyspieszona, gdyż dane zostaną przetworzone równolegle, a nie sekwencyjnie przez jeden proces. 4.Konfiguracja parametrów równoległości Istnieje szereg parametrów w pliku konfiguracyjnym PostgreSQL (postgresql.conf) mających wpływ na równoległe zapytania, m.in.: max_parallel_workers_per_gather: Maksymalna liczba workerów, którzy mogą zostać przydzieleni do wykonania jednego zapytania równoległego. max_parallel_workers: Globalny limit liczby workerów dostępnych dla całej instancji serwera. parallel_leader_participation: Określa, czy proces główny (leader) również uczestniczy w przetwarzaniu danych, czy ogranicza się tylko do koordynacji. Dodatkowo, PostgreSQL automatycznie ocenia opłacalność zastosowania równoległego przetwarzania w oparciu o statystyki i koszty zapytania. Administrator lub projektant może dostosować ustawienia kosztów (np. parallel_setup_cost, parallel_tuple_cost) w celu uzyskania lepszej optymalizacji. 5.Podsumowanie Równoległe zapytania w PostgreSQL to istotny mechanizm poprawy wydajności, który pozwala na lepsze wykorzystanie zasobów sprzętowych i znaczne przyspieszenie czasu wykonywania złożonych operacji bazodanowych. Poprzez zastosowanie workerów równoległych, nodów Gather/Gather Merge oraz odpowiednią konfigurację parametrów, PostgreSQL umożliwia efektywne skalowanie operacji odczytu i przetwarzania danych w wielu scenariuszach, zapewniając wymaganą funkcjonalność parallel queries.
- b)Realizacja równoległego wykonywania zapytań w bazie Oracle SE 1.Wprowadzenie Oracle Database Standard Edition umożliwia realizację zapytań równoległych poprzez zastosowanie mechanizmu dekompozycji operacji SQL na mniejsze segmenty oraz ich współbieżne wykonywanie za pomocą wielu sesji. Jednym z narzędzi służących do tego celu jest pakiet DBMS_PARALLEL_EXECUTE, który pozwala podzielić dane na logiczne fragmenty i równolegle je przetwarzać. 2.Zasada działania DBMS_PARALLEL_EXECUTE DBMS_PARALLEL_EXECUTE umożliwia wykonywanie operacji SQL na podzielonych na fragmenty danych w taki sposób, aby wiele sesji bazodanowych mogło pracować jednocześnie, przetwarzając różne części zbioru rekordów. Mechanizm ten może zostać wykorzystany zarówno dla długotrwałych operacji aktualizacji, wstawiania, jak i odczytu danych, co znacząco skraca czas przetwarzania. 3.Przykładowa procedura użycia Przykładowy scenariusz realizacji zapytań równoległych w Standard Edition może obejmować: Utworzenie zadania: BEGIN DBMS_PARALLEL_EXECUTE.CREATE_TASK('zapytanie_rownolegle'); END; Podział danych na fragmenty (chunks): BEGIN DBMS_PARALLEL_EXECUTE.CREATE_CHUNKS_BY_ROWID( task_name => 'zapytanie_rownolegle', table_owner => 'KADRY', table_name => 'LISTA_WYPLAT', by_row => TRUE, chunk_size => 10000 ); END; W ten sposób tabela TRANSAKCJE zostaje logicznie podzielona na fragmenty po 10 000 wierszy każdy. Definiowanie operacji do wykonania na każdym fragmencie: BEGIN DBMS_PARALLEL_EXECUTE.RUN_TASK( task_name => 'zapytanie_rownolegle', sql_stmt => 'SELECT * FROM LISTA_WYPLAT WHERE :start_id <= rowid AND rowid <= :end_id', parallel_level => 4 ); END; Polecenie SELECT zostanie wykonane w 4 równoległych sesjach, z których każda przetwarza inny fragment danych. Monitorowanie i zakończenie zadania: DBMS_PARALLEL_EXECUTE dostarcza procedury do monitorowania postępu i wyników przetwarzania. Po zakończeniu można zwolnić zasoby: BEGIN DBMS_PARALLEL_EXECUTE.DROP_TASK('zapytanie _rownolegle'); END; 4.Zalety stosowania DBMS_PARALLEL_EXECUTE Efektywne skrócenie czasu przetwarzania dużych zbiorów danych poprzez równoległe wykonywanie poleceń SQL. Możliwość dostosowania liczby sesji i wielkości fragmentów do zasobów sprzętowych. Precyzyjna kontrola nad procesem równoległego przetwarzania oraz elastyczne dopasowanie trybu pracy do rodzaju wykonywanych operacji. 5.Podsumowanie Zastosowanie pakietu DBMS_PARALLEL_EXECUTE pozwala na wykorzystanie mechanizmów równoległego przetwarzania zapytań w Oracle Database Standard Edition. Dane operacje SQL mogą zostać podzielone na fragmenty i przetwarzane przez wiele sesji jednocześnie, co zapewnia efektywną realizację zadań wymagających dużej wydajności. Tym samym wymaganie dotyczące wykonywania zapytań równoległych zostaje spełnione w warunkach oferowanego środowiska.
- c)Realizacja zapytań równoległych poza silnikiem bazy danych, z wykorzystaniem środowiska SPRING BOOT 1.Wprowadzenie Równoległe przetwarzanie zapytań i operacji na danych może zostać osiągnięte nie tylko poprzez bezpośrednie wykorzystanie funkcjonalności silnika bazy danych, lecz również dzięki odpowiednim technikom wdrażanym na poziomie warstwy aplikacyjnej. Środowisko Spring Boot wraz z bogatym ekosystemem narzędzi Java, umożliwia wdrożenie mechanizmów równoległości i asynchronicznego przetwarzania zapytań, a w efekcie efektywne wykorzystanie zasobów sprzętowych oraz skrócenie czasu odpowiedzi systemu. 2.Podejście warstwy aplikacyjnej do równoległości Zamiast polegać wyłącznie na natywnych zdolnościach silnika bazodanowego do wykonywania równoległego wykonywania zapytań, można zastosować równoległe przetwarzanie na poziomie aplikacji. Może to polegać na: Dzielenie zapytania logicznego na mniejsze podzapytania: Aplikacja może generować wiele, wzajemnie niesprzecznych zapytań SQL, które kierowane są do bazy danych równolegle. Następnie rezultaty są łączone w warstwie aplikacyjnej. Asynchroniczne wywołania warstwy danych: Korzystając z możliwości Spring Boot oraz Spring Data, można wykonać wiele odwołań do repozytoriów lub serwisów danych asynchronicznie, np. z użyciem @Async i CompletableFuture, co pozwala na jednoczesne pobieranie danych z różnych źródeł lub podzbiorów tabel. Równoległe przetwarzanie danych w pamięci: Często dane pochodzące z bazy są dalej przetwarzane, filtrowane lub agregowane na poziomie aplikacji. Dzięki mechanizmom udostępnianym przez Javę (Parallel Streams, CompletableFuture, ExecutorService) można równolegle przetwarzać już pobrane dane, skracając w ten sposób czas realizacji złożonych operacji analitycznych. 3. Przykładowy scenariusz w Spring Boot Załóżmy, że chcemy przeprowadzić złożoną operację analityczną na zbiorze rekordów pochodzących z bazy danych: Pobranie fragmentów danych równocześnie: Aplikacja dzieli duże zapytanie na kilka równoległych zapytań ograniczonych warunkami (np. zakresami ID). Każde zapytanie jest wywoływane w osobnym wątku wykonawczym, dzięki czemu baza może obsłużyć kilka operacji odczytu jednocześnie. Asynchroniczne wywołania metod repozytoriów: @Async public CompletableFuture<List<Entity>> fetchPart(int startId, int endId) { List<Entity> results = repository.findByIdBetween(startId, endId); return CompletableFuture.completedFuture(results); } Wywołanie kilku takich metod pozwala na równoczesne pobieranie wielu fragmentów danych. Scalanie wyników i równoległa analiza: Po zakończeniu pobierania danych z różnych zakresów, zebrane wyniki można połączyć i przetworzyć równolegle (np. filtrowanie, mapowanie, agregacja) z użyciem Parallel Streams: List<Entity> allData = Stream.of(listA, listB, listC) .flatMap(List::stream) .parallel() .filter(...) // filtracja równoległa .map(...) // transformacja równoległa .collect(Collectors.toList()); 4.Zasoby i konfiguracja Spring Boot i Spring Data JPA: Umożliwiają dostęp do danych i definiowanie repozytoriów, które można wywoływać asynchronicznie. Pule wątków (Thread Pools): Skonfigurowane w Spring Boot (np. w pliku application.properties lub za pomocą beanów TaskExecutor) pozwalają kontrolować liczbę wątków realizujących równoległe zadania. Asynchroniczne API: Użycie adnotacji @EnableAsync oraz @Async w Spring Boot aktywuje i umożliwia łatwe stosowanie asynchronii. 5.Zalety podejścia aplikacyjnego Elastyczność: Sposób dzielenia i łączenia zapytań można swobodnie modyfikować i dostosowywać do specyficznych wymagań. Skalowalność: Mechanizmy równoległości na poziomie aplikacji doskonale współgrają z architekturą wieloserwerową i konteneryzacją. Uniezależnienie od cech konkretnego silnika bazy: Równoległe przetwarzanie można wdrożyć w podobny sposób niezależnie od tego, jaką bazę danych wykorzystujemy. 6.Podsumowanie Wykorzystując możliwości Spring Boot i powiązanych narzędzi ekosystemu Java, równoległe realizowanie zapytań czy złożonych operacji analitycznych nie wymaga oparcia wyłącznie na funkcjonalnościach oferowanych przez silnik bazy danych. Równoległość można osiągnąć w warstwie aplikacyjnej, co pozwala na efektywną i elastyczną realizację wymagań wydajnościowych niezależnie od szczegółowych możliwości natywnych mechanizmów bazodanowych. 62.Wskazać przy tym należy, iż wiadomość elektroniczna Oracle, wskazana w piśmie COIG z 23.09.2024 r., zgodnie z którą „Możliwość wykonywania „równoległych zapytań” (paraller queries) jest funkcjonalnością dostępną wyłącznie w Oracle Database Enterprise Edition” nie świadczy, iż Oracle Database Standard Edition2 nie zapewnia możliwości równoległego wykonywania zapytań. Zwrócić należy uwagę, iż wymóg TECH_BAZA_024 wskazuje na „równoległe wykonywanie zapytań”, a nie na „równoległe zapytania”, o czym pisze Oracle. Jest to bardzo znacząca subtelność. Oracle jako producent bazy danych nazwał swoją funkcjonalność „Równoległe zapytania” (paraller queries) i umieścił ją w wersji Enterprise Edition. Pytanie COIG do Oracle było zatem świadomie zwodnicze. COIG nie uzyskał bowiem odpowiedzi producenta o to czy Standard Edition spełnia wymóg możliwości „równoległego wykonywania zapytań” (wymóg SW Z), lecz czy zawiera funkcję komercyjnie nazwaną przez producenta „równoległymi zapytaniami (paraller queries)”. Na takie pytanie Oracle udzielił odpowiedzi twierdzącej, chociaż nie świadczy to o nie spełnianiu wymogu TECH_BAZA_024 (o czym mowa w pkt powyżej). Dowód: Pismo COIG z 23.09.2024 r. stanowiące załącznik nr 7 do odwołania 63.Należy również podkreślić, iż dokonana przez Zamawiającego analiza i ocena spornego przedmiotu zamówienia była jedynie powierzchowna i nie dawała mu podstawy do odrzucenia oferty Odwołującego na podstawie art. 226 ust. 1 pkt 5 PZP, w szczególności w sytuacji, gdy Zamawiający opierał się jedynie na treści wiadomości mailowej od szeregowego pracownika Oracle do kontroferenta Odwołującego. 64.W świetle powyższego, nawet zastosowanie bazy danych Oracle Database Standard Editon2 (pomimo tego, iż Odwołujący oferował od początku licencję w wersji Enterprise) w połączeniu z - innymi mechanizmami oferowanymi zgodnie z zasadami sztuki przez Odwołującego, spełnia wymagania SW Z. Brak było zatem podstaw do odrzucenia oferty Odwołującego. Odnośnie zarzutu 4, tj. naruszenia art. 223 ust. 2 pkt 2 PZP w związku z art. 16 pkt1 ) PZP - jego niezastosowanie i brak poprawy oczywistej omyłki rachunkowej, która pojawiła się w treści wyjaśnień Odwołującego z dnia 11.10.2024 r., tj. wskazania kwoty 233.000 zł zamiast wskazywanej poprzednio w wyjaśnieniach z dnia 24.09.2024 r. kwoty 223.000 zł, kiedy to omyłka ta pozostaje oczywista, chociażby ze względu na fakt, iż całkowita suma oferty nie wzrosła i pozostawała nadal na tym samym poziomie. 65.Tożsamą argumentację jak w pkt 15-26 powyżej, w zakresie omyłki nie dającej podstaw do odrzucenia oferty, należy przyjąć do omyłkowego wskazania w piśmie z dnia 11.10.2024 r. kwoty 233.000 zł zamiast 223.000 zł. 66.Zgodnie z art. 223 ust. 2 ustawy PZP zamawiający poprawia w ofercie: 1) oczywiste omyłki pisarskie, 2) oczywiste omyłki rachunkowe, z uwzględnieniem konsekwencji rachunkowych dokonanych poprawek, 3) inne omyłki polegające na niezgodności oferty z dokumentami zamówienia, niepowodujące istotnych zmian w treści oferty ‒ niezwłocznie zawiadamiając o tym wykonawcę, którego oferta została poprawiona. 67.Celem ustawodawcy wprowadzającym powyższy przepis było niedopuszczenie do takiej sytuacji, aby doszło do wyeliminowania z postępowania ofert, które co do zasady są merytorycznie poprawne, jednak zawierają niezamierzone, nieistotne, błahe błędy, które nie wpływają w żaden sposób na możliwość poprawnego wykonania zamówienia. W ocenie Izby, gdyby uznać, że w rozstrzyganej sprawie nie ma możliwości poprawienia omyłki, to doszłoby właśnie do takiej sytuacji, że odrzuceniu podlegałaby oferta obarczona nieistotnymi uchybieniami, pozwalająca jednak na zgodne z oczekiwaniami zamawiającego i prawidłowe wykonanie zamówienia. 68.Analiza stanu faktycznego prowadzi do wniosku, że w przedmiotowej sprawie zostały wypełnione przesłanki poprawienia oferty na podstawie art. 223 ust. 2 pkt 2 PZP. Oferta Odwołującego była bowiem dotknięta oczywistą omyłką rachunkową, która miała charakter oczywisty. 69.Wpisanie cyfry 3 zamiast 2 w rzędzie dziesiętnych stanowi przejaw klasycznej omyłki typograficznej, powstałej w procesie maszynowego wpisywania tekstu. Błąd w tym wypadku bierze się z tożsamości sąsiadujących cyfr (2 i 3). Wbrew twierdzeniom Zamawiającego omyłka nie zwiększyła ceny oferty o 10.000 zł. Całkowita suma oferty nie wzrosła i pozostawała nadal na tym samym poziomie, co tylko świadczy o oczywistości tej omyłki. 70.Omyłka rachunkowa ma charakter oczywisty nie tylko wtedy, gdy jest widoczna na pierwszy rzut oka. Dla uznania, że omyłka rachunkowa ma charakter oczywisty, wystarczający jest fakt jej ustalenia podczas sprawdzania obliczeń zgodnie z podanym przez zamawiającego sposobem obliczenia ceny oferty oraz możliwość jej jednoznacznego stwierdzenia (tak wyrok KIO z dnia 28 lutego 2023 r. sygn. akt 414/23). Skoro zatem cena pakietu licencji (części składowej oferty) „wzrosła” o 10.000 zł w piśmie z dnia 11.10.2024 r. w stosunku do pisma z 24.09.2024 r., zaś cena całkowita pozostała bez zmian, w sposób oczywisty obrazuje to, iż „wzrost” ten był wyłącznie niezamierzoną, błahą omyłką. 71.Abstrahując od powyższego, nawet przyjmując „wzrost” 10.000 zł jako zamierzony przez Odwołującego (czemu Odwołujący zaprzecza), wskazać należy, że kwota rzędu 10.000 zł przy 4 milionowym zamówieniu stanowi dwa promile wartości zamówienia. Bez sprzecznie jest to kwota marginalna, która zgodnie z przytaczanym już wyrokiem KIO 146/24, winny mieścić się w przewidzianych przez Wykonawcę rezerwach. Tego typu podejście – w ocenie Izby - jest przejawem nadmiernego formalizmu i nie ma nic wspólnego z celem, dla jakiego przepisy art. 226 ust. 1 pkt 8 i art. 224 ust. 6 ustawy PZP zostały wprowadzone do ustawy. Odnośnie zarzutu nr 5, tj. naruszenia art. 226 ust. 1 pkt 8 PZP w związku z art. 224 ust. 6 PZP w związku z art. 16 pkt 1) PZP - odrzucenie oferty Odwołującego jako oferty z rażąco niską ceną lub kosztem, podczas gdy cena oferty Odwołującego nie pozostaje rażąco niska, a Odwołujący złożył należyte wyjaśnienia zaoferowanej ceny. 72.Powyższa argumentacja, przytoczona na poparcie Zarzutu nr 1-4, uzasadnia tezę, iż wyjaśnienia zaoferowanej ceny, złożone przez Odwołującego w trakcie postępowania, pozostają należyte i nie pozwalają uznać oferty Odwołującego jako oferty z rażąco niską ceną. 73.Co jednak istotne, zaoferowanie licencji Oracle Enterprise zamiast pierwotnie omyłkowo Standard Edition nie spowodowała rozbieżności w kalkulacji ceny. Obydwa modele bazy danych (wskazane omyłkowo i prawidłowe, które oferuje Odwołujący) zostałyby nabyte przez Odwołującego po cenie zawierającej się w cenie wskazanej w kalkulacji. Omyłka w zakresie modelu bazy danych nie przełożyła się w jakikolwiek sposób na prawidłowość kalkulacji - w wyniku wyjaśnienia tej omyłki nie doszło do zmiany założeń kalkulacyjnych przedstawionych przez Odwołującego. 74.W świetle zaistniałego stanu faktycznego, zdaniem Odwołującego, nie mamy do czynienia z błędem w obliczeniu ceny lub ze zmianą oferowanego przedmiotu. Jak już wskazano powyżej Odwołujący prawidłowo wycenił w ofercie licencję na bazę danych, którą Odwołujący miał zamiar zaoferować. Jedyną omyłką jaka miała miejsce, było omyłkowe umieszczenie błędnego oznaczenia rodzaju licencji bazy danych. Bezzasadnym byłoby więc pozbawienie Odwołującego możliwości wyjaśnienia zaistniałej sytuacji oraz poprawienia zaistniałej omyłki. Przepisy dotyczące rażąco niskiej ceny nie służą temu, by usuwać z postępowania wykonawców, których wyjaśnienia obarczone są jakimiś drobnymi omyłkami, bowiem służą one temu by chronić zamawiających oraz interes publiczny przed narażeniem na ryzyko nieprawidłowej realizacji zamówienia z uwagi na niedoszacowanie ceny oferty, z czym nie mamy do czynienia w zaistniałym stanie faktycznym, jako że cena zakupu licencji Enterprise Edition zawiera się w cenie ofertowej wyliczonej Zamawiającemu. 75.Jak wskazała Izba, w wyżej przytaczanym już wyroku KIO 146/24, „drobne omyłki i błędy kalkulacyjne, które nie wpływają na ogólny odbiór wyjaśnień, tj. nie powodują, że wyjaśnienia nie uzasadniają podanej w ofercie ceny lub kosztu, nie powinny stanowić powodu do odrzucenia oferty wykonawcy z uwagi na rażąco niską cenę. (…) instytucja zamawiająca, która zidentyfikuje nieścisłości w wyjaśnieniach powinna w pierwszej kolejności ocenić, czy wpływają one na ogólny ich odbiór, tj. czy powodują, iż wyjaśnienia jako całość nie uzasadniają ceny podanej w ofercie w dostatecznym stopniu. Jeśli faktycznie charakter błędów jest na tyle istotny, że poddaje w wątpliwość całość złożonych wyjaśnień, sankcja odrzucenia oferty jest uzasadniona. 76.Jako że zaistniała omyłka (zarówno co do typu licencji bazodanowych – zarzut nr 1, jak i kalkulacji jej ceny – zarzut nr 4) nie wpływa na ogólny odbiór wyjaśnień, tj. nie powoduje, że wyjaśnienia nie uzasadniają podanej w ofercie ceny (wręcz przeciwnie, pomimo omyłki cena jest nadal uzasadniona), nie powinna stanowić powodu do odrzucenia oferty Odwołującego z uwagi na rażąco niską cenę. Odnośnie zarzutu 6, tj. naruszenia art. 223 ust. 1 PZP w związku z art. 16 PZP -zaniechania badania ofert pozostałych wykonawców w zakresie, którym jest badana oferta Odwołującego, tj. w zakresie wynikającym z wezwania, które Zamawiający skierował do Odwołującego w dniu 17.09.2024 r. i w dniu 28.10.2024 r. 77.Jak zostało wskazane w opisie stanu faktycznego, Zamawiający podjął wobec Odwołującego szereg czynności badania jego oferty, tak podyktowanej normą art. 224 ust. 2 PZP, jak i wynikających z własnej inicjatywy, zainspirowanej domysłami innego wykonawcy (COIG). 78.Odwołujący jako jedyny na ówczesnym etapie postępowania zobowiązany był do wskazania rodzaju bazy danych oraz jej warunków licencyjnych i szczegółowo (jak w pkt 12 powyżej) odpytany został o zgodność bazy danych z poszczególnymi wymaganiami SW Z oraz wykraczającymi poza wymagania opisane w SW Z. Takie działanie, co istotne, nie zostało podjęte wobec pozostałych oferentów. 79.Zgodnie z postanowieniami art. 223 ust. 1 ustawy PZP, w toku badania i oceny ofert zamawiający może żądać od wykonawców wyjaśnień dotyczących treści złożonych ofert oraz przedmiotowych środków dowodowych lub innych składanych dokumentów lub oświadczeń. 80.W wyroku z 10.03.2023 r., KIO 525/23, Krajowa Izba Odwoławcza uznała, że: „Odnosząc się z kolei do zarzutu dotyczącego art. 223 ust. 1 ustawy PZP, w pierwszej kolejności należy podkreślić, że mimo użycia przez ustawodawcę słowa «może», nie można uznać, że zamawiający ma całkowitą swobodę w stosowaniu tego przepisu. Z jednolitego stanowiska Krajowej Izby Odwoławczej wynika, że w określonych okolicznościach, zwłaszcza wtedy, gdy istnieją jednoznaczne podstawy do powzięcia przez zamawiającego wątpliwości, wezwanie wykonawcy do złożenia wyjaśnień na podstawie ww. przepisu stanowi obowiązek zamawiającego. Powyższe stanowisko Izba wyraziła także w wyroku KIO 2041/21. 81.Działanie Zamawiającego polegające na wyborze jako najkorzystniejszej oferty Sygnity, odrzuceniu oferty Odwołującego oraz zaniechanie przez Zamawiającego badania ofert innych wykonawców, w swoim skutku stanowi naruszenie opisanej w art. 16 pkt 1) PZP zasady uczciwej konkurencji i równego traktowania wykonawców. Zamawiający w odpowiedzi na odwołanie (pismo z dnia 8/01/2025 r.) wnosząc o oddalenie odwołania podał: (...) podtrzymując wszelkie twierdzenia zawarte w informacji o wyniku postępowania z dnia 6 grudnia 2024 r. oraz wnosząc o: ‒oddalenie odwołania w całości, ‒dopuszczenie i przeprowadzenie dowodu z dokumentów wskazanych w niniejszym piśmie na okoliczności przedstawione w jego uzasadnieniu. W uzasadnieniu stanowiska wskazał: Zarzut Nr 1 OCZYWISTA OMYŁKA Odnośnie zarzutu nr 1 odwołania Zamawiający wskazuje, że bezspornym pozostaje, iż w odpowiedzi Odwołującego na wezwanie do udzielenia wyjaśnień rażąco niskiej ceny z dnia 17 września 2024 r., skierowanym na podstawie art. 224 ust. 2 pkt 1 PZP z uwagi na to, że cena oferty Odwołującego była niższa o ponad 30% od średniej arytmetycznej cen wszystkich złożonych ofert niepodlegających odrzuceniu na podstawie art. 226 ust. 1 pkt 1 i 10 PZP, w załączniku do tychże wyjaśnień, w pozycjach „Dostawa i konfiguracja Komponentów technicznych” oraz „Licencje na Rezultaty prac wykonane przez Wykonawcę”, Odwołujący wskazał jednoznacznie, dwukrotnie oprogramowanie bazodanowe i aplikacyjne odpowiednio „ORACLE DB STANDARD EDITION 2” oraz „ORACLE Forms & Reports”. Dowód: ü wezwanie Odwołującego do złożenia wyjaśnień rażąco niskiej ceny z dnia 17 września 2024 r., pismo znak BZPI.271.27.50.2023.MW – w aktach sprawy, ü wyjaśnienia Odwołującego z dnia 24 września 2024 r. wraz z załącznikami – w aktach sprawy Z uwagi na powyższe oraz mając na uwadze treść pisma datowanego na 23 września 2024 r., które zostało Zamawiającemu złożone przez COIG S.A, Odwołujący pismemz dnia 26 września 2024 r. wezwany został do złożenia wyjaśnień treści oferty w zakresie dotyczącym zgodności treści oferty Odwołującego z wymogiem pkt 1.2.25 [TECH_BAZA_024] załącznika nr 3 do SOPZ Szczegółowy opis przedmiotu zamówienia w zakresie Komponentów technicznych, w którym Zamawiający wskazał jako obligatoryjne wymaganie bazodanowe „Mechanizmy przyspieszające dostęp do danych oraz operacje wykonywane na danych wykorzystywane podczas przetwarzania danych, analizy informacji oraz udostępniania danych: indeksowanie, równoległe wykonywanie zapytań i procesów administracyjnych (np. tworzenie indeksów, wykonywanie kopii zapasowych), widoki zmaterializowane lub ich funkcjonalne odpowiedniki”, która to funkcjonalność, w zakresie równoległego wykonywania zapytań, jest niedostępna w bazie danych ORACLE DB STANDARD EDITION 2. Dowód: ü wyjaśnienia Odwołującego z dnia 24 września 2024 r. wraz z załącznikami – w aktach sprawy ü załącznik nr 3 do SOPZ, Szczegółowy opis przedmiotu zamówienia w zakresie Komponentów technicznych – w aktach sprawy ü pismo COIG S.A. z dnia 23 września 2024 r. – w aktach sprawy ü wezwanie Odwołującego do wyjaśnienia treści oferty z dnia 26 września 2024 r., pismo znak BZP-I.271.27.51.2023.MW – w aktach sprawy W odpowiedzi na powyższe, pismem z dnia 1 października 2024 r. Odwołujący oświadczył, że w wyjaśnieniach rażąco niskiej ceny pojawił się omyłkowy zapis (oczywista omyłka pisarska) dotyczący licencji, a Odwołujący „(…) zamierza (…) zaoferować Zamawiającemu oprogramowanie bazodanowe w oparciu o licencję Oracle Database Enterprise Edition”. Dowód: pismo Odwołującego z dnia 1 października 2024 r. – w aktach sprawy W treści odwołania z kolei, Odwołujący wpisanie do załącznika nr 1 do wyjaśnień z 24 września 2024 r. sformułowania „Oracle Database Standard Edition 2” uzasadnia przejawem „oczywistej omyłki” powstałej na etapie przepisywania z dokumentu do oświadczenia Wykonawcy oraz mylnym przepisaniem do tabeli pozycji z SKU7, zamiast z pozycji SKU8 Warunków Handlowych, co z kolei zdaniem Odwołującego stanowić ma, nieznaną zresztą PZP, „inną niedokładność o charakterze przypadkowym”, „błąd kognitywny osoby sporządzającej dokument”, „błąd ludzki o charakterze formalnym”, który „może przydarzyć się każdemu”. Odnosząc się do powyższych twierdzeń Odwołującego wskazać należy, że z powodów szczegółowo wykazanych w zawiadomieniu o wyniku postępowania z dnia 6 grudnia 2024 r., wskazania przez Odwołującego w wyjaśnieniach rażąco niskiej ceny oprogramowania bazodanowego z wersji Oracle DB Standard Edition 2 zamiast Oracle Database Enterprise Edition nie sposób było potraktować jako oczywistej omyłki pisarskiej, stąd Zamawiający nie był zobligowany ani uprawniony do poprawy wersji oprogramowania bazodanowego z Oracle DB Standard Edition 2 na Oracle Database Enterprise Edition z powołaniem się na dyspozycję art. 223 ust. 2 pkt 1 PZP. Wyżej wymieniony „błąd” (jak sam, w treści odwołania – str. 11, lit. b, Odwołujący kwalifikuje wskazanie Oracle DB Standard Edition 2 zamiast Oracle Database Enterprise Edition) nie stanowi także błędu formalnego, który ze swej natury dotyczyć może jedynie strony formalnej oferty, lecz ewidentnie jest to błąd o charakterze merytorycznym, dotyczący merytorycznej treści oferty, którego korekta zgodnie z żądaniem Odwołującego prowadziłaby do wytworzenia w sposób nieuprawniony nowej treści tejże oferty. Próba wykazania przez Odwołującego, że wskazanie w wyjaśnieniach rażąco niskiej ceny oprogramowania bazodanowego Oracle DB Standard Edition 2 zamiast Oracle Database Enterprise Edition stanowi „inną niedokładność o charakterze przypadkowym” wynikającą z „błędu kognitywnego osoby sporządzającej dokument” nie dość, że nie mieści się w hipotezie normy wynikającej z art. 223 ust. 2 PZP (PZP nie przewiduje poprawy tego rodzaju omyłek i niezgodności) to dodatkowo prowadzić musi do wniosku, że osoby sporządzające, zatwierdzające i podpisujące wyjaśnienia rażąco niskiej ceny w imieniu Odwołującego, tak naprawdę nie miały wiedzy na temat treści oferty, której dotyczyły składane wyjaśnienia. Powołanie się zatem na błąd kognitywny, czyli poznawczy oznacza, że Odwołujący powierzył przygotowanie i zatwierdzenie wyjaśnień ceny osobom, które nie miały merytorycznej wiedzy na temat przedmiotu tychże wyjaśnień, a przygotowanie przez nich załączonej do wyjaśnień tabeli opierało się najwyraźniej na, pozbawionym wiedzy co do znaczenia poszczególnych pojęć, działaniu na zasadzie „kopiuj – wklej”. Wskazując na błąd kognitywny, Odwołujący de facto sam przyznaje więc, że wskazanie oprogramowania Oracle DB Standard Edition 2 zamiast Oracle Database Enterprise Edition nie stanowiło „omyłki”. „Omyłka” bowiem ma miejsce, gdy składający oświadczenie zamiast oświadczenia o treści, którą chce i zamierza złożyć, omyłkowo składa inne, a nie wówczas, gdy składający oświadczenie tak naprawdę nie ma merytorycznego pojęcia o tym jakiej treści oświadczenie składa i jedynie „mechanicznie” i bezrefleksyjnie kopiuje, niemającą dla niego poznawczo żadnej różnicy, treść z jednego dokumentu do dokumentu zawierającego oświadczenia woli. Przechodząc do „katalizatora omyłki”, na który powołuje się Odwołujący poszukując, jak zdaje się, „winnego” przedstawienia kalkulacji ceny oferty z uwzględnieniem niezgodnego z dokumentami zamówienia oprogramowania bazodanowego podnieść należy, że informacje pozyskane podczas procedury wyjaśniania rażąco niskiej ceny mogły stanowić podstawę do uznania, że treść oferty Odwołującego jest niezgodna z warunkami zamówienia, skoro przedstawiona kalkulacja wskazywała na przyjęcie przez Odwołującego sposobu realizacji przedmiotu zamówienia, który okazał się niezgodny z dokumentami zamówienia. Powyższe potwierdzone zostało m. in. w wyroku Krajowej Izby Odwoławczej z dnia 8 października 2024 r., sygn. akt KIO 3408/24, w którym wskazano, że brak żądania na etapie składania ofert przedmiotowych środków dowodowych nie oznacza jeszcze, że Zamawiający nie jest uprawniony i zobligowany do badania zgodności przedmiotu oferty z przedmiotowymi warunkami zamówienia. W wyroku Krajowej Izby Odwoławczej z dnia 17 maja 2022 r., sygn. akt KIO 936/22 wskazano z kolei, że „Nie jest jednak tak, że na podstawie wyjaśnień ceny oferty nie mogą ujawnić się podstawy do odrzucenia oferty w oparciu o inne przepisy p.z.p., w tym np. art. 226 ust. 1 pkt 5. Nie można również wykluczyć sytuacji, w której zostaną spełnione łącznie przesłanki określone art. 226 ust. 1 pkt 5 oraz 8 p.z.p.”. Reasumując powyższe, choć wyjaśnienia rażąco niskiej ceny nie stanowią przedmiotowych środków dowodowych, to stanowią one o treści oferty sensu largo. Oczywistym jest także, że wykonawca może obalić domniemanie rażąco niskiej ceny wyłącznie w sytuacji, gdy złożone przez niego wyjaśnienia, w tym wyliczenia oraz dowody, opierać się będą na treści oferty zgodnej z warunkami zamówienia. Mając powyższe na uwadze, Zamawiający w sposób zgodny z PZP, po analizie wyjaśnień rażąco niskiej ceny złożonych przez Odwołującego, uprawniony był przyjąć, że Odwołujący deklaruje realizację przedmiotu zamówienia z wykorzystaniem oprogramowania bazodanowego Oracle DB Standard Edition 2 (merytoryczna treść oferty), w konsekwencji czego Zamawiający podjął czynności związane z wyjaśnieniem treści oferty, zgodnie z art. 223 ust. 1 PZP, które to czynności doprowadziły ostatecznie Zamawiającego do wniosku, zgodnie z którym treść oferty Odwołującego jest niezgodna z warunkami zamówienia. W kontekście oczekiwań Odwołującego w sposób pośredni wyartykułowany w odwołaniu podkreślić należy także, że nie sposób byłoby ocenić jako legalnego działania Zamawiającego, który, co zdaje się sugerować Odwołujący, całkowicie zignorowałby treść wyjaśnień rażąco niskiej ceny wskazującą na niezgodność oferty z warunkami zamówienia, co z kolei prowadziłoby do, niedającego pogodzić się z podstawowymi zasadami zamówień publicznych, wyboru jako najkorzystniejszej oferty wykonawcy, który oferuje świadczenie sprzeczne z wymaganiami zamówienia. Dodatkowo podnieść należy, że jeżeli Odwołujący, jak twierdzi w odwołaniu, uznawał wezwanie skierowane przez Zamawiającego do złożenia wyjaśnień rażąco niskiej ceny za „nieuprawnione”, winien on, w odpowiednim terminie, zaskarżyć ww. czynność Zamawiającego, czego Odwołujący nie uczynił i które to działanie, w chwili obecnej, uznać należy za spóźnione. Odnośnie twierdzeń Odwołującego, w których zdaje się on sugerować, że wskazanie w wyjaśnieniach rażąco niskiej ceny bazy danych, która nie jest zgodna z warunkami zamówienia, stanowi „drobną omyłkę”, która nie powinna stanowić powodu odrzucenia oferty Odwołującego, Zamawiający, będąc całkowicie odmiennego zdania w tej kwestii, pozostawia ją pod ocenę Izbie wskazując jednakże, że oprogramowanie bazodanowe i jego funkcje są niezwykle istotne, a wręcz konstytutywne dla Systemu, stanowiącego przedmiot zamówienia. WYMÓG NIEZALEŻNOŚCI LICENCJI W pierwszej kolejności, przed przejściem do polemiki z merytoryczną argumentacją Odwołującego w przedmiotowym zakresie Zamawiający wskazuje, że wbrew wyobrażeniom Odwołującego o „świętości” poszczególnych zasad, także od wykonawców ubiegających się o zamówienie publiczne oczekuje się profesjonalizmu, z którym to oczekiwaniem skorelowane jest stosowanie do oceny działań, a także zaniechań wykonawców, podwyższonego miernika należytej staranności. Z powyższego powodu od wykonawców biorących udział w postępowaniu oczekuje się m. in. wnikliwej analizy dokumentów zamówienia, występowania z inicjatywą w celu rozwiania ewentualnych wątpliwości oraz precyzji przy konstruowaniu oferty i innych dokumentów składanych w postępowaniu. Wnioskowanie o wyjaśnienie treści SW Z stanowi zatem dla wykonawców nie tylko instrument do pozyskania wiedzy o zamówieniu i informacji niezbędnych w celu skonstruowania oferty, ale także – z uwagi na profesjonalizm i podwyższony miernik staranności – stanowi ono obwiązek wykonawcy, którego zaniechanie (czy wręcz – celowe zaniechanie - mające na celu wyłącznie możliwość późniejszego wykorzystania ewentualnych niejasności na swoją korzyść) może być podstawą zarzucenia wykonawcy niedochowania należytej staranności i nie powinno korzystać z ochrony oraz stawiać takiego wykonawcy w uprzywilejowanej pozycji. Powyższe potwierdzono w wyrokach Krajowej Izby Odwoławczej, w tym np. w orzeczeniu Izby z dnia 30 marca 2023 r., sygn. akt KIO 720/23 gdzie wskazano, że „Obowiązkiem wykonawców ubiegających się o udzielenie zamówienia jest zapoznanie się z dokumentami zamówienia i przygotowanie oferty, która uwzględniać będzie wymagania z nich wynikające. Jeżeli Odwołujący miał wątpliwości co do prawidłowości przyjętych przez Zamawiającego założeń, (…), to powinien był zasygnalizować to Zamawiającemu na odpowiednim etapie - zwrócić się do Zamawiającego z prośbą o wyjaśnienie treści dokumentów zamówienia przed upływem terminu składania ofert lub skorzystać z prawa do wniesienia odwołania wobec treści dokumentów zamówienia, jeśli ich treść była w jego ocenie niejednoznaczna czy błędna. W orzecznictwie podkreśla się, iż wykonawca, który twierdzi, że treść dokumentacji nie jest jednoznaczna, wprowadza w błąd, uwzględniając zawodową staranność wymaganą od profesjonalisty (art. 355 § 2 k.c. w zw. z art. 8 ust. 1 ustawy Pzp) powinien co najmniej, przy wykorzystaniu możliwości wynikającej z art. 135 ust. 1 ustawy Pzp, zadać w tym zakresie zamawiającemu pytania, celem uzyskania wyjaśnienia i doprecyzowania brzmienia wymogów SW Z. Wykonawca, który wątpliwości co do treści dokumentacji nie wyjaśni, co do zasady traci możliwość powoływania się na te okoliczności jako przemawiające na jego korzyść (por. m.in. wyrok KIO z dnia 2 września 2021 r., sygn. akt KIO 2266/21)”, czy też w orzeczeniu Izby z dnia 30 lipca 2019 r., sygn. akt KIO 1332/19, w którym wyraźnie wskazano, że „Wykonawca formalnie nie ma obowiązku wnioskowania o wyjaśnienia do zamawiającego, jednak nie zwalnia go to od dołożenia należytej staranności w celu ustalenia sposobu złożenia prawidłowej oferty. Tym samym wykonawca nie może powoływać się na domniemane nieścisłości w opisie przedmiotu zamówienia, o których wyjaśnienie nie wnioskował”. Mając na uwadze powyższe, skoro Odwołujący wymóg niezależności licencji, jak sam wskazuje w odwołaniu (str. 14, akapit pierwszy), uznał za „lakoniczny”, powinien był on w trybie art. 135 PZP wystąpić do Zamawiającego o wyjaśnienie treści SW Z w analizowanym zakresie, zamiast „ukrywać” wątpliwości co do znaczenia sformułowanego wymogu aż do momentu oceny ofert (a może i realizacji zamówienia) i żądać interpretacji domniemanych wątpliwości tylko i wyłącznie na swoją korzyść. Przechodząc dalej Zamawiający wskazuje, że w załączniku nr 3 do SOPZ, Szczegółowy opis przedmiotu zamówienia w zakresie Komponentów technicznych, poz. 1.2.33 [TECH_BAZA_083], Zamawiający wymagał niezależności licencji na oprogramowanie bazodanowe od licencji na oprogramowanie aplikacyjne. Dowód: załącznik nr 3 do SOPZ, Szczegółowy opis przedmiotu zamówienia w zakresie Komponentów technicznych – w aktach sprawy Powyższy wymóg oznaczał, że Zamawiający powinien mieć prawo do korzystania, oczywiście na warunkach i w zakresie określonych w dokumentach zamówienia, z oprogramowania bazodanowego niezależnie od oprogramowania aplikacyjnego. Każda z ww. licencji powinna być zatem autonomiczna, niezależna od drugiej, oczywistym bowiem jest, że formułując wymóg „niezależności licencji” Zamawiający nie miał na myśli „licencji – prawa” w znaczeniu formalnym, czyli jedynie dokumentu licencyjnego, lecz chodziło mu o „licencję – prawo” w znaczeniu materialnym, a zatem określony w dokumentach zamówienia zakres uprawnień do korzystania z oprogramowania bazodanowego oraz oprogramowania licencyjnego. Pisząc zatem „Niezależność licencji na oprogramowanie bazodanowe od licencji na oprogramowanie aplikacyjne” Zamawiający wymagał niezależności prawa do korzystania (tymże jest bowiem licencja – prawem do korzystania), na warunkach określonych w dokumentach zamówienia, z oprogramowania bazodanowego od prawa do korzystania z oprogramowania aplikacyjnego. Przedmiotowe zapisy Szczegółowego Opisu Przedmiotu Zamówienia w zakresie Komponentów technicznych skorelowane były z postanowieniami załącznika nr 4 do SW Z, Projektowane Istotne Postanowienia Umowy (PIPU), w których (§ 6 ust. 11 i 12) Zamawiający wyraźnie wskazał, że Wykonawca zezwala Zamawiającemu na wprowadzenie dowolnych zmian w Systemie i Rezultatach prac (z wyjątkiem Standardowego Oprogramowania Aplikacyjnego), w tym na modyfikowanie, skracanie, łączenie lub przerabianie ich przez Zamawiającego lub wskazane przez Zamawiającego osoby trzecie; w szczególności Zamawiający wymagał upoważnienia do publicznego udostępniania Systemu i Rezultatów prac w taki sposób, aby każdy mógł mieć do nich dostęp w miejscu i w czasie przez siebie wybranym, w szczególności w celu przeprowadzenia postępowań zakupowych na świadczenie usług utrzymania Systemu / serwisu Systemu / rozwoju Systemu, jak również w celu przekazania podmiotom trzecim, które świadczą przedmiotowe usługi na rzecz Zamawiającego; dodatkowo zgodnie z Projektowanymi Istotnymi Postanowieniami Umowy licencja,
§ 6ust.
2 i 3, nie mogła zawierać ograniczeń polegających na tym, że dane oprogramowanie może być używane wyłącznie z innym oprogramowaniem lub może być wdrażane, serwisowane, rozwijane itp. wyłącznie przez określony podmiot lub grupę podmiotów. W tym miejscu podkreślić należy, że co zdaje się celowo pomijać Odwołujący, Projektowane Istotne Postanowienia Umowy na równi z Opisem Przedmiotu Zamówienia stanowią dokumenty zamówienia, które wyznaczają zakres warunków zamówienia. Dowód: załącznik nr 4 do SWZ, Projektowane Istotne Postanowienia Umowy (PIPU) – w aktach sprawy To z kolei, jak powyżej analizowane zapisy interpretował Odwołujący jest niestety niezwykle enigmatyczne, ponieważ w pkt 31 odwołania Odwołujący, przecząc sam sobie, wskazuje, że „Tymczasem Wykonawca (…) traktował wymóg niezależności licencji na oprogramowanie bazodanowe od licencji na oprogramowanie aplikacyjne w sposób jednoznaczny, tj. iż prawa do korzystania z obu rodzajów oprogramowania są regulowane przez oddzielne umowy licencyjne, pochodzące od różnych dostawców, a status jednej umowy licencyjnej nie wpływa na status drugiej”, która to „jednoznaczna interpretacja” sformułowana została najwidoczniej jedynie na potrzeby odwołania, czemu dowodzi choćby to, że: ‒ z załącznika do wyjaśnień rażąco niskiej ceny wynika, że Odwołujący oferuje oprogramowanie bazodanowe i oprogramowanie aplikacyjne pochodzące od jednego, tego samego producenta (Oracle), ‒ jakkolwiek Odwołujący rozumie „status umowy licencyjnej”, to jednak skoro, zgodnie z wyjaśnieniami Odwołującego z dnia 30 października 2024 r., „Zamawiający nie będzie miał możliwości korzystania z bazy danych poprzez wprowadzanie danych do bazy danych czy też ich odczytywanie przez inne aplikacje czy systemy z pominięciem oprogramowania aplikacyjnego dostarczonego przez Wykonawcę”, to jednak status umowy licencyjnej na oprogramowanie aplikacyjne zdaje się mieć zasadniczy wpływ na status oprogramowania bazodanowego. Dowód: ü wyjaśnienia Odwołującego z dnia 24 września 2024 r. wraz z załącznikiem nr 1 – w aktach sprawy ü wyjaśnienia Odwołującego z dnia 30 października 2024 r. – w aktach sprawy Także argument zawarty w pkt 32 odwołania nie potwierdza prezentowanej przez Odwołującego, wewnętrznie zresztą sprzecznej wykładni oświadczenia Zamawiającego zawartego w SW Z, a dotyczącego „niezależności licencji” z uwagi choćby na to, że w § 6 załącznika nr 4 do SW Z, Projektowane Istotne Postanowienia Umowy (PIPU), który należało interpretować łącznie z pozostałymi postanowieniami dokumentów zamówienia, Zamawiający wyraźnie wymagał, aby w szczególności: § 6 ust. 1 - Rezultaty prac nie były obciążone prawami osób trzecich, uniemożliwiającymi lub utrudniającymi Zamawiającemu korzystanie z tych Rezultatów prac na zasadach określonych w Umowie, § 6 ust. 2 - Wykonawca, w ramach wynagrodzenia, o którym mowa w § 8 Umowy, udzielił Zamawiającemu licencji niewyłącznej na System oraz na wszelkie Rezultaty prac, w tym te stanowiące modyfikacje oraz aktualizacje Systemu powstałe w wyniku świadczenia Gwarancji, Usług Utrzymania oraz Usług Rozwoju, na polach eksploatacji określonych w §6 ust. 3, § 6 ust. 7 - Licencja,
§6ust.
2 i 3, udzielana była bez ograniczeń co do celu lub sposobu korzystania z Systemu lub innych Rezultatów prac, w tym umożliwiała korzystanie z Systemu w Infrastrukturze technicznej Zamawiającego, § 6 ust. 12 - Wykonawca zapewnił, że licencja,
§6ust.
2 i 3 nie będzie zawierała ograniczeń polegających na tym, że dane oprogramowanie może być używane wyłączenie z innym oprogramowaniem lub może być wdrażane, serwisowane, rozwijane itp. wyłącznie przez określony podmiot lub grupę podmiotów. Dowód: załącznik nr 4 do SWZ, Projektowane Istotne Postanowienia Umowy (PIPU) – w aktach sprawy Zaznaczyć należy, że również wykładnia oświadczenia Zamawiającego w zakresie pól eksploatacji określonych w § 6 ust. 3 załącznika nr 4 do SW Z, Projektowane Istotne Postanowienia Umowy (PIPU), a w tym postanowienia § 6 ust. 3 pkt 1, 2, 3 i 4 przesądzają o tym, że wymóg „niezależności licencji” sformułowany przez Zamawiającego nie dotyczył strony formalnej prawa, czyli jak twierdzi Odwołujący jedynie oddzielnych umów licencyjnych, lecz dotyczył on niezależności merytorycznej, czyli takiej, która umożliwi korzystanie z oprogramowania bazy danych w sposób całkowicie niezależny od oprogramowania aplikacyjnego. Dowód: załącznik nr 4 do SWZ, Projektowane Istotne Postanowienia Umowy (PIPU) – w aktach sprawy To, że szczegółowe wezwanie do wyjaśnienia treści oferty w powyższym zakresie zostało do Odwołującego skierowane w treści pisma z dnia 28 października 2024 r. wynikało wyłącznie z treści wcześniejszych wyjaśnień Odwołującego, a w tym w szczególności z treści pisma Odwołującego z dnia 11 października 2024 r., w którym Odwołujący oświadczył, że licencje bazodanowe oraz licencje aplikacyjne w celu realizacji przedmiotu zamówienia nabędzie on w ramach jednego pakietu (bundla), co z kolei zrodziło po stronie Zamawiającego dodatkowe wątpliwości co do zgodności treści oferty Odwołującego z warunkami zamówienia i bynajmniej nie przeczy twierdzeniom Zamawiającego o „wyraźnych” oczekiwaniach w kontekście niezależności licencji. Dowód: ü wezwanie do wyjaśnień z dnia 28 października 2024 r., pismo znak BZP-I.271.27.55.2023.MW – w aktach sprawy, ü wyjaśnienia Odwołującego z dnia 11 października 2024 r. – w aktach sprawy, Odnośnie kwestii poruszanych w pkt 33 i 34 odwołania Zamawiający wskazuje, że analogicznie jak w przypadku kwestionowania przez Odwołującego wezwania go do wyjaśnienia rażąco niskiej ceny, próba kwestionowania obecnie zasadności i „proporcjonalności” (?) wymogów dotyczących opisu przedmiotu zamówienia oraz sformułowany w powyższym kontekście zarzut niegospodarności, w chwili obecnej powinny zostać uznane za spóźnione. Odnosząc się do pkt 37 i nast. odwołania, z których wynikać miałoby, iż wymóg, o którym mowa w § 6 ust. 12 załącznika nr 4 do SW Z, Projektowane Istotne Postanowienia Umowy (PIPU) nie dotyczy licencji na bazę danych wskazać należy, że oprogramowanie bazodanowe bezwzględnie stanowi Rezultat prac zdefiniowany w § 1 załącznika nr 4 do SW Z, Projektowane Istotne Postanowienia Umowy (PIPU), zgodnie z którym Rezultat prac (w tym Produkt) to „Oprogramowanie aplikacyjne, Dokumentacja, inne utwory, a także materiały i informacje niepodlegające ochronie prawa autorskiego, a także usługi stworzone lub świadczone przez Wykonawcę w wyniku wykonywania Umowy lub dostarczone Zamawiającemu w wykonaniu zobowiązań wynikających z niniejszej Umowy, w tym System, Aktualizacje prawne, Aktualizacje techniczne, a także modyfikacje i jakiekolwiek inne zmiany wprowadzone do Systemu oraz istniejących materiałów, w tym Oprogramowania aplikacyjnego w toku wykonywania Umowy.” Dowód: załącznik nr 4 do SWZ, Projektowane Istotne Postanowienia Umowy (PIPU) – w aktach sprawy To, że oprogramowanie bazodanowe stanowi Produkt, który z kolei jest Rezultatem prac wynika również z postanowień Szczegółowego Opisu Przedmiotu Zamówienia stanowiącego załącznik nr 3 do SW Z, w którym w pkt 14, P.I.5 Zamawiający wyraźnie wskazał, że Produktem podlegającym odbiorowi będzie Dostawa Komponentu technicznego – serwer bazy danych (wraz z licencjami) – rodzaj Produktu – Oprogramowanie. Dowód: załącznik nr 3 do SWZ, Szczegółowy Opis Przedmiotu Zamówienia – w aktach sprawy Skoro zatem § 6 ust. 12 PIPU odnosił się do licencji,
§6ust.
2 i 3,a licencja,
§ 6ust.
2 i 3 dotyczyła Systemu oraz wszelkich Rezultatów prac, do Rezultatu prac (Produktu) jakim jest oprogramowanie bazodanowe, bezwzględnie zastosowanie ma wymóg wskazany w § 6 ust. 12 PIPU. Co więcej, sam Odwołujący zakwalifikował oprogramowanie bazodanowe jako „Rezultat prac”, czego dowodzi wskazanie przez niego w załączniku nr 1 do wyjaśnień z dnia 24 września 2024 r. (Etap I) produktu Oracle Database Standard Edition 2 w pozycji „licencje na Rezultaty prac wykonane przez Wykonawcę (wymienić jakie)”. Dowód: wyjaśnienia Odwołującego z dnia 24 września 2024 r. wraz z załącznikami – w aktach sprawy Podejmowanie przez Odwołującego polemiki z powyżej przedstawionymi wymogami odnośnie Systemu i Rezultatów prac w kontekście zasad licencjonowania „komercyjnych oprogramowań bazodanowych” oraz „praktyki rynkowej” dopiero na obecnym etapie postępowania, należy uznać za bezzasadne i spóźnione. ZARZUT NR 2 Odnośnie zarzutu nr 2 odwołania w pierwszej kolejności Zamawiający podnosi, że aby dokonać poprawy w treści oferty wykonawcy tzw. „innej omyłki” zajść muszą łącznie nw. warunki: ‒ błąd w ofercie musi stanowić omyłkę, a nie wynik intencjonalnego działania wykonawcy, ‒ omyłka musi polegać na niezgodności oferty z dokumentami zamówienia, ‒ poprawa omyłki nie spowoduje istotnych zmian w treści oferty. Co do omyłkowego charakteru wskazania w wyjaśnieniach z dnia 24 września 2024 r. bazy danych w wersji Standard zamiast, jak twierdzi Odwołujący, w wersji Enterprise, to nie sposób przyznać racji Odwołującemu, skoro nawet w treści odwołania, Odwołujący najwidoczniej sam do końca nie mogąc zdecydować, którą wersję oprogramowania bazodanowego oferuje wykazuje, że wersja Oracle Database Standard Edition 2 spełnia jednak wymogi dokumentów zamówienia i oferta uwzględniająca tę wersję (co prawda dopiero „w połączeniu” z funkcjonalnościami, które Odwołujący przywołał, jedynie przykładowo i wariantowo, dopiero w treści odwołania) powinna zostać uznana za zgodną z warunkami zamówienia. Dodatkowo, jak już wskazywano w informacji o wyniku postępowania, bezspornym pozostaje, że w przedmiotowym postępowaniu, na zmodyfikowane zapisy dokumentów zamówienia, Odwołujący wniósł odwołanie, w którym podnosił, że kwestionowane przez niego zapisy SW Z „(…) podtrzymują (…) dla rozwiązań opartych na technologii firmy Microsoft, zastosowanie standardowej wersji bazy danych (Standard Edition) jednocześnie uniemożliwiając zastosowanie tej samej, standardowej wersji baz danych innych firm np. Oracle (…)”. Treść ww. odwołania (uwzględnionego przez Zamawiającego) również jednoznacznie potwierdza zatem, że intencją Odwołującego było takie ukształtowanie dokumentów zamówienia, które umożliwi Odwołującemu złożenie w postępowaniu oferty uwzględniającej zastosowanie standardowej wersji bazy danych. Co więcej, nieprzekonujące są twierdzenia Odwołującego o „omyłce” w analizowanym zakresie, z uwagi na to, że: ‒ załącznik nr 1 do wyjaśnień z dnia 24 września 2024 r. składał się jedynie z nieco ponad 30 pozycji (dwie strony tekstu), a zatem popełnienie przy wypełnianiu go „omyłki” jest mało prawdopodobne, ‒ w odwołaniu i w wyjaśnieniach z dnia 1 października 2024 r. Odwołujący powołuje się na „dogłębną analizę OPZ”, poczynioną już po przejściu procedury odwoławczej, która uświadomiła Wykonawcę o konieczności zastosowania licencji Enterprise Edition nie tylko ze względu na zapisy będące podstawą do odwołania, co sprawiło, zgodnie z oświadczenie Odwołującego, że Odwołujący „(…) jeszcze przed przystąpieniem do kalkulacji oferty miał świadomość konieczności zaoferowania licencji w wersji Enterprise” ‒ popełniony „błąd” w składanych wyjaśnieniach został powtórzony dwukrotnie - zatem gdyby intencją Odwołującego rzeczywiście było wskazanie oprogramowania bazodanowego Oracle Database Enterprise Edition, Odwołujący z pewnością zauważyłby popełnioną omyłkę i niezwłocznie skorygował ją w składanym oświadczeniu. Dowód: ü wyjaśnienia Odwołującego z dnia 24 września 2024 r. wraz z załącznikami – w aktach sprawy ü wyjaśnienia Odwołującego z dnia 1 października 2024 r. – w aktach sprawy Jak także podkreślano wcześniej, twierdzeniom Odwołującego o „omyłce” przeczy również to, że w przedstawionych warunkach handlowych Oracle dla oprogramowania OTAGO, oprogramowanie bazodanowe w wersji Oracle Database Standard Edition 2 występuje zawsze „w komplecie” z oprogramowaniem aplikacyjnym Forms&Reports, natomiast Oracle Database Enterprise Edition, i to jako jedyny produkt, występuje w komplecie z Weblogic Suite (w żadnej z opcji warunków handlowych Oracle nie występuje w ramach jednego pakietu Oracle Database Enterprise Edition razem z Forms&Reports). W wyjaśnieniach Wykonawcy z dnia 24 września 2024 r., dwukrotnie wpisano natomiast „komplet” występujący w ww. warunkach handlowych, tj. Oracle Database Standard Edition 2 wraz z Forms&Reports, co także, gdyby rzeczywiście stanowiło „omyłkę”, z pewnością rzuciłoby się w oczy osobie sporządzającej lub weryfikującej składane wyjaśnienia, w konsekwencji czego, zostałoby zauważone i skorygowane przed wysłaniem wyjaśnień Zamawiającemu. Dowód: warunki handlowe Oracle dla oprogramowania OTAGO stanowiące załącznik do wyjaśnień Odwołującego z dnia 24 września 2024 r. – w aktach sprawy W tym miejscu podkreślić należy, że umyślne zastosowanie rozwiązania całkowicie odmiennego od wymagań zamawiającego, nie może być traktowane jako omyłka w tym sensie, który nadaje jej przepis art. 223 ust. 2 pkt 3 ustawy PZP, co potwierdzono m. in. w wyrok Krajowej Izby Odwoławczej z dnia 19 stycznia 2023 r., sygn. akt KIO 54/23. „Błąd” polegający na wskazaniu bazy danych Oracle Database Standard Edition 2 zamiast, jak twierdzi Odwołujący, Oracle Database Enterprise Edition nie może zostać poprawiony w trybie przewidzianym w art. 223 ust. 2 pkt 3 PZP także z uwagi na to, że w dokumentach zamówienia Zamawiający nie wskazał jaką konkretnie licencję bazy danych wykonawcy mają dostarczyć. Stosując zatem wnioski wynikające z uchwały Sądu Najwyższego z dnia 20 października 2011 r., sygn. akt III CZP 52/11 w którym podkreślono, że „W sytuacji, w której zamawiający nie określił w specyfikacji istotnych warunków zamówienia stawki podatku VAT w ogóle nie może dojść do wystąpienia innej omyłki w rozumieniu art. 87 ust. 2 pkt 3 Pr.z.p., ponieważ nie wystąpi wówczas ustawowa przesłanka niezgodności oferty ze specyfikacją wobec braku dwóch potrzebnych do porównania elementów, niezbędnych do oceny przesłanki w postaci zaistnienia niezgodności”, uznać należy, że niemożliwa była korekta oferty Odwołującego z powołaniem się na art. 223 ust. 2 pkt 3 PZP, ponieważ oprogramowanie bazodanowe opisane zostało w dokumentach zamówienia jedynie poprzez wymagane cechy i funkcje, których to cech i funkcji nie spełnia konkretne, zaoferowane przez Odwołującego „z nazwy, wersji i producenta” oprogramowanie bazodanowe. Z ostrożności wskazać należy również, że zmiana, jakiej domaga się Odwołujący, spowodowałaby istotną zmianę w treści oferty. Uzasadniając powyższe podnieść należy, że jako wyjątek od ogólnego zakazu negocjowania i zmieniania treści złożonych ofert, poprawienie omyłek w trybie art. 223 ust. 2 pkt 3 PZP musi być stosowane ostrożnie i z uwzględnieniem wyjątkowego charakteru tej instytucji. W wyroku z 13 września 2012 r., sygn. akt KIO 1821/12 Izba, odnosząc się do zagadnienia poprawienia w ofertach omyłek zwróciła uwagę, iż ratio legis tego przepisu to sanowanie ofert obarczonych nieistotnymi wadami, będącymi wynikiem różnego rodzaju błędów i omyłek, które nie prowadzą do istotnych zmian w treści oferty – nie zniekształcają w znaczącym stopniu oświadczenia woli wykonawcy ubiegającego się o zamówienie. Izba wskazała także, że poprawienie oferty nie może zatem stanowić wytworzenia zupełnie odmiennego, nowego oświadczenia woli wykonawcy, np. w przedmiocie oferowanego świadczenia, czy dowolnego wypełnienia go dodatkową treścią, co do której zamawiający nie posiada żadnych danych i informacji, podkreślając przy tym, iż w szczególności przy zmianie oferowanego świadczenia zamawiający nie może polegać tylko na oświadczeniu wykonawcy, w jaki sposób jego ofertę należy poprawić, bez dodatkowych, niejako obiektywnych przesłanek w tym zakresie. Przenosząc treść powyższych wywodów na stan faktyczny niniejszej sprawy Zamawiający podnosi, że dokonanie przez Zamawiające zmiany bazy danych z Oracle Database Standard Edition 2 na Oracle Database Enterprise Edition, tylko i wyłącznie na podstawie oświadczenia Odwołującego, stanowiłaby istotną ingerencję w treść zaoferowanego przez Odwołującego świadczenia, baza danych bowiem, szczególnie w przypadku systemu kadrowo – płacowego, jako jeden z konstytutywnych jego elementów, ma zasadnicze znaczenia dla funkcjonowania i korzystania z tegoż systemu. Co więcej, nawet treść zarzutu nr 3 Odwołującego wskazuje na istotność zmiany, którą próbuje on przeforsować, skoro bowiem „dostosowanie” Oracle Database Standard Edition 2 do pełnienia funkcji, które posiada Oracle Database Enterprise Edition wymagałaby aż tak wielu działań (Odwołujący opisuje je na dziesięciu stronach tekstu!), nie sposób uznać, że mamy tu do czynienia ze zmianą, która nie powoduje istotnych zmian w treści oferty. Kończąc przedmiotowe rozważania zauważyć należy również, że nieprawdą jest twierdzenie zawarte w pkt 50 odwołania (str. 19), w którym Odwołujący wskazuje, że „(…) poprawa innej omyłki w trybie 223 ust. 2 pkt 3 PZP, poprzez zastąpienie licencji Oracle Database Standard Edition 2 na Oracle Database Enterprise Edition (przy – co istotne – zachowaniu nadal tej samej ceny ofertowej) pozostawało zasadne i konieczne” z uwagi na to, że zmiana, którą forsuje Odwołujący spowodowała właśnie zmianę ceny ofertowej, co wskazywano już w informacji o wyniku postępowania - w piśmie z dnia 11 października 2024 r. Wykonawca wskazał bowiem dwukrotnie(!), że oferuje Zamawiającemu cenę za pakiet licencji bazodanowej Oracle Database Enterprise Edition i licencji aplikacyjnych wynoszącą 233 000 zł + 175 510 zł = 408 510 zł, choć w załączniku do wyjaśnień z dnia 24 września 2024 r., oferowany jeszcze na tym etapie postępowania - pakiet Oracle Database Standard Edition 2 wraz z Forms&Reports Wykonawca wycenił na kwotę o 10 000 zł niższą, tj. 223 000 zł + 175 510 zł. Powyższe oznacza, że zmiana oferty Odwołującego w analizowanym zakresie spowodowała wzrost ceny oferty o co najmniej 10 000 zł, co jest o tyle istotne, że cena oferty Wykonawcy wynosząca 3 999 580,00 zł pokrywa się z wyliczeniami zawartymi w wyjaśnieniach z dnia 24 września 2024 r., w których to wyliczeniach Wykonawca wycenił i zaoferował Zamawiającemu Oracle Database Standard Edition 2 za cenę 223 000 zł. Dowód: ü wyjaśnienia Odwołującego z dnia 11 października 2024 r. – w aktach sprawy, ü wyjaśnienia Odwołującego z dnia 24 września 2024 r. wraz z załącznikami – w aktach sprawy Kończąc przedmiotowe rozważania podnieść należy, że zgodnie z publikacją Urzędu Zamówień Publicznych - Prawo zamówień publicznych. Komentarz pod redakcją Huberta Nowaka i Mateusza Winiarza, art. 223 ust. 2 pkt 3 PZP daje zamawiającemu możliwość poprawiania uchybień w ofertach merytorycznie poprawnych, w celu zapobieżenia ich eliminacji z postępowania z przyczyn wyłącznie formalnych lub niemających istotnego znaczenia w kontekście oferowanego świadczenia. Przepis ten, zdaniem komentatorów, nie stanowi zatem narzędzia do naprawiania błędnie złożonych ofert, lecz jest podstawą poprawienia omyłek, którego może dokonać zamawiający, a znaczenie tych poprawek dla całości złożonego oświadczenia woli (oferty) wykonawcy nie będzie istotne. Proces poprawiania omyłek nie może prowadzić przy tym do konieczności znaczącej ingerencji ze strony zamawiającego w treść oferty. Wystąpienie omyłki, zdaniem Urzędu, nie może też pozostawiać wątpliwości co do zamierzonej treści oświadczenia wykonawcy. Dodatkowo, odwołując się jeszcze do ratio legis normy wyrażonej w art. 223 ust. 2 pkt 3 PZP wskazać należy, że orzecznictwo Krajowej Izby Odwoławczej oraz Trybunału Sprawiedliwości Unii Europejskiej wskazuje, że zasady równego traktowania i niedyskryminacji oraz obowiązek przejrzystości stoją na przeszkodzie negocjacjom między zamawiającym, a wykonawcą w ramach postępowania o udzielenie zamówienia publicznego. Co do zasady więc oferta nie może być modyfikowana po jej złożeniu i to ani z inicjatywy zamawiającego, ani wykonawcy. Co więcej, intencją ustawodawcy towarzyszącą wprowadzeniu artykuł 87 ust. 2 pkt 3 PZP było zniwelowanie formalizmu poprzednich regulacji występującego na gruncie ustawy, a nie doprowadzenie do tego, że wykonawcom umożliwi się dowolne dokonywanie zmian w składanych ofertach, czy też oferowanie świadczenia wariantowego, uzależnionego od tego, którą z „wersji” oferty wykonawcy zamawiający uzna za zgodną z dokumentami zamówienia. Chodziło zatem o umożliwienie brania pod uwagę w postępowaniu o udzielenie zamówienia publicznego ofert obarczonych nieistotnymi wadami, będącymi wynikiem różnego rodzaju błędów i omyłek, których skorygowanie nie prowadzi do istotnych zmian w treści oferty. Wynika to wprost z uzasadnienia do ustawy z dnia 4 września 2008 roku o zmianie ustawy Prawo zamówień publicznych oraz niektórych innych ustaw, w którym wskazano że „W projekcie (…) rezygnuje się z z