Smluvní podmínky pro agilní vývoj softwaru:

Agilní vývoj softwaru slibuje rychlost, flexibilitu a produkt, který přesně odpovídá potřebám trhu. Tento moderní přístup je však v přímém rozporu s tradičními právními rámci. Pokus o řízení dynamického agilního projektu pomocí standardní smlouvy o dílo je jednou z nejčastějších příčin sporů, překročení rozpočtu a v nejhorším případě i ztráty kontroly nad klíčovým firemním aktivem – vaším softwarem.

Autor článku: ARROWS advokátní kancelář (Mgr. Petr Hanzel, LL.M., office@arws.cz, +420 245 007 740)

Proč vaše standardní smlouva o dílo v agilním světě selhává?

Klíč k pochopení problému leží v zásadním rozdílu mezi dvěma hlavními filozofiemi vývoje softwaru: tradičním vodopádovým modelem a moderním agilním přístupem. Každý z nich vyžaduje diametrálně odlišný smluvní rámec.

Tradiční svět jistoty: Vodopádový model

Vodopádový model (Waterfall) je lineární a sekvenční proces, kde každá fáze projektu musí být kompletně dokončena, než začne další. Postupuje se v jasně definovaných krocích: důkladná analýza požadavků, návrh systému, samotný vývoj, testování a finální nasazení. Tento model funguje na předpokladu, že je možné a žádoucí na samém začátku přesně a vyčerpávajícím způsobem definovat celý rozsah práce, cenu i termín dodání.

Právě pro tento předvídatelný svět byla navržena standardní smlouva o dílo podle českého občanského zákoníku (§ 2586 a násl. NOZ). Jejím jádrem je specifikace konečného díla s pevně danými vlastnostmi za pevně stanovenou cenu a v pevném termínu (model Fixed-Time & Fixed-Price). Tento přístup přináší pocit jistoty a kontroly nad rozpočtem, což je pro mnoho firem lákavé.

Nový paradigma flexibility: Agilní přístup

Agilní vývoj je naopak založen na iterativním a inkrementálním přístupu. Velké a komplexní projekty rozděluje na krátké, zvládnutelné cykly, typicky trvající jeden až čtyři týdny, které se nazývají „sprinty“. Na konci každého sprintu je dodána funkční část softwaru, kterou si může klient okamžitě vyzkoušet a poskytnout zpětnou vazbu. Klíčovou hodnotou agilního manifestu je „reagování na změny namísto dodržování plánu“. Finální podoba produktu se tak postupně vyvíjí a přizpůsobuje reálným potřebám uživatelů a trhu.

Fundamentální střet a jeho právní důsledky

Snaha aplikovat rigidní smlouvu o dílo na flexibilní agilní proces nevyhnutelně vede ke konfliktu. Tento střet se projevuje ve třech kritických oblastech, které v praxi způsobují selhání projektů:

1. Zastaralost výsledného produktu: U projektů trvajících měsíce či roky je téměř jisté, že se během vývoje změní tržní podmínky, technologie nebo potřeby zákazníků. Smlouva o dílo s pevně daným zadáním však nutí dodavatele vyvíjet něco, co bylo relevantní v době podpisu smlouvy, nikoli v době dokončení. Výsledkem je často drahý software, který již neodpovídá aktuální realitě a je v podstatě zastaralý v momentě svého spuštění.

2. Nekonečné a neefektivní změnové řízení: Protože ani ta nejdůkladnější počáteční analýza nemůže předvídat všechny detaily a budoucí potřeby, změny jsou nevyhnutelné. V režimu smlouvy o dílo se každá, i sebemenší změna stává předmětem složitého a administrativně náročného dodatkování. Projekt se mění v neustálé vyjednávání o tom, co bylo či nebylo součástí původního zadání, což vede k frustraci, zpoždění a narušení partnerských vztahů.

3. Zbytečně vysoké náklady: Dodavatel, který je nucen zavázat se k pevné ceně za projekt s nejasnou budoucností, musí do této ceny promítnout všechna potenciální rizika. Nabídková cena tak obsahuje značnou umělou rezervu na pokrytí případných změn, nejasností v zadání a hrozících smluvních pokut. Klient ve výsledku platí více, než by musel, za pouhý pocit falešné jistoty.

