Civilinė byla Nr. e2A-423-790/2021

Teisminio proceso Nr. 2-55-3-00978-2020-3

Procesinio sprendimo kategorija 2.6.11.4.1

 (S)

LIETUVOS APELIACINIS TEISMAS

S P R E N D I M A S

LIETUVOS RESPUBLIKOS VARDU

2021 m. liepos 1 d.

Vilnius

Lietuvos apeliacinio teismo Civilinių bylų skyriaus kolegija, susidedanti iš teisėjų Mariaus Bajoro (kolegijos pirmininkas ir pranešėjas), Dalios Kačinskienės ir Agnės Tikniūtės,

apeliacine rašytinio proceso tvarka išnagrinėjo civilinę bylą pagal ieškovės uždarosios akcinės bendrovės „Dekbera“ apeliacinį skundą dėl Vilniaus apygardos teismo 2020 m. lapkričio 18 d. sprendimo civilinėje byloje pagal ieškovės uždarosios akcinės bendrovės „Dekbera“ ieškinį atsakovams Priešgaisrinės apsaugos ir gelbėjimo departamentui prie Vidaus reikalų ministerijos ir Bendrajam pagalbos centrui dėl viešojo pirkimo sąlygų panaikinimo, išvadą byloje teikianti institucija – Viešųjų pirkimų tarnyba.

Teisėjų kolegija

n u s t a t ė :

I.       Ginčo esmė

1.       Ieškovė uždaroji akcinė bendrovė (toliau – ir UAB) „Dekbera“ kreipėsi į teismą, prašydama pripažinti neteisėtomis ir panaikinti viešojo pirkimo „Bendrojo pagalbos centro informacinės sistemos sukūrimas ir įdiegimas“, pirkimo Nr. 494812 (toliau – Pirkimas) 14.2, 14.3.8 papunkčių, techninės specifikacijos 8 skyriaus 19 punkto, 183, 199.6, 201 ir 322 punktų sąlygas.

2.       Ieškovės teigimu, Pirkimo sąlygos nepagrįstai riboja kompetentingų tiekėjų sąžiningą konkurenciją, jos parengtos neteisėtai proteguojant konkretų ūkio subjektą UAB „InnoForce“, kuris su partneriais dominuoja Bendrojo pagalbos centro (toliau – BPC) pirkimuose jau daugelį metų. Atsakovai, siekdami įsigyti tokį pat pirkimo objektą, ankstesniuose pirkimuose taip pat buvo nustatę neteisėtas ir konkurenciją ribojančias sąlygas. Pirmojo pirkimo Nr. 444061 sąlygos buvo pripažintos neteisėtomis Lietuvos apeliacinio teismo 2020 m. vasario 18 d. nutartimi civilinėje byloje Nr. e2A-642-553/2019 (turi būti Nr. e2A-642-553/2020) ir Viešųjų pirkimų tarnybos 2019 m. spalio 10 d. išvadoje, todėl pirkimas buvo nutrauktas. Antrasis pirkimas Nr. 477053 buvo nutrauktas atsakovų sprendimu, gavus ieškovės pretenziją. Atsakovai, trečiąjį kartą skelbdami apie Pirkimą, paliko ankstesniuose pirkimuose numatytas konkurenciją ribojančias sąlygas, be to, numatė papildomus reikalavimus, kuriais siekiama ieškovės pašalinimo iš Pirkimo.

3.       Ieškovės manymu, Pirkimo sąlygų 14.2 papunktyje neteisėtai reikalaujama, kad tiekėjas turėtų patirties vykdydamas sutartis išimtinai tik dėl tokių informacinių sistemų, kuriose yra AML (angl. Advanced Mobile Location) arba lygiavertis funkcionalumas ir GSM/UMTS (2G/3G) vietos nustatymo duomenų arba lygiavertis funkcionalumas. Ieškovės teigimu, šie kvalifikacijos reikalavimai yra pernelyg specifiniai, neproporcingi Pirkimo objektui. Kuriant informacines sistemas, į jas tiekėjas diegia įvairiausius funkcionalumus, pats jų diegimas nėra kuo nors ypatingas ar reikšmingai besiskiriantis. Programuotojui, gebančiam programuoti atitinkama programavimo kalba, nėra svarbu, kokį funkcionalumą įdiegti. Reikalavimas turėti patirties diegiant konkrečius funkcionalumus neproporcingai apriboja galimybę Pirkime dalyvauti tiekėjams, kurie yra sukūrę informacines sistemas, tačiau diegę kitokius informacinės sistemos funkcionalumus. Pirkimo sąlygos apriboja galimybę dalyvauti tiekėjams, kurie yra įdiegę vieną iš nurodytų funkcionalumų, tačiau ne juos abu kartu, vykdant tą pačią sutartį.

4.       Ieškovės teigimu, Pirkimo sąlygų 14.3.8 papunktyje neteisėtai reikalaujama, kad tiekėjo komandoje esantis integracijos su TETRA technologijų radijo ryšio tinklu specialistas turėtų profesinę patirtį išimtinai tik su konkretaus gamintojo Motorola Solutions DIMETRA radijo ryšio tinklu. Lyginant su ankstesniais pirkimais, atsakovai sugriežtino analogišką kvalifikacijos reikalavimą ir numatė, kad tiekėjas turi turėti komandoje integracijos su TETRA technologijų radijo ryšio tinklu specialistą, visiškai nepagrįstai siejant specialisto profesinę patirtį išimtinai su konkretaus gamintojo Motorola Solutions DIMETRA radijo ryšio tinklu. Viešųjų pirkimų tarnybos 2020 m. liepos 23 d. paskelbtose Kvalifikacijos reikalavimų nustatymo informacinių sistemų viešuosiuose pirkimuose gairėse ydingomis ir konkurenciją ribojančiomis pripažįstamos panašios sąlygos, kai profesinės patirties reikalavimas integracijos specialistams yra siejamas su konkrečiu informacinių technologijų produktu. Šiose gairėse Viešųjų pirkimų tarnyba atkreipia dėmesį, kad integravimo specialistui nėra svarbu, kokios informacinės sistemos tarpusavyje veika, jam pakanka įgyti patirties kuriant integracijas tarp sistemų. Ieškovės vertinimu, pakanka nustatyti tokį Pirkimo sąlygų 14.3.8 papunkčio reikalavimą, koks buvo numatytas pirmojo ir antrojo pirkimų metu, nesiejant su konkrečiu gamintoju ir produktu.

5.       Ieškovės nuomone, techninės specifikacijos 8 skyriaus 19 punktas, 183, 199.6 ir 201 punktai pažeidžia Lietuvos Respublikos viešųjų pirkimų įstatymo (toliau – VPĮ) 37 straipsnio 3 dalies reikalavimą, numatantį, kad techninė specifikacija turi užtikrinti konkurenciją ir nediskriminuoti tiekėjų.

6.       Techninės specifikacijos 8 skyriaus 19 punktas, nustatantis, kad programinės įrangos platforma turi būti paremta į paslaugas orientuota žiniatinklio architektūra (angl. Service-Oriented Architecture – SOA, Web-Based), nėra aiškus ir neteisėtai pašalina tiekėjų galimybę Pirkime siūlyti kombinuotų architektūrų informacines sistemas. Techninės specifikacijos 19 punktas reiškia, kad informacinės sistemos programinė įranga turės funkcionuoti per interneto naršyklę, nediegiant skambučių operatorių bei dispečerių kompiuterinėse darbo vietose jokios papildomos programinės įrangos. Austrijos specialistas W. R. 2019 m. rugpjūčio 9 d. išvadoje pažymėjo taikomųjų programinių įrangų (Rich-Client) sprendinių pranašumus bei jų lygiavertiškumą žiniatinklio architektūrai (Web-Based). Italijos specialistas F. F. 2019 m. spalio 14 d. posėdžio Vilniaus apygardos teisme metu taip pat paaiškino sistemų lygiavertiškumą. Lietuvos specialistas I. K. 2019 m. gruodžio 5 d. išvadoje pažymėjo kombinuotų architektūrų informacinių sistemų lygiavertiškumą žiniatinklio architektūrai. Taigi, ieškovės teigimu, kombinuotos architektūros informacinė sistema lygiaverčiai užtikrintų atsakovų poreikius, suformuotus techninėje specifikacijoje. Atsakovai atsakyme į pretenziją nurodo deklaratyvius ir klaidinančius duomenis apie sistemų aptarnavimo ir priežiūros darbų bei laiko sąnaudas, nes jie nėra apskaičiavę jokių administracinių kaštų, kuri sistema būtų pigesnė arba racionalesnė. Atsakovai atsakyme į pretenziją nepagrįstai nurodo, kad kombinuota architektūra negalės būti suderinama su skirtingomis platformomis (Windows, Linux kompiuteriais, planšetiniais kompiuteriais, kt.). Atsakovai neįrodė, kad jų veikloje yra naudojami Linux arba planšetiniai kompiuteriai.

7.       Techninės specifikacijos 183 punktas nustato reikalavimą, kad programinė įranga privalo būti integruota su perkančiosios organizacijos naudojamomis telefoninėmis stotimis Unify OpenScape 4000 V8 Duplex ir skambučių skirstymo programine įranga Unify OpenScape ContactCenter V9 naudojant OpenScape Contact Center Enerprise Software Development Kit (SDK) sąsajas. Prieiga prie SDK sąsajų, jų dokumentacijos turi pasirūpinti ir nepertraukiamą BPC telefoninių stočių darbą integravimo metu turi užtikrinti tiekėjas.

8.       Techninės specifikacijos 199.6 papunktis nustato, kad programinė įranga privalo priimti ir registruoti pajėgų vienetų buvimo vietos koordinates iš TETRA radijo ryšio terminalų, gaunamas LIP formatu. Programinė įranga privalo gebėti dekoduoti skirtingus LIP informacijos formatus, gaunamus iš skirtingų gamintojų TETRA radijo ryšio terminalų (Motorola Solutions, Sepura ir pan.). PT vienetų koordinatės, be kita ko, gaunamos iš TETRA judriųjų terminalų per Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API. Tiekėjas yra atsakingas už prieigos prie Motorola Solutions DIMETRA radijo ryšio tinklo API gavimą ir naudojimą.

9.       Techninės specifikacijos 201 punktas numato reikalavimą, kad programinė įranga būtų integruota su perkančiosios organizacijos turima balso įrašų perklausymo programine įranga Retia ReDAT eXperience naudojant Retia ReDAT API. Prieigą prie aplikacijų programavimo sąsaja (angl. Application Programming Interface) paremtos funkcijos, leidžiančios prijungti nuorodą į konkretų įrašą prie trečiųjų šalių programinės įrangos vartotojo sąsajų, taip pat leidžiančią perklausyti ir atsisiųsti arba tik perklausyti įrašą naudojant trečiųjų šalių aplikacijas iš ReDAT serverio tiekėjui suteiks perkančioji organizacija. Nepertraukiamą balso įrašų perklausymo programinės įrangos veikimą integravimo metu turi užtikrinti tiekėjas.

10.       Ieškovė pažymi, kad tiekėjas UAB „InnoForce“ BPC yra įdiegęs skambučių skirstymo programinę įrangą Unify OpenScape ContactCenter V9, taip pat balso įrašų perklausymo programinę įrangą Retia ReDAT eXperience. Įgyvendinant kuriamos BPC informacinės sistemos programinės įrangos integraciją su skambučių skirstymo programine įranga ir balso įrašų perklausymo programine įranga, integracija būtų vykdoma sąsajomis, kurios šiuo metu prieinamos UAB „InnoForce“ bei jam yra žinomos sąsajų techninės savybės, kt. Šis tiekėjas įgis nepagrįstą pranašumą, kadangi jam nereikės rūpintis sąsajų gavimu bei jų dokumentacija. Kitiems tiekėjams reikės kreiptis į konkurentą UAB „InnoForce“ su prašymu suteikti prieigą ir dokumentaciją, kuri gali būti nesuteikta. Pareiga užtikrinti nepertraukiamą konkurento programinių įrangų veikimą integracijos metu reiškia, kad tiekėjas privalo atsakyti už tiekėjo UAB „InnoForce“ programinių įrangų tinkamą funkcionavimą.

11.       Ieškovės nuomone, atsakovai Pirkimo sąlygų reikalavimu, pagal kurį tiekėjas yra atsakingas už prieigos prie Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API gavimą ir naudojimą, suteikė nepagrįstą konkurencinį pranašumą subjektams, kurie yra Motorola Solutions DIMETRA radijo ryšio tinklo atstovai rinkoje bei jau turi prieigą prie radijo ryšio tinklo aplikacijų programavimo sąsajų (API). Atsakovai 2006 m. viešuoju pirkimu įsigijo, be kita ko, Motorola Solutions DIMETRA radijo ryšio tinklo aplikacijų programavimo sąsajas, todėl jas turėtų suteikti Pirkimo laimėtojui. Tam, kad būtų suteikta prieiga prie Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API, reikia įvykdyti daug neproporcingų reikalavimų.

12.       Techninės specifikacijos 322 punktas įtvirtina reikalavimus techninės serverinės įrangos specifikacijoms, kurias tiekėjas turės pateikti per 1 mėnesį nuo sutarties sudarymo, be kita ko, numatytas reikalavimas, jog serverinės įrangos kiekiai, šios įrangos parametrai ir specifikacijos turi būti suformuluoti atsižvelgiant į perkančiosios organizacijos orientacinį biudžetą specifikuotai įrangai – 500 000 Eur su PVM. Ieškovės įsitikinimu, sąlyga dėl orientacinio biudžeto yra nepakankamai apibrėžta. Pirkimo sąlygose nepateikti jokie minimalūs kiekio ar kokybės kriterijai įrangai, o tik numatytas jos orientacinis biudžetas. Tačiau nėra aišku, koks kainos intervalas atsakovei priimtinas. Tuo būdu visa sutarties vykdymo rizika yra nepagrįstai perkeliama tiekėjui, kadangi sutarties vykdymo tinkamumas išimtinai priklauso nuo subjektyvių elementų, kurių jis nekontroliuoja – perkančiosios organizacijos subjektyvaus vertinimo apie pasiūlytos įrangos tinkamumą funkcine prasme ir jos kainą.

II.       Pirmosios instancijos teismo sprendimo esmė

13.       Vilniaus apygardos teismas 2020 m. lapkričio 18 d. sprendimu ieškinį atmetė.

14.       Teismas nurodė, kad ginčas dėl Pirkimo sąlygų 14.2 papunkčio teisėtumo nagrinėtinas tik tokia apimtimi, kurią ieškovė buvo nurodžiusi 2020 m. liepos 7 d. pretenzijoje, t. y. nagrinėtinas ieškovės reikalavimas panaikinti kvalifikacijos reikalavimo dalį dėl įdiegto AML (angl. Advanced Mobile Location) ar lygiaverčio funkcionalumo, nes tokia sąlyga, ieškovės vertinimu, nurodo į konkrečią pagalbos sistemą, kurią yra įdiegęs konkretus tiekėjas. Tuo tarpu kiti ieškovės nurodyti Pirkimo sąlygos nuginčijimo pagrindai nebuvo pateikti ir nagrinėjami ikiteisminėje ginčo nagrinėjimo stadijoje, todėl negali būti nagrinėjimo dalyku teisme.

15.       Teismas vertino, kad atsakovai pateikė įrodymus, jog išmaniųjų mobiliųjų telefonų skubios pagalbos vietos nustatymo funkcija AML (angl. Advanced Mobile Location) nėra nuoroda į konkrečią pagalbos sistemą. Atsakovų pateiktais duomenimis, Europos skubios pagalbos telefono numerio asociacijos AML sistemos ataskaitos kortelėje nurodoma, kad AML – tai pažangi mobiliosios vietos nustatymo technologija, kuri įjungiama, kai iš mobiliojo telefono skambinama skubios pagalbos iškvietimo numeriu. AML suteikia galimybę teikti skubios pagalbos tarnyboms informaciją apie skambinančio asmens buvimo vietą, nustatytą pagal nešiojamojo aparato duomenis (GNSS, WiFi) be išankstinių pavojuje esančio skambinančiojo asmens veiksmų. Teismas nustatė, kad AML yra aprašyta ir Europos telekomunikacijų standartizacijos instituto (angl. European Telecommunications Standards Institute, ETSI), dokumentuose. Šios organizacijos dokumentai yra bendro pobūdžio, jais grindžiamos daugelis Lietuvoje, Europoje ir pasaulyje naudojamų technologijų. Ši faktinė informacija rodo, kad AML nėra konkreti, vieno tiekėjo sukurta, patentuota ar uždara (uždaro kodo) sistema. AML šiuo metu yra įdiegta ir veikia virš 14 šalių, AML diegimai vykdomi dar 7 šalyse, ir AML diegimą jose vykdė (vykdo) ne vienas ir tas pats tiekėjas. Pagal naujausią 2020 m. rugpjūčio 6 d. paskelbtą Europos skubios pagalbos numerio asociacijos informaciją, Graikija tapo 26 valstybe pasaulyje, kur yra įdiegtas AML funkcionalumas.

