Objednáváte software na míru nebo SaaS?

Rozhodovací rámec: kupujete výsledek, nebo službu

První otázka není právní, ale provozní. Software na míru znamená, že platíte za vytvoření něčeho, co dosud neexistovalo, a chcete si to podržet. SaaS znamená, že si pronajímáte přístup k hotovému řešení, které dodavatel provozuje a rozvíjí pro všechny zákazníky.

Rozdíl má tři praktické důsledky. U vývoje na míru se hraje o práva ke kódu a o dokumentaci, u SaaS o dostupnost, data a podmínky odchodu. U vývoje jste zranitelní v okamžiku předání, u SaaS po celou dobu provozu. A u vývoje je největší riziko, že dostanete něco, co nikdo jiný neumí převzít, u SaaS to, že vám dodavatel jednostranně změní podmínky.

Většina reálných projektů je hybrid: hotová platforma plus úpravy na míru, a právě u těch úprav se pak zjistí, že smlouva řeší jen jednu z obou částí. Praktické řešení je popsat obě vrstvy odděleně a u každé zvlášť říct, kdo drží práva, kdo odpovídá za funkčnost a co platí po ukončení. Provozní vrstvě SaaS se podrobně věnujeme v článku Smluvní zajištění dostupnosti a kvality cloudových služeb (SLA).

Čtvrtá varianta, na kterou firmy narazí až později, je vývoj s využitím generativních nástrojů. Tam je klíčové vědět, čím dodavatel kód vytvářel, protože to ovlivňuje, co vám vlastně může předat. Tuto otázku rozebíráme v článku Vývoj software za použití umělé inteligence – komu patří kód.

Postup krok za krokem

Pořadí kroků kopíruje fáze vyjednávání. Kdo je přeskočí, doplácí to v provozu.

Prvním krokem je popsat výstup tak, aby se dal změřit. Do specifikace patří funkce, výkonové parametry a scénáře, na kterých se bude testovat. Formulace typu „systém bude uživatelsky přívětivý" v akceptačním protokolu neobstojí, formulace „odezva do dvou sekund při padesáti souběžných uživatelích" obstojí.

Druhým krokem je vyřešit práva ke kódu, a to písemně a před podpisem hlavní smlouvy. Rozhodněte, jestli potřebujete vykonávat majetková autorská práva ke kódu, nebo jestli vám stačí dostatečně široká licence, a pokud licence, tak v jakém rozsahu: na kolik uživatelů, na kolik instalací, s právem dát kód třetí straně, která bude systém rozvíjet místo dodavatele.

Třetím krokem je akceptace. Do smlouvy patří, kdo test provádí, jak dlouho trvá, co se stane při dílčím selhání a kdy se dílo považuje za přijaté i bez podpisu. Bez toho vzniká spor o to, jestli bylo dílo dokončeno a předáno a jestli je příslušná část ceny splatná. Zákon podpis protokolu jako podmínku zaplacení nestanoví, ale smlouva ho na něj navázat může.

Čtvrtým krokem je provoz: dostupnost, reakční doby, servisní okna a sankce za jejich nedodržení. Tady se vyplatí sankce nastavit jako automatické kredity, ne jako náhradu škody, kterou by objednatel musel prokazovat.

Pátým krokem je zajištění pro případ, že dodavatel skončí. Klasickým nástrojem je úschova zdrojového kódu u třetí strany s definovanými podmínkami vydání. Úschova bez aktuální dokumentace je k ničemu, takže do smlouvy patří povinnost ukládat i dokumentaci a aktuální build.

Šestým krokem je exit. Do smlouvy patří formát, ve kterém dostanete data, lhůta na jejich vydání, doba součinnosti po ukončení a cena za asistenci při migraci. U vývoje na míru je exit čistě věcí smlouvy a bez sjednané ceny se z něj stává vyjednávání pod tlakem.

U cloudových a SaaS služeb ale exit už neurčuje jen smlouva. Od 12. září 2025 se používá kapitola VI unijního nařízení o datech, která poskytovatelům služeb zpracování dat ukládá odstraňovat překážky přechodu k jinému poskytovateli a umožnit export dat. Poplatky za přechod jsou přechodně omezené na náklady s ním přímo spojené a od 12. ledna 2027 mají být zrušeny úplně. Při vyjednávání se proto vyplatí ověřit, jestli návrh smlouvy tato pravidla respektuje, nebo jestli s nimi je v rozporu.

Sedmým krokem je proces změn. Bez popsaného postupu pro změnové požadavky se změny řeší e-mailem a spor o to, co bylo součástí ceny, je jistý. Do smlouvy proto patří, kdo změnu schvaluje, v jaké lhůtě dodavatel dodá odhad pracnosti a co se stane s termínem, pokud objednatel odhad neschválí.

Co je na trhu standard a co varovný signál

Ve zdravých projektech je běžné, že cena za vývoj je rozdělená na fáze navázané na dílčí akceptace, a poslední část se platí až po převzetí do provozu. Rovněž je běžné, že dodavatel odpovídá za vady po dobu záruky a paralelně poskytuje placenou podporu, což jsou dvě různé věci a nemají se slévat do jedné.

U SaaS je standardem dostupnost popsaná jedním číslem za měsíc, definice plánované odstávky, která se do dostupnosti nepočítá, a kredity za nedodržení. Rovněž je standardem, že dodavatel může měnit funkce, ale ne snižovat sjednanou úroveň služby, a že o změně informuje předem.

