Odpověď hned: Zaplacením vývoje automaticky nezískáte zdrojový kód ani neomezené právo aplikaci měnit a předat jinému dodavateli. Rozhoduje, kdo program vytvořil, v jakém vztahu pracoval a co stanoví smlouva. Vedle práv ke kódu si zajistěte také repozitář, dokumentaci, účty, data a ověřený postup nasazení.
Nejdřív oddělte práva, soubory a provoz
Věta „kód patří zákazníkovi“ může označovat několik různých věcí:
- kdo vykonává majetková autorská práva k programu;
- jakou licenci a v jakém rozsahu získal objednatel;
- kdo má přístup ke zdrojovým souborům a historii změn;
- na koho jsou vedené cloudové, doménové a vývojové účty;
- kdo může aplikaci upravit, nasadit a předat dalšímu týmu;
- kdo může exportovat provozní data a obnovit systém ze zálohy.
Tyto otázky se nepřekrývají. Firma může mít širokou licenci, ale nemít aktuální zdrojový kód. Může držet kopii repozitáře, ale postrádat oprávnění předat ji novému dodavateli. A může mít obojí, avšak bez databáze, klíčů a dokumentace aplikaci stejně nespustí.
Praktický cíl proto není „vlastnit ZIP“. Cílem je mít právní i technickou možnost systém provozovat, měnit, zálohovat a bezpečně převzít bez závislosti na jediném člověku.
Co stanoví autorský zákon
K 2. říjnu 2026 uvádí e-Sbírka u zákona č. 121/2000 Sb. znění účinné od 1. července 2025. Pro zakázkový software jsou podstatné zejména § 58, § 61 a § 66 autorského zákona, zákona č. 121/2000 Sb..
Autorem programu je fyzická osoba, která jej vytvořila. Právně proto nestačí napsat, že se zákazník „stává autorem“ nebo že se na něj převádí autorství. Smlouva má přesně určit výkon majetkových práv, licenci a povinnost předat zdrojový kód.
Výchozí režim se liší podle toho, kdo program skutečně vytváří:
| Kdo program vytváří | Výchozí právní situace |
|---|---|
| Zaměstnanec objednatele | Jestliže program vytvořil ke splnění povinností vyplývajících z pracovněprávního nebo služebního vztahu, může objednatel jako zaměstnavatel vykonávat majetková práva k zaměstnaneckému dílu podle § 58 odst. 1, není-li sjednáno jinak. |
| Autor jako fyzická osoba přímo na objednávku | Počítačový program, který není kolektivním dílem a autor jej vytvořil na objednávku, se podle § 58 odst. 7 považuje za zaměstnanecké dílo a objednatel za zaměstnavatele; majetková práva pak vykonává objednatel, není-li sjednáno jinak. |
| Zaměstnanci vývojářské firmy | Jestliže program vytvořili ke splnění povinností vyplývajících z pracovněprávního nebo služebního vztahu, může jejich zaměstnavatel, tedy dodavatelská firma, vykonávat majetková práva k zaměstnaneckému dílu podle § 58 odst. 1, není-li sjednáno jinak. Zákazník potřebuje oprávnění sjednané s dodavatelem. |
| Externisté a další subdodavatelé | Dodavatel musí mít vyřešené oprávnění ke každé převzaté části a možnost poskytnout zákazníkovi sjednaný rozsah práv. |
U počítačových programů vytvořených autorem na objednávku se podle § 58 odst. 7 nepoužije § 61 autorského zákona. Na obecnou úpravu díla vytvořeného na objednávku proto nelze spoléhat jako na náhradu přesné softwarové smlouvy.
Další zvláštnost se týká postoupení výkonu majetkových práv. Podle § 58 odst. 1 může zaměstnavatel toto právo postoupit třetí osobě pouze se svolením autora, s výjimkou postoupení při převodu obchodního závodu. Požaduje-li zákazník právě postoupení výkonu práv, musí dodavatel ověřit, že k němu má potřebná svolení. V praxi může být vhodnější přesně sjednaná licence; správné řešení závisí na vztahu mezi autory, dodavatelem a objednatelem.
Podle § 66 odst. 1 autorského zákona do autorského práva nezasahuje oprávněný uživatel rozmnoženiny programu, který program mění, je-li to nezbytné k jeho využití při zavedení a provozu, nebo opravuje jeho chyby. Smí si také zhotovit záložní rozmnoženinu, je-li nezbytná pro užívání programu. Toto ustanovení však samo nezajistí předání čitelného zdrojového kódu, historie repozitáře, dokumentace ani přístupů k infrastruktuře.
Jde o obecný přehled, nikoli o právní posouzení konkrétní smlouvy. Dokument před podpisem zkontrolujte s advokátem, který se věnuje autorskému právu a IT.
Co má smlouva vyřešit
1. Rozsah oprávnění k programu
Nestačí věta „objednatel může aplikaci používat“. Smlouva má odpovědět přinejmenším na následující otázky:
- Smí objednatel aplikaci provozovat na vlastní nebo pronajaté infrastruktuře?
- Smí ji upravovat vlastními zaměstnanci a jiným dodavatelem?
- Smí vytvořit vývojové, testovací, záložní a školicí instance?
- Smí zdrojový kód zpřístupnit auditorovi, správci nebo kupujícímu firmy?
- Vztahuje se oprávnění také na později objednané moduly a aktualizace?
- Je licence výhradní, nebo nevýhradní?
- Platí bez časového, územního či množstevního omezení?
- Zůstane oprávnění zachováno po ukončení servisní smlouvy?
Rozsah musí odpovídat plánovanému používání. Jiná práva potřebuje interní evidenční systém jedné společnosti a jiná platforma, kterou má zákazník nabízet svým klientům.
2. Průběžně dostupný repozitář
Zdrojový kód nemá být předán až na konci jako archiv bez historie. Bezpečnější je ukládat jej průběžně do organizace objednatele v GitHubu, GitLabu nebo Azure DevOps. Objednatel má mít administrátorský přístup a dodavatel pouze oprávnění potřebná pro vývoj.
Repozitář by měl obsahovat vše potřebné k sestavení a nasazení sjednané části systému:
- frontend a backend;
- databázové migrace;
- automatizované testy;
- deklarace závislostí a jejich uzamčené verze;
- build a nasazovací skripty;
- konfiguraci CI/CD;
- kontejnerové nebo infrastrukturní definice;
- vzor konfigurace bez skutečných hesel a klíčů.
Přístupové údaje do repozitáře nepatří. Smlouva má samostatně určit, kde jsou uložené tajné klíče, kdo je spravuje a jak proběhne jejich bezpečné předání nebo výměna.
3. Původ kódu a oprávnění subdodavatelů
Dodavatel nemusí psát celý systém od nuly. Aplikace obvykle kombinuje:
- kód vytvořený přímo pro objednatele;
- starší moduly dodavatele;
- open-source balíčky;
- placené komponenty a služby třetích stran;
- části vytvořené externisty nebo generativními nástroji.
Smlouva nebo technická příloha má tyto skupiny rozlišit. U subdodavatelů požadujte potvrzení, že dodavatel získal oprávnění potřebná k poskytnutí sjednané licence. U dřívějších modulů dodavatele musí být zřejmé, zda je smíte po skončení spolupráce dál provozovat, měnit a svěřit jinému správci.
Automaticky vytvořený kód není důvodem ke snížení požadavků na kontrolu. Odpovědnost za začlenění, bezpečnost a původ výsledku musí zůstat součástí vývojového procesu, jak popisujeme v článku Kód od AI: kdo ho přečetl, než šel na uživatele?.
4. Seznam knihoven a licencí
Pro seznam závislostí nestačí pouze soubor package.json, requirements.txt nebo composer.json. Potřebujete také skutečně použité verze, včetně přechodných závislostí, a jejich licence.
MIT, Apache License 2.0, GPL a AGPL stanovují odlišné podmínky. Dodavatel nemůže zákazníkovi poskytnout širší oprávnění, než sám získal od autora komponenty. Součástí předání proto má být aktuální soupis komponent a licencí, případně strojově zpracovatelný seznam softwarových součástí.
Zvlášť označte placené šablony, fonty, mapové podklady, konektory, externí API a cloudové služby. Zdrojový kód nemusí stačit, pokud klíčová funkce závisí na nepřenosné licenci nebo účtu vedeném pouze na dodavatele.
5. Dokumentace ověřená spuštěním
Dokumentace nemá popisovat jen obrazovky. Nový tým potřebuje minimálně:
- přehled architektury a jednotlivých služeb;
- podporované verze běhového prostředí;
- postup sestavení a nasazení;
- databázové schéma a migrace;
- seznam integračních rozhraní;
- konfigurační proměnné bez jejich tajných hodnot;
- způsob zálohování a obnovy;
- provozní kontroly, logování a řešení známých chyb;
- postup pro obnovu po výpadku.
Nejspolehlivější přejímací zkouškou je čisté prostředí. Vývojář, který se na projektu nepodílel, dostane pouze sjednaný repozitář, dokumentaci a přístupy. Podle nich musí sestavit aplikaci, spustit testy, nasadit testovací instanci a obnovit kopii dat.
Obnovu je vhodné opravdu provést, nikoli jen zkontrolovat existenci záložních souborů. Stejný princip rozebírá článek Test obnovy zálohy: jak ho udělat a zdokumentovat.
6. Účty pod kontrolou objednatele
Na objednatele mají být vedené zejména:
- doména a správa DNS;
- cloudový účet a fakturace;
- repozitář a registr kontejnerů;
- produkční a záložní prostředí;
- služba pro rozesílání e-mailů;
- monitoring a centrální logy;
- účty v obchodech s mobilními aplikacemi;
- certifikáty, zálohy a správci identity.
Dodavatel má dostat pojmenovaný účet s odpovídající rolí. Sdílené heslo bez dohledatelnosti a vícefaktorového ověření komplikuje audit i ukončení přístupu.
Pokud aplikaci provozuje dodavatel ve svém prostředí, musí smlouva popsat export, migraci a součinnost při odchodu. Samotná formulace „hosting zajišťuje dodavatel“ neříká, jak zákazník systém převezme.
7. Data a exit plán
Práva ke zdrojovému kódu neřeší automaticky provozní data. Ve smlouvě proto určete:
- která data se předávají;
- v jakém formátu a struktuře;
- zda export obsahuje přílohy, metadata a vazby;
- jak se předají šifrovací klíče;
- jak se ověří úplnost a čitelnost exportu;
- kdo poskytne součinnost při migraci;
- kdy budou odebrány účty původního dodavatele;
- jak se naloží se zbývajícími kopiemi dat.
Exit plán se má připravit při vzniku spolupráce, ne až během sporu. Praktické kroky pro účty, hesla a dokumentaci shrnuje také článek Odešel vám ajťák? Jak převzít a předat firemní IT.
Slabé předání versus převzatelný systém
| Slabé nastavení | Převzatelný systém |
|---|---|
| Repozitář spravuje pouze dodavatel | Objednatel má administrátorský přístup |
| Na konci přijde ZIP bez historie | Kód se průběžně zapisuje do sdíleného repozitáře |
| Smlouva dovoluje jen „užívání“ | Oprávnění výslovně pokrývá provoz, změny a předání |
| Závislosti nejsou evidované | Předání obsahuje verze komponent a jejich licence |
| Nasazení zná jeden programátor | Postup je písemný a ověřený na čistém prostředí |
| Cloudové účty patří dodavateli | Účty vlastní objednatel a přiděluje role |
| Export je tabulka bez příloh | Export zahrnuje data, vazby, soubory i metadata |
| Záloha pouze existuje | Obnova byla provedena a zdokumentována |
Nižší cena nabídky nemusí znamenat nižší celkové náklady. Rekonstrukce databázových migrací, nedohledaných závislostí nebo ruční převod dat mohou pozdější změnu dodavatele výrazně prodražit.
Varovné signály před podpisem
Zpozorněte, pokud dodavatel:
- označuje repozitář za čistě interní věc;
- odmítá popsat použité knihovny a licence;
- nabízí provoz jen na svém účtu bez exportního postupu;
- slibuje dokumentaci až po dokončení;
- nechce uvést subdodavatele ani původ převzatých modulů;
- tvrdí, že zaplacením faktury je vše automaticky vyřešené;
- neumí předvést nasazení ze zdrojového kódu;
- předává data pouze jako tabulku bez souborů a vazeb.
Ústní ujištění „kód je samozřejmě váš“ není náhradou za konkrétní smluvní ustanovení a technickou přejímku.
Pokud potřebujete před podpisem nebo při změně dodavatele prověřit repozitář, přístupy, zálohy a možnost nasazení, v ITHOPE to řešíme jako součást IT auditu malé firmy. Když u nás aplikaci rovnou objednáváte, platí to, co uvádíme u vývoje aplikací na zakázku: dodáváme bez vendor lock-inu, kód i data zůstávají vaše a řešení umíme provozovat i lokálně v Brně. Zadání můžete poslat přes nezávaznou poptávku. Výstupem má být konkrétní seznam chybějících práv, souborů, účtů a kroků k bezpečnému převzetí, ne pouze obecné hodnocení.
Co zkontrolovat při převzetí
Před úhradou poslední části ceny ověřte alespoň toto:
- objednatel má administrátorský přístup do repozitáře;
- repozitář obsahuje aktuální produkční verzi;
- smlouva dovoluje sjednaný provoz, úpravy a zapojení dalšího dodavatele;
- dodavatel doložil oprávnění k externím částem;
- jsou známé verze a licence všech závislostí;
- ze zdrojů lze sestavit a nasadit čistou instanci;
- testy lze spustit podle dokumentace;
- databázové migrace odpovídají produkčnímu schématu;
- úplný export obsahuje data, přílohy a metadata;
- zálohu lze obnovit;
- domény, cloud a klíčové účty ovládá objednatel;
- tajné klíče nejsou uložené ve zdrojovém kódu;
- je připravený postup odebrání přístupů původního týmu.
Časté otázky
Patří nám zdrojový kód, když jsme zaplatili fakturu?
Samotná úhrada faktury nestačí. Rozhoduje způsob vzniku programu, vztah autora k dodavateli, smluvní oprávnění objednatele a ujednání o předání zdrojových souborů. Faktura potvrzuje zaplacení, nikoli automaticky rozsah licence nebo úplnost předání.
Stačí předat zdrojový kód v ZIP souboru?
Nestačí. Archiv obvykle neobsahuje historii změn, nastavení větví, automatizaci nasazení ani přehled použitých verzí. Bez dokumentace, databázových migrací, přístupů a ověřeného sestavení může být taková kopie prakticky nepoužitelná.
Může dodavatel používat své starší moduly?
Ano, pokud má k jejich použití potřebná oprávnění. Smlouva je musí odlišit od částí vytvořených pro zákazníka a určit, zda je objednatel smí po ukončení spolupráce dál provozovat, měnit a zpřístupnit novému správci.
Co když aplikace obsahuje open-source knihovny?
Každá knihovna se řídí vlastní licencí. Požadujte seznam komponent, použitých verzí a licencí. Stejnou kontrolu proveďte u fontů, šablon, map, placených balíčků a externích služeb.
Jak poznáme, že systém opravdu převezme jiný tým?
Nechte nezávislého vývojáře sestavit testovací prostředí pouze z předaného repozitáře, dokumentace a přístupů. Současně proveďte obnovu zálohy, úplný export dat a kontrolu smluvního oprávnění zpřístupnit kód novému dodavateli.