KIO 1043/17 WYROK dnia 7 czerwca 2017 roku

Sygn. akt: 

KIO 1043/17 

WYROK 

z dnia 7 czerwca 2017 roku 

Krajowa Izba Odwoławcza   -   w składzie: 

Przewodniczący:      Justyna Tomkowska 

Protokolant:             Adam Skowroński 

po  rozpoznaniu  na  rozprawie  w  dniu  7  czerwca  2017  roku  w  Warszawie  odwołania 

wniesionego  do  Prezesa  Krajowej  Izby  Odwoławczej  w  dniu  26  maja  2017  roku  przez

Odwołującego  –  INTERGRAPH  Polska  Sp.  z  o.o.  z  siedzibą  w  Warszawie,  

w  postępowaniu  prowadzonym  przez

  Zamawiającego  –  Skarb  Państwa,  Komendanta 

Głównego Państwowej Straży Pożarnej z siedzibą w Warszawie 

przy  udziale  wykonawcy  ubiegającego  się  o  udzielenie  zamówienia

  S&T  Services  Polska 

Sp.  z  o.o.  z  siedzibą  w  Warszawie  zgłaszającego  przystąpienie  do  postępowania 

odwoławczego po stronie zamawiającego 

orzeka: 

oddala odwołanie, 

kosztami postępowania obciąża Odwołującego i: 

zalicza  w  poczet  kosztów  postępowania  odwoławczego  kwotę  15  000,00 zł 

(słownie: piętnastu  tysięcy  złotych  00/100)  uiszczoną  przez 

Odwołującego  INTERGRAPH 

Polska Sp. z o.o. z siedzibą w Warszawie tytułem wpisu od odwołania 

Stosownie  do  art.  198a  i  198b  ustawy  z  dnia  29  stycznia  2004  r.  Prawo  zamówień 

publicznych (Dz.U.2015.2164 j.t. ze zm.) na niniejszy wyrok – w terminie 7 dni od dnia jego 

doręczenia – przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do

Sądu Okręgowego w Warszawie 

Przewodniczący:       

sygn. akt KIO 1043/17 

UZASADNIENIE 

W dniu 26 maja 2017 roku do Prezesa Krajowej Izby Odwoławczej w Warszawie, na 

podstawie  art.  179  ust.  1  i  art.  180  ust.  1,  a  także  art.  182  ust.  2  pkt  1  ustawy  z  dnia  29 

stycznia 2004 roku - Prawo zamówień publicznych (t.j. Dz. U. z 2015 r., poz. 2164 ze zm.), 

zwanej  dalej  „ustawą  Pzp”,  odwołanie  złożył  wykonawca 

Intergraph  Polska  Sp.  z  o.o.  

z siedzibą w Warszawie, zwany dalej „Odwołującym”.  

Postępowanie 

o 

udzielenie 

zamówienia  publicznego 

w  trybie  przetargu 

nieograniczonego  „Budowa  Systemu  Wspomagania  Decyzji  Państwowej  Straży  Pożarnej” 

prowadzi 

Zamawiający:  Skarb  Państwa  -  Komendant  Główny  Państwowej  Straży 

Pożarnej  z  siedzibą  w  Warszawie.  Ogłoszenie  o  zamówieniu  zostało  opublikowane  

w  Dzienniku  Urzędowym  Unii  Europejskiej  w  dniu  16  maja  2017  r.,  pod  numerem  2017/S 

Odwołanie  wniesiono  wobec  treści  ogłoszenia  o  zamówieniu  oraz  Specyfikacji 

Istotnych Warunków Zamówienia (dalej SIWZ) wraz z załącznikami, w tym Załącznikiem nr 2 

Projekt umowy, zarzucając Zamawiającemu naruszenie art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2 

ustawy  Pzp  poprzez  opisanie  przedmiotu  zamówienia  w  sposób,  który  utrudnia 

przestrzeganie  zasad  uczciwej  konkurencji  i  równego  traktowania  wykonawców  oraz  bez 

zachowania  zasad  proporcjonalności  i  przejrzystości,  na  skutek  wprowadzenia  przez 

Zamawiającego 

żą

dań 

udostępnienia 

kodów 

ź

ródłowych 

do 

oprogramowania 

standardowego,  a  także  wyrażenia  zgody  na  wykonywanie  praw  zależnych  do 

oprogramowania  standardowego,  które  to  kryteria  znacząco  i  bezzasadnie  zawężając  krąg 

Wykonawców zdolnych do złożenie ofert w przetargu. 

Odwołujący  wnosił  o  nakazanie  Zamawiającemu  modyfikacji  treści  ogłoszenia  

o  zamówieniu  oraz  SIWZ  poprzez  doprowadzenie  jej  postanowień  do  zgodności  z  ustawą 

Pzp, w szczególności poprzez zmianę treści ogłoszenia o zamówieniu oraz SIWZ w sposób 

opisany w uzasadnieniu odwołania. 

Odwołujący wskazała, iż posiada interes w uzyskaniu zamówienia, a także w złożeniu 

odwołania,  bowiem  zamierza  ubiegać  się  o  udzielenie  zamówienia.  Postanowienia 

ogłoszenia  o  zamówieniu  oraz  SIWZ  uniemożliwiają  mu  złożenie  oferty.  W  konsekwencji, 

Odwołujący się może ponieść szkodę wynikającą z braku możliwości uzyskania zamówienia, 

a  w  konsekwencji  tego  narażony  jest  on  na  szkodę  w  postaci  utraty  zysku,  który  mógłby 

osiągnąć w wypadku wyboru jego oferty, jako oferty najkorzystniejszej. 

Odwołanie  zostało  wniesione  z  zachowaniem  ustawowego  terminu  przewidzianego  

w  art.  182  ust.  1  pkt  1  ustawy  Pzp.  Kopia  odwołania  została  przekazana  Zamawiającemu. 

Odwołujący uiścił wpis w wymaganej wysokości na rachunek UZP.  

W uzasadnieniu zauważono, że przedmiotem zamówienia jest wykonanie i wdrożenie 

Systemu Wspomagania Decyzji Państwowej Straży Pożarnej wspierającego: 

— 

wykonywanie  zadań  krajowego  systemu  ratowniczo-gaśniczego  przez  wszystkie 

jednostki organizacyjne Państwowej Straży Pożarnej, 

— 

przyjmowanie zgłoszeń i rejestrację zdarzeń, 

— 

alarmowanie i powiadamianie sił i środków, 

— 

dysponowanie siłami i środkami, 

— 

nadzorowanie i koordynację działań podczas zdarzeń, 

— 

 wymianę  informacji  i  danych  między  wszystkimi  jednostkami  organizacyjnymi 

Państwowej Straży Pożarnej oraz innymi partnerami, 

— 

 prowadzenie  ewidencji  podmiotów,  sił  i  środków  Państwowej  Straży  Pożarnej, 

Ochotniczej  Straży  Pożarnej,  Zakładowych  Straży  Pożarnych  i  Zakładowych  Służb 

Ratowniczych, oraz innych jednostek i podmiotów współpracujących, 

