Proč je u zaměstnaneckého softwaru potřeba řešit práva hned na začátku
U softwaru vyvinutého vlastním zaměstnancem je klíčové rozlišit dvě roviny: autorské právo a pracovněprávní vztah. To, že programátor dostává mzdu, ještě samo o sobě neznamená, že firma má automaticky všechny potřebné majetkové oprávnění k výslednému dílu v rozsahu, který bude chtít později komerčně využívat. V praxi se řeší zejména to, kdo smí software upravovat, prodávat, licencovat, předávat třetím stranám nebo převést na investora.
Podle české právní úpravy je zaměstnanecké dílo zpravidla vytvořeno zaměstnancem při plnění pracovních úkolů. Zaměstnavatel pak často vykonává majetková práva, ale tento režim má limity a není vhodné na něj spoléhat bez smluvního ošetření. U interních nástrojů může být riziko malé, ale u SaaS produktu, e-shopového řešení nebo vlastního core systému jde o zásadní aktivum firmy.
Prakticky: pokud máte vývojáře na IČO, externí agenturu nebo kombinaci interního a externího vývoje, bez dobře nastavených práv můžete narazit při due diligence. Investor nebo kupující bude chtít vidět, že k repozitáři, dokumentaci, designu, databázím i frameworkům existuje jasný chain of title – tedy doložitelná řada práv od autora až po firmu.
Co musí obsahovat pracovní smlouva a interní dokumentace
Základ je v pracovní smlouvě, případně ve zvláštní IP části vnitřního předpisu nebo samostatné dohodě o nakládání s duševním vlastnictvím. Nestačí obecná věta typu „zaměstnanec předává veškerá práva k vytvořenému softwaru“. Je potřeba přesně vymezit, co je výsledkem práce a jak s ním zaměstnavatel může nakládat.
- Vymezení pracovních úkolů – například vývoj backendu, frontend komponent, integračních rozhraní, automatizovaných testů nebo interních nástrojů.
- Režim zaměstnaneckého díla – jasně potvrdit, že software vzniká při plnění pracovních povinností.
- Rozsah oprávnění zaměstnavatele – užití, úpravy, spojování s dalším softwarem, sublicencování, distribuce, cloudový provoz.
- Povinnost předat zdrojové kódy a dokumentaci – ideálně včetně commit historie, build instrukcí a přístupů.
- Povinnost evidence práce – kdo a kdy vytvořil konkrétní část kódu, designu nebo architektury.
- Úprava režimu po skončení pracovního poměru – aby firma mohla dál software bez problémů používat a rozvíjet.
Velmi praktická je i interní směrnice, která určí, jak se evidují repozitáře, kdo schvaluje merge requesty, kde jsou uloženy přístupy a jak se označují komponenty třetích stran. V menší firmě to může být jednoduchý dokument na 2–3 strany, ve větší organizaci už se vyplatí samostatná IP politika.
Pokud software vzniká v týmu, doporučuji používat nástrojový stack jako GitHub, GitLab nebo Azure DevOps s povinnými branch protection pravidly. Prakticky to znamená, že každý významný commit je dohledatelný, existuje reviewer a je zřejmé, kdo vytvořil kterou část kódu. To je důležité nejen právně, ale i bezpečnostně.
Jak ošetřit práva při vývoji na dálku, hybridně nebo s externisty
Největší chyby vznikají tehdy, když je část vývoje interní a část dodává externí dodavatel. U vlastního zaměstnance je situace relativně přehledná, ale i zde je nutné hlídat, zda zaměstnanec nepoužívá soukromý notebook, osobní GitHub účet nebo cizí knihovny bez licence. V hybridním režimu je potřeba jasně definovat, že veškerá pracovní výstupní data patří firmě a jsou ukládána do firemních systémů.
U externistů je vhodné mít samostatnou licenční a převodní smlouvu. Nestačí objednávka nebo e-mail. Smlouva by měla obsahovat:
- převod majetkových práv nebo výhradní licenci v maximálním možném rozsahu,
- souhlas s úpravami, dalšími verzemi a odvozenými díly,
- záruku originality a neporušení práv třetích stran,
- seznam použitých open-source komponent včetně licenčních podmínek,
- povinnost předat veškeré přístupové údaje, dokumentaci a build prostředí.
V praxi doporučuji mít pro každého dodavatele i zaměstnance jednoduchý checklist. Například při onboardingu vývojáře si firma odškrtne: podepsaná pracovní smlouva, IP doložka, přístup do repozitáře, přístup do ticketovacího systému, NDA, školení k open-source licencím. U menšího produktu to zabere 20 minut, ale může to ušetřit statisíce až miliony korun při budoucím sporu.
Konkrétní příklad: firma vyvíjí interní CRM. Zaměstnanec vytvoří modul pro import dat a použije knihovnu s copyleft licencí bez kontroly. Pokud se později ukáže, že licence vyžaduje zveřejnění odvozeného díla, může to ohrozit celé komerční využití. Proto je nutné mít proces pro kontrolu licencí, například přes FOSSA, Snyk, Dependabot nebo Black Duck.
Open source, licence a komponenty třetích stran: nejčastější právní past
U softwaru vyvinutého zaměstnancem není problém jen v tom, komu patří vlastní kód, ale také v tom, co všechno je v něm použito. Moderní aplikace bývají složené z desítek až stovek balíčků. Například běžný webový projekt v Node.js může mít desítky přímých i nepřímých závislostí, z nichž každá má vlastní licenci.
Praktické minimum je zavést pravidlo, že žádná knihovna nesmí do produkce bez kontroly licence. Typicky se hlídá:
- MIT, Apache 2.0, BSD – obvykle bezpečné pro komerční použití, ale stále s povinností zachovat oznámení.
- GPL, AGPL – mohou zásadně omezit komerční model, zejména u SaaS a odvozených děl.
- Dual licensing – je nutné ověřit, zda je komerční licence skutečně zakoupena pro dané použití.
Pro kontrolu doporučuji kombinaci SBOM (Software Bill of Materials) a automatizované licence compliance. SBOM vám dá přehled o tom, z čeho je software složený, a je dnes stále častěji vyžadován i v enterprise prostředí. V praxi se používají nástroje jako Syft, CycloneDX, SPDX a napojení na CI/CD pipeline.
Pokud zaměstnanec vytváří vlastní plugin, skript nebo modul a použije do něj kód z veřejného repozitáře, je nutné mít evidenci původu. Nestačí spoléhat na to, že „je to z internetu“. Při auditu se řeší přesná licence, datum stažení, autor, verze knihovny a zda byla upravena. Z pohledu firmy je ideální mít jednoduchý proces: každá nová závislost jde přes pull request, bezpečnostní scan a schválení odpovědnou osobou.
Jak si práva pohlídat v praxi: proces, evidence a audit
Nejlépe funguje, když je ochrana práv součástí vývojového procesu, ne až právní oprava po problému. U menších firem stačí nastavit několik pevných bodů, u větších je vhodné zavést pravidelný audit alespoň jednou za půl roku.
- Repozitář pod firemním účtem – ne osobní GitHub zaměstnance.
- Commit policy – každý vývojář používá své jméno a firemní e-mail.
- Dokumentace architektury – minimálně diagram, popis modulů a vlastníků částí systému.
- Evidence licencí – seznam knihoven, verzí a povoleného použití.
- Pravidelné právní a bezpečnostní review – alespoň před releasem, velkým refaktoringem nebo vstupem investora.
Pro audit se hodí kombinace nástrojů: GitHub Advanced Security nebo GitLab Security pro scanning, Jira pro evidenci úkolů, Confluence nebo Notion pro dokumentaci a Drive/SharePoint pro smluvní archiv. Důležité je, aby bylo možné během několika hodin doložit, kdo software vytvořil, na základě čeho a jaká práva firma má.
V případě sporů rozhoduje i to, zda má firma důkazní stopu. Například pokud zaměstnanec odejde a začne tvrdit, že část kódu je jeho osobní dílo, pomůže historie commitů, ticketů, review komentářů a zadání v projektu. Čím lepší je proces evidence, tím menší je prostor pro nejasnosti.
Dobré pravidlo z praxe: u každého většího softwarového produktu si udělejte jednou ročně IP audit. Zkontrolujte smlouvy, seznam vývojářů, externí dodavatele, open-source závislosti, přístupy do repozitářů i stav dokumentace. Ve firmách, které plánují prodej, investici nebo expanzi do zahraničí, je to často rozdíl mezi hladkou transakcí a několikaměsíčním zpožděním.
Co si pohlídat při odchodu zaměstnance nebo při předávání projektu
Nejrizikovější okamžik nastává při odchodu klíčového vývojáře. Pokud měl přístup k architektuře, repozitářům, produkčním serverům a zároveň držel část know-how „v hlavě“, firma může ztratit kontinuitu. Proto je nutné mít předem nastavený offboarding proces.
Součástí by mělo být:
- okamžité odebrání přístupů do Git repozitářů, CI/CD, cloudu a správy domén,
- předání dokumentace, workflow a build skriptů,
- kontrola, zda zaměstnanec nepoužíval soukromé účty nebo osobní tokeny,
- převzetí odpovědnosti za klíčové moduly dalším členem týmu,
- revize NDA, konkurenční doložky a ustanovení o mlčenlivosti.
Pokud firma software dál rozvíjí, měla by mít jasně určeno, že veškeré změny jdou opět přes firemní systémy a že noví lidé vstupují do stejného právního režimu. U dlouhodobých projektů se vyplatí i průběžná revize smluv, zejména při změně pracovní pozice, přechodu na remote režim nebo změně typu odměňování.
V případě, že software vznikal v době, kdy firma neměla dobře nastavené smlouvy, je vhodné provést retrospektivní právní audit. Ten obvykle zahrnuje doplnění dodatků ke smlouvám, potvrzení převodu práv, identifikaci autorů jednotlivých částí a srovnání s historií vývoje. I když to není ideální, je to lepší než čekat na due diligence nebo spor s bývalým zaměstnancem.