Základní problém tedy není pouze právní nebo procesní, ale také psychologický. Klient přirozeně hledá jistotu a předvídatelnost, zejména v oblasti rozpočtu. Agilní metodika však záměrně přijímá nejistotu ohledně finálních funkcí výměnou za flexibilitu a vyšší hodnotu konečného produktu. Úspěšná agilní smlouva proto musí tento mentální rozpor překlenout. Musí klientovi poskytnout mechanismy pro kontrolu nákladů a zároveň ponechat vývojovému týmu prostor pro inovace.

Anatomie neprůstřelné agilní smlouvy: Rámec pro spolupráci, nikoli pro produkt

Řešením výše uvedených problémů není snaha ohýbat standardní smlouvu o dílo, ale přijetí zcela jiného smluvního modelu. Tímto modelem je rámcová smlouva o agilním vývoji, která nedefinuje finální produkt, ale nastavuje jasná a vymahatelná „pravidla hry“ pro celou spolupráci. Nejedná se o smlouvu o dílo v klasickém pojetí, ale spíše o smlouvu o procesu.

Rámcová smlouva a sprinty jako dílčí díla

Základem je rámcová smlouva, která upravuje všechny obecné aspekty spolupráce: role a odpovědnosti, komunikační kanály, sazby, ochranu duševního vlastnictví a mechanismy řešení sporů. Samotný vývoj je pak realizován prostřednictvím dílčích smluv o dílo, kde každá taková dílčí smlouva odpovídá jednomu sprintu.

Tento přístup elegantně řeší problém administrativní zátěže. Uzavření dílčí smlouvy na konkrétní sprint neprobíhá podepisováním formálních dodatků. Vzniká jednoduše tím, že se obě strany dohodnou na obsahu daného sprintu – tzv. Sprint Backlogu. Toto odsouhlasení, často provedené přímo v nástroji pro řízení projektů (např. Jira), je považováno za závaznou objednávku dílčího díla, které se řídí podmínkami nadřazené rámcové smlouvy. Tím je zajištěna jak právní jistota, tak potřebná flexibilita.

Definice rolí, procesů a pojmů

Aby tento model fungoval, musí rámcová smlouva precizně definovat klíčové prvky agilního procesu. To zahrnuje:

• Role: Jasné vymezení pravomocí a odpovědností klíčových rolí, jako jsou Product Owner (zástupce klienta, který definuje a prioritizuje požadavky), Scrum Master (který zodpovídá za dodržování procesu) a Development Team (který realizuje vývoj).
• Ceremonie: Smluvní zakotvení pravidelných schůzek (ceremonií), jako je Sprint Planning (plánování sprintu), Daily Scrum (denní synchronizace týmu) a Sprint Review (prezentace výsledků sprintu klientovi).
• Artefakty: Definice klíčových dokumentů, jako je Product Backlog (celkový seznam požadavků na produkt) a Sprint Backlog (seznam úkolů pro konkrétní sprint).

Je naprosto klíčové tyto agilní termíny ve smlouvě podrobně definovat. Jak praxe ukazuje, každá ze stran si pod pojmy jako „Scrum“ nebo „Product Owner“ může představovat něco jiného, což je živnou půdou pro budoucí spory. Jasné definice tuto nejednoznačnost odstraňují.

Nevíte si s daným tématem rady?

Právníci v ARROWS mají rozsáhlé zkušenosti s přípravou těchto rámcových smluv, které přizpůsobují na míru komplexním potřebám našich klientů, od startupů po nadnárodní korporace.

Takovou agilní smlouvu lze přirovnat k operačnímu systému počítače. Operační systém neurčuje, jaké konkrétní aplikace budete používat, ale poskytuje stabilní a předvídatelné prostředí a protokoly, díky kterým mohou všechny aplikace fungovat hladce a efektivně. Podobně agilní smlouva nedefinuje finální produkt, ale vytváří robustní a transparentní „operační systém“ pro celý projekt. Poskytuje pevný základ, na kterém může dynamicky a bezpečně probíhat inovativní vývoj.

Kdo je skutečným pánem kódu? Zajištění autorských práv a zdrojových kódů

