Spory z IT smluv: kde to u softwarových projektů praská a jak se bránit

Spory kolem vývoje a dodávky softwaru patří k těm nejnákladnějším, které firmy vedou. Nejde jen o zaplacenou cenu, jde o to, že na daném systému často stojí chod firmy. A skoro vždy se dají vystopovat k jednomu místu: ke smlouvě, která se buď nesepsala, nebo se sepsala špatně. Projdeme si, kde spory z IT smluv typicky vznikají, co na ně říká české právo z pohledu vás jako objednatele, a co udělat, abyste se do nich nedostali.

Přejít na nejčastější dotazy

Proč se u IT projektů soudí častěji, než by muselo

Zásadní nedorozumění začíná už u typu smlouvy. Dodávka softwaru není "klasická" smlouva o dílo na hmotnou věc. Je to typicky smlouva nepojmenovaná, která kombinuje víc typů – smlouvu o dílo (samotný vývoj), licenční smlouvu (právo software užívat) a někdy i kupní smlouvu (dodávka hardwaru). Řídí se přitom hlavně občanským zákoníkem (§ 2586 a násl. o smlouvě o dílo) a autorským zákonem (č. 121/2000 Sb.).

Když se tahle kombinovaná povaha podcení a použije se šablona stažená z internetu, chybí přesně ta ustanovení, která jsou důležitá: definice hotového díla, akceptace, určení autorství (např. při počtu vícero externích programátorů), režim autorských práv, licence, zdrojové kódy, součinnost, odpovědnost za vady. 

Nejčastějších bodů střetu je několik. Pojďme je projít popořadě. 

Vágní zadání: nejčastější zárodek sporu

"Vývoj e-shopu" nebo "moderní a intuitivní aplikace" nejsou zadání, ale přání. Čím obecnější popis díla, tím větší prostor pro spor, jestli je hotové. Podle § 2615 odst. 1 občanského zákoníku má dílo vadu, pokud neodpovídá smlouvě. Jenže když smlouva neříká skoro nic, není k čemu funkčnost přiměřovat ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠– a vy pak jen těžko prokazujete, že jste dostali méně, než jste si objednali.

Řešení je nudné, ale funguje: co nejkonkrétnější specifikace. Popis funkcionalit, akceptační kritéria (co přesně musí systém umět a jak se to ověří), výkonové parametry, prostředí, návaznosti na jiné systémy. U agilního vývoje, kde na začátku nevíte přesně, co chcete, se konkrétnost přesouvá do change managementu a definice hotového (definition of done) pro každou iteraci.

Vícepráce a změny zadání: kdo je platí

U softwaru je změna zadání téměř pravidlem. Problém nastává, když dodavatel označí za "vícepráce" (a naúčtuje) něco, co vy považujete za součást původního zadání, nebo dokonce za opravu vlastní chyby. Oprava vady díla je bezplatná, vícepráce ne - a hranice mezi tím je přesně to, o co se vede spor.

Ochranou je změnový mechanismus ve smlouvě: každá změna rozsahu musí projít písemným změnovým protokolem s dopadem na cenu a termín, odsouhlaseným oběma stranami. Bez něj se opakovaně dostáváte do situace "to jsme si přece říkali na začátku", kterou u soudu prokážete jen stěží, popř. tím samotný spor výrazně prodloužíte (o dokazování), což Vás bude stát zvýšené náklady.

Vyjednáváte smlouvu na vývoj softwaru? Než ji podepíšete, projdeme ji s vámi optikou rizik na straně objednatele – specifikace, akceptace, licence, zdrojové kódy i sankce. Ozvěte se nám.

Akceptace a "fikce převzetí": pozor na past

Tohle je z pohledu objednatele klíčové. Podle § 2604 občanského zákoníku je dílo provedeno, je-li dokončeno a předáno. A podle § 2605 odst. 1 je dokončeno tehdy, když je předvedena jeho způsobilost sloužit svému účelu. Objednatel pak dílo převezme buď s výhradami, nebo bez výhrad.

Pozor na odstavec 2 téhož paragrafu: převezmete-li dílo bez výhrad, soud vám nepřizná právo ze zjevné vady, pokud dodavatel namítne, že jste ji neuplatnili včas. Přeloženo do praxe: nikdy nepodepisujte akceptační protokol "na dobrou vůli". Zjevné vady sepište přímo do protokolu jako výhrady.

