Je pro vývojáře vhodné, když se ve smlouvě s klientem objeví věta: „Poskytovatel postupuje právo výkonu veškerých majetkových práv k dílu…“ nebo „Poskytovatel uděluje klientovi výhradní licenci…“?
Pokud kývnete, možná jste si dost zavařili.
Problém jménem „výhradní práva“
Váš standardní kód, ať už mu říkáte core, SDK, framework, platforma nebo prostě „ty vaše utility“, je vaše konkurenční výhoda. Díky němu jste rychlejší a efektivnější.
Když klient požaduje postoupení práv nebo výhradní licenci k celému software, který jste dodali, říká tím: „Jen já to smím používat. A vy už nikdy pro nikoho jiného.“
Pokud na tohle přistoupíte u svého standardního kódu, legálně jste si zakázali ho použít pro dalšího klienta po dobu trvání výhradní licence. Což je problém. Může vás to donutit stejnou funkci, nebo klidně celý core, vyvinout znovu. Neznamená to ale, že nemůžete znovu použít netvůrčí stavební prvky původního kódu (zvlášť ty, které jsou standardní v daném programovacím jazyce) nebo napsat celý zdrojový kód znovu a jinak. Zároveň ale nemůžete jen zkopírovat zdrojový kód původní funkce nebo váš core a lehce ho upravit nebo na něj „nalepit“ nový název. Je možné, že by na to nikdo nepřišel. Ale určitě porušujete práva svého „výhradního“ klienta. Ten by pak mohl chtít nejen to, ať přestanete funkci nebo celý core používat, ale i finanční kompenzaci za to, že jste porušili jeho výhradní licenci.
Je dobré ještě zmínit, že poskytnutím výhradní licence klientovi automaticky nezaniknou nevýhradní licence, které jste někomu udělili dřív. Pokud ale dáte více klientům výhradní licenci a část zdrojového kódu je stejná, zaděláváte si na problémy.
No dobře. Ale co s tím?
Jistě uznáte, že rizika nastíněná výše mohou v extrémních případech ohrozit váš business. Core software je něco, co spousta firem buduje roky a oceňuje to v milionech.
Zásadní je, aby smlouva s klientem dodávaný software rozdělila na dva různé světy. Musíte jasně oddělit, co poskytujete klientovi a vytvořili jste mu na míru a co je vaše „rodinné stříbro“, se kterým budete chtít pracovat i v budoucnu.
1. Custom kód
Tohle je ta část kódu, kterou píšete specificky pro daného klienta. Řeší jeho unikátní problém, jeho procesy, jeho design. Často zahrnuje třeba front end software.
U custom kódu buďte vstřícní. Pokud klient platí odpovídající peníze za řešení na míru, je fér mu dát výhradní licenci nebo mu dokonce postoupit výkon práv. Nic vám samozřejmě nebrání i k těmto částem dávat nevýhradní licenci a například se pouze zavázat, že komukoliv dalšímu nebo přímé konkurenci neposkytnete stejný front end. Nebo se navázat vůbec k ničemu a kód pouze dodat s nevýhradní licencí. Dost to závisí na tom, jak unikátní věc klient chce a kolik je za ni ochotný zaplatit. Pokud je rozumný a vy pro něj máte téměř ready-made řešení, možná bude nevýhradní licence stačit.
2. Standardní kód (Core/SDK)
Tohle je ten váš „šuplík“. Kód, který jste měli už před zahájením projektu, nebo který vyvíjíte nezávisle na tomto klientovi a plánujete ho použít jinde.
K této části VŽDY poskytujte pouze NEVÝHRADNÍ licenci. Klient ji smí bez problémů používat jako součást dodaného řešení, ale vy ji můžete obratem použít pro kohokoli jiného (nebo ji dál rozvíjet).
Závisí i na vaší vyjednávací pozici a na tom, jak software poskytujete:
- Dáváte klientovi celý software včetně kódu jádra rovnou? To určitě nedoporučujeme, protože už technicky nemáte svůj core pod kontrolou. Pohlídejte si případné problémy alespoň smluvně. Jak na to se dozvíte v části „Jak to řešit smluvně“? níže.
- Nebo jádro běží u vás a klient si může svoje custom části v případě ukončení smlouvy odnést jinam? Toto je ideální pro vás, protože držíte fakticky kontrolu nad core a odnést si může jen custom části. Pro klienta to samozřejmě ideální být nemusí, zvlášť když je i váš core unikátní. Těžko se mu totiž bude pak nahrazovat a custom části software mu budou bez core k ničemu. Pokud má klient o core zájem a bojí se možných budoucích problémů, vhodným řešením může být úschova kódu (escrow). Víc o ní v části „Třeba pomůže escrow“.
Jak rozlišovat kód fakticky?
Klient ale běžně dostává software jako jeden celek. Jak tedy správně rozlišit „standardní“ kód a části „na míru“? Na to jako experti určitě přijdete nejlépe sami. Ale na trhu jsou pro inspiraci různé přístupy. Nedá se říct, že by některý byl právně lepší, záleží, jak fungujete vy. Některé jsou ale silnější a bezpečnější pro vás, některé spíš nedoporučujeme.
- Balíčky a knihovny: Kód ve vlastním repozitáři si žije vlastním životem a je komprimován do package, který si klient stáhne jako závislost. Klient tedy nedostane přímo repozitář s kódem nebo kód, což ztěžuje například reverzní inženýrství.
- Oddělené repozitáře: Váš standardní kód žije ve vlastních repozitářích, které klientovi zpřístupníte nebo zkopírujete. Nebo ho ke custom kódu připojíte třeba jako Git submodule. Pak není pochyb o tom, co je co. Ale klient už má samozřejmě přístup k vašemu core kódu.
- Komentáře v kódu: Můžete jít i cestou označování souborů nebo knihoven prefixem, například „Non-exclusive licence, NÁZEV FIRMY“ nebo jen „NÁZEV FIRMY_zbytek názvu“, případně podobný text uvádět přímo v kódu. To je asi nejslabší řešení, které může být méně výhodné pro vás (větší riziko zásahu) i pro klienta (menší povědomí o tom, co je co).
Jak to řešit smluvně?
Technickou realitu by měla odrážet smlouva. Jen zmínit „standardní kód“ nebo uvést, že se jedná o „části kódu, které nebyly vytvořeny specificky pro klienta“, je málo. Za pár let by se totiž špatně dokazovalo, co jste tím mysleli a co bylo vytvořeno specificky pro klienta.
Silnější definice už by měla odkazovat na to, kde je standardní kód umístěn nebo jak se rozezná od toho custom.
A co dělat, když klient vezme váš core kód a dá ho své nové, levnější agentuře? Nebo na něm postaví konkurenční produkt? Musíte se aktivně bránit. Tady už tedy mluvíme o situaci, kdy klient přístup k vašemu core dostane rovnou.
Zákaz „pitvání“ a konkurence
Do smlouvy jasně napište, že nevýhradní licence k vašemu standardnímu kódu je vázaná pouze na provoz toho jednoho softwaru, který jste klientovi dodali.
Klient nesmí váš core kód:
- Vytěžit (vyjmout ho ze zbytku aplikace).
- Použít ho pro vývoj jakéhokoliv jiného softwaru.
- Dát ho konkurenci nebo jakémukoliv jinému dodavateli.
Nemusíme vám asi říkat, že toto nemusí být úplně jednoduché dokázat. Nic vám však nebrání ujednat si ve smlouvě aspoň závazek umožnit vám např. kontrolu kódu a provozu SW u klienta s tím, že neumožnění kontroly je spojení se smluvní pokutou.
Smluvní pokuty
Peníze jsou často nejlepší motivátor. Pokud klient poruší zákaz „pitvání“ z bodu 1, musí ho to bolet.
Přidejte do smlouvy smluvní pokutu za každé porušení licenčních podmínek k vašemu core kódu. Výše musí být citelná, aby se druhé straně nevyplatilo se do toho pouštět. Běžně půjde o vyšší statisíce až miliony korun.
Nejlepší obrana = SaaS a API
Nejbezpečnější kód je ten, který nedáte z ruky. Pokud je to technicky možné, vůbec klientovi zdrojové kódy svého jádra nedodávejte.
Udělejte ze svého core kódu službu přes API. Klientova aplikace na míru pak jen volá vaše zabezpečené API, které běží na vašem serveru, a máte tak 100% kontrolu. Zásadně tím snižujete riziko ukradnutí nebo zneužití kódu. A ještě ho můžete centrálně aktualizovat.
Třeba pomůže escrow
Jak vyřešit klientův strach z toho, že vaše společnost přestane fungovat a bez jádra pod vaší kontrolou mu nebude nic fungovat? Odpovědí je code escrow (úschova kódu).
Funguje to jako kompromis:
- Vy uložíte zdrojové kódy svého jádra (core) u důvěryhodné třetí strany. To můžeme být my, případně specializovaná firma nebo aplikace, například Escode.
- Ve smlouvě se definuje, že tato třetí strana vydá kód klientovi pouze ve specifických případech. Typicky pokud vaše firma zanikne, zkrachuje nebo přestane dlouhodobě plnit servisní smlouvu.
- Klient má jistotu, že o data nepřijde, a vy máte jistotu, že se ke kódu nedostane, dokud normálně fungujete.
Tento článek se věnuje vašemu standardnímu kódu. Ale podobně opatrně doporučujeme postupovat i v dalších situacích.
Open Source (FOSS): Používáte knihovnu pod licencí MIT nebo BSD? K ní samozřejmě také nemůžete postoupit klientovi práva. Ve smlouvě musíte uvést, že součástí díla je i FOSS kód, který se řídí svými vlastními licenčními podmínkami (a ty musíte dodržet). Běžné je zavázat se i k nepoužívání copyleft kódu jako GPL, který může vašemu klientovi u komerčních aplikací pěkně zavařit.
Kód od AI: Používáte ve velkém GitHub Copilot, Cursor nebo cokoliv jiného pro generování kódu? Skvělé. Ale kdo k němu má práva? A můžete je vůbec postoupit? Rádi bychom v závěru dali jasnou odpověď, ale toto je složité téma. Rozhodně se nedá říct, že u AI kódu můžete být v klidu. Na licenční pasti při vývoji s AI se podíváme v samostatném článku, protože to je kapitola sama pro sebe.
Nezaprodávejte svůj core byznys jen proto, abyste získali zakázku. Jasné rozdělení kódu na „standardní“ (nevýhradní) a „na míru“ (výhradní) je základem zdravého IT byznysu. Udělejte si v tom pořádek ve smlouvách i v Gitu. Budete klidněji spát.
A pokud byste si na to netroufli napistenam@elegal.cz, rádi vám s tím pomůžeme.
20. 11. 2025
Sdílet
Tweet
LinkedIn
