Pozor na čertíky ukryté v softwarových smlouvách

Digichef

Jistě jste se i vy během své praxe setkali s problémy, které byly zapříčiněny nedostatky ve smlouvách o vývoji softwaru a jeho následné implementaci. Proto jsme se s kolegy zaměřili na nejproblematičtější části smluv a sepsali, jak se můžete vyhnout nedostatkům a případným rizikům.

Nedostatky těchto smluv jsou často způsobeny jak neznalostí a nepozorností, tak nedostatečnou právní úpravou. Je dobré si uvědomit, že samotný software není nikdy primárním předmětem právních vztahů (stejně jako grafické dílo či jiný nehmotný statek). Předmětem právních vztahů je autorské právo k samotnému softwaru.

V praxi se v případě vývoje softwaru na zakázku běžně setkáme s využitím smlouvy o dílo, která je upravena obchodním zákoníkem. Tato smlouva pak implicitně či explicitně obsahuje licenci ke zhotovovanému softwaru.

image

Pozor na čertíky ukryté v softwarových smlouvách

Pojďme se tedy podívat na několik bodů, které mohou být u softwarových smluv problematické.

Definice předmětu smlouvy (projektová dokumentace)

Častým nedostatkem bývá špatně formulovaný předmět smlouvy. Tedy co nejpřesnější specifikace parametrů vyvíjeného softwaru, která by měla vycházet z analýzy zpracované na základě požadavků klienta.

V našem případě je touto specifikací vždy projektová dokumentace, která v projektu figuruje jako nedílná součást smlouvy o vývoji softwaru a jeho následné implementaci.

Tento dokument přesně definuje funkcionalitu, informační architekturu a další specifika vyvíjeného softwaru. Dokument je po schválení závazný pro obě smluvní strany a je také velmi důležitým podkladem v případě změnového řízení.

Definice pojmů

Před přípravou smlouvy je vždy vhodné jasně si definovat termíny využívané ve smlouvě a jejich užití pak důsledně dodržovat.

Předejdeme tím případným nedorozuměním a zásadnějším problémům. Pokud je to možné, doporučujeme vyvarovat se ve smluvním textu užití odborných termínů.

Způsob úhrady ceny díla a stanovení splatnosti ceny díla

Jedním z nejdůležitějších bodů je stanovení způsobu úhrady ceny díla a především stanovení splatnosti ceny díla.

Ustanovení § 548 odst. 1 obch. zákoníku stanoví, že objednatel je povinen zaplatit zhotoviteli cenu za dílo v době sjednané ve smlouvě. Není-li však splatnost ceny sjednána, vzniká zhotoviteli nárok na uhrazení ceny až provedením díla.

Podle § 554 odst. 1 obch. zákoníku zhotovitel splní svou povinnost provést dílo jeho řádným ukončením a předáním předmětu díla objednateli v dohodnutém místě, jinak v místě stanoveném zákonem.

Splatnost ceny za dílo je tak vázána na zánik závazku zhotovitele splněním. Lze tedy doporučit řešit splatnost ceny smluvním ujednáním prostřednictvím záloh splatných v průběhu vývoje softwaru a po jeho předání a převzetí.

Termín plnění a termín spuštění

Definovat ve smlouvě termíny jistě nikdo nezapomene. Značné potíže však může způsobit stanovení termínu spuštění na pátek nebo před svátkem.

I přes pečlivé testování se může objevit problém, který by bylo v době pracovního volna složité řešit. Pokud je to možné, termíny spuštění stanovujeme po dohodě s klientem na začátek pracovního týdne.

Povinnost součinnosti obou smluvních stran

Velmi důležité je také co nejpřesnější definování podmínek součinnosti obou smluvních stran. Tedy podmínek, za jakých budou obě strany v průběhu projektu komunikovat, tak, aby na jedné nebo druhé straně nedocházelo k prodlení způsobenému neposkytnutím požadované součinnosti druhou stranou.

Může se například jednat o situaci, kdy objednatel zhotoviteli nedodá ve sjednaný termín požadované podklady a na straně zhotovitele tak dojde k prodlení. Ve smlouvě musí být pro takový případ například definováno, že v případě prodlení z výše uvedeného důvodu se prodlouží termín dodání díla o dobu prodlení na straně objednatele. Zásadní problém může nastat, pokud objednatel přestane komunikovat zcela nebo vše neguje.

Licenční ujednání

V případě, že zhotovitelem softwaru je právnická osoba, nastává situace, kdy objednatel hradí zhotoviteli odměnu za vytvoření předmětu smlouvy, ale nestává se vykonavatelem majetkových autorských práv.

To znamená, že objednatel může software vytvořený na základě smlouvy o dílo užít pouze k účelu vyplývajícímu ze smlouvy. V případě, že má zájem využívat dílo nad rámec smlouvy, je jedinou možností uzavření licenční smlouvy.

Ve smlouvě, příloze smlouvy nebo samostatné licenční smlouvě (EULA – end user license agreement) je vhodné definovat licenční podmínky, které jasně specifikují, v jakém rozsahu může objednatel dílo užívat (udělení výhradní nebo nevýhradní licence, uzemní omezení licence, časové omezení licence apod.).

Změnová řízení (dodatky ke smlouvě, aktualizace projektové dokumentace)

Dalším nedostatkem smluv bývá nedostatečná úprava tzv. změnového řízení. V průběhu vývoje softwaru se velmi často stává, že klient předloží nové požadavky a vzniká tak potřeba přizpůsobit změnám jak předmět smlouvy, tak termíny plnění a cenu díla.

