Smlouva o licenci k softwaru 2026 – EULA vzor pro firmy

Software je v Česku stejně chráněn jako román, fotka nebo socha — podle § 65 a § 66 autorského zákona 121/2000 Sb.je počítačový program autorské dílo a vztahuje se na něj plná ochrana, kterou autorský zákon poskytuje. To znamená, že nikdo nesmí tvůj software užít, rozmnožit, distribuovat ani upravit bez licence. A licence není formalita — je to smlouva, která určuje, co s tvým produktem klient může dělat, kdy za to platí a co se stane, když dohodu poruší.

V tomto průvodci projdeme kompletní anatomii softwarové licenční smlouvy (anglicky EULA — End User License Agreement) v roce 2026: rozdíl mezi proprietary, open source a Creative Commons, modely jednotlivá licence vs multilicence vs site license vs enterprise, časové vymezení (perpetuální vs subscription), územní rozsah, omezení použití, zákaz reverse engineering, aktualizace, GDPR pro uživatele, audit license, sankce a vzor pro proprietary i enterprise multilicenci. Cílovka: čeští softwaroví startupy, SaaS provozovatelé, vývojáři vlastních produktů a IT firmy, které chtějí přestat lepit EULA z anglických šablon a začít to dělat správně podle českého práva.

1. EULA pro tvůj software: kdy ji potřebuješ

Pokud distribuuješ vlastní software v jakékoli formě — instalační soubor, plugin do WordPress, mobilní aplikace, SaaS přístupný přes prohlížeč, knihovna v balíčkovém manažeru — potřebuješ licenční smlouvu. Bez ní není jasné, co uživatel smí. A pokud to není jasné, vykládá to za tebe soud, a vykládá to restriktivně v tvůj neprospěch jako poskytovatele.

EULA řeší pět základních otázek:

• Kdo smí software užívat (jeden uživatel, tým, celá firma).
• Kde smí být software nasazen (jeden stroj, jedna síť, celosvětově).
• Jak dlouho trvá oprávnění užít (jednorázově, předplatné, na dobu trvání autorských práv).
• Za jakých podmínek (počet uživatelů, výkon, instalací).
• Co nesmí (reverse engineering, další distribuce, sublicence, prodej).

Bez explicitní EULA se na klientův úmysl použít software vztahuje pouze úzká presumpce z § 66 odst. 1 AutZ — oprávněný uživatel programu smí provádět „úkony nezbytné k zavedení a užívání programu v souladu s jeho určením“. Cokoli nad rámec toho (víc instalací, sdílení s kolegy, další distribuce) už licenci vyžaduje. A pokud nemáš sepsanou, ze zákona presumuješ nevýhradní licenci v nejminimálnějším rozsahu — klient ti nezaplatí, kolik bys chtěl.

2. § 66 autorského zákona: software jako autorské dílo

Speciální status softwaru v českém autorském právu upravuje § 65 a § 66 zákona č. 121/2000 Sb.Tato dvě ustanovení obsahují klíčová pravidla, která by měl znát každý český softwarový podnikatel.

§ 65 AutZstanoví, že počítačový program je autorské dílo a chrání se jako literární dílo. Chrání se program v jakékoli formě — zdrojový kód, strojový kód, přípravné koncepční materiály. Nechrání se ale „myšlenky a principy, na nichž je založen kterýkoli prvek programu“ — algoritmus jako takový tedy chráněn není (na to slouží patenty, ale software patenty se v ČR a EU vydávají velmi zřídka).

§ 66 AutZ stanoví, co smí dělat oprávněný uživatel programu i bez výslovné licence:

• Pořídit si záložní kopii, je-li to nezbytné pro užívání.
• Provést činnosti nezbytné pro zavedení a užívání programu v souladu s jeho určením.
• Provést opravu chyb v programu, pokud je to nezbytné pro užívání.
• Provést dekompilaci v omezeném rozsahu pro účely dosažení interoperability s jinými programy (§ 66 odst. 1 písm. e).

Klíčové: tyto úkony nelze smluvně zcela vyloučit. EULA, která říká „jakákoliv dekompilace je zakázána“, je v rozsahu zákonné výjimky pro interoperabilitu neplatná. To je rozdíl proti americkému právu, kde si poskytovatel může v EULA zakázat prakticky cokoli.

3. Proprietary vs open source vs Creative Commons