Jedním z největších rizik při vývoji softwaru na zakázku je otázka vlastnictví duševního vlastnictví (IP). Pro klienta je naprosto zásadní, aby se po investování značných prostředků stal skutečným a jediným vlastníkem vytvořeného softwaru. Bez správného smluvního ošetření se to však nemusí stát.

Výchozí stav: Kód patří autorovi

Podle autorského práva platí základní pravidlo: pokud smlouva nestanoví jinak, autorská práva k vytvořenému dílu náleží jeho autorovi – tedy vývojáři nebo jeho zaměstnavateli. Klient v takovém případě nezískává vlastnictví, ale pouze licenci k užívání hotového produktu. To znamená, že nemá právo software dále upravovat, rozvíjet s jiným dodavatelem, ani jej prodat.

Smluvní zajištění plného vlastnictví

Aby se klient stal skutečným vlastníkem, musí smlouva obsahovat jednoznačná ustanovení, která toto zajišťují. Klíčové jsou dva body:

1. Doložka o díle na objednávku (Work Made for Hire): Smlouva musí explicitně uvádět, že veškerý software vytvořený v rámci projektu je považován za dílo vytvořené na objednávku. To znamená, že veškerá majetková autorská práva přecházejí okamžikem vzniku díla (nebo jeho zaplacením) na objednatele.

2. Povinnost předat zdrojové kódy: Vlastnit pouze spustitelný soubor je bezcenné. Bez přístupu ke zdrojovému kódu – tedy původnímu, člověkem čitelnému zápisu programu – je nemožné software udržovat, opravovat chyby nebo přidávat nové funkce. Smlouva proto musí obsahovat jasnou povinnost dodavatele předat kompletní a aktuální zdrojové kódy včetně veškeré související technické dokumentace.

Vendor Lock-in: Strategická hrozba pro vaše podnikání

Nedostatečné ošetření autorských práv a nepředání zdrojových kódů vede přímo k situaci známé jako vendor lock-in (závislost na dodavateli). Klient se stává rukojmím svého původního dodavatele. Jakákoli další úprava, oprava nebo rozvoj softwaru je možná pouze u něj, často za neúměrně vysoké ceny. Pokud dodavatel zkrachuje, ztratí klíčové lidi nebo se rozhodne ukončit podporu, klientův software se stává mrtvou investicí. Tato závislost brání inovacím, znemožňuje flexibilně reagovat na tržní změny a představuje vážné strategické riziko pro celou firmu.

V ARROWS běžně formulujeme smlouvy, které zajišťují našim klientům plné vlastnictví veškerého vyvinutého kódu. Pro naše klienty, mezi které patří více než 150 akciových společností a 250 s.r.o., je ochrana jejich digitálního duševního vlastnictví absolutní prioritou.

Následující tabulka shrnuje klíčová rizika spojená s duševním vlastnictvím a závislostí na dodavateli a ukazuje, jak jim lze předejít správným smluvním nastavením.

Rizika spojená s duševním vlastnictvím a závislostí na dodavateli

Riziko k řešení	Potenciální problémy a sankce	Jak pomáhá ARROWS:
Nejasné vlastnictví zdrojového kódu	Dodavatel zůstává vlastníkem kódu. Klient nemůže software upravovat, rozvíjet ani prodat. Ztráta investice a kontroly.	Příprava smluv s doložkou o převodu veškerých majetkových autorských práv (work made for hire) a povinností předat zdrojové kódy.
Vendor Lock-in (Závislost na dodavateli)	Neschopnost změnit dodavatele. Přemrštěné ceny za údržbu a další vývoj. Projekt stagnuje, pokud má dodavatel problémy.	Zajištění práv na zdrojový kód a veškerou dokumentaci, což umožňuje plynulý přechod k jinému dodavateli nebo internímu týmu.
Použití existujícího kódu dodavatele	Dodavatel může použít své proprietární knihovny, ke kterým klient nezíská práva, což opět vede k závislosti.	Revize smluv a licenčních podmínek, které jasně definují, jaká práva klient získává k před-existujícím dílům použitým v projektu.
Práva k dílčím dodávkám (sprintům)	Při předčasném ukončení smlouvy může být sporné, zda klient vlastní nedokončené, ale zaplacené části díla.	Smluvní ošetření vlastnictví IP pro každou dílčí dodávku (inkrement) po jejím schválení a zaplacení, což chrání investici klienta v každé fázi.
Nedostatečná dokumentace	I s kódem je bez dokumentace obtížné a drahé se v projektu orientovat a pokračovat ve vývoji s novým týmem.	Zakotvení povinnosti vést a průběžně předávat podrobnou technickou a uživatelskou dokumentaci jako součást akceptačních kritérií.
Odchod klíčových vývojářů od dodavatele	Znalosti o projektu odcházejí s lidmi, což ohrožuje kontinuitu.	Zajištění smluvních povinností k transferu know-how a podrobné dokumentace, které minimalizují závislost na konkrétních osobách.