— 

ewidencjonowanie  dostępnych  dla  Państwowej  Straży  Pożarnej  sił  i  środków  innych 

zasobów  pochodzących  z  instytucji  i  organizacji  współpracujących  z  Państwową  Strażą 

Pożarną, 

— 

współpracę  z  urządzeniami  łączności  oraz  urządzeniami  umożliwiającymi  śledzenie 

pojazdów,  nadzór,  alarmowanie  i  powiadamianie  sił  i  środków,  a  także  sterowanie 

automatyką przemysłową, 

— 

sporządzanie dokumentacji z prowadzonych działań operacyjnych, 

— 

generowanie analiz, raportów, zestawień i statystyk na podstawie wszystkich danych 

wprowadzonych do systemu, 

— 

korzystanie  z  usług  danych  przestrzennych,  udostępnionych  za  pośrednictwem 

Uniwersalnego Modułu Mapowego, 

— 

wymianę  informacji  z  Centrami  Powiadamiania  Ratunkowego  za  pośrednictwem 

interfejsu komunikacyjnego, 

— 

pozyskiwanie  i  prezentację  danych  dotyczących  lokalizacji  zakończenia  sieci 

telekomunikacyjnej, z których zostało wykonane połączenie do numeru alarmowego. 

Zamawiający w swoich wymaganiach przyjął, że system między innymi obsługiwać ma: 

— 

minimum 1000 równoczesnych użytkowników w przypadku obsługi zgłoszeń/zdarzeń, 

— 

minimum  1000  równoczesnych  użytkowników  dla  pozostałych  funkcjonalności 

systemu, z liczbą kont użytkowników szacowaną na 30000 sztuk. 

System  ten  jest  więc  systemem krytycznym  dla  bezpieczeństwa  kraju.  Zamawiający 

mając  tego  świadomość  postawił  ostre  kryteria  warunków  udziału  dotyczących  zdolności 

technicznej Wykonawcy, który zobowiązany jest wykazać się doświadczeniem polegającym 

na  stworzeniu  ogólnokrajowego  systemu  klasy  C2  (system  o  wzmocnionej  kategorii 

bezpieczeństwa  izolujący  użytkowników  i  dane)  lub  inny  ogólnokrajowy  system  o  wartości 

min.  10  mln  zł  z  łączną  liczbą  użytkowników  na  poziomie  min.  30  tys.  w  tym  min.  2  tys. 

aktywnych  użytkowników,  jego  dostawie  wraz  z  montażem  urządzeń  i  wykonaniu  instalacji 

wraz  z  wdrożeniem.  Podobnie  jest,  jeśli  chodzi  o  dysponowanie  odpowiednim  personelem. 

Od  Wykonawcy  wymaga  się  by  zapewnił  rozbudowany  zespół  projektowy  składający  się  

z  zarówno  z  architektów  systemu  jak  i  inżynierów  z  zakresu  wdrożenia  systemów, 

programowania,  routingu  i  switchingu,  bezpieczeństwa  systemów  informatycznych,  data 

center,  kontroli  jakości  czy  metody  waterfall.  Od  wszystkich  tych  osób  oczekuje  się 

odpowiednich  certyfikatów  oraz  kilku  lat  doświadczenia  przy  podobnych  projektach 

wdrożeniowych. 

Zakres  i  waga  zadania  znajduje  odzwierciedlenie  w  przedmiocie  Umowy.  Zgodnie  

z  definicją  §  1  pkt  35  Umowy  System  stanowi  Oprogramowanie  i  Urządzenia  dostosowane 

do  wymagań  Umowy,  w  tym  w  szczególności  do  wymagań  funkcjonalnych  

i  niefunkcjonalnych  zdefiniowanych  w  załączniku  nr  1  do  Umowy,  zainstalowane  

i  skonfigurowane  na  Infrastrukturze  Technicznej  i  Infrastrukturze  Zamawiającego  w  OK  

i Lokalizacjach. System stanowi dzieło w rozumieniu przepisów kodeksu cywilnego, zaś pod 

pojęciem  Oprogramowanie  zgodnie  z  §  1  pkt  24  Umowy  rozumiemy  całość  lub  dowolny 

element  oprogramowania  dostarczanego  lub  wykonywanego  w  ramach  realizacji  Umowy.  

W skład Oprogramowania wchodzi: 

a) 

Standardowe Oprogramowanie Systemowe - oprogramowanie tworzące  środowisko, 

w  którym  uruchamiane  jest  Oprogramowanie,  w  tym  oprogramowanie  systemowe  lub 

bazodanowe, 

b) 

Standardowe  Oprogramowanie  Aplikacyjne  -  oprogramowanie  będące  podstawą  do 

stworzenia Systemu, istniejące i dystrybuowane przed zawarciem Umowy, 

c) 

Oprogramowanie  Dedykowane  -  oprogramowanie  tworzone  na  potrzeby  Umowy,  

w  tym  rozbudowa  lub  modyfikacja  Standardowego  Oprogramowania  Aplikacyjnego.  Jeżeli 

dane  Oprogramowanie  nie  zostało  przypisane  do  Standardowego  Oprogramowania 

Systemowego  lub  Standardowego  Oprogramowania  Aplikacyjnego  uważa  się  je  za 

Oprogramowanie Dedykowane, 

d) 

Oprogramowanie Open Source - oprogramowanie dystrybuowane na warunkach tzw. 

licencji otwartych. 

Bezspornie  zatem  przedmiotem  zamówienia  jest  skomplikowany,  wymagający 

specjalistycznej  wiedzy,  doświadczenia  i  sprawności  organizacyjnej  system  informatyczny,  

o  szacowanym  budżecie  wykonawczym  kontraktu  ok.  16  mln  zł.  Jest  to  także  system 

autorski,  przeznaczony  do  konkretnych  zadań  wykonywanych  wyłącznie  przez  ściśle 

określone podmioty publiczne, skutkiem czego nie jest dostępny w standardowej ofercie firm 

informatycznych. Oznacza to, że trzeba go zaprojektować, zbudować i wdrożyć od podstaw, 

co  przy  wielowątkowym  i  wielopłaszczyznowym  charakterze  zadania  wymaga  znacznego 

nakładu  pracy  oraz  zaangażowania  dużych  środków  finansowych.  Już  sama  analiza 

postanowień  Umowy  świadczy  o  tym,  że  planowany  System  będzie  zawierał  środowisko 

pracy,  główne  oprogramowanie  (bazę/silnik)  uzupełnioną  o  dedykowane  moduły,  a  także 

może składać się z komponentów na licencjach open source. 

Zamawiający  oczekuje,  że  System  zostanie  zbudowany  na  bazie  Standardowego 

Oprogramowania  Aplikacyjnego  (dalej  SOA),  które  już  istnieje  i  jest  dystrybuowane,  a  więc 

jest  tzw.  pudełkowym  oprogramowaniem  (COTS  -  commercial  off  -  the  -  shelf).  Zgodnie  

z SIWZ by dostosować SOA jako oprogramowanie typu COTS do wytycznych, zostanie ono 