Existují tři velké rodiny licencí, a každá má jinou logiku i ekonomický model. Volba mezi nimi není primárně právní rozhodnutí — je to obchodní strategie, kterou pak právník zformalizuje do licenční smlouvy.

3.1 Proprietary (uzavřená) licence

Klasický komerční model. Autor si nechává plnou kontrolu nad zdrojovým kódem, klient dostává jen oprávnění užívat zkompilovanou verzi (případně přístup k SaaS rozhraní). Příklady: Microsoft Office, Adobe Creative Cloud, JetBrains IDEs, Atlassian Jira. Z pohledu cash flow: dobré, predikovatelné, vysoké marže. Z pohledu adoption: pomalejší rozjezd, klienti chtějí vědět, co kupují, často vyžadují PoC nebo trial.

3.2 Open source licence

Zdrojový kód je veřejně dostupný a každý si ho může číst, kopírovat, upravovat a dál distribuovat, pokud dodrží podmínky konkrétní open source licence. Open source ale není zdarma ani public domain— je to právní režim s konkrétními pravidly, jejichž porušení může vést k žalobě.

Hlavní rodiny open source licencí:

• Permisivní— MIT, BSD, Apache 2.0. Smí se prakticky vše včetně použití v uzavřeném komerčním softwaru. Jediná povinnost: zachovat copyright notice.
• Copyleft— GPL v2/v3. Derivátní díla musí být publikována pod stejnou licencí. Virální charakter — jakmile použiješ GPL knihovnu, celý tvůj projekt musí být GPL.
• Slabý copyleft— LGPL, MPL. Compromise: dynamické linkování nezpůsobí virální efekt, ale úpravy samotné LGPL knihovny ano.

3.3 Creative Commons

Creative Commons je sada licencí pro nesoftwarová autorská díla— texty, foto, hudba, video. Pro samotný software se používá jen výjimečně (CC nedoporučuje používat CC licence na software, protože nepokrývají specifika softwarové distribuce). Pro dokumentaci k softwaru, šablony a obrázky v aplikaci se ale CC hodí dobře.

Rozumný hybridní přístup: software pod MIT nebo proprietary, dokumentace pod CC BY-SA, ikony pod CC BY. Každý artefakt má jasný režim, klient ví, co smí.

4. Licence pro uživatele vs distributor

Tady se hodně lidí ztrácí. Existují dva typy licenčních vztahů, a obě řeší jinou věc.

4.1 End User License (EULA)

EULA je smlouva mezi poskytovatelem softwarua koncovým uživatelem. Uživatel získává oprávnění software užít pro vlastní potřebu — spustit ho, využít jeho funkcí, případně si ho přizpůsobit. EULA typicky nepovoluje další distribuci— uživatel ho nesmí prodávat dál ani sdílet s třetími osobami.

Klasický scénář: B2C SaaS, kde si firma zaplatí předplatné a používá nástroj interně. Klasický scénář B2B: zakoupení ERP systému, který si firma nasadí na své servery a používá ji jen interní zaměstnanci.

4.2 Distribution / VAR License

Distribuční licence je smlouva mezi poskytovatelem softwaru a distributorem nebo VAR (Value Added Reseller), který software dál prodává koncovým klientům. Distributor si licenci dál „reprodukuje“ do EULA pro koncové uživatele — má právo poskytnout sublicenci.

Sublicence vyžaduje výslovný souhlas autora(§ 2364 NOZ). Bez tohoto ujednání není možné. Distribuční smlouva typicky obsahuje:

• Územní vymezení (kde smí distributor prodávat).
• Cenovou politiku (typicky procentní rabaty z MSRP).
• Závazek dodržovat brand guidelines.
• Reporting prodejů a audit.
• Termín a způsob obnovy (revolving annual).

5. Jednotlivá vs multilicence vs site license vs enterprise

Čtyři klíčové modely, jak prodávat software firmám. Každý má jinou cenovou logiku i jiné administrativní pozadí.

5.1 Multilicence v praxi

Nejčastější model pro české SaaS startupy. Typická struktura: prvních 5 uživatelů 990 Kč/měs/user, dalších 6–20 790 Kč/měs/user, 21+ 590 Kč/měs/user. EULA musí jasně říct, co je „uživatel“ — named user (konkrétní osoba), concurrent user (současně přihlášený), nebo registered user (kdokoli s účtem, i pasivní).

5.2 Site license

