Specifika smluv v IT

Díla v IT jsou většinou vyvíjena a implementována na základě smlouvy o dílo nebo na základě inominátní smlouvy, obě podle obchodního zákoníku. Smlouvy o dílo v IT mají však svá specifika, která je nutné zohlednit, aby později nedocházelo ke sporům. Především je vždy nutné myslet na to, že počítačový program, který je zpravidla součástí díla, je-li původní v tom smyslu, že je autorovým vlastním duševním výtvorem, je autorským dílem na základě právní fikce podle autorského zákona. Většina informačních systémů tak má povahu jak děl (předmětů díla) ve smyslu obchodního zákoníku, tak i autorských děl ve smyslu autorského zákona. Důležité přitom je, že je-li počítačový program autorským dílem, není správné uvažovat o vzniku nebo převodu vlastnického práva objednatele k dílu, ale je třeba přemýšlet o licenčních ujednáních, na základě kterých vznikne objednateli majetkové právo dílo užívat.

U děl v IT je dále nutná zejména přesná specifikace díla, způsob provedení díla, dostatečný popis pravidel pro akceptaci (tj. předání a převzetí díla), úprava řešení otázky odevzdání a převzetí dokumentace, příslušná licenční ujednání a ustanovení o ceně díla a způsobu její platby. Protože jsou použitelná ustanovení obchodního zákoníku v zásadě dispozitivní (tj. možnost dohodou stran je pozměnit nebo vyloučit), je třeba klást důraz na precizní smluvní úpravu.

Podle dispozitivní zásady obchodního zákoníku zhotoviteli vzniká právo na zaplacení ceny díla až k okamžiku, co je dílo řádně provedeno, tj. kdy je provedeno bez jakýchkoliv vad a nedodělků[1]. Dílo má vady[2], jestliže provedení díla neodpovídá výsledku určenému ve smlouvě. Tato zásada neváže vznik nároku na zaplacení ceny díla na okamžik předání a převzetí díla mezi smluvními stranami, ale na ultimativní bezvadnost díla. Definitivní posouzení toho, zda je dílo v IT skutečně provedeno bez jakýchkoliv vad a nedodělků je přitom zpravidla téměř nemožné. Proto je vhodné v IT smlouvách sjednávat speciální akceptační mechanismy, ve kterých bude mimo jiné kladen důraz na okamžik předání a převzetí díla, než na nejistý a mnohdy problematický okamžik provedení díla.
 

Specifikace díla v IT

Základ eliminace problémů při předání a převzetí díla v IT spočívá ve smluvní specifikaci díla a v praxi se lze setkat s řadou odlišných přístupů. Rozhodující je především otázka rozsahu plnění a povaha představ objednatele a zhotovitele o tom, co má dílem být. Kamenem úrazu však někdy bývá užívání různorodé IT terminologie zhotovitelem a objednatelem. V této souvislosti je nutné zdůraznit, že projev vůle, který obsahuje výraz připouštějící různý výklad, třeba v pochybnostech vykládat k tíži strany, která jako první v jednání tohoto výrazu použila[3]. Strany by tak měly být při volbě terminologie obezřetné a co nejvíce jednoznačné. Cílem každé specifikace díla by mělo být co nejkonkrétnější určení vlastností díla s odkazem na objektivně měřitelné parametry. Co možná nejdetailnější specifikace je žádoucí i z toho důvodu, že při přílišné obecnosti by mohlo být v důsledku osobami rozhodujícími spor přistoupeno k řešení odkazující na vlastnosti obvyklé pro taková obdobná díla.[4] V některých případech jsou však informační systémy natolik specifické, že měřítko obvyklosti nemůže fungovat a spor bude vyřešen jen těžko spravedlivě.

V IT ale často není možné dosáhnout dostatečně konkrétní specifikace díla ještě před uzavřením smlouvy, protože v předsmluvní fázi je zhotoviteli kolikrát znám pouze seznam požadavků zákazníka, bez konkrétní znalosti prostředí, do kterého má být dílo implementováno. Naopak objednateli nejsou přesně známy vlastnosti funkcionalit zhotovitelem nabízeného informačního systému. Proto lze doporučit, aby bylo splnění smluvních povinností smluvních stran (předání a převzetí díla) vázáno na dohodnutá pravidla pro akceptaci.

V souvislosti s neznalostí prostředí, popř. neznalostí nabízeného řešení, se proto v implementačních smlouvách často nejdříve sjednává úvodní, tzv. analytická fáze. V této fázi se objednatel a zhotovitel fakticky podrobněji seznámí se svými představami o cílovém stavu a s technickými možnostmi nabízeného řešení v konkrétním implementačním prostředí. Strany v této fázi konkretizují vlastnosti díla a objednatel obvykle upřesňuje svoje požadavky na případné úpravy standardní funkcionality dodávaného IT produktu. Výsledek této analytické části se v praxi nazývá, kontrolní specifikace, blueprint, cílový koncept, či podobně.
 