Tikající bomba v projektu: Jak řídit právní rizika open-source softwaru (OSS)

Používání open-source softwaru (OSS) je dnes ve vývoji standardem. Umožňuje zrychlit práci a snížit náklady tím, že se využijí již hotové a komunitou ověřené komponenty. Tento přístup však skrývá významná právní rizika, která mohou v konečném důsledku ohrozit celý komerční produkt. Problém spočívá v licenčních podmínkách, pod kterými je OSS distribuován.

Na koho se můžete obrátit?

Dva světy licencí: Permisivní vs. Copyleft

Ne všechny open-source licence jsou stejné. Pro komerční využití je klíčové rozlišovat mezi dvěma základními typy:

• Permisivní licence (např. MIT, Apache 2.0, BSD): Tyto licence jsou pro komerční projekty obecně bezpečné. Ukládají jen minimální omezení – typicky vyžadují pouze uvedení autora a zachování licenčního textu. Důležité je, že nekladou žádné požadavky na licenci výsledného produktu, do kterého je OSS kód integrován. Váš proprietární kód tak zůstává chráněn a nemusí být zveřejněn.
• Copyleftové licence (např. GNU GPL, AGPL): Tyto licence jsou mnohem restriktivnější a nesou s sebou tzv. virální efekt. Pokud vývojář použije byť jen malou část kódu pod licencí GPL ve vašem komerčním softwaru a tento software dále distribuuje, licence může vyžadovat, aby byl zdrojový kód
  celého vašeho produktu zveřejněn pod stejnou licencí GPL. To v praxi znamená, že byste museli svůj klíčový produkt poskytnout světu zdarma a s otevřeným zdrojovým kódem.

Obchodní katastrofa v praxi

Důsledky neúmyslného porušení copyleftové licence mohou být pro firmu fatální. Nejde jen o technický problém, ale o obchodní katastrofu, která může vést ke kompletní ztrátě obchodního tajemství, konkurenční výhody a znehodnocení veškerých investic do vývoje.Příkladem je kauza sociální sítě Truth Social, která čelila obvinění z porušení licence AGPL, pod kterou je šířen software Mastodon, na němž byla postavena.

Správné řízení OSS licencí navíc není jen provozní nutností. Je to klíčový prvek firemní due diligence. Při budoucím prodeji firmy (M&A) nebo při získávání investic bude právní tým kupujícího či investora podrobně zkoumat duševní vlastnictví společnosti. Zjištění, že je klíčový produkt „nakažen“ copyleftovou licencí, může okamžitě zmařit celou transakci nebo dramaticky snížit hodnotu firmy.

Smluvní ochrana před licenční kontaminací

Jedinou spolehlivou ochranou je prevence zakotvená přímo v agilní smlouvě. Smlouva musí obsahovat přísné doložky, které dodavatele zavazují k následujícímu:

1. Evidence komponent: Povinnost vést a na vyžádání předložit kompletní a aktuální seznam všech použitých open-source a třetích komponent, včetně jejich licencí.

2. Záruka licenční čistoty: Výslovná záruka (warrant), že v projektu nebyly bez předchozího písemného souhlasu klienta použity žádné komponenty pod restriktivními copyleftovými licencemi.

3. Odpovědnost za škodu (Indemnification): Povinnost dodavatele odškodnit klienta za veškeré škody, náklady a právní výlohy, které by mu vznikly v důsledku porušení licenčních podmínek třetích stran.

