Podmínky použití JŘBU

Zadavatel postupem v rámci JŘBU nijak neoznamuje zadávací řízení ve věstníku veřejných zakázek a oslovuje omezený okruh potenciálních dodavatelů, případně pouze jednoho dodavatele. JŘBU lze využít jak na nadlimitní, tak na podlimitní veřejné zakázky. Důvody pro zadávací řízení formou JŘBU a jejich dílčí podmínky jsou v zákoně stanoveny taxativně a jak ukazuje výklad ÚOHS a soudů, není možné aplikovat tyto podmínky extenzivně. Prokázat splnění všech podmínek použití JŘBU je zcela na zadavateli a lze doporučit v dokumentaci k veřejné zakázce, aby byly dostatečně popsány. Podmínky pro JŘBU musí být splněny ve vztahu k celému předmětu veřejné zakázky a nikoliv jen k části. Nicméně i zde je třeba podotknout, že není možné dělit veřejné zakázky, tak aby jejich hodnota klesla pod právním předpisem stanovené limity. Stejně tak může zde být technologická závislost hlavního softwarového plnění veřejné zakázky. V praxi se lze setkat i na nezbytnost spojení různých plnění z důvodů sjednaných dotačních podmínek.

Nejčastějšími důvody pro užití JŘBU při zadávání veřejných zakázek na dodávky softwaru a souvisejícího hardwaru jsou dle § 63 odst. 3 zákona o zadávání veřejných zakázek (dále jen „ZZVZ“):

a) Důvody krajní nouze

Obecným důvodem pro použití JŘBU je případ, kdy je to nezbytné v důsledku krajně naléhavé okolnosti, kterou zadavatel nemohl předvídat a ani ji nezpůsobil, a nelze dodržet lhůty pro otevřené řízení, užší řízení nebo jednací řízení s uveřejněním. Zde si lze představit neočekávané ukončení servisní smlouvy na provoz informačního systému bez přístupu zadavatele ke zdrojovému kódu, ukončení licenční smlouvy ze strany dodavatele, existenční problémy dodavatele, resp. závažné neplnění servisní smlouvy dodavatelem. Všechny tyto situace vytvářejí stav krajní nouze u zadavatele, který je nucen okamžitě zabezpečit fungování softwaru. U velkých informačních systémů takový stav může ohrozit samotné fungování zadavatele, zvlášť pokud nedisponuje zdrojovými kódy. Je evidentní, že příprava nového zadávacího řízení, dodržení lhůt při otevřeném řízení, užším řízení nebo jednacím řízení s uveřejněním, včetně případného námitkového řízení před ÚOHS, by trvala několik měsíců. Nepředvídatelnost takové situace a ohrožení fungování softwaru musí být objektivní.

Shrneme-li podmínky pro JŘBU z těchto důvodů, pak musí:

• se jednat o krajně naléhavý případ,
• který zadavatel nezpůsobil svým jednáním, a
• zadavatel jej nemohl předvídat, a
• z časových důvodů není možné zadat veřejnou zakázku v jiném druhu zadávacího řízení.

b) Technické důvody

Technické důvody mohou způsobit vyloučení hospodářské soutěže a nemožnost zadání veřejné zakázky jiným postupem a současně jejího splnění jiným dodavatelem. Typickými technickými důvody jsou nutnost kompatibility s původním softwarem nebo hardwarem, kdy je splnění veřejné zakázky jediným dodavatelem v souladu s principy 3E (hospodárnost, efektivnost a účelnost), neboť není ekonomicky únosné a účelné pořizovat nový software či hardware. Příkladem může být také inkompatibilita datového formátu s jiným softwarem, resp. přílišná časová a finanční nákladnost migrace předpokládající také většinou součinnost dosavadního dodavatele. Podle rozsudku Nejvyššího správního soudu ze dne 11. 1. 2013, čj. 5 Afs 42/2012-53, platí že: „Rovněž technické důvody, které má citované ustanovení na mysli, mohou spočívat např. v požadavku zadavatele na zajištění kompatibility, v požadavku odůvodněném také technickými okolnostmi, pro které by plnění od jiného dodavatele vyvolalo nepochybně vyšší náklady nebo značné riziko nefunkčnosti již pořízeného plnění (zde informačního systému). Důvodem pro aplikaci tohoto ustanovení je skutečný a prokazatelný stav technické neslučitelnosti či provozních problémů, které by vznikly z důvodu změny dodavatele.“ Zda opravdu technické důvody jsou oprávněným důvodem pro užití JŘBU může následně stanovit až znalec při přezkoumávání postupu zadavatele.