Akceptační procedura

V kontrolní specifikaci se detailněji než ve smlouvě konkretizuje rozsah díla, stanovují se milníky provádění díla a upřesňují se akceptační kritéria. Aby mohla být pro obě smluvní strany kontrolní specifikace závazná, je ovšem nutné ji oběma stranami přijmout, proto by měla být již ve smlouvě stanovena pravidla pro samotnou akceptaci kontrolní specifikace. Pro tyto účely je rovněž vhodné sjednat důsledky, které mohou nastat v případech, kdy k takové akceptaci nedojde, a to ať už to bude z důvodu vzniklého na straně zhotovitele, či objednatele. Kontrolní specifikace, i když je vyhotovena za součinnosti objednatele, je zpravidla samostatným výstupem zhotovitele, který má pro objednatele hodnotu samu o sobě, neboť mu přináší nové technologické poznatky a ukazuje cestu možných řešení. Z toho důvodu se doporučuje, aby za takový výstup zhotovitele byla sjednána samostatné odměna, a to právě pro případ, že spolupráce stran bude po vyhodnocení kontrolní specifikace ukončena.

Součástí kontrolní specifikace bývá stanovení detailních akceptačních kritérií a pravidel akceptační procedury. Akceptační procedura má pro vyhodnocení úspěšnosti plnění smlouvy ze strany zhotovitele zcela zásadní význam. Po jejím úspěšném ukončení zpravidla dochází k formálnímu předání a převzetí díla. Předání a převzetí díla následně vyvolává, je-li tak sjednáno ve smlouvě, klíčové právní účinky, kterými jsou zpravidla nabytí licence k předmětnému dílu objednatelem a vznik nároku zhotovitele na zaplacení ceny díla.

V zákonné úpravě regulaci akceptační procedury z pochopitelných důvodů nenalezneme, proto rozhodujícího významu nabývá úprava smluvní. Akceptační proceduru lze chápat jako proces ověření určitých, smlouvou a případně též kontrolní specifikací, definovaných kritérií, na základě kterých je možné určit, zda dílo bylo provedeno v souladu se smlouvou a zda má požadované a sjednané vlastnosti. Takováto kritéria by měla být co možná nejvíce objektivní, neboť subjektivní kritéria jsou v případě sporu těžko přezkoumatelná a především účelově zneužitelná. Možnosti způsobů úpravy postupu při akceptační proceduře jsou různé. Zpravidla je prováděna za účasti zástupců obou smluvních stran, přičemž její výsledek je pak zachycen v akceptačním protokolu. Rovněž může být smluvními stranami sjednáno, že celou akceptační proceduru či její část provede nezávislá třetí osoba s příslušnou odborností. Takové řešení lze doporučit především u velkých projektů, na něž jsou kladeny vysoké nároky co do spolehlivosti díla a v nichž vzniká prostor pro spory mezi stranami. S takovou třetí osobou je zpravidla uzavřena smlouva o kontrolní činnosti, kterou se vykonavatel kontroly zavazuje za úplatu provést nestranně zjištění stavu určité věci nebo ověření výsledku určité činnosti a vydat o tom kontrolní osvědčení.[5] Smlouva o kontrolní činnosti by měla vedle podstatných náležitostí obsahovat především přesné určení rozsahu a způsobu vykonávané kontroly.

Pro samotný akceptační proces se pak v praxi často používá členění vad do několika typů (skupin), které mají pro akceptaci díla různé důsledky. Obecně lze rozdělit vady například na kritické, podstatné a ostatní[6], přičemž lze sjednat, že i přes výskyt některých vad zahrnutých do jedné či více z výše uvedených skupin (zpravidla nikoliv té s těmi nejzávažnějšími vadami) lze dílo či část díla akceptovat (s výhradami), a to se závazkem zhotovitele takové vady bez zbytečného odkladu odstranit. Důsledkem takového ujednání a následné úspěšné akceptace je pak řádné předání a převzetí díla. V opačném případě, kdy se naopak vyskytnou vady zásadní (v souladu s uvedeným členěním zařazené do skupiny kritických) lze sjednat, že takové dílo nebude považováno jako řádně dokončené, dokud nebudou jeho vady odstraněny tak, aby mohlo být akceptováno prostřednictvím sjednané akceptační procedury. Po odstranění takto závažných vad je pak nutné opakovat celou akceptační proceduru znovu, tentokrát však jen v té části díla, kde se vyskytla vada.