Náš tým v ARROWS provádí audity licenční čistoty a připravuje interní směrnice pro vývojové týmy našich klientů, aby se předešlo neúmyslné kontaminaci jejich klíčových produktů.

„Hotovo“ jako právní kategorie: Síla „Definition of Done“ a akceptačních kritérií

V agilním světě je jedním z nejčastějších zdrojů konfliktů otázka, kdy je práce skutečně dokončena. Bez jasně definovaných pravidel se může stát, že úkol je „na 90 % hotový“ celé týdny, což vede ke skrytému technickému dluhu, zpoždění a sporům o to, zda má být práce zaplacena. Právě zde vstupují do hry dva klíčové koncepty, které je nutné přenést z technické roviny do právně závazné smlouvy: akceptační kritéria a „Definition of Done“.

Akceptační kritéria (Acceptance Criteria – AC)

Akceptační kritéria se vážou ke konkrétnímu požadavku (tzv. User Story) a definují, co musí daná funkce umět z pohledu uživatele, aby byla považována za funkčně správnou. Jsou to v podstatě testovatelné podmínky, které popisují očekávané chování.

Příklad: Pro požadavek „Jako uživatel si chci moci resetovat heslo“ mohou být akceptační kritéria následující:

• Systém odešle odkaz pro reset na můj registrovaný e-mail.
• Odkaz pro reset je platný po dobu jedné hodiny.
• Po kliknutí na odkaz mohu zadat a potvrdit nové heslo.

Nevíte si s daným tématem rady?

Definice „Hotovo“ (Definition of Done – DoD)

Zatímco akceptační kritéria definují funkčnost, „Definition of Done“ je globální kontrolní seznam (checklist), který definuje kvalitu odvedené práce. Vztahuje se na všechny úkoly ve sprintu a zajišťuje, že každá dodaná část softwaru splňuje jednotný standard, než může být prohlášena za dokončenou.

Typický DoD checklist může obsahovat body jako:

• Kód prošel revizí jiného člena týmu (Code Review).
• Byly napsány a úspěšně proběhly automatizované testy (Unit Tests).
• Byla aktualizována technická dokumentace.
• Funkce prošla bezpečnostním skenováním.
• Funkce byla úspěšně nasazena na testovací prostředí.

Právní síla DoD a akceptačních kritérií

Smluvní zakotvení těchto dvou konceptů je transformuje z pouhých technických pomůcek na mocný právní nástroj. Stávají se totiž základem pro formální akceptaci (převzetí) díla dodaného v každém sprintu. 

V rámciSprint Review klient ověřuje, zda dodaná funkcionalita splňuje předem dohodnutá akceptační kritéria a celý balík práce odpovídá definici „Hotovo“. Pokud ano, dílčí dílo je právně převzato, což spouští povinnost klienta zaplatit za daný sprint a zároveň na něj přecházejí autorská práva k vytvořenému kódu.

V ARROWS pomáháme klientům integrovat robustní, právně vymahatelné definice DoD a akceptačních kritérií přímo do rámcových smluv, čímž transformujeme technický proces v transparentní a právně jistý mechanismus přejímky.

Následující tabulka ukazuje, jak správné smluvní nastavení pomáhá řídit klíčová provozní a finanční rizika, která jsou s agilním vývojem často spojována.

Provozní a finanční rizika v agilním vývoji