c) Licenční důvody

Licenční důvody spočívají obvykle v předchozí smluvní úpravě licencí stávajícího softwaru, přičemž licenční podmínky zakazují úpravy, rozšiřování, vývoj či servis softwaru třetí osobou než původním dodavatelem softwaru. U softwaru zhotoveného pro zadavatele na míru by mělo být v licenčních podmínkách upraveno, aby zadavatel či třetí osoba měli možnost upravovat software, což předpokládá předání zdrojových kódů zadavateli. Pakliže toto oprávnění zadavatel mít nebude, nastává situace tzv. vendor lock-in omezující zadavatele při dalším rozvoji či servisu softwaru. Tento typ softwaru na míru je obvykle licencován pod výhradní licencí, resp. dochází k převodu výkonu autorských práv. Pro další vývoj a servis je rovněž možné ze strany zadavatele využití institutu tzv. escrow, tj. úschovy zdrojových kódů.

Nevýhradní licence, pro které není typické předávání zdrojových kódů, se vztahují k softwaru hromadně distribuovanému ze strany výrobce. Software pod nevýhradní licencí je naopak od softwaru na míru s výhradní licencí podstatně ekonomicky výhodnější na pořízení. Nelze tak obviňovat automaticky zadavatele později, že si nezajistil možnost zásahu do zdrojového kódu či výhradní licenci s tímto právem, pokud mu jeho situace u původní veřejné zakázky v souladu se shora uvedenými principy 3E toto neumožňovala.

Samozřejmě v praxi se objevují i kombinace obojího, kdy jádro softwaru je licencováno nevýhradně, kdežto jednotlivé moduly jsou upravovány na základě specifických požadavků zadavatele.

Každopádně zadavatel, který nemá k dispozici zdrojové kódy a nechce-li pořizovat zcela nový software, by se měl pokusit před vypsáním nové zakázky o převod zdrojových kódů od dosavadního dodavatele. Lze však usuzovat, že dosavadní dodavatel se bude takovému převodu bránit, vzhledem k tomu, že je zvýhodněn oproti konkurenci. Jiná situace nastává, kdy na straně dodavatelů softwaru je mnohem víc subjektů, kteří jsou pověření distribucí a také i úpravami softwaru nadnárodními výrobci. Zde hospodářská soutěž existuje a JŘBU je vyloučeno.

Z uvedeného plyne, že veřejná zakázka, jejímž předmětem je úprava, vývoj či servis zadavatelem dosud užívaného softwaru, může být bez práva zadavatele k úpravám zdrojového kódu, splněna pouze jedním dodavatelem. Další podmínkou pro využití postupu dle JŘBU je, že současně nelze využít jiného postupu (k tomuto viz výklad níže) a zadavatel nestanovil zadávací podmínky veřejné zakázky s cílem vyloučit hospodářskou soutěž, tzn. že nebyl nastolen samotným zadavatelem stav exkluzivity.

d) Důvody rozšíření původní dodávky

Dalším důvodem pro použití JŘBU je potřeba zadavatele na tzv. dodatečné dodávky k původnímu plnění předchozí veřejné zakázky, které jsou určeny jako částečná náhrada předchozího softwaru nebo jako rozšíření stávajícího rozsahu softwaru. Předpokladem je, že by změna dodavatele nutila zadavatele pořizovat software s odlišnými technickými vlastnostmi, což by mělo za následek neslučitelnost s původním plněním nebo by znamenala nepřiměřené technické obtíže při provozu a údržbě stávajícího softwarového řešení. Podstatnou podmínkou tohoto důvodu pro JŘBU je časové omezení realizace dodatečných dodávek, a to lhůtou nejdéle 3 roky od uzavření původní smlouvy, pokud delší doba není odůvodněna zvláštními okolnostmi.

Nemožnost jiného dodavatele a postupu

U technických a licenčních důvodů pro užití JŘBU je ovšem dána jeho nepřípustnost tehdy, kdy veřejnou zakázkou požadované plnění přímo není závislé (technicky a licenčně) na dosavadním softwaru a lze objektivně jej dodat třetí osobou.

Zákon vedle naplnění ostatních podmínek zákona podmiňuje užití JŘBU tím, že není možný jiný postup. Mám za to, že se nejedná pouze o jiné zadávací řízení, ale i to, že lze cíle sledovaného veřejnou zakázkou dosáhnout při dodržení principů 3 E (hospodárnost, efektivnost a účelnost) pořízením jiného srovnatelného softwarového řešení (přiměřená alternativa). To však bude často vyloučeno tím, že pořízení nového softwarové řešení bude:

• časově náročné, když vypsání a realizace veřejné zakázky na celkové softwarové řešení (nová analýza a zpracování zadávací dokumentace, otevřené řízení, datová migrace atd.) by znamenalo náročnost i několika let;
• podstatně ekonomicky náročnější než rozšíření stávajícího informačního systému, zejména pokud byl pořízen před nedávnou dobou či nákladně vyvíjen po dlouhou dobu;
• nést riziko nefunkčnosti či problematičnosti s neověřenou spolehlivostí nového softwaru či s migrací dat do nového informačního systému;
• narážet na odpor u stávajících uživatelů pro uživatelsky diskomfort při přechodu na nový systém, nutnost jejich zaškolení atd.;
• předpokládat pořízení dalšího hardwaru apod.

ÚOHS ve svém rozhodnutí ze dne 9. 6. 2014, č. j. ÚOHS-S108/2009/VZ-12162/2014/521/VSt vydaném v řízení se zadavatelem, který si neupravil smluvně právo zasahovat do zdrojových kódů, uvedl: „V případě, že by se zadavatel rozhodl realizovat předmětnou veřejnou zakázku bez využití již existujících programů vytvořených v rámci předchozích veřejných zakázek, jednalo by se sice o postup možný, avšak z ekonomického hlediska, značně nehospodárný a neefektivní, neboť by zadavatel pořizoval plnění, která již jednou zakoupil. V takovém případě by tedy sice byla zajištěna hospodářská soutěž a konkurenční prostředí mezi dodavateli, ale došlo by k nehospodárnému a neúčelnému vynakládání veřejných prostředků (zadavatel by platil za plnění, které již má a na něž již jednou veřejné prostředky vynaložil).“

Pro úplnost uvádím, že všechny skutečnosti odůvodňující použití JŘBU bude nucen prokázat zadavatel a lze doporučit, aby je učinil součástí svého rozhodnutí či zadávací dokumentace. Nadto je vhodné z pohledu zadavatele ekonomickou náročnost jiného řešení prokázat např. zjištěním cenových podmínek konkurenčních firem než dodavatele. Nicméně finanční náročnost pořízení nového softwarového řešení musí zadavatel hodnotit ve vztahu ke stávajícímu softwaru při porovnání výše počáteční investice, servisu, nákladů rozvoje, ostatních nákladů provozu a v neposlední řadě nákladů na přechod k novému dodavateli, včetně migrace.

Stav exkluzivity

K použití JŘBU není zadavatel oprávněn, pokud sám vytvořil exkluzivitu smluvní úpravou v rámci předchozí veřejné zakázky, když ve smlouvě chybí právo zadavatele či třetí osoby zasahovat do zdrojového kódu či zadavatel zdrojový kód nemá vůbec k dispozici. Zákon totiž automaticky nepřiznává takové oprávnění zadavateli při jeho výslovné absenci ve smlouvě. V těchto případech by se zkoumal účel původní smlouvy a také, zda se jedná o výhradní či nevýhradní licenci, software na míru (na objednávku) atd. Ke stavu exkluzivity se ÚOHS, krajské soudy a následně Nejvyšší správní soud, vyjadřovaly již několikrát. Stejně tak i Soudní dvůr EU svými rozhodnutími již stanovil mantinely pro výklad možností použití JŘBU. K exkluzivitě uvádím následující dvě rozhodnutí Nejvyššího správního soudu:

Exkluzivita vytvořená zadavatelem a protiprávní použití JŘBU byly konstatovány např. v kauze „Opencard“. Podle rozsudku Nejvyššího správního soudu ze dne 12. 5. 2016, čj. 1 As 256/2015-95 platí, že „jednací řízení bez uveřejnění lze využít, pokud jsou důvody pro jeho použití objektivní, tedy nezávislé na vůli zadavatele… Zadavatel se tak nemůže dovolávat existence pouhého jediného dodavatele (právně nebo fakticky) schopného realizovat předmět veřejné zakázky, pakliže sám tento „stav exkluzivity“ vytvořil, a to navíc teprve ve chvíli, kdy již není možné nastalou situaci dostupnými právními prostředky změnit… Omezení, díky němuž není možné využít jednací řízení bez uveřejnění, jestliže stav exkluzivity způsobil zadavatel sám, se plně vztahuje na situaci, kdy následnou veřejnou zakázku uzavírá zadavatelem zcela ovládaná právnická osoba.“ Současně Nejvyšší správní soud uzavřel, že s ohledem na objem investic do předmětného projektu se nejevilo jako pravděpodobné, že by zadavatel od rozvoje platformy bez dalšího upustil a vydal se zcela odlišným směrem.