zaadaptowane  do  specyfiki  procedur  biznesowych  stosowanych  przez  Zamawiającego, 

rozszerzone  o  brakujące  w  SOA  funkcjonalności  i  warstwę  integracyjną  z  systemami 

znajdującymi  się  w  otoczeniu  systemu  SWD.  Analizując  dokumentację  techniczną  gotowe 

oprogramowanie  SOA  powinno  posiadać  konstrukcję  modułową,  która  w  połączeniu  

z  Oprogramowaniem  Aplikacyjnym  Dedykowanym  umożliwi  dostarczenie  modułów  aplikacji 

realizujących 

wymagania 

Zamawiającego 

związane 

z 

następującymi 

grupami 

funkcjonalności:  Stanowisko  kierowania,  Informacje  o  zdarzeniach,  Sztab,  Odwody 

operacyjne,  Czasy  operacyjne,  Siły  i  środki,  Wspomaganie  decyzji,  Moduł  analityczno- 

statystyczny,  Ewidencja  czasu  służby  i  dane  kadrowe  oraz  Moduł  administrowania 

systemem.  Oprogramowanie  oferowane  przez  Wykonawców  jako  SOA  musi  spełniać 

powyższe założenia, tym samym istnieć już obecnie na zaawansowanych poziomie zarówno 

jeśli chodzi o wewnętrzną architekturę, jak i strukturę samego kodu. 

Założenia techniczne w ocenie Odwołującego są poprawne. Działanie polegające na 

dostosowywaniu  oprogramowania  standardowego  do  potrzeb  klienta,  tzw.  kastomizacja 

oprogramowania,  jest  normalną  praktyką  rynkową  w  branży  IT,  znacząco  przyspieszającą  

i ograniczającą koszty wdrożenia nowych systemów informatycznych. Bezspornie koncepcja 

bazy  na  gotowym  oprogramowaniu  COTS,  które  zostanie  dostosowane  do  wymagań 

Zamawiającego usprawni proces wdrożeniowy Systemu Wspomagania Decyzji  Państwowej 

Straży Pożarnej i jest pochodną faktu, że współczesne metasystemy to połączone struktury 

wielu  systemów  operacyjnych,  środowisk  deweloperskich,  systemów  baz  danych, 

frameworków,  aplikacji,  bibliotek,  komponentów  i  modułów.  Z  tym  że  w  praktyce  rynkowej 

właściwie  wszystkie  wdrożeniowe  kontrakty  informatyczne  zawierane  w  ramach  zamówień 

publicznych  posługują  się  konstrukcją,  w  której  do  komponentów  gotowych  udziela  się 

licencji  standardowych,  zaś  majątkowe  prawa  autorskie  przenosi  się  jedynie  do 

dedykowanego oprogramowania. Konstruowanie w ten sposób zapisów umów z obszarze IT 

wynika  ze  znajomości  przez  zamawiających  specyfiki  branży,  gdyż  strony  umów 

wdrożeniowych  zdają  sobie  sprawę,  że  przeniesienie  praw  autorskich  do  oprogramowania 

standardowego,  nierzadko  stanowiącego  rezultat  wieloletniej  pracy  firmy,  będzie  bardzo 

kosztowe bądź wręcz niemożliwe. 

O ile więc bez wątpienia Zamawiający mógł zgodnie z dobrą praktyką zaprojektować 

System  jako  kompilacje  oprogramowania  gotowego  i  dedykowanego,  to  żądanie 

udostępnienia kodów źródłowych do oprogramowania standardowego wraz z uprawnieniem 

do wykonywania praw zależnych w ocenie Odwołującego narusza normy ustawy Pzp. Zarzut 

opisania  przedmiotu  zamówienia  w  sposób,  który  utrudnia  uczciwą  konkurencję,  narusza 

równe  traktowania  wykonawców  oraz  zasady  proporcjonalności  i  przejrzystości  sprowadza 

się  do  tego,  że  przy  tak  skonstruowanych  postanowieniach  prawnoautorskich  oferta  może 

zostać  złożona  tylko  przez  producenta  oprogramowania,  który  w  dodatku  zdecyduje  się 

udostępnić  do  niego  kody  źródłowe,  a  także  zezwoli  na  dalszą  swobodną  dystrybucję 

opracowań.  Oznacza  to,  że  Zamawiający  przyznaje  uprzywilejowaną  pozycję  producentom 

oprogramowania  z  pokrzywdzeniem  podmiotów,  które  dystrybuują  i  zapewniają  opiekę 

techniczną  produktów  w  pełni  zdolnych  do  wykonania  założeń  Umowy.  Ponadto  żądanie 

przekazania  kodów  źródłowych  i  udzielnie  zgody  na  wykonywania  praw  zależnych  nie  jest 

także  uzasadnione,  ani  przedmiotem  zamówienia,  ani  w  żaden  sposób  nie  przystaje  do 

praktyki rynkowej. 

Zgodnie z § 18 ust. 4 Umowy Licencja na Standardowe Oprogramowanie Aplikacyjne 

obejmuje: 

tłumaczenie,  przystosowywanie,  zmiany  układu  lub  wprowadzanie  jakichkolwiek 

innych zmian w Standardowym Oprogramowaniu Aplikacyjnym; 

zezwolenie  na  wykonywanie  zależnych  praw  autorskich  do  wszelkich  opracowań 

Standardowego  Oprogramowania  Aplikacyjnego,  to  jest  rozporządzanie  i  korzystanie  

z  takich  opracowań  w  zakresie  wszystkich  uprawnień  nabytych  przez  Zamawiającego 

stosownie do postanowień niniejszego paragrafu. 

Uzupełnia to § 20 Umowy: 

Ilekroć  zgodnie  z  postanowieniami  Umowy  Zamawiający  nabywa  na  jakiejkolwiek 

podstawie  prawnej  uprawnienie  do  tłumaczenia,  przystosowywania,  zmiany  układu  lub 

wprowadzania jakichkolwiek innych zmian do określonego Oprogramowania lub korzystania  

i  rozporządzania  autorskimi  prawami  zależnymi  do  opracowań  Oprogramowania, 

Wykonawca  dostarczy  Zamawiającemu  Oprogramowanie  również  w  formie  kodu 

ź

ródłowego. 

Kod  źródłowy,  o  którym  mowa  w  ust.  12,  zostanie  dostarczony  na  informatycznym 

nośniku  danych,  w  formie  umożliwiającej  Zamawiającemu  swobodny  odczyt  kodu 

ź

ródłowego,  a  także  zapisanie  kodu  na  innym  nośniku  i  doprowadzenie  tego  kodu 

ź

ródłowego  do  formy  wykonywalnej,  w  szczególności  w  drodze  kompilacji,  na  odpowiednio 

wyposażonym stanowisku komputerowym. Wraz z kodem źródłowym Wykonawca dostarczy 

kompletny wykaz narzędzi programistycznych, bibliotek i innych elementów niezbędnych do 

doprowadzenia  takiego  Oprogramowania  do  formy  wykonywalnej.  Wykonawca  nie  jest 