„Site“ znamená fyzickou lokalitu — jednu budovu, jeden kampus, jednu adresu. Klasické na univerzitách: licence pro celou univerzitu Karlovu v Praze (všichni studenti a zaměstnanci na pražských fakultách). Smlouva musí přesně definovat, co je site — jedna IČO, jedna IP adresa, jeden fyzický areál?

5.3 Enterprise license

Nejvyšší kategorie. Neomezený počet uživatelů v celé organizaci, typicky včetně dceřiných společností v zahraničí. Doprovází ji obvykle master service agreement (MSA)a několik statements of work (SOW)pro jednotlivé moduly nebo služby. Cena se negotsuje na míru, kontrakty bývají 3–5leté.

6. Časové vymezení: perpetuální vs subscription vs on-demand

Druhá zásadní volba po počtu uživatelů: na jak dlouho licenci prodáváš.

6.1 Perpetuální (věčná) licence

Klient zaplatí jednou a smí software užívat napořád. Klasický model 90. let — Microsoft Office na CD, AutoCAD, Adobe Photoshop. Velmi výhodný pro klienta krátkodobě, špatný pro poskytovatele dlouhodobě (žádný recurring revenue).

Perpetuální licence typicky obsahuje právo používat verzi aktuální v době zakoupení. Aktualizace a major upgrady jsou často placeny zvlášť (tzv. maintenance fee, typicky 20 % z licenční ceny ročně). Klient tak vlastně platí „permanentní subscription“, ale formálně je vlastníkem licence.

6.2 Subscription

Klient platí pravidelně — měsíčně nebo ročně. Když přestane platit, ztrácí přístup. Dnes dominantní model. Pro klienta: nižší vstupní bariéra, vždy aktuální verze, ale dlouhodobě dráž. Pro poskytovatele: predictable MRR/ARR, vyšší LTV.

Subscription smlouva musí jasně řešit:

• Automatickou obnovu — ano/ne, s jakou výpovědní lhůtou.
• Cenovou úpravu — smí poskytovatel zvyšovat cenu? O kolik? S jakým upozorněním?
• Data ownership — co se stane s daty klienta po ukončení (export, retention, GDPR výmaz).
• Suspense klauzuli — co se stane při prodlení s platbou (typicky 14 dní grace, pak suspense).

6.3 On-demand / pay-as-you-go

Klient platí za konkrétní využití — počet API calls, GB úložiště, počet zpracovaných dokumentů. Typické pro cloud infrastructure (AWS, GCP, Azure), API služby (OpenAI, Twilio), analytics platformy.

EULA u on-demand musí explicitně řešit metering — jak se měří spotřeba, kdo nese důkazní břemeno při sporu o objem, právo na audit ze strany klienta.

7. Územní vymezení: CZ vs EU vs globální

Software je přirozeně globální, ale licence být nemusí. Územní omezení dává smysl ze tří důvodů: cenová diferenciace, compliance s místními zákony, a zachování distribuční sítě.

7.1 Pouze ČR

Nejúžší rozsah. Klient smí software užívat jen v ČR — nasazení v dceřiné společnosti v Polsku už by vyžadovalo samostatnou licenci. Vhodné, pokud máš odlišnou cenovou politiku pro jednotlivé trhy.

7.2 EU/EHP

Sjednocený trh. Licence pro celé EU/EHP je často default pro evropské SaaS produkty. Pozor — v EU platí doktrína vyčerpání práv: pokud klient legálně zakoupí kopii softwaru v jednom členském státě, smí ji bez omezení používat v ostatních (rozsudek SDEU UsedSoft v. Oracle, C-128/11). To znamená, že územní omezení uvnitř EU je v určitých scénářích neúčinné.

7.3 Celosvětová licence

Worldwide license. Klient smí software užívat kdekoli na světě. Nejdražší varianta, typická pro enterprise klienty s globálními pobočkami. Pozor na export control regulace— software určité kategorie (kryptografie, dual-use technologie) nesmí být exportován do zemí pod sankcemi (Severní Korea, Írán, Rusko po roce 2022).

8. Omezení použití: uživatelé, instalace, výkon

Tady se v praxi rozhoduje, kolik klient zaplatí. Tři hlavní metriky:

8.1 Počet uživatelů

Klíčové je definovat, co to znamená „uživatel“:

• Named user— konkrétní jmenovaná osoba. Když odejde z firmy, licenci lze předat jinému zaměstnanci (typicky jednou za 6 měsíců, abys zabránil hopskotchingu).
• Concurrent user— současně přihlášený. Klient může mít 100 zaměstnanců, ale licence na 10 concurrent users znamená, že jen 10 se najednou přihlásí.
• Registered user— kdokoliv s aktivním účtem, i když ho nepoužívá. Nejvyšší cena, klient platí i za pasivní účty.

8.2 Počet instalací

Zejména u desktop softwaru. Klient smí nainstalovat na X strojů, i kdyby na nich pracoval jen on sám. Klasické u CAD aplikací (1 design engineer používá workstation v kanceláři a laptop na služebních cestách — potřebuje 2 instalace, 1 named user).

8.3 Výkonové limity

U serverového softwaru se licencuje podle výkonu hardware, na kterém běží: počet CPU jader, RAM, počet transakcí za vteřinu, počet zpracovaných záznamů. Klasické u databází (Oracle, MS SQL Server) nebo u ERP systémů.

Pozor: každé navýšení výkonu znamená nutnost upgradu licence. Klient nemůže koupit licenci na 4-core server a tajně ji nasadit na 32-core mainframe. To je důvod, proč si výrobci nárokují právo na audit (viz dále).

9. Reverse engineering: zákaz!

Reverse engineering je proces zkoumání softwaru za účelem pochopení, jak funguje — typicky dekompilace, disassembling, sniffing síťové komunikace. V EULA bývá obvykle zakázán.

Jak jsme zmínili výše, v ČR ho nelze zakázat absolutně. § 66 odst. 1 písm. e AutZ stanoví, že oprávněný uživatel smí dekompilovat program pro účely dosažení interoperability. Tedy: pokud tvůj software potřebuje komunikovat s programem konkurence, klient ho smí v omezeném rozsahu dekompilovat, aby pochopil rozhraní.

Co lze v EULA platně zakázat:

• Reverse engineering za účelem replikace algoritmů.
• Extrakci obchodního tajemství (zdrojový kód, knowhow).
• Vytváření konkurenčního produktu na základě reverse engineered poznatků.
• Publikaci výsledků reverse engineering (white papers, blog posty).
• Sdílení dekompilovaného kódu třetím stranám.

Typická formulace v EULA: „Nabyvatel se zavazuje neprovádět reverse engineering, dekompilaci ani disassembling Softwaru, s výjimkou rozsahu výslovně povoleného závaznými právními předpisy (zejména § 66 odst. 1 písm. e zákona č. 121/2000 Sb.). Výsledky takto získané smí Nabyvatel použít výhradně k zajištění interoperability s vlastním softwarem Nabyvatele a nesmí je dále distribuovat ani publikovat.“

10. Aktualizace a podpora

Klíčové ujednání v každé EULA. Klient potřebuje vědět, co dostává: jen samotný software, nebo i následné updaty? Major upgrady, nebo jen bug fixes? Telefonickou podporu, nebo jen knowledge base?

10.1 Typy aktualizací

• Bug fix release(1.0.0 → 1.0.1) — opravy chyb. Typicky zdarma součástí licence.
• Minor release(1.0 → 1.1) — nové funkce, ale ne breaking changes. Často zdarma u subscription, placené u perpetuální.
• Major release(1.0 → 2.0) — významné změny, často breaking. Typicky placené i u subscription (upsell na vyšší tier).

10.2 Úrovně podpory

• Self-service— dokumentace, knowledge base, fórum. Zdarma součást licence.
• Standard support— email response do 24 hodin v pracovní době. Součást licence nebo placené.
• Premium support— telefonní podpora, SLA reakce do 4 hodin, dedikovaný account manager. Placené (typicky 15–25 % z licenční ceny ročně).
• Enterprise support— 24/7 reakce do 1 hodiny, on-site help, custom SLA. Placené, vysoké částky.

11. Ochrana osobních údajů uživatelů (GDPR)

Pokud tvůj software zpracovává osobní údaje — a v praxi prakticky každý moderní software je zpracovává, alespoň přes login a usage analytics — musíš v EULA řešit GDPR compliance.

11.1 Role: správce vs zpracovatel

Při SaaS klient typicky vystupuje jako správce(data controller) — rozhoduje, co se s daty dělá. Ty jako poskytovatel softwaru jsi zpracovatel(data processor) — zpracováváš data podle pokynů klienta.

