Rozlišení konkrétních vad
Hovoříme-li o vadách softwaru, je v první řadě důležité určit, o jakou vadu se jedná. Je potřeba rozlišovat, zda se jedná o vadu faktickou či vadu právní. Vedle toho se vyskytuje i zcela specifická vada, a to vada v podobě zastarání nebo aktualizace hardwaru, operačního systému či jiného programu (softwaru), na kterém je předmětný „vadný“ software závislý. V důsledku toho se pak dá hovořit o podkategorii vad, které lze rozdělit na vady podstatné či kritické a vady nepodstatné.
Vada v obecném pojetí je určité opotřebení či nedodělek dané věci a jedná se tedy o nedostatečnou kvalitu dané věci. Toto pojetí se velmi jednoduše prokazuje u věci hmotné, kde se prostě poukáže např. na díru na kabátě. Na takovéto zcela zřejmě vadné plnění lze bez jakéhokoli problému aplikovat § 1914 odst. 1 zákona č. 89/2012 Sb., občanský zákoník, (dále jen „OZ“) ve smyslu § 1916 odst. 1, § 1917 a § 1919 odst. 1 OZ, tedy díra na kabátě, na kterou prodejce neupozornil při prodeji, je vadou výrobku, neboť kabát po stanovenou dobu nemá či si neudržel požadované vlastnosti – kabát svého nositele neuchrání před zimou, protože skrze díru profukuje.
Jinak je tomu ovšem u věci nehmotné, navíc natolik specifické jako je software. Odborná literatura tak v případě softwaru definuje vadu jako vadu funkcionality, která se může projevovat „jako nefunkčnost softwaru či jeho části nebo jako nesoulad funkcí softwaru s definovanou funkcionalitou.“1) Je tomu dáno skutečností, že software je stále stejný, na rozdíl od kabátu v čase neměnný. Software není možné opotřebit, zlomit či rozbít apod. Tuto neměnnost zajišťuje u softwaru jeho samovolně neměnný zdrojový kód. Software se tak nemůže bez zásahu člověka nijak zkazit či porouchat. Co se ovšem mění, je hardware, na kterém je software uchováván, spouštěn a používán. Ten se mění v čase – opotřebovává se, stárne a následně nahrazuje za novější, výkonnější a rychlejší či ekologičtější. Tím ovšem mohou nastat nejrůznější problémy, které se uživateli mohou jevit jako vady softwaru. Zde je ovšem nutné zdůraznit, že se nejedná o vadu softwaru, ale o změnu specifikací. Vývojář totiž vyvíjí software (program) v daném okamžiku, kdy počítá s kompatibilitou na v daném okamžiku dostupnou techniku (ať už hardwarovou nebo softwarovou) a tím pádem software nemusí být kompatibilní s novou pokročilejší technikou.
Vady faktické
Z popsaného obecného pojetí vady se lze dobrat k vadě faktické. Faktická vada softwaru je taková, která je v softwaru už od samotného začátku, tedy software ji měl již při předání a na takovou vadu lze velmi dobře aplikovat ustanovení § 1914 odst. 1 OZ, který říká, že kdo plní za úplatu, je zavázán plnit bez vad a s vlastnostmi vymíněnými nebo obvyklými tak, aby bylo možné použít předmět plnění, zde daný software, podle smlouvy a dle jejího účelu.
Jinými slovy, pokud software již od samého začátku nesplňuje smlouvou stanovené funkce či postrádá takto dohodnuté funkcionality, a tedy nelze užít k danému účelu, jedná se o vadné plnění a příjemci tak vznikají práva z vadného plnění (§ 1914 odst. 2 OZ).
Příjemce je povinen řídit se postupem uvedeném v § 1921 OZ, což znamená vytknout danou faktickou vadu bez zbytečného odkladu poté, co měl možnost věc prohlédnout a danou vadu zjistit. Splní-li tuto podmínku, má příjemce dle ustanovení § 1923 OZ u odstranitelné vady právo na odstranění vady dodáním nového softwaru či jeho chybějící části, na odstranění vady opravou softwaru nebo na přiměřenou slevu z kupní ceny. Nelze-li vadu odstranit a není-li pro ni možné předmět řádně užívat, je dle téhož ustanovení možné i odstoupení od smlouvy.
Z výše uvedeného tak vyplývá, že pro strany je zcela zásadní si dopodrobna a co nejpřesněji definovat, co má daný software umět, k jakému účelu bude používán a jaké konkrétní funkce, které se hodí k dosažení účelu použití, má software obsahovat. Toto vymezení bude následně při případném sporu zcela zásadní pro určení, zda se v daném případě jedná o vadu nebo ne. Nebude-li ve smlouvě či jiném dokumentu uzavřeném mezi stranami toto specifikováno, bude se na software pohlížet tak, že má obsahovat funkce, které se obecně hodí k dosažení sjednaného účelu softwaru.
Popsaný stav vad, odpovídá vadám zjevným, tedy takovým, které jsou ihned bez většího hledání patrné. Nicméně totéž platí i pro vady na první pohled neviditelné, tzv. vady skryté. Dodavatel softwaru odpovídá za všechny vady, které měl předmětný software v době předání, tedy jak za vady zjevné, tak za vady skryté. Proto je v odborné literatuře doporučováno provedení tzv. akceptační zkoušky, která by měla „prověřit, zda software skutečně vady nevykazuje.“2) „Software by měl být podroben testování před předáním a převzetím. V tomto procesu se zjistí, zda software vykazuje funkcionality dohodnuté mezi stranami, ale zároveň objednatel zjistí, zda má software vady. Pokud ano, pak je musí oznámit dodavateli a software nepřebírat. Dodavatel pak odpovídá za řádné odstranění chyb a opětovné testování softwaru.“3) Tuto zkoušku, či spíše zkušební období, je doporučeno nastavit v délce jednoho až tří měsíců.4)
Vady právní
Vada právní bude na rozdíl od právě popsané faktické vady mnohem hůře zjistitelná. V případě vady právní se totiž bude jednat o nedostatečné „oprávnění poskytovatele poskytovat software formou licence“.5) Půjde tak například o skutečnost, že místo výhradního práva k použití daný software mohou používat i další osoby 6) či o zásah do práv třetích osob.7) V takovém případě se příjemci softwaru krátí nároky z vadného plnění, neboť v případě právní vady není možné vadu jednoduše opravit. Z výčtu práv z vadného plnění uvedeného v § 1923 OZ tak není možné použít odstranění vady opravou či dodáním chybějící části. Přichází proto v úvahu pouze práva z vadného plnění v podobě dodání nového softwaru, přiměřené slevy z kupní ceny nebo odstoupení od smlouvy.
Incidenty
Zcela specifickou kategorií vad, která je typická především pro IT segment, je vada v podobě zastarání nebo aktualizace hardwaru, operačního systému či jiného programu (softwaru), na kterém je předmětný „vadný“ software závislý. Není to tedy ve své podstatě vada jako taková, neboť vývojář v době tvorby softwaru nebyl schopen předvídat budoucí vývoj techniky a míru jejího zastarání, a proto nebyl ani schopen předcházet budoucím vadám. Jinými slovy, nejedná se o vadu, ale o chybu vzniklou v důsledku okolností nezávislých na samotném softwaru. Jelikož takové chyby nejsou vadou v pravém smyslu slova, není možné na ně ani aplikovat výše popsaná práva z vadného plnění, neboť plnění jako takové vadné nebylo, pouze se změnily okolnosti. Odborná literaturu tyto chyby či vady označuje jako tzv. „incidenty“.8)
Zde nastává potřeba pečovat o provoz softwaru udržováním jeho aktuálnosti, čehož lez docílit pouze pravidelnými aktualizacemi. K tomu slouží servis v podobě podpory, údržby a dalších služeb. Ty se uzavírají skrze servisní smlouvy, tzv. SLA (Service Level Agreement). Cílem těchto smluv by mělo být chyby nejen opravovat, ale v ideálním případě jim zcela předcházet.9)
Aby servis poskytovaný skrze SLA uspokojoval obě strany smlouvy, je nutné si přesně určit specifikaci stávajícího softwaru nebo zařízení, kterého se poskytování služby týká. Od toho (a od dohodnutého účelu funkcí v kupní/licenční smlouvě) se bude také odvíjet ve smlouvě dohodnutá definice incidentu. Dále je v SLA nutné specifikovat objednané servisní nebo jiné činnosti (např. update a upgrade), reakční doby na jednotlivé incidenty a doby vyřešení incidentů a způsob ohlašování požadavků nebo incidentů.
Také je nutné specifikovat, co je považováno za incident podstatný či kritický a co za incident nepodstatný. Podstatný incident bude takový, který znemožňuje zcela nebo z velké části používání a/nebo funkčnost softwaru, a tedy bude nutné ho co nejdříve odstranit. Naopak např. incident v podobě změny grafické podoby bude spíše považován za nepodstatný a na jeho opravu se nebude tolik spěchat. Nicméně i změna grafické podoby může být pro někoho podstatnou změnou, a proto je nutné jednotlivé druhy incidentů ve smlouvě předem definovat a domluvit požadovanou dobu k jejich odstranění servisní službou.10)
Závěr
Vad, které vznikly na základě vadného plnění (§ 1914 a § 1916 OZ), respektive uplatnění práv plynoucích z vadného plnění (§ 1923 OZ), je možné se domáhat pouze u vad, které představují nesplnění funkcionality nebo znemožnění výkonu účelu, který byl sjednán kupní, licenční či jinou smlouvou o dodání softwaru. Tato smlouva by měla být co se účelu a požadovaných funkcí co nejpodrobnější, tedy čím podrobněji bude software charakterizován, tím snadnější bude vadu od vlastnosti softwaru odlišit. Software by se měl co možná nejdříve od předání vyzkoušet a případné vady plynoucí z nesplnění smlouvy bez prodlení dodavateli softwaru vytknout. Dodavatel je pak povinen vytknutou vadu, je-li to možné, opravit. To samé platí i u vad skrytých, které se neprojeví hned, ale až později.
Následné vady, incidenty, způsobené zastaráváním hardwaru, operačního systému či jiného programu (softwaru), na kterém je předmětný „vadný“ software závislý již nejsou řešeny pomocí práv z vadného plnění, protože se o vadné plnění nejedná. Tyto incidenty řeší SLA smlouvy, které mají za cíl pravidelnou údržbu provozu softwaru, pravidelnou aktualizaci softwaru a předcházení incidentům.
Rozdíl mezi vadou a vlastností, tedy vadou ve smyslu incidentu tkví v tom, že vadou ve smyslu vady zakládající práva z vadného plnění je vada, která již v době předání softwaru nesplňovala požadavky na funkcionalitu softwaru. Naopak vadou ve smyslu incidentu, tedy chyby způsobené zastaráním techniky potřebné pro provoz softwaru, je chyba, kterou nemohl dodavatel softwaru nijak ovlivnit, neboť vznikla až díky změně vnějších okolností, kterými jsou právě zmiňované změny na hardwaru vzniklé jeho opotřebením nebo výměnou a nebo změnou či upgradem softwaru, na který je daný software navázán. Tyto chyby nejsou vadou ve smyslu vadného plnění, a proto jsou řešeny za pomoci SLA smluv v rámci zajištění provozu softwaru.
----------------------
[1] Jansa, Lukáš. Odpovědnost za škodu v IT. [online] Dostupné na: https://www.pravoit.cz/novinka/odpovednost-za-skodu-v-it
[2] Garajová, Michaela. j) Vady softwaru. In: Sedláková, Jana, Tomek, Roman, Formanová, Tereza, Čech, Pavel, Hradský, Jiří a kol. Softwarové smlouvy. 1. vydání. Praha: C. H. Beck, 2021, marg. č. 796.
[3] Garajová, Michaela. k) Záruka na software. In: Sedláková, Jana, Tomek, Roman, Formanová, Tereza, Čech, Pavel, Hradský, Jiří a kol. Softwarové smlouvy. 1. vydání. Praha: C. H. Beck, 2021, marg. č. 801.
[4] Císek, Jiří. Smlouvy v IT: záruka za dílo. [online] Dostupné na: https://akcisek.cz/cs/blog/3-smlouvy-v-it-zaruka-za-dilo
[5] Jansa, Lukáš. Odpovědnost za škodu v IT. [online] Dostupné na: https://www.pravoit.cz/novinka/odpovednost-za-skodu-v-it
[6] Garajová, Michaela. j) Vady softwaru. In: Sedláková, Jana, Tomek, Roman, Formanová, Tereza, Čech, Pavel, Hradský, Jiří a kol. Softwarové smlouvy. 1. vydání. Praha: C. H. Beck, 2021, marg. č. 786.
[7] Jansa, Lukáš. Odpovědnost za škodu v IT. [online] Dostupné na: https://www.pravoit.cz/novinka/odpovednost-za-skodu-v-it
[8] Čech, Pavel. 3. Údržba a řešení poruch. In: Sedláková, Jana, Tomek, Roman, Formanová, Tereza, Čech, Pavel, Hradský, Jiří a kol. Softwarové smlouvy. 1. vydání. Praha: C. H. Beck, 2021, marg. č. 918.
[9] Čech, Pavel. Kapitola 8. [Smlouva o poskytování služeb podpory a údržby a SLA]. In: Sedláková, Jana, Tomek, Roman, Formanová, Tereza, Čech, Pavel, Hradský, Jiří a kol. Softwarové smlouvy. 1. vydání. Praha: C. H. Beck, 2021, marg. č. 896-898.
[10] Podrobně je celá problematika náležitostí specifikace incidentů a na ně navázaných doplňkových služeb popsána zde: Čech, Pavel. Kapitola 8. [Smlouva o poskytování služeb podpory a údržby a SLA]. In: Sedláková, Jana, Tomek, Roman, Formanová, Tereza, Čech, Pavel, Hradský, Jiří a kol. Softwarové smlouvy. 1. vydání. Praha: C. H. Beck, 2021.