uprawniony  do  stosowania  jakichkolwiek  technik  lub  ograniczeń,  które  uniemożliwiłyby  lub 

istotnie  utrudniły  Zamawiającemu  odczyt  lub  zapisywanie  kodu,  w  szczególności 

szyfrowania. 

Kod 

ź

ródłowy 

zostanie 

przekazany 

Zamawiającemu 

wraz 

z 

danym 

Oprogramowaniem,  w  każdym  przypadku  nie  później  niż  na  10  Dni  Roboczych  przed  datą 

Odbioru. 

Zatem Zamawiający żąda udzielenia na SOA licencji, która jednak będzie zezwalała 

na  modyfikacje  standardowego  oprogramowania  i  jej  dalszą  dystrybucję,  a  także 

przekazania  wszystkich  kodów  źródłowych.  O  takiej  intencji  Zamawiającego  świadczy  też 

zapis  §  21  Umowy:  Ilekroć  Umowa  przewiduje  udzielnie  przez  Wykonawcę,  intencją  Stron 

jest  zbliżenie  takiego  upoważnienia  na  korzystanie  ze  Standardowego  Oprogramowania 

Aplikacyjnego  do  umowy  o  charakterze  jednorazowej  transakcji  podobnej  do  sprzedaży  -  

w związku z tym w zamian za uiszczoną opłatę licencyjną (stanowiącą w przypadku Umowy 

element  Wynagrodzenia)  Zamawiający  otrzymuje  ciągłe,  stałe  i  niewypowiadalne  prawo  do 

korzystania z takiego Oprogramowania w zakresie określonym w Umowie. 

Zamawiający  konstruując  Umowę  posiłkował  się  dokumentem  udostępnionym  na 

stronie  Ministerstwa  Cyfryzacji  Umowa  wdrożeniowa  z  usługami  utrzymania.  Wzorcowe 

klauzule (opracowanie: Marcin Maruta, Bartłomiej Wachta, zespół kancelarii Maruta Wachta 

sp.  j.).  Przedmiotowe  opracowanie  w  odniesieniu  do  oprogramowania  SOA  zawiera  kilka 

opcji,  różniących  się  znacznie  podejściem  do  praw  zależnych  i  kodów  źródłowych. 

Zamawiający  wybrał  najbardziej  restrykcyjne  rozwiązanie,  stosując  jedną  z  opcjonalnych 

klauzul bezkrytycznie, zupełnie pomijając istotne uwagi i wytyczne. W komentarzu do klauzul 

związanych  ze  Standardowym  Oprogramowaniem  Aplikacyjnym  (Opracowanie:  str.  75-76) 

możemy  wyczytać  „Standardowe  oprogramowanie  aplikacyjne  to  oprogramowanie,  które 

oferowane  jest  na  rynku  jako  standardowe  rozwiązanie  wykonawcy  lub  zewnętrznego 

producenta  takiego  oprogramowania,  będące  podstawą  do  stworzenia  systemu. 

Oprogramowanie  to  jest  kluczowym  elementem  systemu,  a  czasem  jedynym  przedmiotem 

zamówienia. Nabycie praw majątkowych do takiego oprogramowania wiązałoby się z bardzo 

dużymi  kosztami  lub  wręcz  byłoby  niemożliwe.  Jednocześnie  w  odniesieniu  do 

standardowego  oprogramowania  aplikacyjnego  zazwyczaj  są  większe  możliwości  zmiany 

warunków  licencyjnych  niż  w  odniesieniu  do  oprogramowania  systemowego,  z  reguły  też 

zamawiający  ma  inne  wymagania  w  stosunku  do  aplikacji  (np.  przewiduje  konieczność  jej 

modyfikacji). Konieczne jest dokładne opisanie takich wymagań w SIWZ. 

W  proponowanych  klauzulach  zrezygnowano  z  podziału,  pojawiającego  się  

w  rekomendacjach,  skupionego  na  tzw.  oprogramowaniu  standardowym  wykonawcy.  Taka 

kategoria  opisywała  standardowe  oprogramowania  aplikacyjne,  ale  tylko  takie,  do  którego 

prawa  miał  wykonawca.  W  tej  sytuacji  wykonawca  mógł  swobodnie  kształtować  swoje 

uprawnienia. Z punktu widzenia zamawiającego taki podział ma mniejsze uzasadnienie - dla 

zamawiającego istotne jest, aby aplikacja, będąca podstawą systemu, była objęta warunkami 

SIWZ.  W  przeciwnym  razie  może  dojść  do  niepożądanej  sytuacji,  kiedy  oprogramowanie 

oferowane  przez  wykonawcę  -  polski  podmiot  -  byłoby  traktowane  jako  standardowe 

oprogramowanie  wykonawcy  w  rozumieniu  rekomendacji  (a  więc  np.  z  prawem  do 

modyfikacji),  a  funkcjonalnie  równoważne  oprogramowanie  dostawcy  zagranicznego  -  jako 

oprogramowanie  systemowe  (narzędziowe)  czy  „oprogramowanie  osób  trzecich”,  jak  to 

opisano w rekomendacjach. Co więcej, to samo oprogramowanie byłoby różnie traktowane w 

zależności  od  tego,  czy  ofertę  złożyłby  jego  producent,  czy  partner  producenta  -  w  tym 

drugim  przypadku  ponownie  byłoby  kwalifikowane  jako  „  oprogramowanie  osób  trzecich  ”  

w rozumieniu rekomendacji. 

Kluczową decyzją - w dużej mierze uzależnioną od charakteru oprogramowania - jest 

ewentualne  wymaganie  uzyskania  prawa  modyfikacji  kodu.  Mimo  że  taka  praktyka  jest 

często rekomendowana w celu uniknięcia uzależnienia od wykonawcy (tzw. vendor lock-in), 

zależy ona od wielu uwarunkowań. W części przypadków żądanie takie nie będzie możliwe, 

biorąc pod uwagę skalę projektu (kluczowi dostawcy oprogramowania nieujawniający kodu), 

lub  nie  będzie  miało  uzasadnienia  ze  względu  na  architekturę  aplikacji  (np.  takiej,  która 

dostarcza  wbudowane  narzędzia  do  konfiguracji  i  rozbudowy,  bez  możliwości  i  potrzeby 

ingerencji w kod źródłowy lub w ogóle nie posiada kodu źródłowego jako takiego). 

W niektórych przypadkach może też nie mieć uzasadnienia ze względu na specyfikę 

rozwiązania  i  brak  zasobów  do  ewentualnej  modyfikacji  po  stronie  zamawiającego 

(specjalistyczne rozwiązania autorskie wymagające know-how znanego wyłącznie autorom). 

Przy  uwzględnieniu  zastrzeżenia,  że  warunki  OPZ  nie  mogą  być  uznane  za 

dyskryminacyjne,  jeżeli  będą  z  nich  wynikały  wymagania  niemożliwe  do  spełnienia  przez 

danego wykonawcę, kwestia ta powinna być dokładnie zweryfikowana przez zamawiającego 

na etapie przygotowania SIWZ. 