Riziko k řešení	Potenciální problémy a sankce	Jak pomáhá ARROWS:
Nekontrolované navyšování rozpočtu (Scope Creep)	Projekt se neustále rozšiřuje bez formálního schválení, což vede k překročení rozpočtu a zpoždění.	Implementace smluvního procesu pro řízení změn. Každá změna mimo dohodnutý sprint backlog musí být vyhodnocena a schválena Product Ownerem.
Nejasná kvalita a nedokončené dodávky	Dodavatel tvrdí, že je práce hotová, ale je plná chyb a nesplňuje očekávání. Spory o platby.	Definování a smluvní zakotvení jasných "Definition of Done" (DoD) a akceptačních kritérií pro každou dodávku. Práce není hotová, dokud nesplní tyto podmínky.
Nedostatečná transparentnost a reporting	Klient neví, na čem se pracuje a jaký je reálný pokrok. Ztráta kontroly nad projektem.	Smluvní nastavení povinných ceremonií (např. Sprint Review), kde dodavatel musí prokazatelně demonstrovat funkční software, a pravidelného reportingu.
Platební model neodpovídající agilitě	Snaha o fixní cenu za celý projekt vede k rizikovým přirážkám a sporům (viz bod 1).	Nastavení flexibilního platebního modelu (Time & Material s budget capem na sprint), který odpovídá iterativní povaze vývoje a zajišťuje platby za reálně dodanou hodnotu.
Neefektivní spolupráce a komunikace	Týmy si nerozumí, dochází k nedorozuměním, což zpomaluje vývoj a zvyšuje náklady.	Příprava rámcové smlouvy, která jasně definuje role, odpovědnosti a komunikační kanály, čímž vytváří pevný základ pro efektivní spolupráci.
Riziko selhání projektu	Kvůli výše uvedeným problémům projekt selže, což vede k finanční ztrátě a poškození reputace.	Právní stanoviska a konzultace, které pomáhají nastavit celý projektový a smluvní rámec tak, aby se riziko selhání minimalizovalo od samého počátku.

Globální ambice, lokální právo: Zajištění mezinárodních IT projektů s ARROWS International

Vývoj softwaru je dnes ze své podstaty globální disciplínou. Není neobvyklé, že klient sídlí v České republice, vývojový tým v Polsku, designérské studio v Asii a data jsou uložena na serverech v Irsku. Tato mezinárodní konstelace sice přináší obchodní výhody, ale zároveň vytváří komplexní síť právních rizik.

Klíčovými otázkami, které je třeba řešit, jsou: Kterým právním řádem se bude smlouva řídit? V jaké zemi se budou řešit případné spory? Jak efektivně vymáhat práva k duševnímu vlastnictví přes hranice? Odpovědi na tyto otázky vyžadují hlubokou znalost nejen českého práva, ale i mezinárodního práva soukromého a specifik jednotlivých jurisdikcí.

Právě zde se projevuje unikátní síla naší kanceláře. Díky deset let budované síti ARROWS International jsme schopni poskytovat komplexní a bezproblémovou právní podporu i pro ty nejsložitější mezinárodní IT projekty. V ARROWS prakticky denně řešíme případy s mezinárodním prvkem. 

Ať už se jedná o přípravu smlouvy řídící se právem státu New York pro českého klienta s vývojáři ve Španělsku, nebo o ochranu a vymáhání práv k duševnímu vlastnictví v jihovýchodní Asii, naše síť nám umožňuje zajistit špičkovou lokální expertízu koordinovanou z jednoho místa.

 Tato schopnost je pro firmy s globálními ambicemi klíčovou přidanou hodnotou, kterou standardní advokátní kanceláře nemohou nabídnout.

Budujte software, ne spory. Smlouva, která podporuje inovace.

Správně nastavená smlouva na agilní vývoj není byrokratickou překážkou, ale strategickým nástrojem, který podporuje inovace. Tím, že vytváří jasný a předvídatelný rámec pro spolupráci, řídí rizika a buduje důvěru mezi klientem a dodavatelem, uvolňuje energii obou stran, aby se mohly soustředit na to nejdůležitější: tvorbu špičkového softwaru, který přináší reálnou obchodní hodnotu.

V ARROWS rozumíme nejen právu, ale i technologiím a byznysu. Naše zkušenosti z dlouhodobé spolupráce s více než 150 akciovými společnostmi, 250 společnostmi s ručením omezeným a desítkami subjektů veřejné správy nám umožňují navrhovat řešení, která jsou nejen právně neprůstřelná, ale i praktická a efektivní. Zakládáme si na rychlosti, vysoké kvalitě a schopnosti propojovat naše klienty, pokud vidíme zajímavé obchodní či investiční příležitosti.

Nechcete tenhle problém řešit sami? Advokátní kanceláři ARROWS věří více než 2000 klientů a jsme oceněni jako Právnická firma roku 2024. Podívejte se ZDE na naše reference a bude nám ctí pomoci vám při řešení vašeho problému. Poptávka je zdarma.