Ve smlouvě tak musí být vždy přesně stanoven způsob, jakým budou takové požadavky řešeny. V praxi řešíme takové situace aktualizací projektové dokumentace a dodatkem ke smlouvě. Změny v dokumentaci a s tím spojené změny ceny díla vždy podléhají schválení obou smluvních stran.

Odpovědnost za uveřejňovaný obsah

Pozor také na materiály uveřejňované v oblasti internetu. Ty vyžadují, aby byl klient oprávněn s těmito materiály nakládat zejména ve smyslu zákona č. 121/2000 Sb. o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon) ve znění pozdějších předpisů, a jiných právních předpisů.

Bude to klient, kdo odpovídá za obsah uveřejňovaného textu (a dalších materiálů) a za pravdivost informací v nich uvedených a nese veškeré právní následky spojené s porušením zákonných povinností.

Kompatibilita s webovými prohlížeči

Nezapomínejme také na kompatibilitu s webovými prohlížeči. Podpora starších verzí prohlížečů může enormně zvýšit cenu díla a bude mít vliv také na samotnou funkčnost aplikace.

Již v přípravné fázi projektu je nutné si s klientem odsouhlasit verze webových prohlížečů, které bude aplikace podporovat.

Kódy třetích stran

Většina firem zahrnuje do svých aplikací kódy třetích stran. Ty představují zejména právní riziko, ale mohou představovat také riziko bezpečnostní a v případě změny jejich kódu může dojít k narušení funkčnosti aplikace.

Proto je nutné, aby bylo ve smlouvě jasně definováno, zda náklady spojené s nápravou ponese objednatel, nebo zhotovitel.

Dohoda o mlčenlivosti

NDA – non-disclosure agreement neboli dohoda o mlčenlivosti - je dokumentem, v němž se firma zavazuje, že informace získané v průběhu projektu od klienta využije pouze k dohodnutým účelům a nebude je dále šířit. Klient se tak chrání proti tomu, aby se informace dostaly například do rukou konkurence.

Dohoda o mlčenlivosti může být buď součástí smlouvy, nebo figurovat samostatně.

Předání a převzetí díla

Předání a převzetí díla by mělo předcházet po předem stanovenou dobu období testování na straně klienta, tzv. user acceptance testing.

Testování by mělo vyústit v podpis akceptačního či předávacího protokolu.

V případě, že klient během testovacího období narazí na nedostatky, musí být tyto uvedeny v protokolu a stanoven termín jejich odstranění.

Nedostatky, které nemají vliv na funkčnost softwaru, by však neměly bránit předání a převzetí. Nesmí se také zapomínat na situaci, kdy k předání díla není poskytnuta dostatečná součinnost a k předání formálně nedojde.

Odpovědnost za vady a škodu (pojištění odpovědnosti)

Za chyby se pyká. U softwarové firmy mohou být následky chyb devastující. Způsobů, jak se takových následků vyvarovat, je naštěstí více.

Každá firma zabývající se vývojem softwaru by měla mít pojištění odpovědnosti za škodu. Samotná smlouva by pak měla upravovat rozsah náhrady škod. Neomezená odpovědnost stanovená zákonem představuje pro firmu značné riziko a měla by ji proto limitovat.

Zrušení a odstoupení od smlouvy

V průběhu projektu může nastat situace, kdy se klient rozhodne odstoupit od smlouvy a vyhnout se i povinnosti uhradit smluvně dohodnutou cenu. V takovém případě bude klient jistě hledat jakýkoli důvod, který by mohl být důvodem pro odstoupení.

Samotná smlouva by proto měla jasně vymezit důvody pro odstoupení od ní. Zapomínat by se nemělo ani na stanovení lhůt pro nápravu. Smlouva by také měla upravovat podmínky pro úhradu již provedených prací a předání a převzetí alespoň částečného plnění.

Záruční doba

V první řadě je třeba říci, že software není chápán jako zboží a nelze na něj uplatnit stejné záruční podmínky (Obchodní zákoník).

Záleží tedy na dohodě obou smluvních stran, v jakém rozsahu a délce bude záruka poskytnuta. Nejčastěji se v praxi setkáme se zárukou v délce 12 či 24 měsíců.

Zajištění správy a údržby

Po dokončení projektu by měla firma svému klientovi zajistit následný servis a údržbu právě vytvořeného softwaru.

Podmínky by měly být buď již součástí smlouvy o vývoji softwaru a jeho následné implementaci, nebo jako samostatná smlouva o servisu a údržbě SW.

Specifikovány by měly být například podmínky garantované dostupnosti (stupeň garantované dostupnosti, právo na odstávky, nefunkčnost způsobenou vnějšími závislostmi), odstraňování závad (způsob hlášení, kategorie závad, doba odezvy, lhůty pro odstranění závad, součinnost), změnová řízení viz výše, úhrady za neoprávněné hlášení závad, zajištění upgradu systému a další.

Setkali jste se také s nějakým problémem u smluv o vývoji softwaru a jeho následné implementaci? O jaký problém šlo a jak jste jej řešili? Doplnili byste do článku další bod?

Odborným konzultantem článku byl Josef Aujezdský, partner v advokátní kanceláři Mašek, Kočí, Aujezdský a spolutvůrce systému eAdvokacie – online právní poradenství. Ve své právní praxi se zaměřuje na obchodní právo a autorské právo (zejména ve vztahu k počítačovým programům).

  • Celkový průměr hodnocení: 4.6 z 5
  • 4.6
  • 4.6
  • 4.6
  • 4.6
  • 4.6

24. května 2013