Druhá past číhá v samotné smlouvě. Dodavatelé rádi prosazují fikci akceptace – ujednání, že dílo se považuje za převzaté, když do krátké lhůty nezareagujete, nebo jakmile ho začnou používat vaši uživatelé. Fikce převzetí je platná, jen pokud je sjednaná (jinak ji podle judikatury dovodit nelze), ale bývá nastavená ve prospěch dodavatele. Trvejte na přiměřené akceptační lhůtě, na tom, že testovací provoz není akceptace, a na možnosti opakovaného testování skrytých vad.

Vada, nebo jen "nelíbí se mi to"?

Časté napětí: vám se výsledek nelíbí, dodavatel tvrdí, že dodal přesně to, co bylo ve smlouvě. Právně platí střízlivé pravidlo – vada je odchylka od smlouvy, ne od vaší nevyslovené představy. Pokud jste do zadání nedali, že aplikace má "působit moderně" nebo být "intuitivní", těžko to uplatníte jako vadu.

Rozhodující je opět specifikace. Kde je funkce definovaná a nefunguje, jde o vadu podle § 2615 a máte nárok na její odstranění, případně na slevu z ceny. Kde definovaná není, jde o nový požadavek, tedy vícepráce. Skryté vady navíc musíte vytknout bez zbytečného odkladu poté, co je při náležité péči můžete zjistit, u díla jiného než stavba nejpozději do dvou let od předání (§ 2618 občanského zákoníku).

Odstoupení od smlouvy o dílo: kdy na něj máte právo (a kdy ne)

Nejčastější omyl objednatelů: "nefunguje to podle představ, tak odstoupím." Právo na odstoupení "protože se mi to nelíbí" ale neexistuje. Odstoupení od smlouvy o dílo je možné jen při porušení smlouvy, a záleží na jeho intenzitě:

• Podstatné porušení (např. dílo nefunkční pro sjednaný účel, zásadní prodlení) - odstoupit lze bez dalšího podle § 2002 občanského zákoníku. 
• Nepodstatné porušení - nejdřív musíte poskytnout dodatečnou přiměřenou lhůtu k nápravě a teprve po jejím marném uplynutí odstoupit (§ 2107).

Nejvyšší soud k tomu dodává důležitou věc pro objednatele: vykazuje-li dílo vady, které brání jeho užívání k účelu, není dokončené, i kdyby bylo spuštěné do zkušebního provozu. Dodavatel je tak dál v prodlení a běží mu např. smluvní pokuta (je-li sjednána) za prodlení (rozsudek Nejvyššího soudu sp. zn. 23 Cdo 3512/2018 ze dne 13. 7. 2020). Naopak drobné vady, které účelu nebrání, dokončení nevylučují. Takový případ pak neospravedlňuje odmítnout převzetí.

A pozor na jeden mýtus: odstoupením spor nekončí a nároky nemizí. Odstoupení od smlouvy se nedotýká nároků, které do té doby vznikly, tj. např. práva na náhradu škody, nároku na smluvní pokutu, úroku z prodlení. Stejně tak se odstoupení nevztahuje na rozhodčí či prorogační doložky. Ty vás zavazují dál.

Licence, zdrojové kódy a vendor lock-in

Tohle je spor, který často přijde až po rozchodu s dodavatelem – a bývá nejbolestivější. Software je autorské dílo chráněné jako dílo literární (§ 2 a § 65 autorského zákona). Že jste za vývoj zaplatili, ještě neznamená, že s ním můžete dělat, co chcete.

U softwaru na míru (díla na objednávku) platí, že objednatel je oprávněn užít dílo jen k účelu vyplývajícímu ze smlouvy (§ 61 autorského zákona), k širšímu užití potřebuje licenci. Když licenční ujednání ve smlouvě chybí, spoléháte se na vratkou obecnou domněnku § 2634 občanského zákoníku (dílo se poskytuje k účelu vyplývajícímu ze smlouvy). To v praxi znamená, že vám dodavatel může bránit software upravovat, rozvíjet ho s někým jiným nebo ho přenést k jinému poskytovateli.

Co si proto ohlídat ve smlouvě:

• Rozsah licence – výhradní vs. nevýhradní, časově a územně neomezená, s právem software upravovat, spojovat s jiným dílem a udělovat podlicence; ideálně sjednané postoupení výkonu majetkových práv (převod autorských práv jako takových české právo nepřipouští).
• Zdrojové kódy a dokumentace – právo na jejich bezplatné a aktuální předání, ideálně průběžně a při ukončení spolupráce (varianta: úschova zdrojového kódu u třetí strany, tzv. escrow).
• Autorská práv – autorem může být jen fyzická osoba, takže je nutné vědět, kdo kód reálně píše (zaměstnanci, subdodavatelé, freelanceři), a mít od dodavatele záruku, že je oprávněn licenci poskytnout. Vyřešení autorských práv může být zvlášť problematické, pokud část zdrojového kódu vytvořila umělá inteligence, která ze zákona nemůže být autorem.Teoreticky může takovou část zdrojového kódu kdokoliv užívat, a to bez jakéhokoliv právního postihu (Přečtěte si: Vibecoding v praxi: Kdo odpovídá za kód a bezpečnost)
• Součinnost při odchodu – povinnost dodavatele spolupracovat na převodu díla a údržby k jinému dodavateli a jasné náklady s tím spojené.

Pozor 🚨 – autorem může být pouze fyzická osoba, která počítačový program vytváří. V rámci naší praxe jsme se u soudu setkali s poněkud kuriózním případem, kdy se spoluautorství domáhá osoba, která sice nenapsala ani řádek zdrojového kódu, ale programátorovi sdělila námět o tom, jak by měl příslušný počítačový program vypadat. Programátor tento námět (myšlenky) objednatele přenesl do formátu zdrojového kódu (tedy odvedl veškerou programátorskou práci), načež po několika měsících od dokončení díla přišel objednatel s tvrzením, že je spoluautorem počítačového programu, z čehož dovozoval další peněžité nároky. Své nároky přitom opíral o argumentaci, že programátor by bez něj program nevytvořil, a že právě díky svým myšlenkám na provedení programu je spoluautorem výsledného díla.

Bez těchto ujednání vzniká vendor lock-in: technicky funkční software, ke kterému právně nemůžete pustit nikoho jiného. 

Přebíráte hotový software nebo končíte s dodavatelem? Zkontrolujeme licenční ujednání, práva ke zdrojovým kódům a nastavení exitu, abyste nezůstali uvěznění u jednoho dodavatele. Napište nám.

Prodlení, smluvní pokuta a limitace odpovědnosti

Termín "v přiměřené době" nebo "jakmile to bude možné" není z hlediska vymahatelnosti  optimální. Bez určení nejzazší lhůty, konkrétního data (nebo dílčích milníků) neuplatníte smluvní pokutu za prodlení. Sjednávejte proto konkrétní termíny a dílčí milníky a k nim sankci.

Smluvní pokuta má oproti nároku na náhradu škody praktickou výhodu: je vymahatelná bez toho, abyste museli složitě prokazovat výši škody. Zádržné (např. 10 % z ceny vyplacené až po odstranění vad) je další pákou na straně objednatele.

Dodavatelé naopak prosazují limitaci odpovědnosti – strop náhrady škody. To je legitimní vyjednávací téma, ale hlídejte si dvě věci: strop by neměl být symbolický a nelze se předem vzdát práva na náhradu škody způsobené úmyslně nebo z hrubé nedbalosti (§ 2898 občanského zákoníku takové vzdání zakazuje).

Když spor už nastal: jak postupovat

Když projekt hoří, platí několik zásad:

• Nepřebírejte a neplaťte "na oko". Jakmile podepíšete akceptaci bez výhrad nebo doplatíte, ztrácíte páky. Vady vždy vytýkejte písemně a konkrétně.
• Sbírejte důkazy. Akceptační protokoly, e-mailová komunikace, změnové protokoly, záznamy z testování – to všechno je u soudu rozhodující. Kdo dokáže, co bylo dohodnuto, obvykle vyhrává.
• Pošlete kvalifikovanou výzvu. U nepodstatného porušení dodatečnou lhůtu k nápravě, u prodlení výzvu se stanovením následků. Často to samo vrátí projekt do kolejí.
• Zkontrolujte doložku o řešení sporů. Ve smlouvě může být sjednaná rozhodčí doložka (arbitráž) místo obecného soudu, popř. přímo určena místní příslušnost soudu. To zásadně mění, kam a jak se spor povede – a platí i po odstoupení od smlouvy.

Většina těchto kroků má jedno společné: fungují jen tehdy, když byla smlouva sepsaná dobře. Proto se vyplatí investovat do smlouvy dřív, než do sporu.