Pro zhotovitele je rovněž velice důležité se „ozbrojit“ proti případné pasivitě či bezdůvodnému odmítnutí akceptace objednatelem v rámci akceptačního procesu. Jelikož jsou často v takových případech dodávané informační technologie vyvíjeny na míru objednateli, mohlo by být bezdůvodné nepřijetí zhotoveného díla pro zhotovitele kritickým. V praxi se již nejednou stalo, že objednatel užil dosud neakceptované dílo ke svým komerčním účelům, ačkoliv stále namítal, že dílo trpí vadami, a proto ho odmítá akceptovat a posléze rovněž zaplatit. Je proto vhodné smluvně upravit i nakládání s neakceptovaným dílem. Celkově lze doporučit sjednávat fikce úspěšné akceptace pro případ, že je objednatel zcela nečinný nebo jestliže dostatečně určitě nespecifikuje svoje výhrady vůči dílu v rámci akceptační procedury. Užitečné rovněž může být určení třetí osoby, jakéhosi arbitra, který by o úspěšnosti či neúspěšnosti akceptační procedury rozhodl v případě, že by strany nedokázaly najít potřebný konsenzus.

Po úspěšném dokončení akceptační procedury nastává zpravidla okamžik, kdy jsou strany formálně povinny předat a převzít implementované dílo a potvrdit tuto skutečnost v předávacím protokolu. Okamžik předání a převzetí díla má přitom zejména za následek, že objednatel nabývá licenci dílo ve sjednaném rozsahu užít. Okamžikem předání a převzetí obvykle začíná i fáze poimplementační údržby a podpory díla a zahájení účinnosti SLA. V případech, kde je to vhodné a bylo-li to dohodnuto stranami, počíná tímto okamžikem běžet také záruční doba.
 

Úschova zdrojových kódů

V některých případech se v souvislosti s předáním a převzetí IT díla řeší i otázka zdrojových kódů. Dodávané informační technologie bývají často vyvíjeny na míru objednateli, a proto se můžeme setkat s tím, že se zdrojové kódy předávají společně s dílem přímo objednateli. Obvyklejší však je, že se zdrojové kódy předávají do úschovy[7] u třetích osob. V praxi se úschovami zabývají notáři nebo advokátní kanceláře a základem takové úschovy je smlouva o úschově zdrojových kódů[8]. Tato smlouva představuje úpravu vztahů mezi nabyvatelem licence (objednatelem) a jejím poskytovatelem (zhotovitelem). Úschovou zdrojových kódů je jednak zajištěna ochrana oprávněných zájmů zhotovitele díla, který nechce zveřejnit své obchodní tajemství vůči objednateli[9], a jednak je tím zaručena ochrana investice objednatele, neboť například v případě úpadku zhotovitele mohou být objednateli odevzdány zdrojové kódy, aniž by tím byl narušen chod jeho systému. Úschova někdy slouží jako záruka objednateli, že ze strany  zhotovitele bude řádně vykonávána správa softwaru (jako je například update, upgrade atd.). Na základě toho je pak ve smlouvě o úschově zdrojových kódů možné sjednat, že v případě odmítnutí zhotovitele odstranit podstatné, či jakékoliv smlouvou určené vady, bude moci být vydán zdrojový kód objednateli, který pak bude schopen takové vady odstranit sám, respektive prostřednictvím jiné společnosti poskytující IT služby.

Závěrem lze shrnout, že v oblasti IT smluv je v důsledku nepřiléhavé zákonné úpravy nutné přistupovat ke smluvním ujednáním s velkou obezřetností a důsledností, neboť zdánlivě malá nepozornost či nepřesnost může při konečném účtování přinést nepříjemné důsledky, a to jak pro objednatele, tak pro zhotovitele. Význam předání a převzetí díla je přitom třeba smluvně vymezit tak, aby odpovídal skutečnému zájmu obou stran a aby nemohl být žádnou ze stran zneužitelný.
 

JUDr. Martin Maisner, Mgr. Michal Křižka, Mgr. Martin Flaškár

ROWAN LEGAL s.r.o., advokátní kancelář

GEMINI Center
Na Pankráci 1683
140 00 Praha 4

tel.: +420 224 216 212       
fax: +420 224 215 823
e-mail: praha@rowanlegal.com

--------------------------------------------------------------------------------

[1] Srov. např. rozhodnutí NS 29 Odo 416/2001, NS 32 Odo 631/2002.
[2] § 560 odst. 1 obchodního zákoníku
[3] § 266 odst. 4 obchodního zákoníku
[4] Viz též Bejček, J., Eliáš, K., Raban, P. a kol. Kurs obchodního práva. Obchodní závazky. 4. Vydání. Praha: C.H. Beck 2007, str. 337.
[5] Srov. ustanovení §§ 591 – 600 obchodního zákoníku.
[6] Jedná se o názorné členění; v praxi dochází ke sjednávání mnoha různých alternativ.
[7] Tzv. escrow.
[8]  Tzv. source code escrow agreement.
[9] Ve snaze zabránit tím zneužití, spočívajícím např.  ve vytvoření konkurenčního produktu na základě v modifikace zdrojového kódu

© EPRAVO.CZ – Sbírka zákonů, judikatura, právo | www.epravo.cz