Typ smlouvy

Základní nedostatky plynou ze skutečnosti, že na vytvoření a dodání softwaru je používána v právní praxi klasická smlouva o dílo. Taková smlouva je upravena obchodním zákoníkem a je použitelná na zcela jiný předmět, než je software (zejména na stavby, zhotovení věci apod.). Nicméně vývoj a implementace softwaru jsou složitějším procesem se svými specifiky, a takto je třeba i přistupovat k psaní „softwarové smlouvy“. Je třeba zmínit, že smlouva je smlouvou nepojmenovanou, kombinující více typů smluv – smlouvu o dílo, licenční smlouvu, kupní smlouvu (často bývá součástí dodávky softwaru i dodávka hardwaru).

Definice pojmů

IT business často používá rozdílných pojmů pro jedno a to samé, a proto je vždy vhodné předem si zcela jasně vymezit jednotlivé pojmy klíčové pro realizaci smlouvy, jako je například software, uživatelská stanice, server, vzdálená správa, databáze, implementace, licence atd. Tohoto dohodnutého pojmosloví je třeba se pak striktně v textu smlouvy držet, aby nevznikly jakékoliv výkladové nejasnosti či spory.

Definice předmětu smlouvy

Základním nedostatkem je špatně formulovaný předmět vývoje, tzn. parametry softwaru. Software by měl být definován v návaznosti na analýzu IT prostředí a požadavků zákazníka. Výsledkem této analýzy je projektový plán či implementační projekt popisující postup při realizaci vývoje softwaru a jeho dodávce, ale zejména popis funkcionality. Popis funkcionality je klíčový z pohledu splnění smlouvy ze strany IT firmy, a tedy i pro úhradu ceny za dodávku softwaru.

Změnové řízení

Dalším nedostatkem smluv o vývoji a dodávce softwaru je nedostatečná úprava tzv. změnového řízení či project managementu. V průběhu vývoje softwaru bývají měněny požadavky ze strany zákazníka a tím vzniká i potřeba přizpůsobit jak předmět smlouvy, tak termíny plnění, a konečně i cenu. Proto by mělo být vždy pamatováno na přesný popis způsobu vzájemné komunikace, kompetencí jednotlivých osob a schvalování změn.

Povinnost součinnosti

Mezi úskalí smluv patří chybně sjednaná povinnost součinnosti ze strany zákazníka, kdy dochází v důsledku neposkytnutí IT firmou požadované součinnosti k prodlení na straně IT firmy, které může znamenat i povinnost platit smluvní pokutu za pozdní dodání softwaru.

Licence

Pokud vzniká software na objednávku, pak by veškerá majetková autorská práva vznikla přímo zákazníkovi a IT firma by neměla právo stejný software, či dokonce i jeho části dodávat jiným zákazníkům. IT firmy většinou mají zájem na tom, aby mohly části programu, který vytvořili i v jiných projektech, dodat dalším zákazníkům. Proto je nutné i tomuto požadavku přizpůsobit autorskoprávní ujednání smlouvy a definovat licenční podmínky a sjednat, že majetková autorská práva náleží IT firmě, která uděluje licenci svému zákazníkovi (neomezenou časově, místně či množstvím). Licenční podmínky bývají stanoveny přímo v textu smlouvy nebo přílohou či samostatnou smlouvou (EULA – end user license agreement).

Předání a převzetí softwaru

Další klíčovou oblastí, kterou není radno podceňovat, je předání a převzetí softwaru. Tomuto by měl předcházet testovací provoz softwaru u zákazníka (UAT – user acceptance testing), jehož výsledkem by měl být podpis akceptačního protokolu deklarující předání softwaru. Pokud má software vady, pak je nutné stanovit lhůtu pro jejich odstranění a podpis akceptačního protokolu odložit na dobu, kdy tyto vady softwaru budou odstraněny. Nicméně menší vady, jako jsou chybové hlášky, které nemají vliv na funkcionalitu softwaru, by neměly bránit předání softwaru. V praxi jsou předmětem sporu právě tyto „nepodstatné“ vady a zákazník požaduje následně slevu nebo smluvní pokutu za nepředání softwaru. To vše je však potřeba přesně upravit ve smlouvě.

Zákaz konkurence

Pokud si zákazník nechá vytvořit software na zakázku, tak aby jeho podnikání bylo efektivnější a měl výhodu před konkurencí, pak doporučujeme z pohledu zákazníka stanovit pro IT firmu ve smlouvě zákaz dodat shodný či obdobný software či jeho část subjektu, který je v konkurenčním postavení k zákazníkovi. Chybět samozřejmě nesmí sankce v podobně smluvní pokuty za porušení této povinnosti.