Varovné signály jsou tři a poznáte je hned při čtení návrhu smlouvy. Prvním je smlouva, která neobsahuje slovo o zdrojovém kódu ani o dokumentaci, protože to znamená, že převzetí systému jiným dodavatelem nebude technicky možné. Druhým je odpovědnost dodavatele omezená na výši měsíční platby, což u ročního provozu znamená, že za způsobenou škodu prakticky neodpovídá.

Třetím varovným signálem je vázání dat na formát, který jinde nepřečtete. Formulace „data budou vydána ve formátu používaném poskytovatelem" znamená v praxi export, jehož zpracování zaplatíte dvakrát. Stejnou logikou je potřeba číst i ustanovení o zpracování osobních údajů; věnujeme se jim v článku SaaS platforma v EU.

Kde je právní hranice

Zákonná úprava je u softwaru přísnější, než firmy očekávají, a v jednom bodě naopak vstřícnější.

Podle § 58 odst. 7 autorského zákona se počítačové programy a databáze považují za zaměstnanecká díla i tehdy, byly-li autorem vytvořeny na objednávku, a objednatel se v takovém případě považuje za zaměstnavatele. To znamená, že u programátora na volné noze, který kód napsal na vaši objednávku, vykonáváte majetková práva vy, pokud jste si nesjednali jinak.

Situace se ale mění, když je dodavatelem softwarová firma. Píší-li kód její zaměstnanci, vykonává majetková práva podle stejného ustanovení ona jako zaměstnavatel a k vám se práva dostanou jen tak, jak to řekne smlouva.

V praxi navíc dodavatel často kombinuje práci zaměstnanců, externistů, subdodavatelů, open source knihoven a komponent třetích stran, takže je potřeba ověřit celý řetězec oprávnění, ne jen prohlášení dodavatele. I u programátora na volné noze proto do smlouvy patří předání zdrojového kódu, dokumentace, oprávnění k úpravám a výčet použitých komponent třetích stran.

Pro díla, na která se toto pravidlo nevztahuje, platí podle § 61 autorského zákona, že autor poskytl licenci jen k účelu vyplývajícímu ze smlouvy. Užití nad tento rámec vyžaduje licenční smlouvu. U grafiky, textů nebo návrhů rozhraní dodaných spolu se softwarem to bývá přehlížený detail.

Licenční smlouva sama má zákonné minimum. Podle § 2358 poskytuje poskytovatel licenci v ujednaném omezeném nebo neomezeném rozsahu a nabyvatel se zavazuje poskytnout odměnu, není-li ujednáno jinak; písemnou formu smlouva vyžaduje u výhradní licence. Rozsah je tedy nutné popsat, jinak se o něm bude vést spor.

Na exit má vliv i pravidlo o postoupení licence. Podle § 2364 občanského zákoníku může nabyvatel postoupit licenci třetí osobě jen se souhlasem poskytovatele, který vyžaduje písemnou formu. U převodu závodu nebo jeho samostatné složky se podle § 2365 souhlas vyžaduje jen tehdy, bylo-li to zvlášť ujednáno. Kdo plánuje prodej firmy nebo vyčlenění divize, má tento bod řešit už při podpisu IT smlouvy.

U akceptace se pak uplatní pravidla o díle. Podle § 2610 občanského zákoníku vzniká právo na zaplacení ceny díla jeho provedením, a je-li dílo přejímáno po částech, vzniká právo na zaplacení za každou část při jejím provedení. Podle § 2605 je přitom dílo dokončeno, je-li předvedena jeho způsobilost sloužit svému účelu, a převezme-li objednatel dílo bez výhrad, soud mu nepřizná právo ze zjevné vady, namítne-li dodavatel opožděné uplatnění. Podpis akceptačního protokolu tedy není zákonnou podmínkou vzniku nároku na cenu, ale smlouva na něj splatnost navázat může, a proto se o jeho podobě vyjednává.

Poslední hranici tvoří limitace odpovědnosti. Podle § 2898 občanského zákoníku se nepřihlíží k ujednání, které předem vylučuje nebo omezuje povinnost k náhradě újmy způsobené člověku na jeho přirozených právech, anebo způsobené úmyslně nebo z hrubé nedbalosti. Sjednaný strop odpovědnosti proto na tyto případy nedopadá, ať už si ho strany nastaví jakkoli.

Závěrečné shrnutí

IT smlouva se má psát od konce. Nejdřív si odpovězte, co potřebujete mít v ruce ve dni, kdy s dodavatelem skončíte: zdrojový kód, dokumentaci, data v použitelném formátu a někoho, kdo systém převezme. Teprve potom řešte cenu a termíny. Akceptační kritéria napište měřitelně, exit popište včetně ceny za asistenci a proces změn zaveďte hned na začátku.

Právní hranice je přitom v jednom bodě příznivější, než firmy tuší, a v jiném tvrdší. U programátora na objednávku vykonáváte majetková práva vy, u softwarové firmy je máte jen v rozsahu, který sjedná smlouva. Advokátní kancelář ARROWS je pro případ profesní odpovědnosti pojištěna s limitem 350 000 000 Kč a IT smlouvy vyjednává v rámci služby IT a softwarové právo, kyberbezpečnost. Napište na konzultace@arws.cz.