16.       Teismas atmetė ieškovės argumentus dėl Techninės specifikacijos 8 skyriaus 19 punkto neteisėtumo kaip nepagrįstus ir neįrodytus. Perkančioji organizacija reikalavimą dėl programinės įrangos pasiekimo žiniatinklio architektūros pagrindu įrodinėjo aplinkybėmis, susijusiomis su Pirkimo objekto specifika, kuo sklandesniu skubos tarnybų informacinės sistemos veikimu, patikimumu, lankstumu, tuo pačiu eksploatavimo paprastumu bei kaštų racionalumu. Teismo vertinimu, ieškovės pateikti įrodymai – specialisto W. R. rašytiniai paaiškinimai ir F. F., apklausto kaip liudytojo, parodymai kombinuotos architektūros lygiavertiškumo neįrodo. Paminėti įrodymai buvo pateikti civilinėje byloje dėl pirmojo pirkimo sąlygų teisėtumo, joje ieškovė kombinuotos architektūros informacinės sistemos lygiavertiškumo neakcentavo ir iš esmės neįrodinėjo. Specialistai apie kombinuotos architektūros (angl. Rich Client + Web-based) vertinimą iš esmės nepasisakė, neanalizavo, kuo skiriasi kombinuota architektūra nuo programinės įrangos, veikiančios taikomųjų programų pagrindu (angl. Rich Client). Teismas pažymėjo, kad ieškovės teiginys dėl programinės įrangos, veikiančios taikomųjų programų pagrindu (angl. Rich Client) lygiavertiškumo žiniatinklio architektūrai (angl. Web-based) buvo atmestas įsiteisėjusiais teismų procesiniais sprendimais, šis faktas yra prejudicinis nagrinėjamoje byloje. Teismas taip pat atmetė specialisto I. K. 2019 m. gruodžio 5 d. ekspertinio vertinimo aktą, kadangi specialisto teiginys, jog naudojant hibridinę technologiją (kai sprendime visiems Pirkimo sąlygose nurodytiems funkciniams reikalavimams patenkinti kartu naudojama ir Web-Based, ir Rich Client technologijos), galima pasiekti (realizuoti) visus Pirkimo sąlygose numatytus funkcionalumus, pateiktas kaip deklaracija; vertinimo akte nėra jokių motyvų, jokių tyrimų ar samprotavimų, kurių pagrindu ekspertas padarė kategorišką išvadą; specialisto ekspertinio vertinimo aktas neturi jokios tiriamosios ar motyvuojamosios dalies.

17.       Teismas nustatė, kad ieškovė ginčija Techninės specifikacijos 183 punkto sąlygas, jog BPC programinė įranga turi būti suderinama su skambučių skirstymo programine įranga naudojant OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajas, kurių prieigos gavimu bei dokumentacijos gavimu turi pasirūpinti pats BPC informacinės sistemos kūrėjas bei tuo pačiu tiekėjas turi būti atsakingas už nepertraukiamą telefoninių stočių darbą integravimo metu, taip pat Techninės specifikacijos 201 punkto reikalavimus, kad BPC programinė įranga turi būti suderinama su balso įrašų perklausymo programine įranga naudojant Retia ReDAT aplikacijų programavimo sąsają bei tiekėjas turi būti atsakingas už nepertraukiamą balso įrašų perklausymo programinės įrangos veikimą integravimo metu.

18.       Teismas nurodė, kad Techninės specifikacijos 183 ir 201 punktų reikalavimai nustatyti atsižvelgiant į objektyvius perkančios organizacijos poreikius ir į Pirkimo objekto specifiką, taip pat jie nesukuria esminės šalių nelygybės tiekėjams arba pranašumo vienam iš tiekėjų. Šiais reikalavimais iš tiekėjo reikalaujama turėti reikalingas prieigas pagal atitinkamas licencijavimo sąlygas tam, kad Pirkimu įsigyjama programinė įranga tinkamai funkcionuotų, atsakovams sutarties vykdymo metu nereikėtų įsigyti papildomų darbų ar prekių ir tiekėjas pasirūpintų visais reikalingais komponentais ir kvalifikacija, kurių Atsakovai suteikti objektyviai negali.

19.       Teismas nustatė, kad atsakovai šiuo metu naudoja programinę įrangą, įsigytą pagal atskiras pirkimo sutartis: Unify OpenScape ContactCenter V9 pagal 2019 m. rugpjūčio 22 d. pirkimo sutartį ir balso įrašų perklausymo programinę įrangą Retia ReDAT eXperience pagal 2019 m. rugpjūčio 22 d. pirkimo sutartį, sistemas įdiegė tiekėjas UAB „InnoForce“. Nagrinėjamo Pirkimo objektas yra valstybinės reikšmės projektas, skirtas įgyvendinti Lietuvos Respublikos bendrojo pagalbos centro įstatymo Nr. IX-2246 2, 10, 15, 16 straipsnių, trečiojo skirsnio ir priedo pakeitimo įstatymo 11 straipsnio nuostatą, kad BPC ir skubiosios pagalbos tarnybos (policija, priešgaisrinės gelbėjimo pajėgos, greitosios medicinos pagalbos tarnyba, aplinkos apsaugos pajėgos) nuo 2021 m. sausio 1 d. tarpusavio sąveikai užtikrinti bendrai naudotų Unify techninę ir programinę įrangą pagalbos skambučių skubiosios pagalbos tarnybų telefono numeriu 112 priėmimui, skirstymui bei nukreipimui kitoms pagalbos tarnyboms.

20.       Teismo teigimu, perkančioji organizacija neplanuoja keisti turimos, gerai veikiančios ir atnaujintos skambučių priėmimo ir skirstymo techninės ir programinės įrangos. Skambučių valdymo sistemų gili integracija į naujai perkamą programinę įrangą yra vienas esminių kriterijų, užtikrinančių efektyvų ir savalaikį pagalbos teikimą skambinantiesiems pagalbos numeriu 112 ir kitais pagalbos numeriais, skambinančiojo vietos nustatymo, AML, eCall funkcijų veikimui, ryšio sudarymui tarp skambinančiojo bei pagalbos tarnybų ar skambinančiojo ir pagalbos tarnybų ekipažų bei kitoms esminėms funkcijoms užtikrinti.

21.       Teismas pažymėjo, kad atsakovai pagal savo veiklos pobūdį pagrįstai reikalauja, kad tiekėjas būtų atsakingas tiek už nepertraukiamą telefoninių stočių darbą, tiek ir už balso įrašų perklausymo programinės įrangos veikimą integravimo metu. Atsakovai glaudžiai bendradarbiaus su sutartį pasirašiusiu tiekėju vykdant integravimo darbus, tačiau esminės kompetencijos ir gebėjimo užtikrinti nenutrūkstamą minėtų komponentų veikimą pagrįstai tikisi iš tiekėjo, nes savo jėgomis užtikrinti šių integracijų neturi galimybės.

22.       Teismas nurodė, kad perkančioji organizacija neturi prieigos prie įrangos OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajų, todėl reikalaujama, kad ja pasirūpintų tiekėjas. Ieškovės argumentai, kad ginčijami Techninės specifikacijos 183 ir 201 punktai suteikia pranašumą ir proteguoja BPC dabartinį informacinės įrangos ir paslaugų tiekėją UAB „InnoForce“ yra nepagrįsti, nes nuo 2020 m. gruodžio 31 d. yra nutraukiamas BPC esamos programinės įrangos palaikymas (baigiamas įrangos gyvavimo ciklas), todėl dabartinis tiekėjas UAB „InnoForce“ neturės techninio ar kitokio pranašumo kitų tiekėjų atžvilgiu. Teismo teigimu, reikalavimas užtikrinti sąsajas su naudojama programine įranga taikomas visiems tiekėjams. Atsakovai pateikė įrodymus, kad programinės įrangos gamintojas Unify  Europos Sąjungoje turi 94 Unify OpenScape 4000 sertifikuotus partnerius ir 13 Unify OpenScape ContactCenter sertifikuotų partnerių. Atsakovai kreipėsi į BPC naudojamos balso įrašų perklausymo programinės įrangos Retia ReDAT eXperience gamintoją „RETIA, a.s.“, kuri informavo, kad turi 27 aktyvius verslo partnerius. Teismas padarė išvadą, kad tiekėjai turi lygias galimybės dalyvauti Pirkime, o kokius pateiks pasiūlymus ir kokius partnerius pasitelks Pirkimo sąlygų įgyvendinimui, yra visiška tiekėjų diskrecija.

23.       Teismas, spręsdamas dėl Pirkimo sąlygų 14.3.8 papunkčio, numatančio kvalifikacijos reikalavimą, jog tiekėjas Pirkime turi pasiūlyti integracijos su Motorola Solutions gamintojo DIMETRA radijo ryšio tinklu, veikiančiu TETRA technologijų pagrindu specialistą, kuris turi turėti specifinę profesinę patirtį su Motorola Solutions gamintojo DIMETRA radijo ryšio tinklu, ir Techninės specifikacijos 199.6 papunkčio, nustatančio, kad tiekėjas yra atsakingas už prieigos prie Motorola Solutions DIMETRA radijo ryšio tinklo API gavimą ir naudojimą, konstatavo, jog atsakovai įrodė, kad Pirkimo tikslų įgyvendinimui neužtenka specialisto profesinės patirties, įgytos TETRA technologijų radijo ryšio tinklo statusų siuntimo ir priėmimo, trumpųjų žinučių siuntimo ir priėmimo, koordinačių priėmimo funkcijų integravime į informacinę sistemą, naudojant TETRA technologijų radijo ryšio tinklo aplikacijų programavimo sąsajas (API). Atitinkamai, Pirkimo sąlygų 14.3.8 papunktyje nustatytas kvalifikacinis reikalavimas yra tiesiogiai susijęs su Techninės specifikacijos 199.6 papunkčio nuostatų įgyvendinimu, proporcingas Pirkimo objektui ir pateisinamas Pirkimo objekto specifika.  

24.       Tokią išvadą teismas padarė atsižvelgęs į tai, kad Techninės specifikacijos 16.3 papunktyje yra nustatyta, jog šiuo Pirkimu įsigyjama programinė įranga turės būti integruota su Lietuvos viešojo saugumo ir pagalbos tarnybų skaitmeninio mobiliojo radijo ryšio tinklu (tinklo įranga DIMETRA (Versija 9.0.2), gamintojas Motorola Solutions). Šį tinklą savo veikloje naudoja BPC, priešgaisrinės gelbėjimo pajėgos, policija, VšĮ Panevėžio greitosios medicinos pagalbos stotis, Valstybės sienos apsaugos tarnyba ir kiti naudotojai. Bendras tinkle registruotų radijo ryšio terminalų skaičius viršija 11 tūkstančių. Pagal Techninės specifikacijos 199.13 papunktį, diegiant programinės įrangos radijo ryšio funkcionalumą tiekėjas turi naudoti Lietuvos viešojo saugumo ir PT skaitmeninio mobiliojo radijo ryšio tinklo (Motorola Solutions DIMETRA 9.0.2) sąsajas (API), nurodytas specifikacijos 11 priede, arba lygiavertes, užtikrinančias keitimąsi duomenims tarp BPCIS ir Lietuvos viešojo saugumo ir pagalbos tarnybų skaitmeninio mobiliojo radijo ryšio tinklo. Motorola Solutions DIMETRA 9.0.2 sąsajos (API) ir dokumentacija, kurios nurodytos specifikacijos 11 priede ir kurias privalės naudoti tiekėjas integruodamas savo pasiūlytą programinę įrangą su tinklu, yra uždaro pobūdžio – platinamos tik gamintojo, reikalauja atitinkamos kvalifikacijos jas naudojant, todėl prieiga prie jų suteikiama kompanijos Motorola Solutions nurodytomis sąlygomis, kad naudojant sąsajas integracijoms nebūtų pažeistas Motorola DIMETRA tinklų saugumas, vientisumas ir veikimo nenutrūkstamumas. Be to, perkančioji organizacija neturi teisės suteikti tinklo sąsajų (API) dokumentacijos trečiosioms šalims, nes kitaip būtų pažeidžiamos Motorola Solutions intelektinės nuosavybės teisės.

25.       Teismas sprendė, kad Techninės specifikacijos 322 punktas skaidrumo principo nepažeidžia. Teismas nurodė, kad šiame punkte reglamentuojamas tiekėjo dalyvavimas formuluojant perkančiosios organizacijos poreikius (techninės specifikacijas) perkant papildomą techninę serverinę  įrangą, numatyta, kad tokie pirkimai bus vykdomi atskirai, po Pirkimo sutarties pasirašymo. Teismo teigimu, ginčijama Pirkimo sąlyga yra susijusi su viešojo pirkimo sutarties vykdymu ir nėra tiesiogiai susijusi su nagrinėjamo Pirkimo sąlygomis, todėl netrukdo tiekėjams pateikti pasiūlymą Pirkime, o perkančiai organizacijai įvertinti tiekėjų pasiūlymus. Teismas atmetė ieškovės argumentus, kad Pirkimo sąlygų 322 punkte nustatytas orientacinis kriterijus būsimo viešojo pirkimo objekto kainai yra neaiškus, dviprasmiškas ir neskaidrus.

III.       Apeliacinio skundo ir atsiliepimo į jį argumentai

26.       Ieškovė apeliaciniu skundu prašo panaikinti Vilniaus apygardos teismo 2020 m. lapkričio 18 d. sprendimą ir priimti naują sprendimą – ieškinį tenkinti. Ieškovė nurodo tokius pagrindinius argumentus:

26.1.                                            Spręsdamas dėl Pirkimo sąlygų 14.2 papunktyje nustatyto kvalifikacijos reikalavimo teismas iš esmės rėmėsi tik Pirkimo pobūdžiu ir vertino, ar pats AML funkcionalumas yra būtinas atsakovams, o ne tai, ar tiekėjas, turintis patirties diegiant kitus diegimo požiūriu reikšmingai nesiskiriančius funkcionalumus, gali užtikrinti AML funkcionalumą. Teismas padarė išvadą, kad AML nėra konkreti, vieno tiekėjo sukurta sistema, AML šiuo metu įdiegta ir veikia virš 14 šalių, diegimai vykdomi dar 7 šalyse, ir AML diegimą vykdo ne vienas ir tas pats tiekėjas. Tačiau šie teismo teiginiai nepagrįsti. Bylos medžiaga patvirtina, kad kvalifikacijos reikalavimas dėl AML funkcionalumo diegimo patirties reikšmingai riboja konkurenciją. Lietuvoje AML sistemą yra įdiegusi tik viena įmonė UAB „Innoseven Technologies“. Visos Europos mastu kvalifikacijos reikalavimą taip pat galėtų atitikti mažai įmonių, visoje Europos Sąjungoje AML yra įdiegtas tik 9 valstybėse, todėl tik 9 tiekėjai visoje Europos Sąjungoje galėtų atitikti įdiegimą. Be to, teismas nepagrįstai nevertino Viešųjų pirkimų tarnybos išvados, pateiktos civilinėje byloje dėl pirmojo pirkimo, kurioje tarnyba pažymėjo, kad ginčo kvalifikacijos reikalavimas galimai riboja konkurenciją. Teismas nepagrįstai nevertino ir kitų ieškovės nurodytų argumentų dėl ginčijamos Pirkimo sąlygų nuostatos.

26.2.                                            Ieškovė ginčijo kitą kvalifikacijos reikalavimą, nustatytą Pirkimo sąlygų 14.3.8 papunktyje, kad TETRA technologijų specialistas turėtų profesinę patirtį dirbant su konkretaus gamintojo Motorola Solutions DIMETRA radijo ryšio tinklu. Teismas sprendime šio kvalifikacijos reikalavimo teisėtumą nepagrįstai siejo su Techninės specifikacijos 199.6 papunkčio reikalavimo teisėtumu. Tačiau, ieškovės teigimu, Techninės specifikacijos sąlyga negali pagrįsti kvalifikacijos reikalavimo teisėtumo, o kitų argumentų, pagrindžiančių minėto reikalavimo teisėtumą, teismas nenurodė.