Odpovědnost za vady

Nezbytnou součástí smluv je i úprava odpovědnosti za vady. Špatná úprava je ta, která vychází ze zákona a zapomíná, že výpadky softwaru potřebují okamžitou nápravu a nikoliv třicetidenní lhůtu. Proto je na místě definice jednotlivých kategorií vad (např. I. a II. kategorie, závada, kritický problém) a jejich způsob hlášení, doby reakce IT firmy a doby jejich odstranění, včetně sankcí za prodlení s odstraněním. Odpovědnost za vady je však nutné omezit v případě nedostatečného zabezpečení IT prostředí před průnikem virů, při neoprávněném zásahu do zdrojového kódu softwaru, při pořízení nekompatibilních programů atd.

Odpovědnost za škodu

Rovněž zde by zákonná úprava odpovědnosti za škodu mohla být pro IT firmu zcela zničující. Kromě toho, že IT firma by měla mít pojištění odpovědnosti, je nutné vždy pamatovat na limitaci náhrady škody. Neomezená odpovědnost stanovená zákonem znamená odpovědnost za ušlý zisk a skutečnou škodu, přičemž ušlý zisk či škoda (požadovaná klienty zákazníka po zákazníkovi) může dosahovat při výpadku například ERP systému obrovských rozměrů. Proto doporučujeme limitovat náhradu škody pouze na skutečnou škodu do maximální výše, a to vždy s ohledem na hrozící výši škody a k okolnostem daného případu.

Povinnost mlčenlivosti

Nelze zapomínat ani na povinnost mlčenlivosti, jelikož zákazník již při analýze a pak při implementaci získává přístup k citlivým a tím i zneužitelným datům. Na druhou stranu příliš obecně formulovaná povinnost mlčenlivost představuji v kombinaci s vysokou smluvní pokutou velmi velké riziko pro IT firmu. Před úvodní analýzou se obvykle uzavírá smlouva o utajení (NDA – non-disclosure agreement).

Zrušení smlouvy

V praxi jsme již několikrát řešili situaci, kdy v průběhu vývoje či implementace softwaru chtěl zákazník „vycouvat“ ze smlouvy a tím i povinnosti hradit za software (ať již z důvodu finančních nebo výhodnější konkurenční nabídky). Zákazník v takovém případě hledá jakýkoliv důvod, který by mohl být důvodem pro odstoupení od smlouvy. Zákonem formulovaná možnost odstoupení pro podstatné či nepodstatné porušení smlouvy je velmi snadno zneužitelná a za takové porušení pak zákazník může považovat cokoliv, aniž by si například připouštěl nedostatečně poskytnutou součinnost. Doporučujeme tedy vždy nejlépe taxativně vymezit důvody pro odstoupení a případně stanovit lhůtu k nápravě. Dále je vhodné upravit i úhradu dosud provedených prací a jako ideální se jeví ohodnocení jednotlivých fází implementace a ukončení každé fáze podpisem akceptačního protokolu a její úhradou. Samozřejmě je nutné vzít v úvahu i využitelnost dosud provedených prací z pohledu zákazníka a sjednat tak předání výsledku činnosti zákazníkovi.

Navazující správa a údržba softwaru

Je již zvykem v IT byznysu, že na implementaci softwaru by měla navázat speciální smlouva o servisu a údržbě (pokud není součástí smlouvy o dodávce softwaru). Pouze servis a údržba s přesně stanovenými principy hlášení vad, vzdálené správy, servisních zásahů u zákazníka, úhrad neoprávněně hlášených vad, upgrade, customizace, kategorizací vad atd. může zajistit IT firmě další přísun finančních prostředků a zákazníkovi bezproblémové fungování softwaru.

Závěr

Je zřejmé, že problematika softwarového práva je velmi složitá a specifická. Při tvorbě softwarových smluv by měly být o to intenzivněji komunikovány s IT firmou jednotlivé procesy vývoje a implementace softwaru a tyto pak zapracovány společně s právními ustanoveními do dané smlouvy.

Lukáš Jansa
Autor článku, JUDr. Lukáš Jansa, působí jako advokát v advokátní kanceláři Jansa, Mokrý, Otevřel & partneři, kde se zabývá zejména obchodním právem, právem informačních technologií, problematikou pracovněprávních vztahů v oblasti IT a internetovým právem.