Vztah mezi správcem a zpracovatelem musí být upraven písemnou smlouvou o zpracování osobních údajů (Data Processing Agreement, DPA). Tu typicky připojuješ jako přílohu k EULA. Obsahuje:

• Předmět a doba trvání zpracování.
• Povaha a účel zpracování.
• Typ osobních údajů a kategorie subjektů údajů.
• Povinnosti a práva správce.
• Technická a organizační opatření.
• Pravidla pro sub-procesory.
• Pravidla pro mezinárodní přenos dat (mimo EU).
• Spolupráce při výkonu práv subjektů údajů.
• Pravidla pro oznamování úniků dat.
• Vrácení / výmaz dat po skončení smlouvy.

11.2 Mezinárodní přenos dat

Pokud zpracováváš data v USA (typicky AWS, GCP, Azure regiony US), potřebuješ standardní smluvní doložky(SCC) podle rozhodnutí Evropské komise 2021/914, případně certifikaci podle EU-US Data Privacy Framework(od července 2023). Pro Velkou Británii po Brexitu platí UK SCC.

12. Audit license: právo dodavatele

Audit license je standardní ujednání u enterprise EULA, ve kterém si poskytovatel vyhrazuje právo prověřit, zda klient používá software v souladu s licencí. Důvody: typicky odhalení nelicencovaných uživatelů, instalací na více strojích, použití nad sjednaný výkonový limit.

12.1 Typické ujednání

„Poskytovatel je oprávněn nejvýše jednou ročně provést audit užívání Softwaru Nabyvatelem. Audit se uskuteční po předchozím písemném oznámení nejméně 30 dní předem v pracovní době Nabyvatele. Audit nesmí narušit běžný provoz Nabyvatele. Náklady auditu nese Poskytovatel, ledaže by audit prokázal porušení licence nad 5 % sjednaného rozsahu — v takovém případě nese náklady auditu Nabyvatel a doplatí licenci za neoprávněné užití.“

12.2 Praktická realita

V praxi se audity dělají velmi zřídka — jsou drahé a vztah s klientem se po nich obvykle zhorší. Většinou jde o „atomic option“, který poskytovatel použije, když má silný signál, že klient podvádí (whistleblower, veřejná zmínka o nadměrné spotřebě, atd.).

U moderních SaaS produktů audit license ztrácí význam, protože poskytovatel má přímý přehled o spotřebě přes telemetrii a usage tracking. Audit zůstává relevantní u on-premise enterprise nasazení (SAP, Oracle, IBM), kde poskytovatel klientovo prostředí nevidí.

13. Porušení licence: sankce a výpovědní právo

Sankce za porušení licence by měly být v EULA explicitní. Bez nich má klient malou motivaci dodržovat sjednané limity — a soudní vymáhání bezsankčního porušení je v ČR komplikované.

13.1 Typy porušení

• Nelicencované užití — klient používá víc uživatelů, instalací nebo výkon, než licence povoluje.
• Neoprávněná modifikace — klient modifikuje software v rozporu s EULA.
• Neoprávněná sublicence — klient poskytuje přístup třetím stranám.
• Reverse engineering — klient dekompiluje za zakázaným účelem.
• Prodlení s platbou — klient neplatí licenční poplatek.

13.2 Sankční mechanismy

EULA může kombinovat několik sankčních mechanismů:

• Smluvní pokuta— typicky 5× ročního licenčního poplatku za neoprávněné užití, plus 50 000 Kč za každý den prodlení s nápravou.
• Náhrada škody— nad rámec smluvní pokuty, pokud lze prokázat konkrétní škodu (ušlý zisk z legálních klientů, kteří odešli kvůli levnější nelegální verzi).
• Vrácení licenčního poplatku— u podstatného porušení, poskytovatel může požadovat vrácení částek, které již obdržel.
• Výpovědní právo— při podstatném porušení smí poskytovatel okamžitě odstoupit od smlouvy a deaktivovat klientovi přístup k softwaru.

14. Vzor EULA pro proprietary software

Tady je vzor klíčových ustanovení EULA pro proprietary SaaS nebo desktop produkt. Ne kompletní text, ale strukturovaná kostra, kterou si můžeš nahrát do Dokumentomatu jako svoji šablonu a generovat z ní jednotlivé smlouvy.

15. Vzor enterprise multilicence: klíčové dodatky