26.3.                                            Viešųjų pirkimų tarnybos gairėse aiškiai ir nedviprasmiškai nurodyta, kad integravimo specialistui nėra svarbu, kokios informacinės sistemos sąveikauja tarpusavyje. BPC byloje iš esmės pripažino, kad Pirkimo sąlygų 14.3.8 papunkčio reikalavimas buvo nustatytas todėl, kad specialistas, turėdamas patirties integruojant sistemas naudojant būtent Motorola DIMETRA sąsajas (API), jam nustatytas užduotis atliktų sklandžiau, greičiau ir kokybiškiau. Tai reiškia, kad atsakovas pripažįsta, jog TETRA technologijų specialistas būtų pajėgus vykdyti pirkimo sutartį. Tačiau galimybė sklandžiau, greičiau ir kokybiškiau įvykdyti sutartį byloje ne tik nebuvo įrodyta, bet ji nepateisina pagrindo nustatyti specifinius kvalifikacijos reikalavimus. Vidaus reikalų ministerija rašte, kurį paminėjo teismas, nenurodė jokių aplinkybių, kad tik specialistas, turintis patirties su Motorola Solutions DIMETRA radijo ryšio tinklais, bus pajėgus įvykdyti sutartį.

26.4.                                            Teismas neatsižvelgė į tai, kad būtent perkančioji organizacija turi pareigą įrodyti, kad nustatydama kvalifikacijos reikalavimus ji laikėsi VPĮ reikalavimų. Teismas visą įrodinėjimo naštą perkėlė ieškovei ir laikė, kad ieškovė neįrodė Pirkimo sąlygų neteisėtumo.

26.5.                                            Teismas nepagrįstais ir deklaratyviais motyvais atmetė į bylą pateiktas specialistų išvadas ir byloje nesant Techninės specifikacijos 8 skyriaus 19 punkto teisėtumą patvirtinančių įrodymų šį reikalavimą nepagrįstai pripažino teisėtu. Ieškovė byloje įrodinėjo, kad ginčijama sąlyga nepagrįstai apribojo tiekėjų galimybę pasiūlyti informacines sistemas, veikiančias kombinuotu būdu (žiniatinklio architektūros (angl. Web-Based) bei taikomųjų programų architektūros (angl. Rich-Client) pagrindais kartu). Teismas nevertino specialistų W. R. ir F. F. paaiškinimų dėl to, kad jie nepasisakė apie kombinuotą architektūrą. Tačiau W. R. pažymėjo taikomųjų programų įrangų (angl. Rich-Client) pranašumus, kurie turi įtakos ir vertinant kombinuotą architektūrą. F. F. paaiškino aplinkybes, susijusias su atsakovų pasirinktu architektūros sprendiniu ir kodėl jis nepagrįstai nustatytas kaip vienintelis galimas. Todėl teismas nepagrįstai šių paaiškinimų nevertino. Teismas taip pat nepagrįstai nevertino I. K. ekspertinio vertinimo akto. Priešingai nei nurodė teismas, šiame ekspertinio vertinimo akte specialistas išsamiai pagrindė savo išvadas, be kita ko, ir kombinuotos architektūros kontekste. Taigi, ekspertinio vertinimo aktas patvirtino, kad ginčijamas Techninės specifikacijos reikalavimas iš esmės apriboja konkurenciją ir neleidžia siūlyti kombinuotos architektūros pagrindu veikiančios programinės įrangos. Specialistas I. K. 2020 m. gruodžio 1 d. pateikė ir papildomą ekspertinio vertinimo aktą, kuriame pažymėjo, kad jo išvados nesikeičia.

26.6.                                            Teismas neatskleidė bylos esmės bei netinkamai įvertino prieigos prie programavimo sąsajų (API) teisinę reikšmę, dėl to nepagrįstai nustatė, kad Techninės specifikacijos 183, 199.6 ir 201 punktų reikalavimai teisėti. Aplikacijų programavimo sąsajos – tai sąsajos, kurias suteikia kompiuterinė sistema, biblioteka ar programa tam, kad programuotojas per kitą programą galėtų pasiekti jos funkcionalumą ar apsikeistų su ja duomenimis. Iš API negalima atkurti, nukopijuoti kompiuterių programos, tačiau tai yra tam tikros informacijos ir instrukcijų rinkinys, reikalingas programuotojui, kuriančiam kitą programą, pasiekti atitinkamos programos funkcionalumus. Todėl API nėra saugoma autorių teisės. Pirkimo sutartį vykdančiam tiekėjui API faktinis turėjimas bus reikalingas tam, kad jis galėtų sukurti informacinę sistemą, kuri galėtų tinkamai sąveikauti su perkančiosios organizacijos ir trečiųjų asmenų naudojamomis programomis ir informacinėmis sistemomis.

26.7.                                            Ieškovės teigimu, API sąsajas privalo pateikti perkančioji organizacija, kadangi ji, anksčiau įsigijusi atitinkamas informacines sistemas, turėjo įsigyti ir atitinkamas API sąsajas tam, kad ateityje tas sąsajas panaudodama įgytų papildomus sistemos komponentus. Techninėje specifikacijoje negali būti nustatomas reikalavimas, kad atitinkamas sąsajas pateiktų tiekėjai, nes tokiu atveju būtų sukuriama praktika, kai perkančiosios organizacijos, įsigijusios vieną programinę įrangą, vėliau visus su šia programine įranga susijusius komponentus galėtų įsigyti tik iš to paties tiekėjo.

26.8.                                            Teismas netinkamai įvertino Techninės specifikacijos 322 punktą bei nepagrįstai konstatavo, kad jis nepažeidžia VPĮ 35 straipsnio 4 dalies bei 17 straipsnyje įtvirtintų skaidrumo ir proporcingumo principų. Ieškovo įsitikinimu, ginčijama sąlyga dėl orientacinio biudžeto dydžio yra nepakankamai apibrėžta. Techninėje specifikacijoje nurodžius tik orientacinį biudžetą, tačiau nenustačius jokių minimalių įrangos kiekių ar charakteristikų, tiekėjai gali pasiūlyti brangiausią, bet nebūtinai būtinų ar geriausių charakteristikų įrangą. Teismo motyvas, kad aptariamas reikalavimas susijęs su Pirkimo sutarties vykdymu, nepatvirtina šio reikalavimo teisėtumo, kadangi tiekėjai turi teisę ginčyti visus Pirkimo dokumentus, įskaitant ir pirkimo sutarties nuostatas.

26.9.                                            Teismas pažeidė proceso teisės normas ir nepagrįstai vertino atsakovo BPC įrodymus dėl bylinėjimosi išlaidų, kurie buvo pateikti 2020 m. lapkričio 10 d., pasibaigus bylos nagrinėjimui iš esmės. Atsakovas prašyme dėl bylinėjimosi išlaidų atlyginimo nepateikė jokių argumentų, kad neturėjo galimybės tokio prašymo pateikti anksčiau.          

27.       Atsiliepime į apeliacinį skundą atsakovas BPC ir prisidėjime prie atsiliepimo į apeliacinį skundą atsakovas Priešgaisrinės apsaugos ir gelbėjimo departamentas prie Vidaus reikalų ministerijos prašo apeliacinį skundą atmesti. Atsakovas BPC nurodo tokius esminius nesutikimo su apeliaciniu skundu argumentus:

27.1.                                            Teismas pagrįstai, vadovaudamasis Lietuvos Respublikos civilinio proceso kodekso (toliau – ir CPK) 4233 straipsnio nuostatomis, nenagrinėjo ieškovės reikalavimo dėl Pirkimo sąlygų 14.2 (b) papunkčio, nes jis nebuvo reiškiamas ieškovės 2020 m. liepos 7 d. pretenzijoje. Taip pat teismas pagrįstai nagrinėjo klausimą dėl Pirkimo sąlygų 14.2 papunkčio teisėtumo tik tokia apimtimi, kokia ji buvo aptarta ieškovės pretenzijoje, t. y. dėl Pirkimo sąlygų nuostatos, susijusios su AML, kuri, ieškovės teigimu, nurodo į konkrečią pagalbos sistemą, kurią įdiegęs konkretus tiekėjas. Ieškovė šių teismo išvadų neskundžia.

27.2.                                            Pirkimo sąlygų 14.2 papunktį ieškovė ginčijo tuo aspektu, kad paminėta AML sistema yra nuoroda į konkrečią pagalbos sistemą. Teismas turėjo pareigą išsiaiškinti AML sistemos paskirtį ir jos funkcionalumą, todėl ieškovė apeliaciniame skunde nepagrįstai teigia, kad AML funkcionalumas byloje neturi jokios reikšmės. Atsakovas pateikė į bylą įrodymus, kad AML yra bendrinė sąvoka ir atviros technologijos apibūdinimas. AML neįvardina konkretaus produkto, bet tik bendru terminu apibūdina tam tikrą standartizuotą struktūrizuotos vietos nustatymo informacijos perdavimo technologiją. Tai yra technologinis veikimo principas, o ne konkretus prekės ženklas, konkretaus gamintojo produktas ar procesas. 

27.3.                                            Pirkimo sąlygose nustatyti tiekėjo kvalifikacijos reikalavimai turi atitikti esminį kriterijų  – jie turi būti pakankami, kad perkančioji organizacija galėtų būti užtikrinta tiekėjo pajėgumu įvykdyti pirkimo užduotį. Ieškovės apeliaciniame skunde pabrėžiami argumentai, kad Pirkimo objektas, jo svarba neturi jokios reikšmės nustatant kvalifikacijos reikalavimus, prieštarauja VPĮ ir kasacinio teismo praktikai. Atsakovas procesiniuose dokumentuose nurodė, kad AML technologija reikalauja specialių žinių ir patirties, atsižvelgiant į šios technologijos veikimo principą, struktūrą ir įvairius techninius komponentus. AML diegimas yra technologiškai specifinis, nes būtina užtikrinti sistemos gebėjimą saugiai ir patikimai realiu laiku su minimaliu vėlinimu priimti ir apdoroti didelį kiekį SMS žinučių, kurios gali būti pateikiamos tiek tekstiniu formatu (iš įrenginių su iOS operacine sistema), tiek ir binarinių duomenų (angl. Binary SMS) formatu (iš įrenginių su Android operacine sistema). Šias žinutes būtina realiu laiku atpažinti iš visų į 112 numerį gaunamų SMS žinučių srauto ir dekoduoti. Nepagrįsti ieškovės argumentai, kad Pirkimo sąlygų reikalavimas dėl tiekėjų patirties diegiant AML sistemą sumažina potencialių tiekėjų skaičių. Ieškovė nepagrįstai tiekėjų skaičių tapatina su valstybių, įdiegusių AML, skaičiumi. Pagal Europos skubios pagalbos numerio asociacijos skelbiamą informaciją, AML yra įdiegusios visos Baltijos, Skandinavijos ir dauguma Vakarų Europos valstybių, o viso pasaulyje AML yra įdiegusios 26 valstybės ir šis skaičius nuolat didėja. Taigi, tarptautinėje rinkoje jau yra pakankamai teikėjų, diegiančių šią naują ir pažangią technologiją. Nagrinėjamu atveju Pirkimas yra tarptautinis, todėl vietinių tiekėjų galimas trūkumas neturės įtakos tiekėjų konkurencijai Pirkime.  

27.4.                                            Ieškovės argumentai, kad teismas sprendime Pirkimo sąlygų 14.3.8 papunkčio ir Techninės specifikacijos 199.6 papunkčio sąlygas vertino kartu, nepaneigia teismo sprendimo teisėtumo, nes teismas turi teisę pasirinkti, kaip išdėstyti sprendimo motyvus.

27.5.                                            Teismas pagrįstai sprendė, kad Pirkimo sąlygų 14.3.8 papunktyje nustatytas kvalifikacinis reikalavimas proporcingas pirkimo objektui, visiškai pateisinamas Pirkimo objekto specifika, todėl yra teisėtas. Nepagrįsti apeliacinio skundo argumentai, kad Pirkimo sąlygų 14.3.8 papunkčio reikalavimai nėra būtini, yra neadekvatūs ar neproporcingi Pirkimo pobūdžiui. Pagal Pirkimo sąlygų 14.3.8 papunktį, iš tiekėjų reikalaujama turėti integracijos su Motorola Solutions gamintojo DIMETRA radijo ryšio tinklu, veikiančiu TETRA technologijų pagrindu, specialistą. Šis kvalifikacijos reikalavimas yra tiesiogiai susijęs su Techninės specifikacijos 199.6 papunkčio nuostatų įgyvendinimu. Perkamai informacinei sistemai sukurti ir įdiegti, atsižvelgiant į jos apimtį ir sudėtingumą, reikės įvairių specialistų, tačiau yra nepagrįsta, atsižvelgiant į Pirkimo pobūdį ir sudėtingumą, iš perkančiosios organizacijos reikalauti parengti tokias Pirkimo sąlygas, kad jos tiktų visiems tiekėjams ir atitiktų visų jų turimus profesinius pajėgumus.

27.6.                                            Nepagrįsti ieškovės argumentai, kad Pirkimo sąlygų 14.3.8 papunktis yra pritaikytas konkrečiam tiekėjui UAB „InnoForce“, nes ieškovė šiems teiginiams pagrįsti nepateikė jokių įrodymų. Šiuos ieškovės teiginius paneigia kartu su tripliku pateikta partnerių ieškiklio informacija, iš kurios matyti, kad UAB „InnoForce“ nėra Motorola Solutions partneris, todėl neturi jokių išskirtinių teisių bei konkurencinio pranašumo kitų tiekėjų atžvilgiu šiame Pirkime.

27.7.                                            Pagal Lietuvos Respublikos Bendrojo pagalbos centro įstatymo 111 straipsnio 2 dalį, BPC, policija, priešgaisrinės gelbėjimo pajėgos, greitosios medicinos pagalbos tarnyba komunikacijai balsu ir operatyviajam pajėgų valdymui naudoja Lietuvos viešojo saugumo ir pagalbos tarnybų skaitmeninį mobilųjį radijo ryšio tinklą. Siekiant įgyvendinti minėtą įstatymo nuostatą, Techninės specifikacijos 16.3 papunktyje, kurio ieškovė neginčija, yra nustatyta, kad programinė įranga turės būti integruota su Lietuvos viešojo saugumo ir pagalbos tarnybų skaitmeninio mobiliojo radijo ryšio tinklu (tinklo įranga DIMETRA (versija 9.0.2), gamintojas Motorola Solutions). Kadangi BPC ir kitos pagalbos tarnybos savo veikloje naudoja Motorola Solutions gamintojo DIMETRA radijo ryšį, šio ryšio integraciją turi atlikti sertifikuoti ir atitinkamą patirtį turintys specialistai, nes yra tikimybė, kad atliekant tokią integraciją gali būti sutrikdytas visos sistemos veikimas.

27.8.                                            Pagal Techninės specifikacijos 199 punktą, programinė įranga privalo būti integruota su Vidaus reikalų ministerijos valdomu Lietuvos viešojo saugumo ir PT skaitmeninio mobiliojo radijo ryšio tinklu, veikiančiu TETRA (Motorola Solutions DIMETRA 9.0.2) technologijos pagrindu pagal reikalavimus, nurodytus Techninės specifikacijos 199.1–199.13 papunkčiuose. Pagal Techninės specifikacijos 199.13 papunktį, diegiant programinės įrangos radijo ryšio funkcionalumą, tiekėjas turi naudoti Lietuvos viešojo saugumo ir PT skaitmeninio mobiliojo radijo ryšio tinklo (Motorola Solutions DIMETRA 9.0.2) sąsajas (API), nurodytas Techninės specifikacijos 11 priede arba lygiavertes, užtikrinančias keitimąsi duomenims tarp BPC ir Lietuvos viešojo saugumo ir pagalbos tarnybų skaitmeninio mobiliojo radijo ryšio tinklo. Nustatant Pirkimo sąlygų 14.3.8 papunkčio ir Techninės specifikacijos 199.6 papunkčio reikalavimų formuluotes, atsakovas konsultavosi su Vidaus reikalų ministerija, šio tinklo įrangos gamintoja bendrove Motorola Solutions ir konkuruojančiais TETRA tinklo įrangos gamintojais. Specialistas, turėdamas patirties integruojant sistemas naudojant būtent Motorola DIMETRA sąsajas (API), jam nustatytas užduotis atliks sklandžiau, greičiau ir kokybiškiau. Atsižvelgiant į tai, kad BPC naujos programinės įrangos diegimas turi būti įgyvendintas kuo greičiau, reikalaujama specialisto patirtis yra būtina, leisianti užtikrinti sklandų integracijų atlikimą ir įdiegimą.