Szczegółowe  warunki  licencji  mogą  być  określone  na  dwa  sposoby  -  po  pierwsze, 

przez  odesłanie  do  standardowych  warunków  licencyjnych  producenta  standardowego 

oprogramowania  aplikacyjnego;  po  drugie,  przez  wskazanie  warunków  licencji  na 

standardowe oprogramowanie aplikacyjne wprost w umowie. W wariancie drugim warunki te 

zapewniają  z  reguły  szerszy  i  bardziej  dostosowany  do  specyfiki  zamawiającego  zakres 

licencji.  Z  tego  powodu wariant  ten  jest rekomendowany,  ale wymaga  dokładnego  opisania  

w umowie. Wzorcowa klauzula jest dość szeroka i może wymagać korekty (np. co do liczby 

stanowisk, jeżeli może mieć to wpływ na cenę). 

Wśród  postanowień  opcjonalnych  podano  przykład  postanowień  zezwalających 

zamawiającemu  na  modyfikację  standardowego  oprogramowania  aplikacyjnego.  Zwracamy 

uwagę,  że  faktyczna  możliwość  wykonania  modyfikacji  uzależniona  jest  od  dostępu 

zamawiającego do kodu źródłowego. Dostęp zamawiającego do kodu źródłowego powinien 

zostać zapewniony na podstawie odrębnych postanowień umowy. 

Zaakcentowania wymaga zwłaszcza fragment komentarza do Opracowania, mówiący 

o  tym,  Zamawiający  na  etapie  przygotowywania  zamówienia  powinien  dokładnie 

zweryfikować  czy  zastosowanie  restrykcyjnych  warunków  prawnoautorskich  nie  zamknie 

drogi  większości,  jeżeli  nie  wszystkim  Wykonawcom  do  złożenia  ofert  oraz,  że  warunki  w 

pewnych  przypadkach  mogą  być  uznane  za  dyskryminacyjne,  jeżeli  będą  z  nich  wynikały 

wymagania niemożliwe do spełnienia. 

Odwołujący jako spółka grupy kapitałowej Hexagon dysponuje prawami autorskimi do 

oprogramowania,  które  spełnia  podobne  zadania  jak  System  w  postępowaniu  i  które  

z sukcesem zostało wdrożone w ponad 40 lokalizacjach, w tym w ponad 20 krajach Europy. 

Odwołujący jest więc w stanie wykonać przedmiot zamówienia w oparciu o swoje know-how 

oferując  produkt  typu  COTS  -  I/CAD.  Jednocześnie  nie  jest  producentem  I/CAD,  stąd  nie 

może udostępnić kodów źródłowych ani zezwolić na wykonywanie praw zależnych. 

Ponownie  zaznaczono,  że  żądanie  przekazania  dostępu  do  kodów  źródłowych 

narusza konkurencję, albowiem SOA ma być rozwiązaniem pudełkowym typu COTS, a więc 

na  udostępnienie  kodów  źródłowych  może  zgodzić  się  wyłącznie  producent  takiego 

oprogramowania  -  co  stawia  go  w  pozycji  uprzywilejowanej  w  stosunku  do  wykonawcy  nie 

będącego  takim  producentem.  Zamawiający  decydując  się  bezkrytycznie  na  restrykcyjną 

klauzulę prawnoautorską w stosunku do SOA przez pozornie poprawne rozwiązanie prawne 

wyeliminował  z  zamówienia  wszystkich  nieproducentów  (dystrybutorów  i  dostawców 

oprogramowania),  a  także  wszystkich  producentów,  dla  których  oprogramowanie  SOA  jest 

produktem  dedykowanym  szczególnie  chronionym  ze  względu  na  jego  cenę  i  wartość  dla 

firmy.  Zamawiający  musiał  mieć  świadomość,  że  ze  względu  na  stopień  skomplikowania 

Systemu, a tym stopień złożoności SOA nie da się użyć oprogramowania open source oraz, 

ż

e żadnej z mniejszych podmiotów rynkowych nie będzie w stanie wypełnić rozbudowanych 

wszystkie  oczekiwania  funkcjonalne  i  merytoryczne  Zamawiającego.  Podobnie  jako 

kryterium dyskryminujące należy potraktować przekazanie uprawnień do wykonywania praw 

zależnych,  co  będzie  właściwie  jest  równoważne  z  utratą  kontroli  nad  oprogramowaniem, 

wykonanym w oparciu o gromadzony latami potencjał i doświadczenie, które jest zasadniczą 

podstawą działalności firmy. 

Aktualnie  brzmienie  praw  autorskich  do  SOA  oznacza,  że  na  przekazanie  kodów 

ź

ródłowych  może  zdecydować  się  jedynie  podmiot,  który  ma  małe  doświadczenie,  krótko 

działała  na  rynku  i  ma  produkt,  który  nie  był  przedmiotem  wielokrotnych  wdrożeń  na 

przestrzeni  wielu  lat,  gdyż  tacy  wykonawcy  nie  będą  ponosić  ryzyka  związanego  

z  wyzbyciem  się  kodów  źródłowych  do  produktu,  lub  ryzyka  z  tym  związane  będą 

wielokrotnie  mniejsze,  pomijalne  z  punktu  widzenia  korzyści  jakie  uzyskają  ubiegając  się  

o  zamówienie.  Trzeba  jednak  podkreślić,  że  taki  producent  nie  będzie  w  stanie  spełnić 

kryteriów  związanych  z  wykazaniem  doświadczenia  i  potencjału  osobowego,  a  więc  nie 

będzie zainteresowany przedmiotowym przetargiem.  

Podsumowując,  w  ocenie  Odwołującego,  postawione  wymagania  co  do  praw 

autorskich  SOA  są  nieracjonalne  i  rażąco  zawyżają  koszty  realizacji  zamówienia.  Krąg 

podmiotów mogących złożyć ofertę został zawężony, bez żadnych obiektywnych przesłanek, 

jedynie do producentów. W realiach rynku polskiego automatycznie oznacza to skierowanie 

przetargu do dwóch, może trzech firm. Wątpliwym jest jednak to, czy zdecydują się one na 

wzięcie  udziału  w  postępowaniu,  gdyż  praktyka  rynkowa  pokazuje,  że  każda  firma 

informatyczna o ustalonej renomie szczególnie chroni swoje prawa autorskie i nie decyduje 

się  na  przekazanie  kodów  źródłowych  do  swojego  oprogramowania  standardowego. 

Niezrozumiałym  jest  zatem  podjęcie  przez  Zamawiającego  decyzji  o  takim  ukształtowaniu 

postanowień  prawnoautorskich  do  SOA,  gdyż  w  sposób  oczywisty  ograniczają  one 

konkurencję  i  naruszają  zasadę  równego  traktowania  wykonawców.  Przedmiotowe  żądania 

są  nieuzasadnione  także  z  uwagi  na  potencjalne  potrzeby  Zamawiającego,  gdyż 

Zamawiający  nie  ma  ani  wiedzy  ani  potencjału  osobowego,  by  dokonywać  samodzielnym 

zmian w kodach źródłowych, musi więc wspierać się zewnętrznym podmiotem, który otrzyma 