Pro enterprise klienty je standardní EULA nedostatečná. Klíčové dodatky a změny:

• MSA + SOW struktura— rámcová smlouva Master Service Agreement, ke které se přilepují jednotlivé Statements of Work pro konkrétní moduly.
• SLA dodatek— explicitní dostupnost (99.5 %, 99.9 %), reakční doby na incident, sankce za nedodržení (kredit, vrácení části poplatku).
• Bezpečnostní příloha— ISO 27001 certifikace, penetration testing, SOC 2 audit, kybernetická bezpečnost dle NIS2.
• Custom DPA— specifický pro enterprise klienta (často klient přinese vlastní šablonu).
• Source code escrow— uložení zdrojového kódu u nezávislé třetí strany (advokát, notář) pro případ, že by Poskytovatel zanikl — klient pak může získat zdrojový kód a zajistit si vlastní vývoj.
• Anti-bribery klauzule— pro globální enterprise klienty (FCPA, UK Bribery Act).
• Most favored nation— klient požaduje, aby získával nejlepší podmínky jako kterýkoli jiný klient.
• Audit ze strany klienta— right to audit poskytovatele (typicky max. 1x ročně, 30 dní oznámení, NDA).
• Insurance requirements— minimální pojistné krytí poskytovatele (typicky 10–50 milionů Kč profesní odpovědnost).

16. Časté chyby v softwarových licencích

16.1 Vágní rozsah licence

Smlouva říká „klient smí Software užívat pro své podnikání“. To je k ničemu — co když má klient 50 zaměstnanců, ale jen 5 z nich Software reálně používá? Mohou ostatní zaměstnanci taky? A co dceřiná společnost? A externí dodavatelé na projektu klienta?

Lék: exaktní definice uživatele (named / concurrent / registered) a explicitní vyjmenování, kdo do kategorie spadá a kdo ne.

16.2 Chybějící GDPR ujednání

EULA, která neobsahuje DPA, je v případě sporu velký problém. Klient může tvrdit, že nesouhlasil se zpracováním jeho dat, a Úřad pro ochranu osobních údajů (ÚOOÚ) může uložit pokutu až 20 milionů eur nebo 4 % celosvětového obratu.

Lék: DPA jako povinná příloha EULA, jasně nastavené role (správce vs zpracovatel), seznam sub-procesorů, pravidla pro mezinárodní přenos.

16.3 Žádné auditní právo

Bez ujednaného práva na audit nemá poskytovatel způsob, jak ověřit, že klient nepoužívá Software nad rámec licence. Pokud klient zaplatil za 10 uživatelů a používá ho pro 100, bez auditu se to nedozvíš.

Lék:standardní auditní klauzule (1× ročně, 30 dní oznámení, klient platí při porušení nad 5 %).

16.4 Neřešený exit plán

Co se stane s daty klienta po ukončení smlouvy? Export do kterého formátu? Jak dlouho po ukončení smí klient ještě stáhnout svá data? Co se nechá uložené po jakou dobu?

Lék: explicitní exit klauzule. Typický scénář: 30 dní po ukončení smlouvy export dat ve standardním formátu (JSON, CSV), pak 90 dní retention v cold storage, poté nevratná destrukce v souladu s GDPR.

Závěr

Softwarová licence není formalita ani „právnické otravování“. Je to klíčový dokument, který určuje, jestli tvůj software bude generovat predikovatelný revenue, nebo bude každý spor s klientem znamenat nervy a ztrátu času.

Klíčové, co si z tohoto článku odnést:

• Software je v ČR autorské dílo dle § 65 AutZ. Bez licence nikdo nesmí užít, rozmnožit ani distribuovat.
• § 66 AutZ stanoví neopominutelná práva uživatele — záložní kopie, oprava chyb, dekompilace pro interoperabilitu. EULA je nemůže vyloučit.
• Volba mezi proprietary, open source a Creative Commons je obchodní strategie, ne jen právní formalita.
• Klíčové parametry: kdo (uživatelé), kde (území), jak dlouho (čas), jak (rozsah), kolik (cena), co nesmí (reverse engineering, sublicence, prodej).
• GDPR DPA je povinnou přílohou každé EULA, která zpracovává osobní údaje.
• Auditní právo, sankce a exit plán musí být v každé enterprise smlouvě.
• Pro globální klienty potřebuješ MSA + SOW + DPA + SLA jako balíček, ne jediný dokument.