27.9.                                            Ieškovė apeliaciniame skunde nepagrįstai nurodo, kad teismas, nagrinėdamas Techninės specifikacijos 8 skyriaus 19 punktą, nepagrįstai neįvertino ieškovės pateiktų įrodymų ir nesant jokių įrodymų šį punktą pripažino teisėtu. Techninės specifikacijos 8 skyriaus 19 punkto analogiškos nuostatos buvo numatytos 2019 m. liepos 13 d. paskelbto pirkimo Nr. 444061 Techninės specifikacijos 19 punkte. Ieškovė šią nuostatą ginčijo teisme, tačiau Vilniaus apygardos teismo 2019 m. lapkričio 21 d. sprendimu civilinėje byloje Nr. e2-3950-340/2019 ir Lietuvos apeliacinio teismo 2020 m. vasario 18 d. nutartimi civilinėje byloje Nr. e2A-642-553/2020 ši ieškinio dalis buvo atmesta. Atsakovas nagrinėjamoje byloje pareikštą ieškinį prašė atmesti remiantis įsiteisėjusiuose teismo sprendimuose išdėstytomis aplinkybėmis ir išvadomis, teismas šiuos atsakovo argumentus pripažino pagrįstais ir sprendė, kad ieškovės teiginys dėl programinės įrangos, veikiančios taikomųjų programų pagrindu (angl. Rich-Client) lygiavertiškumo žiniatinklio architektūrai (angl. Web-based) buvo atmestas įsiteisėjusiais teismų procesiniais sprendimais. Ieškovė šių teismo išvadų neginčija. Nepagrįsti ieškovės argumentai, kad teismas nemotyvuotai atmetė ieškovės įrodymus: Austrijos specialisto W. R. rašytinius paaiškinimus, Italijos specialisto F. F. liudytojo parodymus ir Lietuvos specialisto I. K. ekspertinio vertinimo aktą. Atsakovas pažymi, kad visus ieškovės pateiktus įrodymus teismas išnagrinėjo ir teismo sprendime pasisakė dėl jų įrodomosios reikšmės.

27.10.                                            Nepagrįsti ieškovės argumentai, kad teismas, pasisakydamas dėl Techninės specifikacijos 183, 201, 199.6 punktų, neatskleidė bylos esmės. Ieškovė į bylą nepateikė jokių įrodymų, kad ginčijamos Techninės specifikacijos sąlygos dėl API sąsajų suteikia konkurencinį pranašumą UAB „InnoForce“. Apeliacinį skundą šioje dalyje ieškovė grindžia ne įrodymais, o vien savo samprotavimais ir prielaidomis. UAB „InnoForce“ nėra Unify įgaliotas atstovas (tripliko 3 priedas), todėl neturi jokio konkurencinio pranašumo dėl Techninės specifikacijos 183 punkto sąlygų. BPC kreipėsi į telefoninės stoties Unify OpenScape 4000 V8 Duplex ir skambučių skirstymo programinės įrangos Unify OpenScape ContactCenter V9 gamintoją Unify, kurios atstovas informavo, kad Europos Sąjungoje Unify turi 94 Unify OpenScape 4000 sertifikuotus partnerius ir 13 Unify OpenScape ContactCenter sertifikuotų partnerių (atsiliepimo į ieškinį 13 priedas). Programinės įrangos integracija su BPC turima Unify telefonijos įranga turi būti atliekama nesutrikdant su veikiančios sistemos darbo, o pati integracija turi būti atlikta kokybiškai, todėl būtina, kad integraciją atliktų sertifikuoti Unify partneriai, turintys patirtį atlikti tokią integraciją. Integracijai su Unify sistemomis gamintojas kelia tam tikrus reikalavimus, kuriuos tiekėjai gali atitikti patys, registruodamiesi Unify partneriais, arba pasitelkti partnerius subrangai ar jungtinei veiklai. UAB „InnoForce“ nėra programinės įrangos gamintojo Retia įgaliotas atstovas, todėl taip pat neturi konkurencinio pranašumo dėl Techninės specifikacijos 201 punkto sąlygų. BPC kreipėsi į balso įrašų perklausymo programinės įrangos Retia ReDAT eXperience gamintoją „RETIA, a.s.“, kurios atstovas informavo, kad turi 27 aktyvius verslo partnerius (atsiliepimo į ieškinį 14 priedas). Perkamos programinės įrangos integracija su BPC turima Retia ReDAT balso įrašymo įranga taip pat yra vienas svarbiausių funkcinių reikalavimų įsigyjamai sistemai, nes neturint šių funkcijų, BPC veiklos efektyvumas bus prastesnis nei turimas šiuo metu. Integracijai su Retia ReDAT sistemomis gamintojas Retia kelia tam tikrus reikalavimus, kuriuos tiekėjai gali atitikti patys, registruodamiesi Retia partneriais, arba pasitelkti partnerius subrangai ar jungtinei veiklai.

27.11.                                            Techninės specifikacijos 199.6 papunktis taip pat nevaržo tiekėjų konkurencijos, nesuteikia nepagrįsto konkurencinio pranašumo tik Motorola Solutions atstovams bei šio gamintojo sprendimus jau įdiegusiems tiekėjams. Ieškinį šioje dalyje ieškovė grindė tuo, kad Motorola Solutions atsisakė suteikti ieškovei API (angl. Application Programming Interface, liet. aplikacijų programavimo sąsaja) (dubliko 164 punktas). Tačiau ieškovė nepateikė įrodymų, kad Motorola Solutions prašė suteikti API. Iš Motorola Solutions įgalioto atstovo atsakymo (dubliko 7 priedas) matyti, kad buvo atsisakyta suteikti ne API, o prieigą prie ADK aplikacijų programavimo priemonių komplekto (angl. Application Developer Kit (ADK)). Ieškovas nepateikė teismui prašymo, adresuoto Motorola Solutions, todėl neaišku, ko ir kokiomis sąlygomis ieškovė prašė Motorola Solutions. Dėl šių priežasčių Motorola Solutions įgalioto atstovo atsakymas negali būti vertinamas kaip įrodymas, patvirtinantis atsisakymą suteikti ieškovei API. Ieškovė šiuo atveju neįrodė, kad jai nebus prieinama API ir dėl šios priežasties neturės galimybių pateikti pasiūlymo. Atsakovas pažymi, kad integracijai su Motorola TETRA sistema sistemos gamintojas Motorola kelia tam tikrus viešai prieinamus reikalavimus, kuriuos tiekėjai gali atitikti patys, registruodamiesi partneriais, arba pasitelkti partnerius subrangai ar jungtinei veiklai. Registruotų Motorola partnerių Lietuvoje yra du, tarp kurių nėra UAB „InnoForce“. Todėl nepagrįsti ieškovės argumentai, kad Techninės specifikacijos 199.6 papunktis konkurencinį pranašumą suteikia UAB „InnoForce“. Atsakovas taip pat nurodo, kad saugoti tinklo API dokumentaciją ir jos neplatinti trečiosioms šalims nurodė tinklo tvarkytojas.

27.12.                                            Ieškovė, nesutikdama su teismo sprendimu dėl Techninės specifikacijos 322 punkto,  apeliacinį skundą grindžia vien savo įsitikinimu, kad ginčijama sąlyga dėl orientacinio biudžeto dydžio yra nepakankamai apibrėžta. Teismas pagrįstai atmetė ieškovės įsitikinimus ir nuomonę, nes perkančioji organizacija jokių reikalavimų dėl serverinės įrangos įsigijimo Pirkime nenustato. Techninės specifikacijos 322 punkte yra nurodyta, kad pagal tiekėjo pateiktus kiekius, parametrus ir specifikaciją serverinę įrangą kartu su operacinių sistemų ir virtualizavimo įrankių licencijomis įsigys ir duomenų centrą naudojimui paruoš perkančioji organizacija. Techninės specifikacijos 322 punkte pateikta informacija apie perkančiosios organizacijos orientacinį biudžetą specifikuotai įrangai, priešingai nei teigia ieškovė, yra labai aiški ir tiksli. Ši suma buvo įvertinta ir apskaičiuota atsižvelgiant į BPC turimą techninę serverinę įrangą, jos kiekius ir įsigijimo kainas. Perkančioji organizacija, pateikdama šią informaciją tiekėjams, kaip tik siekia skaidrumo ir racionalaus lėšų panaudojimo. Tikroji serverinės įrangos kaina paaiškės tik įvykdžius atskirą pirkimą. Atsakovas, turėdamas ribotus finansinius išteklius, siekia, kad serverinės įrangos kaina neviršytų 500 000 Eur su PVM sumos, todėl tikisi, kad tiekėjas, su kuriuo bus pasirašyta sutartis, pateikdamas specifikacijas, pagrįs reikalingos įrangos charakteristikas ir kiekius, atsižvelgs į šią sumą, todėl pasiūlys pigesnes, tačiau kokybiškas serverinės įrangos alternatyvas. Tik įvykdęs viešąjį serverinės įrangos pirkimą atsakovas sužinos tikrąsias įrangos kainas, tačiau tiekėjui, parengusiam specifikacijas, dėl to jokių sankcijų atsakovas nėra numatęs ir nelaikys netinkamu sutarties vykdymu.

27.13.                                            Atsakovas nesutinka su ieškovės argumentais, kad teismas pažeidė CPK 98 straipsnio 1 dalies nuostatas ir neteisingai išsprendė bylinėjimosi išlaidų priteisimo atsakovo naudai klausimą. Kasacinis teismas yra išaiškinęs, kad CPK 98 straipsnio 1 dalyje nustatytas teisinis reguliavimas negali būti aiškinamas ir taikomas taip, kad būtų paneigta asmens, kurio naudai priimtas sprendimas, teisė gauti jo patirtų bylinėjimosi išlaidų atlyginimą. Atsakovas laiku pateikė prašymą dėl bylinėjimosi išlaidų priteisimo, tačiau iki bylos nagrinėjimo iš esmės pabaigos nespėjo pateikti teismui išlaidų dydį patvirtinančių įrodymų. Pagal kasacinio teismo praktiką teismas turėjo išaiškinti atsakovui teisę pateikti prašymą dėl papildomo sprendimo priėmimo, nurodant svarbias išlaidų dydį patvirtinančių įrodymų nepateikimo priežastis. Tačiau teismas patenkino atsakovo prašymą dėl bylinėjimosi išlaidų ir jas priteisė, todėl šiuo atveju atsakovui nebuvo teisinio pagrindo ir nebeliko procesinės galimybės pateikti prašymą dėl papildomo sprendimo priėmimo. CPK 328 straipsnyje numatyta, kad iš esmės teisėtas ir pagrįstas teismo sprendimas ar nutartis negali būti panaikinami vien formaliais pagrindais. Teismas nustatė, kad atsakovo nurodytos išlaidos advokato teisinei pagalbai apmokėti neviršija maksimalaus atlyginimo už byloje pateiktų procesinių dokumentų parengimą ir kitų veiksmų atlikimą. Ieškovė šių teismo išvadų neginčija, todėl taip pat sutinka, kad bylinėjimosi išlaidos atsakovui yra priteistos teisingai.

28.       Lietuvos apeliacinis teismas 2021 m. vasario 9 d. nutartimi byloje paskyrė informacinių technologijų (toliau – IT) teismo ekspertizę, ją pavedė atlikti ekspertams O. V. ir T. J., ekspertams pavedė pateikti eksperto išvadą, išdėstytą teismo ekspertizės akte, šios nutarties 51.1–51.73 punktuose išdėstytais klausimais, sustabdė civilinę bylą, iki bus atlikta teismo ekspertizė. Ekspertas O. V. 2021 m. balandžio 2 d., o ekspertas T. J. 2021 m. balandžio 30 d. pateikė teismui ekspertizės aktus, teismo ekspertai buvo apklausti 2021 m. birželio 1 d. vykusiame žodiniame teismo posėdyje. Ieškovė ir atsakovė BPC 2021 m. birželio 8 d. pateikė apeliacinės instancijos teismui rašytinius paaiškinimus.

Teisėjų kolegija

k o n s t a t u o j a :

IV.       Apeliacinės instancijos teismo nustatytos bylos aplinkybės, teisiniai argumentai ir išvados

29.       Bylos nagrinėjimo apeliacine tvarka ribas sudaro apeliacinio skundo faktinis ir teisinis pagrindai bei absoliučių sprendimo negaliojimo pagrindų patikrinimas (CPK 320 straipsnio 1 dalis). Apeliacinės instancijos teismo teisėjų kolegija, nagrinėdama bylą apeliacine tvarka, nenustatė absoliučių sprendimo negaliojimo pagrindų ir aplinkybių, dėl kurių turėtų būti peržengtos apeliaciniame skunde nustatytos ribos (CPK 320 straipsnio 2 dalis, 329 straipsnio 2 dalis).

Dėl kvalifikacijos reikalavimų, išdėstytų Pirkimo sąlygų 14.2, 14.3.8 papunkčiuose, teisėtumo

30.       Iš Pirkimo sąlygų 1 punkto matyti, kad Priešgaisrinės apsaugos ir gelbėjimo departamentas prie Vidaus reikalų ministerijos, vykdydamas Pirkimą, numato įsigyti BPC informacinės sistemos programinės įrangos sukūrimą ir įdiegimą. Detalūs reikalavimai Pirkimo objektui nurodyti Techninėje specifikacijoje, iš kurios 1–3 punktų matyti, kad BPC informacinės sistemos programinės įrangos atnaujinimo tikslas – įdiegti ir paruošti eksploatacijai naują programinę įrangą, skirtą atsakyti į pagalbos skambučius ir kontaktus kitais ryšio būdais, komunikuoti šiais būdais su skambinančiuoju, priimti ir vizualizuoti vietos nustatymo informaciją, vykdyti operatyvų pagalbos tarnybų pajėgų valdymą ir užregistruotų įvykių monitoringą, kt. Įsigyjama ir įdiegiama programinė įranga kartu su kitais esamais BPC informacinės sistemos komponentais ir išorinėmis sistemomis sudarys darnią informacinę ir ryšių sistemą, kuri bus naudojama visuomenės prieigai prie skubios pagalbos paslaugų užtikrinti ir BPC bei pagalbos tarnybų sąveikai ir skubios pagalbos suteikimui organizuoti. Ši sistema veiks uždarame Vidaus reikalų telekomunikacijų tinkle ar (ir) saugiajame valstybės duomenų perdavimo tinkle, o padaliniams, kurie neturės tiesioginės prieigos į šiuos tinklus, bus sukurta prieiga VPN (angl. Virtual Private Network) priemonėmis. Programinę įrangą, kaip sistemos dalį, naudos BPC, policijos operatyvaus valdymo padaliniai, greitosios medicinos dispečerinės, priešgaisrinių gelbėjimo pajėgų operatyvaus valdymo padaliniai, aplinkos apsaugos pajėgų operatyviais valdymo padaliniai, taip pat pagal poreikį atitinkamų pagalbos tarnybų pajėgų vienetai.

31.       Ieškovės ginčijamame Pirkimo sąlygų 14.2 papunktyje nustatytas kvalifikacijos (techninio ir profesinio pajėgumo) reikalavimas – tiekėjas per paskutinius 6 (šešis) metus arba per laiką nuo tiekėjo įregistravimo dienos (jeigu tiekėjas vykdė veiklą mažiau nei 6 (šešis) metus) iki pasiūlymų pateikimo dienos turi būti tinkamai įvykdęs sutartį (-is), kurios (-ių) vertė ne mažesnė nei 1 300 000 Eur be PVM. Sutarties (-čių) vykdymo metu sukūrė ir (ar) modernizavo ir įdiegė informacinę (-es) sistemą (-as), kurio (-se): a) yra įdiegtas AML (angl. Advanced Mobile Location) arba lygiavertis funkcionalumas; b) yra įdiegtas GSM/UMTS (2G/3G) vietos nustatymo duomenų priėmimo, apdorojimo ir pateikimo funkcionalumas.

32.       Ieškovė 2020 m. liepos 7 d. pretenzijoje dėl ginčijamo kvalifikacijos reikalavimo nurodė, kad nors Viešųjų pirkimų tarnyba į bylą dėl pirmojo pirkimo pateikė 2019 m. spalio 10 d. išvadą, kurioje, be kita ko, pažymėjo, kad reikalavimas, jog tiekėjas būtų įdiegęs AML ar lygiaverčius funkcionalumus, nukreipia į konkrečias pagalbos sistemas, kurias galimai įdiegęs konkretus tiekėjas, tačiau atsakovas Pirkime paliko sąlygą dėl įdiegto AML, nors tai yra nuoroda į konkrečią pagalbos sistemą, kurią įdiegęs konkretus tiekėjas. Ieškovė pretenzijoje prašė patikslinti Pirkimo sąlygų 14.2 papunktį ir panaikinti kvalifikacijos reikalavimo dalį dėl įdiegto AML ar lygiaverčio funkcionalumo. Atsakovas atsakyme į pretenziją netenkino pretenzijos reikalavimo, nurodęs, kad AML nėra nuoroda į konkrečią pagalbos sistemą, tai yra bendrinė sąvoka ir atviros technologijos apibūdinimas.

33.       CPK 4233 straipsnio 3 dalis nustato, kad ieškinio pagrindas turi sutapti su tiekėjo kreipimesi, pareikštame išankstinio ginčų sprendimo ne teisme tvarka, nurodytomis faktinėmis aplinkybėmis, kuriomis buvo grindžiamas tas kreipimasis, išskyrus atvejus, kai šių aplinkybių ieškovas negalėjo nurodyti kreipimosi padavimo metu.