nieautoryzowany dostęp do oprogramowania istotnego ze względu na bezpieczeństwo kraju. 

Zmiany w kodzie źródłowym oprogramowania SOA będą wymagać wiedzy programistycznej 

jak  jest  zbudowany  dany  kod,  dostępu  do  środowiska  deweloperskiego  i  odpowiednich 

certyfikatów.  Zamawiający  nie  wyjaśnił  zresztą  dlaczego  oczekuje  dostępu  do  kodów 

ź

ródłowych SOA, skoro nawet w trakcie wdrożenia Systemu modyfikacje będą dokonywane 

poprzez  tworzenie  komponentów  traktowanych  jako  Oprogramowanie  Dedykowane,  bez 

ingerencji  w  SOA.  Po  wdrożeniu  takie  oprogramowanie  jakie  oferowałby  Odwołujący  jako 

SOA,  co  jest  zresztą  standardem  rynkowym,  ma  wbudowane  odpowiednie  narzędzia  tzw. 

API, które nie wymagają znajomości całego kodu źródłowego oprogramowania a pozwalają 

na dostosowanie oprogramowania do nowych funkcjonalności. Tym samym Zamawiający nie 

zastosował  się  do  zasad  Ustawy  Pzp  w  zakresie  zasad  proporcjonalności  i  przejrzystości 

oczekując  dostarczenia  rozwiązań  i  uprawnień,  które  właściwie  uniemożliwiają  złożenie 

oferty w tym przetargu większości firm informatycznym. 

Reasumując  -  prawidłowe,  nieograniczające  konkurencji  żądanie  od  Wykonawcy 

przekazania Zamawiającemu kodów źródłowych winno być ograniczone do Oprogramowania 

Dedykowanego, wykonanego na potrzeby tego zamówienia. 

Przepis  art.  29  ust.  1  Pzp  zobowiązuje  Zamawiającego  do  opisania  przedmiotu 

zamówienia  w  sposób  jednoznaczny  i  wyczerpujący,  za  pomocą  dostatecznie  dokładnych  

i  zrozumiałych  informacji,  uwzględniając  wszystkie  wymagania  i  okoliczności  mogące  mieć 

wpływ na sporządzenie oferty. Istota tego przepisu sprowadza się więc do określenia przez 

zamawiającego  wymagań  dotyczących  przedmiotu  zamówienia  w  taki  sposób,  aby  każdy 

wykonawca był w stanie zidentyfikować czego zamawiający oczekuje oraz móc przygotować 

prawidłowo  oszacowaną  ofertę.  Nadto  Zamawiający  nie  może  opisywać  przedmiotu 

zamówienia w sposób, który mógłby utrudniać uczciwą konkurencję, lub chociaż potencjalnie 

zagrozić  uczciwej  konkurencji.  Zatem  bezwzględnym  obowiązkiem  Zamawiającego jest  taki 

opis  przedmiotu  zamówienia,  który  prowadzi  do  złożenia  ofert  porównywalnych, 

obejmujących  rozwiązania  lub  produkty  spełniające  identyczne  wymagania  techniczne  

i  jakościowe  z  uwzględnieniem  wszystkich  elementów  niezbędnych  do  prawidłowego 

skalkulowania  oferty  przez  wykonawcę.  Jednocześnie,  zgodnie  z  art.  7  Pzp  treść 

sformułowanych wymagań musi zachować równowagę stron. 

Na  istotne  znaczenie  zasady  uczciwej  konkurencji  oraz  jej  realizacji  poprzez 

dokonanie  opisu  przedmiotu  zamówienia  z  uwzględnieniem  zachowania  równości 

wykonawców,  proporcjonalności  i  przejrzystości  wskazuje  bogate  orzecznictwo  sądów  

i Krajowej Izby Odwoławczej. Krajowa Izba Odwoławcza wielokrotnie podkreślała, iż zbytnie 

dookreślenie  wymagań  przedmiotu  zamówienia,  w  sposób  który  nie  znajduje  uzasadnienia  

w potrzebach Zamawiającego jest dokonaniem opisu przedmiotu zamówienia z naruszeniem 

zasady uczciwej konkurencji.  

W  świetle  powyższego,  sformułowanie  przez  Zamawiającego  warunku  konieczności 

przekazania  kodów  źródłowych  do  SOA  oraz  udzielenie  zgody  na  realizowanie  do  niego 

praw  zależnych  nie  znajduje  odzwierciedlenia  w  obiektywnych  potrzebach  i  interesach 

Zamawiającego i jest zapisem ograniczającym konkurencję w przedmiotowym postępowaniu 

wskutek czego został naruszony art. 7 ust. 1 w zw. z art. 29 ust. 1 i 2 Ustawy Pzp. 

W związku z powyższym Odwołujący wnosi o nakazanie Zamawiającemu dokonania 

zmiany treści Załącznikiem nr 2 do SIWZ Projekt umowy poprzez usunięcie treści § 18 ust. 4 

Umowy w brzmieniu „Licencja na Standardowe Oprogramowanie Aplikacyjne obejmuje: 

tłumaczenie,  przystosowywanie,  zmiany  układu  lub  wprowadzanie  jakichkolwiek 

innych zmian w Standardowym Oprogramowaniu Aplikacyjnym; 

zezwolenie  na  wykonywanie  zależnych  praw  autorskich  do  wszelkich  opracowań 

Standardowego  Oprogramowania  Aplikacyjnego,  to  jest  rozporządzanie  i  korzystanie  

z  takich  opracowań  w  zakresie  wszystkich  uprawnień  nabytych  przez  Zamawiającego 

stosownie do postanowień niniejszego paragrafu ” 

oraz  §  18  ust  5.  „Tłumaczenie,  przystosowywanie,  zmiany  układu  lub  wprowadzanie 

jakichkolwiek  innych  zmian  w  Standardowym  Oprogramowaniu  Aplikacyjnym  może  być 

dokonane przez Zamawiającego lub osobę trzecią działającą na jego rzecz”. 

a  także  dodanie  do  §  20  ust  12  Umowy  w  brzmieniu  „Ilekroć  zgodnie  z  postanowieniami 

Umowy  Zamawiający  nabywa  na  jakiejkolwiek  podstawie  prawnej  uprawnienie  do 

tłumaczenia,  przystosowywania,  zmiany  układu  lub  wprowadzania  jakichkolwiek  innych 

zmian do określonego Oprogramowania lub korzystania i rozporządzania autorskimi prawami 

zależnymi  do  opracowań  Oprogramowania,  Wykonawca  dostarczy  Zamawiającemu 

Oprogramowanie również w formie kodu źródłowego zdania „ W celu uniknięcia wątpliwości 

obowiązek  dostarczenia  kodu  źródłowego  nie  obejmuje  Standardowego  Oprogramowania 

Aplikacyjnego”. 

Na  podstawie  dokumentacji  przedmiotowego  postępowania  oraz  biorąc  pod 

uwagę  stanowiska  Stron  i  Uczestnika  postępowania  odwoławczego,  Izba  ustaliła  i 

zważyła, co następuje: 

