Proč je vlastnictví produktu potřeba řešit hned na začátku
V praxi se často stává, že produkt vzniká „na důvěru“: dva nebo tři společníci si rozdělují práci, někdo programuje, jiný dělá design a další obchod. Dokud vše funguje, téma vlastnictví se odkládá. Jenže při první větší investici, odchodu jednoho člena nebo sporu o směr projektu se ukáže, že není jasné, kdo vlastní zdrojový kód, doménu, grafiku, databázi, brand ani účet na cloudové službě.
To je zásadní problém. Investor bude chtít vidět, že společnost nebo tým má čistý řetězec práv k tomu, co vyvíjí. U software produktů se běžně kontroluje, zda jsou práva ke kódu převedena na firmu, zda jsou všechny externí části licenčně v pořádku a zda nikdo z bývalých spolupracovníků nemůže tvrdit, že je spoluvlastníkem klíčové části řešení.
U menších projektů se chyba projeví i bez právní bitvy: jeden společník si odnese přístupy, druhý začne produkt dál rozvíjet pod podobným názvem a třetí tvrdí, že mu patří design i obsah. Náklady na pozdější nápravu bývají výrazně vyšší než náklady na správné nastavení na začátku.
Rozdělení práv mezi společníky: co musí být napsané černé na bílém
Základ je rozlišit několik vrstev vlastnictví. Nejde jen o „kdo je zakladatel“, ale o to, kdo vlastní jednotlivé části produktu a za jakých podmínek přecházejí na firmu.
1. Kdo vlastní výsledky práce
Pokud více společníků vyvíjí produkt, je potřeba jasně určit, zda výsledky jejich práce vznikají:
- jako dílo na objednávku pro společnost,
- jako společné dílo více autorů,
- nebo jako individuální dílo, které se následně převádí na firmu.
Pro startupovou praxi je nejčistší model, kdy každý zakladatel i externista podepíše smlouvu o převodu práv nebo licenční ujednání tak, aby firma získala plná uživatelská i majetková práva k výsledku. Bez toho může zůstat část IP „uvězněná“ u konkrétní osoby.
2. Kód, design, texty a databáze nejsou totéž
U software produktu je běžné, že na něm pracuje programátor, UX designer, copywriter a třeba i datový analytik. Každá z těchto rolí vytváří jiný typ výstupu:
- zdrojový kód a technická dokumentace,
- vizuální návrhy a UI komponenty,
- texty, mikrocopy a obchodní obsah,
- databázové struktury a datové modely,
- značka, logo a domény.
Každá z těchto oblastí by měla mít vlastní doložku, že práva přecházejí na společnost nebo že společnost získává výhradní licenci. Nestačí obecná věta typu „všechno, co dělám, patří firmě“, pokud není právně správně formulovaná.
3. Podíly ve firmě nejsou totéž co práva k IP
Častá chyba: zakladatelé si myslí, že když mají ve firmě stejný podíl, automaticky tím vyřešili i vlastnictví produktu. Není to pravda. Podíly řeší ekonomickou účast ve společnosti, ale ne nutně to, komu patří kód, grafika nebo ochranná známka.
Prakticky to znamená, že i společník s menšinovým podílem může mít právní nárok na část díla, pokud nebylo převzetí práv ošetřeno smluvně. A naopak: většinový vlastník firmy nemusí mít automaticky nárok používat produkt, pokud práva zůstala na fyzické osobě.
Jak nastavit smlouvy, aby byl projekt právně čistý
Nejspolehlivější je kombinace několika dokumentů. V praxi se osvědčuje mít minimálně zakladatelskou dohodu, smlouvu o převodu práv k dílu, NDA a pravidla pro přístup k repozitáři, doménám a účtům.
Zakladatelská dohoda
Zakladatelská dohoda by měla obsahovat:
- kdo je spoluzakladatel a jaká je jeho role,
- jaké jsou podíly a za co byly získány,
- co se stane při odchodu jednoho ze společníků,
- jak se řeší rozhodování o produktu,
- kdo schvaluje použití rozpočtu a externích dodavatelů,
- jak se zachází s IP vytvořeným před vznikem firmy.
U startupů je důležité doplnit i tzv. vesting, tedy postupné nabývání podílů. Běžný model je 4 roky s 1letým cliffem. Pokud někdo odejde po třech měsících, neměl by automaticky držet plný podíl za budoucí hodnotu projektu.
Převod práv k dílu a licence
Pokud zakladatelé programují ještě před založením společnosti, je vhodné mít samostatnou smlouvu o převodu práv nebo alespoň výhradní licenci s možností dalšího postoupení na firmu. U externích vývojářů a designérů to platí dvojnásob.
U české praxe je důležité hlídat, aby smlouva přesně určovala:
- rozsah díla,
- územní a časový rozsah užití,
- odměnu za převod práv,
- možnost úprav a odvozených děl,
- právo dílo dále prodávat, licencovat a integrovat do dalších produktů.
Bez výslovné úpravy může být problém i s tím, že firma sice kód používá, ale nemůže ho legálně upravovat nebo komerčně šířit v plném rozsahu.
NDA a pravidla přístupu
NDA samo o sobě vlastnictví neřeší, ale chrání know-how a obchodní tajemství. U produktů v rané fázi je vhodné definovat, co je důvěrná informace, kdo k ní má přístup a jak dlouho mlčenlivost trvá. Současně je praktické nastavit přístupy do nástrojů podle principu nejmenších oprávnění.
Užitečné nástroje pro správu přístupů a důkazů o vlastnictví:
- GitHub / GitLab pro audit commitů a historii změn,
- Google Workspace / Microsoft 365 pro vlastnictví dokumentů a domén,
- 1Password / Bitwarden pro sdílené přístupy,
- Notion / Confluence pro dokumentaci rozhodnutí,
- DocuSign / Signi / Bankovní identita pro elektronické podepisování.
Praktický postup: jak si vlastnictví pohlídat v každé fázi vývoje
Nejlepší je vytvořit jednoduchý, ale důsledný proces. Nečekejte na právní problém, až budete řešit investici nebo exit. Vlastnictví se má dokumentovat průběžně.
Fáze 1: nápad a prototyp
V této fázi často vzniká nejvíc nejasností, protože se pracuje neformálně. Doporučuji hned na začátku sepsat:
- kdo přišel s původním nápadem,
- kdo financuje první vývoj,
- kdo má kontrolu nad doménou a hostingem,
- kdo bude právním vlastníkem prototypu.
U prototypu je vhodné ukládat verze návrhů do repozitáře nebo do sdíleného úložiště s historií změn. To pomáhá později doložit autorství a časovou posloupnost.
Fáze 2: MVP a první uživatelé
Jakmile produkt získává první zákazníky, je potřeba mít čistě nastavené obchodní vztahy. Pokud například jeden ze společníků fakturuje vývoj jako OSVČ, ale výstup má patřit firmě, musí být v dokumentech jasně uvedeno, že odměna zahrnuje i převod práv.
V této fázi se také často objevují externí konzultanti. U nich je vhodné mít smlouvu ještě před zahájením práce, ne až po dodání výstupu. Dodatečné dohánění dokumentace je slabé při due diligence a často zbytečně prodlužuje investiční proces.
Fáze 3: růst, investor a exit
Při vstupu investora se kontroluje zejména to, zda veškerá práva patří společnosti. Pokud ne, může investor požadovat doplnění smluv, escrow řešení nebo přímý převod práv od jednotlivců na firmu. To umí transakci zpomalit o týdny až měsíce.
U větších startupů je běžné, že právní audit odhalí drobnosti jako:
- doména je registrovaná na soukromou osobu,
- Figma účet je na freelancera,
- část kódu vznikla v rámci jiného projektu,
- chybí souhlas s použitím open-source komponent pod nevhodnou licencí.
Takové problémy je lepší řešit dřív, než se objeví na due diligence checklistu.
Nejčastější chyby a jak se jim vyhnout
V praxi se stále opakují stejné chyby. Nejčastější je spoléhání na ústní dohodu. Ta může fungovat mezi přáteli, ale v okamžiku sporu je obtížně vymahatelná. Další častý problém je používání open-source knihoven bez kontroly licence. Například licence typu GPL může mít pro komerční produkt zásadní dopady, pokud není správně implementována.
Další rizika:
- doména a hosting na soukromé kartě jednoho člověka,
- zdrojový kód v osobním GitHub účtu bez firemní správy,
- bez smluv s externisty,
- nejasné rozdělení mezi spoluzakladateli,
- chybějící evidence, kdo co vytvořil.
Velmi praktické je zavést interní checklist pro každou novou část produktu. U každého výstupu si položte tři otázky: kdo je autor, kdo je vlastníkem a jaké jsou podmínky použití. Tato jednoduchá disciplína ušetří mnoho času i peněz.
Co si pohlídat v dokumentaci, aby byl produkt připravený na růst
Dobře připravený produkt má v dokumentaci nejen popis funkcí, ale i právní a provozní stopu. Vhodné je mít centrální složku nebo wiki, kde budou uložené:
- zakladatelská dohoda,
- smlouvy o převodu práv,
- seznam externistů a jejich rozsah práce,
- seznam použitých open-source komponent a licencí,
- přehled domén, hostingů, cloudů a účtů,
- evidence přístupů a vlastníků klíčových služeb.
Pokud chcete být připravení na investora nebo prodej firmy, vyplatí se udělat si interní „IP audit“ alespoň jednou za kvartál. U malého týmu zabere několik hodin, ale dokáže odhalit problémy včas. U produktů, kde se počítá s růstem, je to stejně důležité jako monitoring výkonu nebo analytika.
Vlastnická práva nejsou administrativní formalita, ale základní ochrana hodnoty produktu. Čím dříve je nastavíte, tím menší riziko, že se z technického projektu stane právní spor.