Naopak exkluzivita není důvodem pro vyloučení JŘBU, pokud nebylo možné např. z důvodu nových potřeb zadavatele nebo technologického vývoje předvídat, že bude nutné zadání veřejné zakázky s předmětem, na který má být použito JŘBU. K tomuto se vyjádřil např. Nejvyšší správní soud ve svém rozsudku ze dne 11. 1. 2013, č. j. 5 Afs 42/2012 – 53, když uvedl: „V postupu žalobce není možno shledávat účelovost a úmysl obejití zákona o veřejných zakázkách při zadávání návazných veřejných zakázek. Původní veřejné zakázky zadával zadavatel prokazatelně, aniž by měl vědomí o tom, že v budoucnu mu vznikne potřeba zadat dotčené veřejné zakázky. Rovněž je třeba zdůraznit, že stav exkluzivity nebyl vytvořen zadavatelem a nevznikl samoúčelně jako v odkazovaných případech, ale byl přirozenou součástí předmětu plnění, resp. neoddělitelným důsledkem toho, že v rámci předmětu plnění vznikala autorská díla ve smyslu ustanovení § 2 autorského zákona.“

Neplatnost uzavřené smlouvy a sankce ze strany ÚOHS

ZZVZ umožňuje ze strany ÚOHS uložit tzv. zákaz plnění smlouvy uzavřené zadavatelem. U JŘBU se pro téměř nulovou míru transparentnosti konkurenční dodavatelé ani o probíhajícím zadávacím řízení nedozví. Navrhovatel návrh musí však doručit do jednoho měsíce od uveřejnění oznámení o uzavření smlouvy zadavatelem dle zákona. Smlouva na plnění veřejné zakázky se stává neplatnou z důvodu porušení ZZVZ pouze v případech, kdy ÚOHS uloží zákaz jejího plnění. ÚOHS musí podmínky JŘBU zkoumat pečlivě a musí být splněny všechny požadavky zákona na vyslovení zákazu plnění, přičemž existují výjimky pro které ÚOHS zákaz plnění nevysloví.

ÚHOS častěji ukládá za neoprávněný postup zadavatele formou JŘBU pokutu do výše 10 % ceny veřejné zakázky, maximálně do 20 mil. Kč, nelze-li celkovou cenu veřejné zakázky zjistit. Často se stává, že zadavatel u při realizaci JŘBU s uložením pokuty počítá, jelikož jiný postup by byl pro něj daleko časově a finančně náročnější. Pokud je soudně protiprávnost postupu zadavatele prokázána, pak vzniká otázka odpovědnosti za škodu. Dovozovat odpovědnost za škodu konkrétní osoby je u složitých veřejných zakázek připouštějících různých právní výklad velice problematické.

Jak z toho ven?

Pokud zadavatel se již ocitá v postavení, kdy musí z důvodu Vendor lock-in postupovat formou JŘBU a má v úmyslu se z této situace vyvázat, pak má v podstatě dvojí cestu. První je donutit stávajícího dodavatele, aby poskytl zadavateli zdrojové kódy k úpravám a to s právem i ve prospěch třetí osoby, což bude k tendenci dodavatele setrvat v obchodním vztahu či chránit své obchodní tajemství velmi problematické. Druhou cestou je vypsat novou veřejnou zakázku v otevřeném řízení bez vazby na stávající software, což někdy může být ze shora uvedených důvodů ekonomicky a časově náročné. Ani jedna z cest tedy není ideální.

Závěr

Z výše uvedeného textu vyplývá, že JŘBU je často důsledkem tzv. Vendor lock-in, který má svůj původ v předchozím nastavení licenčních podmínek, v technických důvodech, důvodech migrace dat či časové a finanční náročnosti na změnu. Použití JŘBU je právně přípustné jen z omezených důvodů při splnění všech zákonných podmínek, a to bez možnosti rozšiřujícího výkladu ze strany zadavatele. JŘBU by tak mělo být výjimečným postupem a zadavatel by se k němu měl odhodlat pouze po důkladné právní, technické a ekonomické analýze a měl by být schopen splnění všech podmínek prokázat.

JUDr. Lukáš Jansa, jansa@lawyer.cz Autor působí jako advokát v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři. Je spoluautorem odborné publikace „Softwarové právo“ a „Internetové právo“. Je členem Pracovní komise pro soukromé právo Legislativní rady vlády.