Skład  orzekający  Izby  ustalił  że  nie  została  wypełniona  żadna  z  przesłanek 

skutkujących  odrzuceniem  odwołania  na  podstawie  art.  189  ust.  2  ustawy  Pzp,  

a  Wykonawca  wnoszący  odwołanie  posiadał  interes  w  rozumieniu  art.  179  ust.  1  Pzp, 

uprawniający  do  jego  złożenia.  Należy  bowiem  wskazać,  że  środki  ochrony  prawnej 

określone  w  ustawie  Pzp  przysługują  wykonawcy,  uczestnikowi  konkursu,  a  także  innemu 

podmiotowi,  jeżeli  ma  lub  miał  interes  w  uzyskaniu  danego  zamówienia  oraz  poniósł  lub 

może  ponieść  szkodę  w  wyniku  naruszenia  przez  zamawiającego  przepisów  ustawy.  Na 

etapie  postępowania  o  udzielenie  zamówienia  przed  otwarciem  ofert,  np.  w  przypadku 

odwołań  czy  skarg  dotyczących  postanowień  ogłoszenia  i  SIWZ  przyjąć  należy,  iż  każdy 

wykonawca  deklarujący  zainteresowanie  uzyskaniem  danego  zamówienia  posiada 

jednocześnie  interes  w  jego  uzyskaniu,  a  szkodą  jest  niemożliwość  złożenia  oferty  

i podpisania ważnej umowy (za wyrokiem KIO z dnia 04.10.2010 r., sygn. akt KIO 2036/10). 

Wykonawca 

jest 

zdolny 

do 

wykonania 

zamówienia, 

deklaruje 

zainteresowanie 

postępowaniem,  ma  więc  szanse  na  uzyskanie  zamówienia,  natomiast  sposób 

ukształtowania  zapisów  SIWZ,  w  tym  opisu  przedmiotu  zamówienia  i  przyszłych  warunków 

wykonywania  umowy  przekłada  się  na  sytuację  Wykonawcy  w  postępowaniu  i  możliwość 

złożenia konkurencyjnej oferty.  

Izba ustaliła, że w przedmiotowej sprawie do postępowania odwoławczego zgłoszenie 

przystąpienia po stronie zamawiającego złożył wykonawca 

S&T Services Polska Sp. z o.o. 

z siedzibą w Warszawie. Przystąpienie uznano za skuteczne.  

Zamawiający  złożył  pisemną  odpowiedź  na  odwołanie,  w  której  wnosił  o  oddalenie 

odwołania w całości.  

Odwołujący  w  odwołaniu  prawidłowo  przytoczył  zapisy  SIWZ  i  warunków  umownych 

mające znaczenie dla rozstrzygnięcia przedmiotu sporu.  

Biorąc  powyższe  ustalenia  pod  uwagę,  Izba  uznała,  że  odwołanie  nie  mogło  zostać 

uwzględnione,  bowiem  Odwołujący  nie  wykazał  przede  wszystkim,  iż  działania 

Zamawiającego są niezgodne z przepisami ustawy Pzp oraz ustawy Prawo autorskie.  

Z  uwag  natury  ogólnej  dostrzeżenia  wymaga  w  ślad  za  orzecznictwem,  że:  "(…) 

zasada  wyrażona  w  przepisie  art.  7  Pzp  nie  może  być  interpretowana  w  taki  sposób,  że 

wymaga dopuszczenia wszystkich  zainteresowanych  zamówieniem a wybór produktu, który 

należy  zaoferować  w  ramach  danego  zamówienia,  pozostawiony  jest  wykonawcom"  (tak 

wyrok  KIO  z  22.03.2012  r.,  sygn.  akt:  KIO  471/12).  Zaś:  "Obowiązek  przestrzegania  reguł 

określonych  w  art.  29  ust.  1  i  2  Pzp  nie  oznacza,  że  zamawiający  nie  ma  prawa  określić 

przedmiotu  zamówienia  w  sposób  uwzględniający  jego  potrzeby  i  aby  uzyskać  oczekiwany 

efekt, nawet jeśli wyklucza to możliwość dopuszczenia do realizacji  zamówienia wszystkich 

wykonawców działających na rynku. Prawem zamawiającego jest takie opisanie przedmiotu 

zamówienia,  którego  realizacja  zaspokoi  w  najszerszym  kontekście  określone  potrzeby 

społeczne"  (tak  wyrok  KIO  z  28.03.2014  r.,  sygn.  akt:  KIO  486/14).  Niewątpliwie  granicę 

dozwolonych  działań  Zamawiającego  w  zakresie  opisu  przedmiotu  zamówienia  oraz 

przyszłych  postanowień  kontraktowych  stanowią  wspomniane  wyżej  zasady  uczciwej 

konkurencji oraz równego traktowania wykonawców.  

Zasada  równego  traktowania  sprowadza  się  do  konieczności  identycznego 

traktowania  takich  wykonawców,  których  sytuacja  jest  taka  sama  lub  bardzo  podobna,  nie 

oznacza  to  natomiast  konieczności  identycznego  traktowania  wszystkich  wykonawców 

znajdujących  się  na  rynku  lub  aspirujących  do  wejścia  na  rynek.  Opis  przedmiotu 

zamówienia  nie  może  preferować  jedynie  niektórych  podmiotów.  Wszyscy  wykonawcy 

powinni  mieć  zapewniony  równy  dostęp  do  istotnych  dla  postępowania  informacji  

w jednakowym czasie, dokonywanie oceny warunków oraz ofert powinno następować wedle 

wcześniej  sprecyzowanych  i  znanych  wykonawcom  kryteriów,  na  podstawie  przedłożonych 

dokumentów,  a  nie  wiedzy  zamawiającego.  W  ocenie  Izby  nie  oznacza  to  jednak,  że 

zamawiający  tylko  wówczas  działa  w  granicach  uczciwej  konkurencji  oraz  z  zachowaniem 

wymogu proporcjonalności przy opisie przedmiotu zamówienia, gdy jego działania pozwalają 

na  uczestnictwo  w  postępowaniu  o  udzielenie  zamówienia  publicznego  wszystkim 

podmiotom  występującym  na  rynku.  Jeżeli  zatem  zamawiający,  określając  warunki  udziału  

w  postępowaniu,  w  tym  warunki  kontraktowe,  nie  czyni  tego  w  sposób,  który  wskazuje  na 

konkretny produkt lub wykonawcę, nie można uznać, iż narusza zasady uczciwej konkurencji 

poprzez  odniesienie  się  do  przedmiotu  zamówienia.  Nie  jest  obowiązkiem  Zamawiającego 

uwzględnianie  doświadczenia  zawodowego  i  polityki  prowadzenia  działalności  komercyjnej 

wszystkich  podmiotów  działających  na  rynku  ale  uwzględnienie  wymagań  gwarantującej 

sprawne wykonanie danej usługi, co pozwoli na stworzenie sprawnie działającego systemu, 

istotnego z punktu widzenia bezpieczeństwa państwa.  

Nie  można  również  zapominać,  że  obowiązkiem  Zamawiającego  jest  uwzględnienie 