34.       Nagrinėjamu atveju teisėjų kolegija sprendžia, kad pirmosios instancijos teismas pagrįstai, vadovaudamasis aptarta CPK nuostata, nenagrinėjo tų ieškinio argumentų dėl Pirkimo sąlygų 14.2 papunktyje nustatyto kvalifikacijos reikalavimo, kurie nebuvo nurodyti 2020 m. liepos 7 d. pretenzijoje. Iš ieškinio turinio matyti, kad jame ieškovė išplėtė nesutikimo su Pirkimo sąlygų 14.2 papunkčiu argumentus ir teigė, jog reikalavimas neproporcingas ne tik dėl to, kad AML yra nuoroda į konkrečią pagalbos sistemą, bet ir dėl to, kad reikalaujama būti įdiegus tiek AML, tiek GSM/UMTS (2G/3G) funkcionalumus, be to, vykdant tą pačią sutartį, taip pat nėra aišku, pagal kokius techninius parametrus bus vertinamas AML ir GSM/UMTS (2G/3G) diegimo lygiavertiškumas. Šiuo atveju nenustatyta, kad tokių argumentų ieškovė dėl objektyvių priežasčių negalėjo nurodyti pretenzijoje. Taigi, pirmosios instancijos teismas pagrįstai nagrinėjo tik tokius ieškovės argumentus, kuriuos ji buvo nurodžiusi 2020 m. liepos 7 d. pretenzijoje, t. y. kad aptariamas kvalifikacijos reikalavimas yra neteisėtas, nes AML yra nuoroda į konkrečią pagalbos sistemą, kurią yra įdiegęs konkretus tiekėjas.

35.       VPĮ 47 straipsnio 1 dalis nustato, kad perkančioji organizacija privalo išsiaiškinti, ar tiekėjas yra kompetentingas, patikimas ir pajėgus įvykdyti pirkimo sąlygas, todėl ji turi teisę skelbime apie pirkimą ar kituose pirkimo dokumentuose nustatyti būtinus kandidatų ar dalyvių kvalifikacijos reikalavimus ir šių reikalavimų atitiktį patvirtinančius dokumentus ar informaciją. Perkančiosios organizacijos nustatyti kandidatų ar dalyvių kvalifikacijos reikalavimai negali dirbtinai riboti konkurencijos, turi būti proporcingi ir susiję su pirkimo objektu, tikslūs ir aiškūs. 

36.       Kasacinio teismo praktikoje išaiškinta, kad konkurenciją riboja pernelyg aukšti arba specifiniai, neadekvatūs pirkimo pobūdžiui ar neproporcingi jo sąlygoms reikalavimai, kurie atima galimybę pirkimo procedūrose dalyvauti sutartį realiai ir faktiškai gebantiems įvykdyti kandidatams ar dalyviams (Lietuvos Aukščiausiojo Teismo 2010 m. gegužės 4 d. nutartis civilinėje byloje Nr. 3K-3-126/2010, kt.).

37.       Pirmosios instancijos teismas pagrįstai nustatė, kad AML nėra nuoroda į konkrečią pagalbos sistemą – šią aplinkybę patvirtina tiek pirmosios instancijos teismo nurodyti informacijos šaltiniai (Europos skubios pagalbos telefono numerio asociacijos parengta AML sistemos ataskaitos kortelė ir Europos telekomunikacijų standartizacijos instituto (ETSI) dokumentai), tiek teismo eksperto O. V. apeliacinės instancijos teismui pateiktas ekspertizės aktas. Kaip matyti iš teismo eksperto O. V. atsakymų į 1 klausimą, AML – tai išmaniųjų mobiliųjų telefonų, iš kurių skambinama skubiosios pagalbos numeriu, vietos nustatymo funkcija, kuri yra aprašyta Europos telekomunikacijų standartizacijos instituto (ETSI) techniniame standarte. Šis standartas yra atviras, pagal jį AML yra įdiegusios ne mažiau 18 Europos valstybių, dalis JAV ir Meksikos valstijų, Naujoji Zelandija ir JAE. AML yra įgalinta ir palaikoma didžiųjų išmaniųjų telefonų operacinių sistemų gamintojų, tai – bendrinė technologija, kuri nėra orientuota į vieną diegėją. Nors teismo eksperto T. J. ekspertizės akte teigiama, kad AML yra referencija į konkrečią technologiją, tačiau akte nėra paneigta, jog ši technologija iš esmės yra atvira ir gali būti be apribojimų diegiama įvairių tiekėjų, priešingai, ekspertas T. J., atsakydamas į 13 klausimą, nurodė, kad AML technologija bei jo struktūra yra vieša.

38.       Vis dėlto, nors pirmosios instancijos teismas teisingai nustatė, kad AML yra bendrinė technologija, tačiau, spręsdamas dėl aptariamo kvalifikacijos reikalavimo, neatsižvelgė į tai, jog informacinių sistemų su AML diegimo patirtį turi labai mažai tiekėjų. Iš Europos skubios pagalbos telefono numerio asociacijos parengtos AML sistemos ataskaitos kortelės matyti, kad AML šiuo metu yra įdiegta ir veikia virš 14 šalių. Pagal naujausią 2020 m. rugpjūčio 6 d. paskelbtą Europos skubios pagalbos numerio asociacijos informaciją, Graikija tapo 26 valstybe pasaulyje, kurioje yra įdiegtas AML funkcionalumas. Teismo ekspertas O. V. ekspertizės akte, kaip minėta, nurodė, kad AML yra įdiegusios ne mažiau 18 Europos valstybių, dalis JAV ir Meksikos valstijų, Naujoji Zelandija ir JAE. Iš Europos skubios pagalbos telefono numerio asociacijos parengtos AML sistemos ataskaitos kortelės, teismo eksperto T. J. ekspertizės akte pateiktų atsakymų į 12 klausimą matyti, kad Lietuvoje AML technologiją naudoja BPC informacinė sistema, o ją įdiegė UAB „Innoseven Technologies“. Nei teismo ekspertas T. J., nei teismo ekspertas O. V. kitų Lietuvoje veikiančių įmonių, turinčių AML sistemos diegimo patirtį, nenurodė. Taigi, iš šių duomenų spręstina, kad ginčijamą kvalifikacijos reikalavimą Lietuvoje atitinka tik viena įmonė, o Europoje tokių įmonių yra labai mažai. Vadinasi, ieškovės ginčijamas kvalifikacijos reikalavimas itin varžo konkurenciją, todėl atsakovai byloje privalo pateikti įtikinantį tokio reikalavimo proporcingumo pagrindimą, t. y. įrodyti, kad aptariamo reikalavimo taikymas tikslingas dėl juo siekiamo tikslo.

39.       Atsakovai byloje įrodinėjo, kad ginčijamo kvalifikacijos reikalavimo nustatymas yra pagrįstas ypatinga Pirkimo objekto svarba ir rizikomis, jei AML funkcionalumą diegtų neturintis patirties tiekėjas. Antai, teismo ekspertas O. V. ekspertizės akte, atsakydamas į 13 klausimą, nurodė, kad tiekėjas be AML diegimo patirties gali įgyvendinti AML funkcijas ir jas integruoti į diegiamą sistemą, tačiau tai sukelia didelę riziką, jog sprendimas ne iš karto pradės veikti tinkamai ir sukels riziką nesuteikti pagalbos, suteikti ją netinkamai ar ne laiku. Teismo ekspertas O. V. ekspertizės akte detalizavo, kad tiekėjas, neturintis specifinės patirties gaunant ir apdorojant AML žinutes nestandartinėse situacijose, su jomis susidurs tik pradėjus naudoti AML programinę įrangą ir tik tuomet pradės ieškoti galimų sprendimo būdų, kurie jau yra žinomi patyrusiam tiekėjui. Taip pat, šio eksperto vertinimu, diegiant aptariamą technologiją, būtinas testavimas, kuris taip pat reikalauja patirties iš AML technologijos diegėjo.

40.       Teisėjų kolegijos vertinimu, aptarti atsakovų argumentai ir teismo eksperto O. V. nurodytos rizikos nėra pakankami tam, kad būtų pagrįstas nustatyto kvalifikacijos reikalavimo proporcingumas. Pats teismo ekspertas O. V. nurodė, kad tiekėjas be AML diegimo patirties iš esmės gali įgyvendinti AML funkcijas ir jas integruoti į diegiamą sistemą. Šią aplinkybę patvirtina ir teismo ekspertas T. J., kuris ekspertizės akte, atsakydamas į 13 klausimą, nurodė, kad būsimam BPC kūrėjui nereikia turėti konkrečios patirties įdiegiant būtent AML ir bet kuris informacinių sistemų kūrėjas užtikrintų tokio viešo sprendinio integraciją su kuriama informacine sistema. Pažymėtina, kad, kaip matyti iš byloje surinktų duomenų apie teismo ekspertų kvalifikaciją, eksperto O. V. turima patirtis IT srityje yra daugiau teorinio pobūdžio, tuo tarpu eksperto T. J. – praktinė, vadinasi, eksperto O. V. nurodytos rizikos vertintinos kaip teorinės. Minėtos technologijos diegimo rizikos, nurodytos teismo eksperto O. V., galėtų būti pašalintos mažiau konkurenciją varžančiomis priemonėmis Pirkimo sutarties vykdymo metu ir, be kita ko, teismo eksperto T. J. apeliacinės instancijos teismo posėdyje nurodytu būdu, t. y. atliekant testavimą. Kaip galima spręsti iš Pirkimo sąlygų, perkančioji organizacija reikalauja, kad tiekėjas turėtų patyrusį testavimo  specialistą. Be to, net ir sutinkant su teismo eksperto O. V. nuomone dėl rizikų, su kuriomis susidurtų AML diegimo patirties neturintis tiekėjas, teisėjų kolegijos nuomone, byloje nebuvo pagrįsta, kad šios rizikos būtų tokio lygmens, kad pateisintų itin reikšmingą konkurencijos apribojimą, kai ginčijamą reikalavimą Lietuvoje atitinka tik viena įmonė, o Europoje tokių įmonių yra labai mažai.

41.       Aptariamo kvalifikacijos reikalavimo neteisėtumą patvirtina ir tai, kad nustatant šį reikalavimą, nebuvo laikytasi Viešųjų pirkimų tarnybos parengtų Tiekėjo kvalifikacijos reikalavimų nustatymo informacinių sistemų viešuosiuose pirkimuose gairių. Pagal šias gaires, nustatant reikalavimą dėl tiekėjo įvykdytų sutarčių, reikėtų nepamiršti, kad faktiškai sutartis vykdo ir paslaugas teikia ne pati įmonė, o joje dirbantys specialistai, todėl nereikėtų apriboti konkurencijos nustatant labai specifinius, orientuotus į konkrečias kurtas informacines sistemas reikalavimus. Kvalifikacijos reikalavimas turėtų parodyti tiekėjo patirtį ir gebėjimą atlikti tam tikro dydžio ar sudėtingumo sistemų kūrimo projektus. Be to, tiekėjas yra sutarčių administratorius, atliekantis sutarties valdymą, paskirstantis specialistų srautus, todėl jo patirtis dažniausiai turėtų būti vertinama tik finansiniu aspektu, nurodant įvykdytos sutarties vertę ir nevertinant techninių sistemų parametrų. Šiuo atveju ginčijamu kvalifikacijos reikalavimu iš tiekėjų reikalaujama turėti itin specifinę patirtį, orientuotą į konkrečią AML technologiją, nors tiekėjų, turinčių tokią patirtį, skaičius yra itin mažas, todėl toks reikalavimas vertintinas kaip neatitinkantis Viešųjų pirkimų tarnybos parengtų gairių.

42.       Ieškovės ginčijamame Pirkimo sąlygų 14.3.8 papunktyje numatyta, kad tiekėjas turi pasiūlyti kvalifikuotus specialistus, galinčius tinkamai įvykdyti sutartį. Integracijos su Motorola Solutions  gamintojo DIMETRA radijo ryšio tinklu, veikiančiu TETRA technologijų pagrindu specialistas turi turėti patirtį bent 1 (viename) įgyvendintame (baigtame) informacinės sistemos diegimo, kūrimo ir (arba) modernizavimo projekte, kurio metu atliko Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo statusų siuntimo ir priėmimo, trumpųjų žinučių siuntimo ir priėmimo, koordinačių priėmimo funkcijų integravimą į informacinę sistemą, naudojant Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo aplikacijų programavimo sąsajas (API). Ieškovės manymu, šiame kvalifikacijos reikalavime neteisėtai reikalaujama, kad tiekėjo komandoje esantis integracijos su TETRA technologijų radijo ryšio tinklu specialistas turėtų profesinę patirtį išimtinai tik su konkretaus gamintojo Motorola Solutions DIMETRA radijo ryšio tinklu.

43.       Atsakovai šio kvalifikacijos reikalavimo teisėtumą grindė Techninės specifikacijos sąlygomis, gamintojo Motorola atstovo M. I. 2020 m. balandžio 22 d. elektroniniu laišku, Vidaus reikalų ministerijos 2020 m. gegužės 12 d. raštu BPC, taip pat kitų TETRA technologijų pagrindu dirbančių gamintojų atsakymais. Skirtingai nei vertino pirmosios instancijos teismas, teisėjų kolegijos nuomone, šie duomenys neįrodo ginčijamo kvalifikacijos reikalavimo teisėtumo.

44.       Visų pirma, pažymėtina, kad pirmosios instancijos teismas neatsižvelgė į tai, kad atsakovai į bylą nepateikė įrodymų, jog nustačius aptariamą kvalifikacijos reikalavimą nėra reikšmingai suvaržoma konkurencija. Priešingai, paties atsakovo BPC į bylą (tripliko priedas) pateiktas Motorola Solutions partnerių Lietuvoje sąrašas patvirtina, kad šio gamintojo partneriais, dirbančiais su DIMETRA radijo ryšio tinklu, yra tik dvi įmonės. Taigi, spręstina, kad nustatytas kvalifikacijos reikalavimas ženkliai riboja konkurenciją, nes specialistų, turinčių integracijos patirties su konkretaus gamintojo Motorola Solutions DIMETRA tinklu, yra mažai.     

45.       Antra, Techninės specifikacijos sąlygos taip pat nepatvirtina objektyvaus poreikio nustatyti ginčijamą kvalifikacijos reikalavimą. Techninės specifikacijos 16.3 papunktyje nustatyta, kad programinė įranga turės būti integruota su Lietuvos viešojo saugumo ir pagalbos tarnybų skaitmeninio mobiliojo radijo ryšio tinklu (tinklo įranga DIMETRA (versija 9.0.2), gamintojas Motorola Solutions). Pagal Techninės specifikacijos 199.13 papunktį, programinė įranga privalo būti integruota su Vidaus reikalų ministerijos valdomu Lietuvos viešojo saugumo ir PT skaitmeninio mobiliojo radijo ryšio tinklu, veikiančiu TETRA (Motorola Solutions DIMETRA 9.0.2) technologijos pagrindu. Diegiant programinės įrangos radijo ryšio funkcionalumą tiekėjas turi naudoti Lietuvos viešojo saugumo ir PT skaitmeninio mobiliojo radijo ryšio tinklo (Motorola Solutions DIMETRA 9.0.2) sąsajas (API), nurodytas specifikacijos 11 priede arba lygiavertes, užtikrinančias keitimąsi duomenims tarp BPC informacinės sistemos ir Lietuvos viešojo saugumo ir PT skaitmeninio mobiliojo radijo ryšio tinklo. Teisėtą prieigą prie Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API ir dokumentacijos tiekėjas gauna ir naudoja Motorola Solutions interneto puslapyje nurodytomis sąlygomis. Pagal informaciją, skelbiamą puslapyje https://www.motorolasolutions.com/en_xu/partners/become-partner/application-partner-developer-program.html, specialistas gali prisijungti prie Motorola Solutions aplikacijų vystymo programos, kai jis užpildo atitinkamą prašymą ir atitinka gamintojo nurodytus patirties bei kitus kriterijus. Taigi, pagal šias Techninės specifikacijos sąlygas svarbu yra tai, kad tiekėjo turimas specialistas gamintojo Motorola Solutions nustatytomis sąlygomis įgytų teisėtą prieigą prie Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API ir dokumentacijos, ir toks reikalavimas būtų pakankamas tam, kad šis specialistas galėtų vykdyti diegiamos informacinės sistemos integraciją su Motorola Solutions gamintojo DIMETRA radijo ryšio tinklu.

46.       Šią teisėjų kolegijos išvadą iš esmės patvirtina ir atsakovo pateiktas į bylą Vidaus reikalų ministerijos 2020 m. gegužės 12 d. raštas, kuriame ministerija pateikė nuomonę, jog Pirkimo sąlygose būtina numatyti, kad tiekėjas turi būti įgaliotas trečiųjų šalių aplikacijų (informacinių sistemų) diegimo su Motorola DIMETRA radijo ryšio tinklu atstovas (partneris, diegėjas (angl. developer). Vis dėlto, šiame rašte ministerija neišreiškė nuomonės, jog tiekėjo specialistams turėtų būti keliamas reikalavimas turėti integravimo į informacines sistemas patirties naudojant būtent Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo aplikacijų programavimo sąsajas (API).  

47.       Trečia, atsakovai į bylą pateikė gamintojo Motorola atstovo M. I. 2020 m. balandžio 22 d. elektroninį laišką, kuriame atstovas nurodo, kad Pirkime būtina reikalauti ne tik, kad integraciją vykdysiantis specialistas turėtų teisėtą prieigą prie Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API ir dokumentacijos, bet ir kad būsimasis paslaugų teikėjas pateiktų sąrašą jį rekomenduoti galinčių subjektų, kur jo siūlomas sprendimas buvo sėkmingai įgyvendintas ir integruotas su Motorola Dimetra sistemomis. Tačiau pažymėtina, kad toks gamintojo nurodymas jokiais objektyviais duomenimis, įgalinančiais spręsti, kad tik specialistas, dirbęs su Motorola Solutions DIMETRA intergracija, galėtų tinkamai įvykdyti Pirkimo reikalavimus, nepateikė, todėl toks gamintojo nurodymas vertintinas kaip nemotyvuotas ir neprivalomas perkančiajai organizacijai.

48.       Ketvirta, aptariamo kvalifikacijos reikalavimo neteisėtumą patvirtina ir tai, kad nustatant šį reikalavimą, nebuvo laikytasi Viešųjų pirkimų tarnybos parengtų Tiekėjo kvalifikacijos reikalavimų nustatymo informacinių sistemų viešuosiuose pirkimuose gairių. Šiose gairėse Viešųjų pirkimų tarnyba laikosi nuomonės, kad integravimo specialistui nėra svarbu, kokios informacinės sistemos sąveikauja tarpusavyje. Jis privalo būti įgijęs patirties, kuriant integracijas tarp sistemų. Tarnyba gairėse atkreipia dėmesį, kad specialistas, turintis patirties kuriant sistemas su dviem integracijomis, taip pat gebės atlikti ir sistemų su daugiau integracijų projekte jam pavestas užduotis. 

49.       Penkta, integracijos su TETRA technologijų radijo ryšio tinklu specialistui keliamo reikalavimo turėti patirtį su konkretaus gamintojo Motorola Solutions DIMETRA radijo ryšio tinklu proporcingumo siekiamiems tikslams nepagrindžia ir teismo ekspertų O. V. bei T. J. ekspertizės aktuose nurodytos išvados. Antai, ekspertas T. J., atsakydamas į 30 klausimą, nurodė, kad TETRA radijo ryšio sistemos funkcionalumai yra standartizuoti ETSI standarte, kuris aprašo tiek pačios antžeminio magistralinio radijo ryšio sistemos veikimo struktūrą, tiek antžeminio magistralinio radijo ryšio sistemos sąveiką su kitomis sistemomis. Todėl nepriklausomai nuo to, su kokio konkretaus gamintojo radijo ryšio sistema specialistas turi darbo patirties, specialistas galės dirbti ir su kito gamintojo radijo ryšio sistema, kuri veikia tuo pačiu TETRA standarto pagrindu.

50.       Teismo ekspertas O. V., atsakydamas į 30 klausimą, nurodė, kad kiekvienas TETRA tinklo valdymo įrangos gamintojas (Motorola, EADS, DAMM ir kiti) API sąsajas įgyvendina skirtingomis priemonėmis ir būdais bei užtikrina skirtingas sąsajų galimybes, naudoja skirtingas funkcijas ir atributus. Eksperto teigimu, nekorektiškas sąsajų naudojimas gali sutrikdyti TETRA tinklo veikimą. Taip pat ekspertas nurodo, kad specialistas, neturintis patirties su naudojamos TETRA sistemos sąsaja, turės nagrinėti specifinę, tik šio gamintojo naudojamą unikalią API sąsają, tokių darbų metu padidėja tikimybė, kad gali įvykti funkcijų veikimo sutrikimai, TETRA radijo ryšio sutrikimai, todėl perkančioji organizacija reikalauja, kad specialistas turėtų darbo su naudojama įranga patirties.

51.       Tačiau, teisėjų kolegijos vertinimu, teismo eksperto O. V. išvados nepakankamos pagrįsti nustatyto kvalifikacijos reikalavimo proporcingumo. Teismo ekspertas, nors ir nurodo tam tikras rizikas, jeigu integraciją vykdytų neturintis darbo su gamintojo Motorola Solutions DIMETRA sistema patirties, tačiau nepagrindžia, kad tokios rizikos negalėtų būti sumažintos kitu, mažiau konkurenciją ribojančiu reikalavimu, kuris yra nurodytas Techninės specifikacijos 199.13 papunktyje, t. y. kad specialistas turi turėti teisėtą prieigą prie Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo API ir dokumentacijos. Kaip minėta, tokiam reikalavimui įvykdyti gamintojas Motorola Solutions taiko atitinkamus patirties bei kitus kriterijus, tačiau ekspertas nepagrindžia, kad paties gamintojo nustatyti kriterijai būtų nepakankami ir dar turėtų būti keliamas itin specifinis reikalavimas būti įgyvendinus projektą, kurio metu specialistas atliko Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo integravimą į informacinę sistemą, naudojant Motorola Solutions gamintojo DIMETRA radijo ryšio tinklo aplikacijų programavimo sąsajas (API).

Dėl Techninės specifikacijos sąlygų 

52.       Ieškovė byloje ginčijo Techninės specifikacijos 8 skyriaus 19 punkto teisėtumą. Techninės specifikacijos 8 skyriuje esančios sąlygos nustato bendruosius programinės įrangos techninius, funkcinius ir kitus reikalavimus, o šiame skyriuje esantis 19 punktas detalizuoja, kad programinės įrangos platforma turi būti paremta į paslaugas orientuota žiniatinklio architektūra (angl. Service-Oriented Architecture – SOA, Web-Based), suteikiančia atviras taikomųjų programų sąsajas (angl. Application Programming Interfaces, APIs) ir pasiekiama interneto naršyklėmis Chrome ir Firefox. Skambučių operatorių ir dispečerių kompiuterinėse darbo vietose neturi būti diegiama jokia programinė įranga. Turi būti užtikrintas suderinamumas su skirtingomis platformomis (pvz., Windows kompiuteriai, Linux kompiuteriai, planšetiniai kompiuteriai). 

53.       Teisėjų kolegija pirmiausia atkreipia dėmesį į tai, kad dėl analogiškos pirmojo pirkimo sąlygos ieškovė jau buvo pareiškusi ieškinį teismui. Tačiau tiek Vilniaus apygardos teismo 2019 m. lapkričio 21 d. sprendimu civilinėje byloje Nr. e2-3950-340/2019, tiek Lietuvos apeliacinis teismas 2020 m. vasario 18 d. nutartimi civilinėje byloje Nr. e2A-642-553/2020 atmetė ieškovės reikalavimus dėl analogiškos pirkimo sąlygos. Lietuvos apeliacinis teismas 2020 m. vasario 18 d. nutartyje, be kita ko, nurodė, kad VPĮ 37 straipsnio lingvistinis bei loginis aiškinimas patvirtina, kad techninėje specifikacijoje iš esmės draudžiama nustatyti konkretų procesą, būdingą konkretaus tiekėjo teikiamoms prekėms ar teikiamoms paslaugoms. Apeliacinės instancijos teismo vertinimu, Techninės specifikacijos 8 skyriaus 19 punkte nustatytas reikalavimas, kad atitinkama informacinė sistema turi būti pasiekiama naudojant žiniatinklio naršyklę, nustato ne konkretaus tiekėjo prekei būdingą konkretų procesą, o įtvirtina būdą, kaip programinės įrangos naudotojas turėtų pasiekti atitinkamą informacinę sistemą. Žiniatinklio architektūra yra konkretus tam tikros informacijos pasiekimo būdas, jo naudojimas yra visuotinai paplitęs, nesiejamas su konkrečiais tiekėjais, todėl tai, kad atsakovas BPC pasirinko vieną iš šių būdų, nesudaro pagrindo teigti, jog ginčo Techninėje specifikacijoje buvo nustatytas VPĮ 37 straipsnio 5 dalies draudžiamas konkretus procesas, būdingas konkretaus tiekėjo prekėms ar paslaugoms. Apeliacinės instancijos teismas konstatavo, kad aptariamas Techninės specifikacijos reikalavimas buvo parengtas VPĮ 37 straipsnio 4 dalies leistinu būdu – nurodant Pirkimo objekto funkcinius reikalavimus (VPĮ 37 straipsnio 4 dalies 1 punktas).

54.       Lietuvos apeliacinis teismas 2020 m. vasario 18 d. nutartyje taip pat pažymėjo, kad kita ieškovės skundo argumentų grupė buvo susijusi su programinės įrangos, veikiančios taikomųjų programų pagrindu (angl. Rich-Client), arba kombinuotos architektūros (angl. Rich-Client + Web-based), lygiavertiškumu žiniatinklio architektūrai (angl. Web-based). Tačiau Lietuvos apeliacinis teismas nepasisakė dėl skundo argumentų, susijusių su kombinuotos architektūros lygiavertiškumu žiniatinklio architektūrai, nes šiuos argumentus ieškovė nurodė tik apeliacinės instancijos teisme, o ieškovės argumentus dėl taikomųjų programų pagrindu veikiančios programinės įrangos lygiavertiškumo žiniatinklio architektūros pagrindu veikiančiai programinei įrangai Lietuvos apeliacinis teismas atmetė kaip nepagrįstus.

55.       Kadangi ieškovės argumentai dėl taikomųjų programų pagrindu veikiančios programinės įrangos lygiavertiškumo žiniatinklio architektūros pagrindu veikiančiai programinei įrangai jau buvo išnagrinėti ir teismų pripažinti nepagrįstais, ieškovė šioje byloje kelia tik klausimą dėl pašalintos tiekėjų galimybės Pirkime siūlyti kombinuotų architektūrų informacines sistemas, kurios, ieškovės vertinimu, taip pat gali užtikrinti perkančiosios organizacijos poreikius. Tačiau, teisėjų kolegijos vertinimu, tokie ieškovės argumentai pirmosios instancijos teismo buvo pagrįstai atmesti.

56.       Teisėjų kolegija pažymi, kad, kaip nurodė ir Lietuvos apeliacinis teismas 2020 m. vasario 18 d. nutartyje, ginčijamas Techninės specifikacijos reikalavimas neapibūdina konkretaus tiekėjo prekei būdingo proceso, o įtvirtina būdą, kaip programinės įrangos naudotojas turėtų pasiekti atitinkamą informacinę sistemą. Nurodyti siekiamus įsigyti Pirkimo objekto funkcinius reikalavimus – perkančiosios organizacijos teisė. Kasacinio teismo praktikoje perkančiosioms organizacijoms pripažįstama didelė diskrecija formuluojant technines pirkimo specifikacijas, nes būtent jos geriausiai žino prekes, kurių joms reikia, ir gali geriausiai nustatyti reikalavimus, kurie turi būti tenkinami tam, kad būtų gauti pageidaujami rezultatai (Lietuvos Aukščiausiojo Teismo 2011 m. gruodžio 14 d. nutartis civilinėje byloje Nr. 3K-3-507/2011; 2017 m. gegužės 18 d. nutartis civilinėje byloje Nr. e3K-3-241-690/2017). Šiuo atveju ieškovė byloje nepagrindė, kuo perkančiosios organizacijos pasirinktas būdas, kuriuo programinės įrangos naudotojas turėtų pasiekti atitinkamą informacinę sistemą (žiniatinklio architektūra), apriboja jos galimybes dalyvauti Pirkime, t. y. ieškovė nepagrindžia, kad ji ir kiti rinkoje veikiantys subjektai negali sukurti informacinės sistemos, veikiančios būtent perkančiosios organizacijos pageidaujamu būdu. Atsakovas atsakyme į ieškovės pretenziją nurodė, kad atlikta rinkos analizė parodė, jog rinkoje egzistuoja pakankamai tiekėjų, siūlančių įsigyjamo tipo sistemas. Taigi, ieškovės argumentai dėl to, kad Techninė specifikacija neužtikrina konkurencijos ir diskriminuoja tiekėjus, vertintini kaip deklaratyvūs. 

57.       Kita vertus, teisėjų kolegija, išsamiai įvertinusi teismo ekspertų O. V. bei T. J. ekspertizės aktuose padarytas išvadas, nesutinka su ieškovės pozicija, kad kombinuotų architektūrų pagrindu veikiančios informacinės sistemos yra lygiavertės į paslaugas orientuotos žiniatinklio architektūros pagrindu veikiančioms sistemoms.

58.       Kaip nurodyta eksperto O. V. atsakyme į 32 klausimą, žiniatinklio architektūra (angl. Web-Based) grindžiamos sistemos naudotojui reikalingas funkcijas vykdo programinėje įrangoje, įdiegtoje serveryje (vadinamajame Web serveryje). Naudotojas tokios sistemos funkcionalumą pasiekia per įdiegtą kliento kompiuteryje interneto naršyklę. Tokios programinės įrangos privalumai – pati naudotojo sąsajos programinės įrangos dalis be specifinio adaptavimo operacijų sistemai veikia įvairiose operacijų sistemose ir platformose; lyginant su kitų tipų kliento dalimi, paprastesnė sistemos kliento dalies priežiūra, nes nereikia diegti programinės įrangos komplekto ir užtikrinti skirtingų programų suderinamumo; supaprastėja galimybės atnaujinti sistemą, nes išleidus naują versiją, kiekvieną kartą nėra poreikio diegti funkcionalumą užtikrinančios programinės įrangos visuose naudotojų kompiuteriuose ar valdyti automatizuotą diegimo posistemį. Kaip nurodo ekspertas, pastaruoju metu daugelis programinės įrangos gamintojų kuria programinę įrangą, kurios naudotojo sąsaja pasiekiama per naršyklę (t. y. naudoja žiniatinklio architektūra grindžiamas sistemas) (Gmail, Facebook, Valstybinės mokesčių inspekcijos deklaravimo sistema ir kt.). Tuo tarpu kombinuota architektūra grindžiama sistema funkcionuoja taip, kad jos funkcijos vykdomos tiek programinės įrangos, kuri yra įdiegta serveryje, tiek programinės įrangos, kuri įdiegta naudotojo kompiuteryje. Programinė įranga, įdiegta naudotojo kompiuteryje, turi būti sukurta ir įdiegta specialiai tam, kad suderintai funkcionuotų su serveryje veikiančia programine įranga. Ekspertas nurodo, kad tokių sistemų kliento dalis gali veikti tik vieno tipo operacijų sistemoje, kuriai yra parašytas kliento dalies programos kodas. Be to, naudojama programinė įranga turi būti suderinta su konkrečiame kompiuteryje veikiančios operacijų sistemos, tvarkyklių ir kitų įdiegtų skirtingų gamintojų programinės įrangos komponentų veikimu. Sistemos kliento dalies diegimas apima programinės įrangos fizinį diegimą kiekvienoje darbo vietoje. Ekspertas, atsakydamas į 34 klausimą, nurodė, kad kombinuotos architektūros pagrindu veikia tokios žinomos programos, kaip Skype, Spotify, Zoom, Microsoft Teams.

59.       Iš esmės panašiai žiniatinklio architektūra (angl. Web-Based) ir kombinuota architektūra grindžiamas sistemas apibūdino ir ekspertas T. J.. Šis ekspertas, atsakydamas į 32 klausimą, nurodė, kad įprastai Web-Based architektūros atveju interneto naršyklė yra kliento dalis, kuri teikia užklausas serveriui. Ekspertas, atsakydamas į 33 klausimą, nurodė, kad kombinuotos architektūros atveju kompiuterio vartotojas vietoje interneto naršyklės turi atsidaryti kitą programinę įrangą (aplikaciją), kuri yra sukuriama pagal vartotojo poreikius. Ekspertas, lygindamas šiomis architektūromis grindžiamas sistemas, nurodė, kad abiejų atveju instaliavimo, atnaujinimo, administravimo klausimai sprendžiami panašiai, tačiau kombinuota architektūra grindžiamos sistemos pranašesnės naujų funkcijų diegime, kadangi Web-Based, veikianti išimtinai per interneto naršyklę, turi ribotas modifikacijos ir plėtros galimybes, nes naršyklių funkcionalumus prižiūri jų gamintojai.        

60.       Iš šių ekspertų padarytų išvadų seka, kad žiniatinklio architektūra (angl. Web-Based) ir kombinuota architektūra grindžiamų sistemų pagrindinis skirtumas tas, kad žiniatinklio architektūra (angl. Web-Based) veikiančios sistemos atveju naudotojas sistemos funkcionalumą pasiekia per įdiegtą kliento kompiuteryje interneto naršyklę, tuo tarpu kombinuota architektūra grindžiamos sistemos atveju naudotojas sistemos funkcionalumą pasiekia per darbo vietoje įdiegtą kitą programinę įrangą (aplikaciją), kuri yra sukuriama pagal vartotojo poreikius.

61.       Nagrinėjamu atveju perkančioji organizacija vertino, kad būtent pirmasis būdas jai yra priimtinesnis, o tokį sprendimą grindė argumentais dėl sistemos aptarnavimo ir priežiūros darbų bei laiko sąnaudų, taip pat nurodė, jog siekia užtikrinti būtiną įsigyjamo sprendimo lankstumą, kadangi sprendimą naudos ne tik atsakovai, bet ir kitos organizacijos, o taip pat nutolę padaliniai. Tokie perkančiosios organizacijos argumentai, atsižvelgus į paminėtus sistemų skirtumus, t. y. kad kombinuota architektūra grindžiamos sistemos atveju naudotojas sistemos funkcionalumą pasiekia per darbo vietoje įdiegtą kitą programinę įrangą, o ne per interneto naršyklę, teisėjų kolegijai atrodo logiški ir racionalūs, o juos patvirtina ir teismo eksperto O. V. nurodyti žiniatinklio architektūra (angl. Web-Based) grindžiamų sistemų privalumai. Nors ekspertas T. J. ekspertizės akte neigė žiniatinklio architektūros (angl. Web-Based) privalumus, tačiau šio eksperto išvados aptariamu klausimu, kolegijos vertinimu, mažiau nuoseklios ir aiškios, lyginant su eksperto O. V. išvadomis (pavyzdžiui, T. J. prie kombinuota architektūra grindžiamų sistemų priskiria tiek tas sistemas, kurių kliento dalis yra kita programinė įranga (aplikacijos), tiek interneto naršyklė, tokiu būdu nėra pakankamai aišku, kaip turėtų būti atskiriamos viena nuo kitos šios architektūros). 

62.       Be to, teisėjų kolegija atkreipia dėmesį ir į tai, kad pagal Pirkimo sąlygų 10 punktą tiekėjas gali siūlyti ir atitinkamus lygiaverčius produktus ar procesus, nepriklausomai nuo to, ar šalia yra prierašas „arba lygiavertis“; lygiavertiškumo įrodymas yra tiekėjo pareiga. Vadinasi, ieškovė turi teisę siūlyti Techninę specifikaciją atitinkančius lygiaverčius sprendimus. Dėl šių argumentų teisėjų kolegija konstatuoja, kad pirmosios instancijos teismas tinkamai įvertino byloje surinktus įrodymus ir pagrįstai vertino, jog Techninės specifikacijos 8 skyriaus 19 punktas yra teisėtas, juo konkurencija neleistinai neribojama.

63.       Ieškovė byloje ginčijo ir Techninės specifikacijos 183, 199.6 bei 201 punktus.

64.       Techninės specifikacijos 183 punktas nustato, kad programinė įranga privalo būti integruota su Perkančiosios organizacijos naudojamomis telefoninėmis stotimis Unify OpenScape 4000 V8 Duplex ir skambučių skirstymo programine įranga Unify OpenScape ContactCenter V9 naudojant OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajas. Prieiga prie SDK sąsajų, jų dokumentacijos turi pasirūpinti ir nepertraukiamą BPC telefoninių stočių darbą integravimo metu turi užtikrinti tiekėjas.

65.       Pagal Techninės specifikacijos 201 punktą, programinė įranga privalo būti integruota su Perkančiosios organizacijos turima balso įrašų perklausymo programine įranga Retia ReDAT eXperience naudojant Retia ReDAT API. Prieigą prie aplikacijų programavimo sąsaja (angl. Application Programming Interface) paremtos funkcijos, leidžiančios prijungti nuorodą į konkretų įrašą prie trečiųjų šalių programinės įrangos vartotojo sąsajų, taip pat leidžiančią perklausyti ir atsisiųsti arba tik perklausyti įrašą naudojant trečiųjų šalių aplikacijas iš ReDAT serverio tiekėjui suteiks Perkančioji organizacija. Nepertraukiamą balso įrašų perklausymo programine įrangos veikimą integravimo metu turi užtikrinti tiekėjas.

66.       Esminiai ieškovės argumentai, kuriais ji grindžia šių Techninės specifikacijos reikalavimų neteisėtumą, yra dėl integracijos sąsajų – ieškovė nurodo, kad kadangi tiekėjas UAB „InnoForce“ BPC yra įdiegęs skambučių skirstymo programinę įrangą Unify OpenScape ContactCenter V9, taip pat balso įrašų perklausymo programinę įrangą Retia ReDAT eXperience, tai šiam tiekėjui žinomos sąsajų techninės savybės, todėl šis tiekėjas įgis konkurencinį pranašumą.

67.       Pirmosios instancijos teismas atmetė ieškovės reikalavimus, konstatavęs, kad ginčijami Techninės specifikacijos reikalavimai nustatyti atsižvelgiant į objektyvius perkančios organizacijos poreikius ir Pirkimo objekto specifiką. Tokią teismo išvadą dėl Techninės specifikacijos 183 punkto teisėjų kolegija vertina kaip nepagrįstą.

68.       Iš Techninės specifikacijos sąlygų matyti, kad perkančioji organizacija šiuo metu naudoja skambučių skirstymo programinę įrangą Unify OpenScape ContactCenter V9, ir Pirkimu siekiama perkamą programinę įrangą integruoti su šia turima programine įranga. Ginčijamose Techninės specifikacijos sąlygose nurodyta, kad tai turi būti daroma naudojant OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajas, o prieiga prie SDK sąsajų, jų dokumentacijos turi pasirūpinti tiekėjas. Pirmosios instancijos teismas nustatė, kad Unify OpenScape ContactCenter V9 programinę įrangą atsakovas įsigijo pagal 2019 m. rugpjūčio 22 d. pirkimo sutartį, sistemą įdiegė tiekėjas UAB „InnoForce“.

69.       BPC byloje teikė paaiškinimus, kad jis neturi OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajų, todėl reikalaujama, kad jomis pasirūpintų tiekėjas. Dėl šios ir kitų Pirkimo sąlygų nuostatų perkančioji organizacija numato ilgesnį nei įprastai pasiūlymų pateikimo terminą, kad tiekėjai turėtų pakankamai laiko pasiruošti pasiūlymų pateikimui, pasitelkti reikalingus ūkio subjektus, jeigu patys nėra pajėgūs įgyvendinti Pirkimo sąlygose keliamus reikalavimus. BPC taip pat nurodė, kad kreipėsi į skambučių skirstymo programinės įrangos Unify OpenScape ContactCenter V9 gamintoją Unify, kurios atstovas informavo, kad Europos Sąjungoje Unify turi 13 Unify OpenScape ContactCenter sertifikuotų partnerių.

70.       Pagal VPĮ 37 straipsnio 3 dalį, techninė specifikacija turi užtikrinti konkurenciją ir nediskriminuoti tiekėjų. Šiuo atveju Techninės specifikacijos reikalavimu tiekėjui pasirūpinti prieiga prie OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajų ir jų dokumentacijos ribojama konkurencija, todėl perkančioji organizacija turi pateikti įtikinamą tokio nustatyto reikalavimo pagrindimą. Vis dėlto, teisėjų kolegijos vertinimu, minėti BPC paaiškinimai nepagrindžia nustatyto reikalavimo pagrįstumo. Šiuo atveju atsakovas BPC nepagrindė, kokias sąlygas gamintojas Unify kelia sąsajų gavimui, ar tokias sąsajas gali suteikti tik pats gamintojas, ar užsakovai, įdiegę skambučių skirstymo programinę įrangą Unify OpenScape ContactCenter V9, tokių sąsajų negauna ir negali jų naudoti. Nors, kaip minėta, skambučių skirstymo programinę įrangą Unify OpenScape ContactCenter V9 atsakovas įsigijo pagal 2019 m. rugpjūčio 22 d. pirkimo sutartį, o sistemą įdiegė tiekėjas UAB „InnoForce“, tačiau atsakovas BPC nepagrindė, jog pagal šią sutartį jis iš tiesų neįgijo prieigos prie OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajų ir jų dokumentacijos. Abejones, ar atsakovas BPC neįgijo prieigos prie sąsajų ir dokumentacijos, sustiprina ir tai, kad pagal Techninės specifikacijos 201 punktą, perkančioji organizacija suteiks tiekėjui sąsajas, leidžiančias integruoti perkamą programinę įrangą su balso įrašų perklausymo programine įranga Retia ReDAT eXperience. Tokia aplinkybė patvirtina, kad IT rinkoje programinės įrangos gamintojai iš principo gali suteikti sąsajas, reikalingas tokios įrangos integracijai, užsakovams. Taigi, atsakovams konkrečiais įrodymais nepagrindus, kad jie neturi OpenScape ContactCenter V9 sąsajų arba pagal gamintojo nustatytas sąlygas negali tokių sąsajų pateikti integraciją vykdantiems tretiesiems asmenims, nustatytas Techninės specifikacijos reikalavimas vertintinas kaip nepagrįstas.

71.       Tokią teisėjų kolegijos išvadą patvirtina ir teismo ekspertų O. V. bei T. J. išvados. Ekspertas O. V., atsakydamas į 62 klausimą, nurodė, kad prieigą ir teisę naudotis SDK, kaip ir API, suteikia programinės įrangos gamintojas ir jis nustato, kas, kaip ir kokiomis sąlygomis gali naudotis gamintojo sukurtais API ir SDK produktais. Ekspertas T. J., atsakydamas į 62 klausimą, išanalizavęs gamintojo interneto puslapyje pateiktą informaciją, o taip pat viešai skelbiamus duomenis apie sutarties, pagal kurią BPC pirko programinę įrangą Unify OpenScape ContactCenter V9, sąlygas, nustatė, kad gamintojas, prekiaudamas produktu, siūlo SDK sprendimus klientams, todėl be gamintojo šiuos SDK sprendimus turi turėti klientai ir konkrečiai BPC. Be to, kaip nurodė ekspertas, be gamintojo ir kliento, SDK sąsajas gali turėti ir gamintojo autorizuoti atstovai, kurie diegė ar atnaujina šią programinę įrangą.    

72.       Pažymėtina, kad ekspertas O. V., atsakydamas į 62 klausimą, nurodė, kad daugeliu atvejų verslo programinės įrangos paketų, saugai ar veiklai kritinių sistemų SDK ir API yra prieinami visiems sertifikuotiems, atitinkamai apmokytiems programinės įrangos gamintojo partneriams. Net jei SDK ir API sąsajų dokumentacija pateikiama perkančiosioms organizacijoms, joms dažniausiai nėra suteikiama teisė perduoti tokią dokumentaciją trečiųjų šalių atstovams. Vis dėlto, tokias eksperto išvadas teisėjų kolegija vertina kaip pernelyg abstrakčias ir nesusietas su konkretaus gamintojo Unify taikomomis sąlygomis. Taigi, šios eksperto išvados nepaneigia, kad  BPC įgijo prieigą prie OpenScape Contact Center Enterpise Software Development Kit (SDK) sąsajų ir jų dokumentacijos.

73.       Kartu teisėjų kolegija pažymi, kad iš esmės analogiškų išvadų dėl tiekėjams taikomo reikalavimo pasirūpinti skirtingų sistemų integracijai reikalingomis sąsajomis neteisėtumo Lietuvos apeliacinis teismas priėjo ir 2021 m. gegužės 13 d. sprendime civilinėje byloje Nr. e2A-434-302/2021.

74.       Ieškovė iš esmės analogiškais pagrindais ginčija ir Techninės specifikacijos 199.6 papunktį, nustatantį, kad programinė įranga privalo priimti ir registruoti pajėgų vienetų buvimo vietos koordinates iš TETRA radijo ryšio terminalų, gaunamas LIP formatu. Programinė įranga privalo gebėti dekoduoti skirtingus LIP informacijos formatus, gaunamus iš skirtingų gamintojų TETRA radijo ryšio terminalų (Motorola Solutions, Sepura ir pan.). PT pajėgų vienetų koordinatės gaunamos iš: <…> b) TETRA judriųjų terminalų per Motorola Solutions gamintojo Dimetra radijo ryšio tinklo API. Tiekėjas yra atsakingas už prieigos prie Motorola Solutions Dimetra radijo ryšio tinklo API gavimą ir naudojimą.

75.       Teisėjų kolegijos vertinimu, pastaroji Techninės specifikacijos sąlyga, numatanti pareigą tiekėjui pasirūpinti prieiga prie Motorola Solutions DIMETRA radijo ryšio tinklo API gavimu, pirmosios instancijos teismo buvo pagrįstai pripažinta teisėta. Tokią teisėjų kolegijos išvadą lemia skirtingos faktinės aplinkybės, nei aptariant programinės įrangos Unify OpenScape ContactCenter V9 sąsajas.

76.       Pirmiausia, pastebėtina, kad, kaip matyti iš Techninės specifikacijos duomenų, skaitmeninis mobiliojo radijo ryšio tinklas (tinklo įranga DIMETRA (versija 9.0.2), gamintojas Motorola Solutions) yra Lietuvos viešojo saugumo ir pagalbos tarnybų tinklas, jį valdo ne atsakovai, bet Vidaus reikalų ministerija, o šį tinklą naudoja BPC, priešgaisrinės gelbėjimo pajėgos, policija, VšĮ Panevėžio greitosios medicinos pagalbos stotis, Valstybės sienos apsaugos tarnyba ir kiti naudotojai. Bendras tinkle registruotų radijo ryšio terminalų skaičius viršija 11 tūkstančių. Kaip minėta, Vidaus reikalų ministerija 2020 m. gegužės 12 d. rašte pateikė nuomonę, kad Pirkimo sąlygose būtina numatyti, jog tiekėjas turi būti įgaliotas trečiųjų šalių aplikacijų (informacinių sistemų) diegimo su Motorola DIMETRA radijo ryšio tinklu atstovas (partneris, diegėjas (angl. developer). 

77.       Antra, sutiktina su pirmosios instancijos teismo išvada, kad Motorola Solutions DIMETRA 9.0.2 sąsajos (API) ir dokumentacija, kurios nurodytos specifikacijos 11 priede ir kurias privalės naudoti tiekėjas integruodamas savo pasiūlytą programinę įrangą su tinklu, yra uždaro pobūdžio – platinamos tik gamintojo, reikalauja atitinkamos kvalifikacijos jas naudojant, todėl prieiga prie jų suteikiama kompanijos Motorola Solutions nurodytomis sąlygomis, kad naudojant sąsajas integracijoms nebūtų pažeistas Motorola DIMETRA tinklų saugumas, vientisumas ir veikimo nenutrūkstamumas. Šią pirmosios instancijos teismo išvadą patvirtina ir Techninės specifikacijos 199.13 papunktyje nurodytame gamintojo Motorola interneto tinklapyje skelbiama informacija, pagal kurią prisijungti prie Motorola Solutions aplikacijų vystymo programos galima tik užpildžius atitinkamą prašymą ir atitinkant gamintojo nurodytus patirties bei kitus kriterijus.

78.       Taigi, kitaip nei programinės įrangos Unify OpenScape ContactCenter V9 atveju, atsakovai byloje įrodė, jog gamintojas Motorola klientams nesuteikia prieigos ir teisės naudotis API bei jos perduoti tretiesiems asmenims. Šiuo konkrečiu atveju šią aplinkybę patvirtina ir gamintojo Motorola atstovo M. I. 2020 m. balandžio 22 d. elektroninis laiškas. Nors ieškovė ir ekspertas T. J. ekspertizės akte (atsakant į 65 klausimą) nurodė, kad diegiant Motorola Solutions DIMETRA radijo ryšio tinklą buvo reikalaujama atviro tipo sąsajų, tačiau aukščiau aptarti įrodymai patvirtina, jog Lietuvos viešojo saugumo ir pagalbos tarnybų tinklo valdytojas Vidaus reikalų ministerija neturi teisės sąsajų perduoti trečiųjų šalių atstovams.

79.       Techninės specifikacijos 201 punktas aptariamu aspektu pirmosios instancijos teismo pagrįstai buvo pripažintinas teisėtu, nes šiame punkte numatyta, kad prieigą prie Retia ReDAT API sąsajų tiekėjui suteiks perkančioji organizacija.

80.       Ieškovė Techninės specifikacijos 183 ir 201 punktus ginčijo ir dėl nustatyto reikalavimo tiekėjui užtikrinti nepertraukiamą BPC telefoninių stočių bei balso įrašų perklausymo programine įrangos veikimą integravimo metu. Pirmosios instancijos teismas netenkino šio ieškovės reikalavimo, pažymėjęs, kad atsakovai pagal savo veiklos pobūdį pagrįstai reikalauja, jog tiekėjas būtų atsakingas tiek už nepertraukiamą telefoninių stočių darbą, tiek ir už balso įrašų perklausymo programinės įrangos veikimą integravimo metu. Ieškovė apeliaciniame skunde neginčija šios pirmosios instancijos teismo išvados, todėl teisėjų kolegija dėl jos pagrįstumo nepasisako.  

81.       Techninės specifikacijos 5 punktas numato, kad tiekėjas turi įdiegti programinę įrangą į du duomenų centrus Vilniaus mieste taip, kad būtų užtikrintas įdiegtos sistemos veiklos tęstinumas įvykus sutrikimams, automatiškai įdiegtą sistemą perjungiant iš pagrindinio duomenų centro į rezervinį duomenų centrą, užtikrinti po perjungimo atsarginį duomenų kopijavimą. Perkančioji organizacija yra atsakinga už duomenų centrų infrastruktūros suteikimą. Techninės specifikacijos 320 punktas nustato, kad tiekėjas per 1 mėnesį nuo sutarties pasirašymo dienos turi pateikti perkančiajai organizacijai dviejų duomenų centrų, kuriuose bus diegiama tiekėjo siūloma programinė įranga, serverinės techninės ir programinės įrangos kiekius, šios įrangos parametrus ir specifikacijas. Remiantis Techninės specifikacijos 321 punktu, duomenų centrų serverinės techninė ir programinė įranga turi apimti šiuos duomenų centrų komponentus: a) fizinių serverių ir jų operacinių sistemų, jų licencijų ir konfigūracijų specifikacijas; b) fizinių duomenų talpyklų jų licencijų ir konfigūracijų specifikacijas; c) virtualizacijos programinius įrankius ir jų licencijų ir konfigūracijų specifikacijas; d) apkrovos išlyginimo įrenginių (angl. Load Balancer), jų licencijų ir konfigūracijų specifikacijas. Pirkimo sąlygų 323 punktas nustato, kad pagal tiekėjo pateiktus kiekius, parametrus ir specifikaciją serverinę įrangą kartu su operacinių sistemų ir virtualizavimo įrankių licencijomis įsigys ir duomenų centrą naudojimui paruoš perkančioji organizacija.

82.       Techninės specifikacijos 322 punktas nustato, kad serverinės įrangos kiekiai, šios įrangos parametrai ir specifikacijos turi būti suformuluoti atsižvelgiant į: a) šioje specifikacijoje pateiktą kiekybinę ir kitą informaciją; b) perkančiosios organizacijos orientacinį biudžetą specifikuotai įrangai – 500.000 Eur su PVM; c) tai, kad tiekėjo siūloma programinė įranga įdiegta serverinėje įrangoje veiktų sklandžiai, be trikdžių ir vėlavimų. Ieškovė nagrinėjamoje byloje ginčija šio punkto b papunktyje nustatytą reikalavimą serverinės įrangos kiekius, parametrus ir specifikacijas suformuluoti atsižvelgiant į perkančiosios organizacijos orientacinį biudžetą. Ieškovės tvirtinimu, sąlyga dėl orientacinio biudžeto yra nepakankamai apibrėžta, nes nepateikti minimalūs kiekio ar kokybės kriterijai įrangai, tik numatytas jos orientacinis biudžetas, taip pat nėra aišku, koks kainos intervalas atsakovei priimtinas.

83.       Pirmosios instancijos teismas netenkino ieškovės reikalavimo nurodęs, kad ginčijama Pirkimo sąlyga yra susijusi su viešojo pirkimo sutarties vykdymu ir nėra tiesiogiai susijusi su nagrinėjamo Pirkimo sąlygomis, todėl netrukdo tiekėjams pateikti pasiūlymą Pirkime, o perkančiajai organizacijai įvertinti tiekėjų pasiūlymus. Ieškovės įsitikinimu, teismas netinkamai įvertino ginčijamą Techninės specifikacijos sąlygą, kadangi ji nepakankamai apibrėžta, Techninėje specifikacijoje nurodžius tik orientacinį biudžetą, tačiau nenustačius jokių minimalių įrangos kiekių ar charakteristikų, tiekėjai gali pasiūlyti brangiausią, bet nebūtinai būtinų ar geriausių charakteristikų įrangą. Ieškovės nuomone, teismo motyvas, kad aptariamas reikalavimas susijęs su Pirkimo sutarties vykdymu, nepatvirtina šio reikalavimo teisėtumo, kadangi tiekėjai turi teisę ginčyti visus Pirkimo dokumentus, įskaitant ir pirkimo sutarties nuostatas.

84.       Teisėjų kolegija pritaria pirmosios instancijos teismo vertinimui, kad ginčijama Techninės specifikacijos sąlyga yra nustatyta teisėtai. Kaip matyti iš Techninės specifikacijos 5, 320 – 321, 323 ir kitų punktų, ieškovė siekia, kad tiekėjas parengtų dviejų duomenų centrų serverinės techninės ir programinės įrangos kiekius, parametrus ir specifikaciją, kurios pagrindu bus atliekamas tokios įrangos pirkimas. Būtent šiuose duomenų centruose, kuriems bus perkama konkreti techninė ir programinė įranga, bus diegiama tiekėjo siūloma programinė įranga, todėl ne perkančioji organizacija, bet tiekėjas geriausiai galės įvertinti atitinkamos serverinės įrangos kiekius, parametrus, reikalingas savybes. Taigi, perkančioji organizacija pagal Pirkimo pobūdį negali nurodyti minimalių įrangos kiekių ar charakteristikų, kaip reikalauja ieškovė. Kita vertus, pažymėtina, kad tam tikra kiekybinė ir kita informacija dėl serverinės įrangos Techninėje specifikacijoje yra nurodyta (žr., pvz., 321 punktą, kuriame apibūdinti duomenų centrų komponentai).

85.       Teisėjų kolegijos manymu, perkančiosios organizacijos nurodytas orientacinis biudžetas, priešingai nei teigia ieškovė, užtikrina skaidrumo ir racionalaus lėšų panaudojimo principą, kadangi tiekėjas yra informuojamas apie perkančiajai organizacijai priimtiną serverinės įrangos kainos ribą. To nepadarius, atsirastų neapibrėžtumas dėl galimos siūlyti serverinės įrangos kainos, nukentėtų perkančiosios organizacijos interesai, kadangi tiekėjai būtų laisvi siūlyti ir itin brangią serverinę įrangą. Kita vertus, Pirkimo sutarties vykdymo metu tiekėjas bet kuriuo atveju privalės pagrįsti reikalingos įrangos charakteristikas, kiekius ir kainas, todėl jei dėl objektyvių priežasčių nebus galima pasiūlyti įrangos, atitinkančios orientacinį biudžetą, dėl tokios aplinkybės turės būti sprendžiama Pirkimo sutartyje nustatyta tvarka. Dėl išdėstytų argumentų teisėjų kolegija konstatuoja, kad pirmosios instancijos teismas tinkamai įvertino ginčijamos sąlygos teisėtumą.

Dėl bylos procesinės baigties ir Pirkimo nutraukimo

86.       Teisėjų kolegija, apibendrindama išdėstytus argumentus, konstatuoja, kad pirmosios instancijos teismas netinkamai taikė VPĮ 47 straipsnio 1 dalies nuostatas ir jas aiškinančią kasacinio teismo praktiką bei netinkamai įvertino byloje surinktus įrodymus dėl ginčijamų kvalifikacijos reikalavimų nustatymo teisėtumo. Pirmosios instancijos teismas, nors tinkamai įvertino byloje surinktus įrodymus ir teisingai taikė VPĮ 37 straipsnio nuostatas, spręsdamas dėl Techninės specifikacijos 8 skyriaus 19 punkto, 199.6 papunkčio, 201 ir 322 punktų teisėtumo, tačiau  neteisingai taikė VPĮ 37 straipsnio nuostatas ir netinkamai įvertino byloje surinktus įrodymus, konstatuodamas Techninės specifikacijos 183 punkto teisėtumą. Todėl skundžiamas teismo sprendimas naikinamas ir priimamas naujas sprendimas, kuriuo Pirkimo sąlygų 14.2, 14.3.8 papunkčiai ir Techninės specifikacijos 183 punktas pripažįstami neteisėtais.

87.       Pirkimo procedūros negali būti toliau vykdomos pagal neteisėtomis pripažintas Pirkimo sąlygas. Kasacinis teismas yra išaiškinęs, kad kai teismas dėl pareikšto reikalavimo (atitinkamą pirkimo sąlygą bet kokiu VPĮ normų ar kitų teisės nuostatų pagrindu pripažįsta neteisėta, tik ieškinio patenkinimas – nepakankamas sprendžiant dėl perkančiosios organizacijos neteisėtų veiksmų padarinių. Tokiu atveju teismas privalo ex officio (savo iniciatyva) tokį pirkimą nutraukti nepriklausomai nuo pareikšto reikalavimo (Lietuvos Aukščiausiojo Teismo 2011 m. gegužės 24 d. nutartis civilinėje byloje Nr. 3K-3-249/2011). Dėl šių priežasčių priimant naują teismo sprendimą Pirkimas nutrauktinas.

Dėl bylinėjimosi išlaidų paskirstymo

88.       Apeliacinės instancijos teismui priėmus naują sprendimą, pakeičiamas bylinėjimosi išlaidų paskirstymas (CPK 93 straipsnio 5 dalis).

89.       Ieškovė savarankiškais pagrindais ginčijo 7 Pirkimo sąlygas, iš kurių apeliacinės instancijos teismas neteisėtomis pripažino 3, tuo būdu patenkindamas 42,86 proc. pareikštų reikalavimų.

90.       CPK 98 straipsnio 1 dalis nustato, kad šaliai, kurios naudai priimtas sprendimas, teismas priteisia iš antrosios šalies išlaidas už advokato ar advokato padėjėjo, dalyvavusių nagrinėjant bylą, pagalbą, taip pat už pagalbą rengiant procesinius dokumentus ir teikiant konsultacijas. Dėl šių išlaidų priteisimo šalis teismui raštu pateikia prašymą su išlaidų apskaičiavimu ir pagrindimu. Šios išlaidos negali būti priteisiamos, jeigu prašymas dėl jų priteisimo ir išlaidų dydį patvirtinantys įrodymai nepateikti iki bylos išnagrinėjimo iš esmės pradžios.

91.       Nagrinėjamu atveju ieškovė 2020 m. spalio 21 d. prašymu pirmosios instancijos teismo prašė priteisti jai 26 281,66 Eur išlaidas advokato teisinei pagalbai apmokėti pagal pateiktas PVM sąskaitas faktūras. Tačiau iki bylos išnagrinėjimo iš esmės pradžios ieškovė teismui nepateikė šių sąskaitų apmokėjimą patvirtinančių dokumentų. Ieškovė 2020 m. spalio 21 d. prašyme pažymėjo, kad sąskaitos dar nėra apmokėtos. Esant tokioms aplinkybėms, ieškovės 2020 m. spalio 21 d. prašyme nurodyta išlaidų advokato teisinei pagalbai apmokėti suma nepriteistina.

92.       Kaip teisingai nurodė ieškovė apeliaciniame skunde, atsakovas BPC iki bylos išnagrinėjimo iš esmės pradžios pirmosios instancijos teismui nepateikė prašymo dėl išlaidų advokato teisinei pagalbai apmokėti priteisimo ir nepateikė išlaidas patvirtinančių įrodymų. Atsakovas BPC tokį prašymą ir išlaidas patvirtinančius įrodymus pateikė pirmosios instancijos teismui jau po bylos išnagrinėjimo iš esmės, 2020 m. lapkričio 10 d. Atsakovas prašyme nenurodė jokių objektyvių aplinkybių, dėl kurių jis negalėjo pateikti prašymo ir išlaidas patvirtinančių įrodymų laiku. Todėl atsakovo 2020 m. lapkričio 10 d. prašyme nurodyta išlaidų advokato teisinei pagalbai apmokėti suma nepriteistina.

93.       Ieškovė už ieškinį sumokėjo 2 288 Eur, už atskirąjį skundą dėl pirmosios instancijos teismo  nutarties dėl laikinųjų apsaugos priemonių sumokėjo 38 Eur, viso patyrė 2 326 Eur žyminio mokesčio išlaidų. Proporcingai patenkintai ieškinio reikalavimų daliai, ieškovei iš atsakovų lygiomis dalimis priteistina 996,92 Eur žyminio mokesčio (2 326 × 42,86 / 100).

94.       Ieškovė už apeliacinį skundą sumokėjo 2 250 Eur žyminio mokesčio. Taip pat ieškovė sumokėjo 1 000 Eur avanso už ekspertizę ir 400 Eur avansą už ekspertų apklausą teismo posėdyje. Ieškovė kartu su 2021 m. sausio 11 d. ir 2021 m. birželio 9 d. prašymais pateikė duomenis, kad apeliacinės instancijos teisme patyrė 32 580,01 Eur išlaidas advokato teisinei pagalbai apmokėti. Teisėjų kolegija, atsižvelgusi į tai, kad toks išlaidų dydis viršija Rekomendacijose dėl civilinėse bylose priteistino užmokesčio už advokato ar advokato padėjėjo teikiamą pagalbą maksimalaus dydžio, patvirtintose Lietuvos Respublikos teisingumo ministro 2004 m. balandžio 2 d. įsakymu Nr. 1R-85, nustatytus rekomenduojamus priteisti dydžius, taip pat atsižvelgusi į bylos sudėtingumą, apeliacinės instancijos teisme atliktų procesinių veiksmų kiekį ir pobūdį, vertina, kad pagrįsta ieškovės patirtų išlaidų advokato teisinei pagalbai suma sudaro 10 000 Eur. Taigi, ieškovė apeliacinės instancijos teisme patyrė bendrą 13 650 Eur pagrįstų bylinėjimosi išlaidų sumą (2 250 + 1 000 + 400 + 10 000). Proporcingai patenkintai ieškinio reikalavimų daliai, ieškovei iš atsakovų lygiomis dalimis priteistina 5 850,39 Eur suma (13 650 × 42,86 / 100).  

95.       Atsakovas BPC apeliacinės instancijos teisme patyrė tokias išlaidas – sumokėjo 1 000 Eur avansą už ekspertizę ir patyrė 4 401,37 Eur išlaidų advokato teisinei pagalbai apmokėti, viso patyrė 5 401,37 Eur bylinėjimosi išlaidas. Proporcingai atmestai ieškinio reikalavimų daliai, atsakovui BPC iš ieškovės priteistina 3 086,34 Eur suma (5 401,37 × 57,14 / 100).  

Lietuvos apeliacinio teismo Civilinių bylų skyriaus teisėjų kolegija, vadovaudamasi Lietuvos Respublikos civilinio proceso kodekso 326 straipsnio 1 dalies 2 punktu, 331 straipsniu,

n u s p r e n d ž i a :

Vilniaus apygardos teismo 2020 m. lapkričio 18 d. sprendimą panaikinti ir priimti naują sprendimą.

Ieškovės uždarosios akcinės bendrovės „Dekbera“ ieškinį iš dalies patenkinti.

Pripažinti neteisėtomis viešojo pirkimo „Bendrojo pagalbos centro informacinės sistemos sukūrimas ir įdiegimas“, pirkimo Nr. 494812, 14.2, 14.3.8 papunkčių ir techninės specifikacijos 183 punktų sąlygas.

Viešąjį pirkimą „Bendrojo pagalbos centro informacinės sistemos sukūrimas ir įdiegimas“, pirkimo Nr. 494812, nutraukti.

Kitą ieškinio dalį atmesti.

Priteisti ieškovei uždarajai akcinei bendrovei „Dekbera“ (juridinio asmens kodas 123502493) lygiomis dalimis iš atsakovų Bendrojo pagalbos centro (juridinio asmens kodas 188787474) ir Priešgaisrinės apsaugos ir gelbėjimo departamento prie Vidaus reikalų ministerijos (juridinio asmens kodas 188601311) 6 847,31 Eur (šešis tūkstančius aštuonis šimtus keturiasdešimt septynis eurus 31 ct) bylinėjimosi išlaidų.

Priteisti atsakovui Bendrajam pagalbos centrui (juridinio asmens kodas 188787474) iš ieškovės uždarosios akcinės bendrovės „Dekbera“ (juridinio asmens kodas 123502493)  3 086,34 Eur (tris tūkstančius aštuoniasdešimt šešis eurus 34 ct) bylinėjimosi išlaidų.  

Teisėjai                                                                        Marius Bajoras

Dalia Kačinskienė

Agnė Tikniūtė