jego  potrzeb  związanych  z  należytą  realizacją  zamówienia,  które  w  obiektywny  sposób 

doprowadzą do wyboru wykonawcy gwarantującego należyte wykonanie zamówienia. Tezy, 

iż  nie  jest  możliwe  zaoferowanie  takiego  oprogramowania,  gdzie  w  ramach  realizacji 

wykonawca  nie  będzie  mógł  udzielić  Zamawiającemu  licencji  na  wykorzystanie  kodów 

ź

ródłowych w określonych polach eksploatacji Odwołujący nie udowodnił. Dla Izby znaczący 

jest  również  fakt,  iż  jak  twierdzi  sam  Odwołujący,  postępowanie  skierowane  jest  do  dużych 

podmiotów  działających  na  rynku  IT,  jednak  żaden  z  podmiotów  nie  przystąpił  po  stronie 

Odwołującego  do  sporu.  Jak  wynika  również  z  ustaleń  Zamawiającego,  na  ponad  600 

zadanych  w  postępowaniu  pytań,  żadne  nie  odnosiło  się  do  kwestii  związanych  z  prawami 

autorskimi i niemożliwością udzielenia licencji na wykorzystanie kodów źródłowych.  

Przechodząc  do  wspominanej  przez  Odwołującego  zasady  proporcjonalności, 

dostrzeżenia  wymaga,  iż  w  wyroku  z  dnia  6  grudnia  2016  r.  (sygn.  akt  KIO  2180/16)  Izba 

odwołała  się  do  orzecznictwa  TSUE  wskazując,  że  proporcjonalność  polega  na  określeniu 

przez  zamawiającego  wyłącznie  takich  wymagań,  które  są  konieczne  do  osiągnięcia 

zakładanego  celu. Wyrażono  również  pogląd  w  zakresie  rozkładu  ciężaru  dowodu  przy  tak 

rozumianej zasadzie proporcjonalności. Izba uznała, że to od odwołującego się wykonawcy 

należy  oczekiwać  argumentacji  wskazującej,  że  postawione  przez  zamawiającego 

wymagania są oderwane od zasadniczego celu prowadzenia postępowania i w konsekwencji 

realizacji  zamierzenia  inwestycyjnego,  stanowiącego  jego  przedmiot,  jak  również  że  nie  są 

one  konieczne  do  osiągnięcia  zakładanych  celów  lub  pozostają  z  nimi  w  wyraźnej 

dysproporcji.  Takiej  argumentacji  Odwołujący  w  ocenie  składu  orzekającego  Izby  nie 

przedstawił.  Niezmiennie,  zarówno  w  odwołaniu,  jak  też  na  rozprawie,  Odwołujący 

wskazywał  na  praktykę  własnej  firmy,  odwoływał  się  do  specyfiki  swoich  relacji  między 

producentem oprogramowania o jego dystrybutorem. Zamawiający podkreślał, iż jego celem 

jest  zbudowanie  systemu,  którym  w  przyszłości  swobodnie,  bez  uzależnienia  od  monopolu 

jednego  wykonawcy  będzie  mógł  dysponować,  dokonywać  jego  modyfikacji,  ulepszeń. 

Odwołujący  nie  podał  w  jaki  sposób  cel  ten  może  być  osiągnięty  przy  przyjęciu  założeń 

strony odwołującej.  

Nie można nie dostrzec, iż Odwołujący w odwołaniu koncentruje się na dowodzeniu, 

ż

e  przeniesienie  praw  autorskich  do  oprogramowania  standardowego  będzie  bardzo 

kosztowne bądź wręcz niemożliwe. Tym samym Odwołujący nieproporcjonalności upatruje w 

okoliczności,  iż  nie  będzie  mógł  złożyć  konkurencyjnej  cenowo  oferty,  ponieważ  nie  jest 

producentem  oprogramowania,  które  chce  zaoferować.  Dowodzi  to,  iż  Zamawiający  swym 

postępowaniem  nie  narusza  przepisów  ustawy  Pzp  wymienionych  w  odwołaniu,  samo  zaś 

ustalenie  warunków  kontraktowych  na  wysokim  poziomie  wymagań  nie  stanowi  jeszcze 

przekroczenia  uprawnień  strony  zamawiającej.  Poza  tym  zauważyć  należy,  iż  Zamawiający 

wymaga  jedynie  udzielenia  licencji  o  rozszerzonym  charakterze,  nie  zaś  przeniesienia 

autorskich  praw  majątkowych  do  oprogramowania.  Słusznie  zauważył  Przystępujący,  iż 

udzielenie  licencji  na  określonych  polach  eksploatacji  nie  spowoduje  uszczuplenia 

przysługujących  wykonawcy  majątkowych  praw  autorskich.  Poza  tym  Zamawiający  nie 

będzie  mógł  posiadanymi  kodami  źródłowymi  swobodnie  obracać  i  udostępniać  je  osobom 

trzecim,  ale  będzie  mógł  używać  ich  zgodnie  z  przeznaczeniem  w  ściśle  określonych 

sytuacjach.  Zdaniem  Izby  Zamawiający  dąży  jedynie  do  zapewnienia  sobie  możliwości 

dalszej eksploatacji i rozwoju zakupionego sytemu przy możliwości stosowania postępowań o 

charakterze konkurencyjnym.  

Z  zakwestionowanych  przez  Odwołującego  postanowień  umownych  nie  wynika,  aby 

wskazane  w  odwołaniu  przepisu  ustawy  Pzp  zostały  naruszone.  Co  do  zaś  dodatkowego 

stanowiska pisemnego Odwołującego, złożonego na rozprawie, to stosowanie do art. 192 ust 

7  ustawy  Pzp,  Izba  przy  orzekaniu  związana  jest  zarzutami  odwołania.  Stanowisko  to 

natomiast  zawiera  w  ocenie  Izby  dodatkowe  zarzuty,  nie  wymienione  w  odwołaniu, 

odnoszące  się  do  innych  nieprawidłowości  w  opisie  przedmiotu  zamówienia,  czy  też 

preferowaniu przez ten opis konkretnych producentów. Takie kwestie nie były w ustawowym 

terminie 10 dni od zamieszczenia ogłoszenia i SIWZ poruszone, więc Izba pozostawiła je bez 

rozpoznania.  

O  kosztach  postępowania  odwoławczego  orzeczono  stosownie  do  jego  wyniku, 

na podstawie art. 192 ust. 9 i 10 ustawy Pzp oraz w oparciu o przepisy § 5 ust. 3 pkt 1) oraz 

ust.  4  w  zw.  z  §  3  pkt  2)  rozporządzenia  Prezesa  Rady  Ministrów  z  dnia  15  marca  2010  r.  

w  sprawie  wysokości  i sposobu  pobierania  wpisu  od  odwołania  oraz  rodzajów  kosztów  

w  postępowaniu  odwoławczym  i  sposobu  ich  rozliczania  (Dz.  U.  Nr  41,  poz.  238  ze 

zmianami) obciążając nimi Odwołującego.  

Przewodniczący: