Open-source licence pro web3 projekty: MIT, GPL a obchodní modely

Proč licence ve web3 světě záleží více, než si myslíte

V open-source kultuře web3 se kód sdílí, forkuje a nasazuje rychle – avšak právní rámce se vyvíjejí pomaleji. Licence určuje, jak mohou ostatní používat váš kód, zda musí své změny zveřejnit a zda jsou chráněny patenty. Ve web3 má výběr licence svá specifika: smart kontrakty běží bez povolení, frontend a indexery jsou často oddělené, na scéně jsou tokeny a správa formou DAO a produkty jsou „forkovatelné“ během jednoho víkendu. Tento článek porovnává MIT a rodinu GPL, vysvětlí dopady na architekturu web3 a načrtne udržitelné byznys modely, aniž byste opustili principy otevřeného softwaru.

Rychlý přehled licencí: permisivní vs. copyleft

Permisivní licence (MIT, BSD, Apache-2.0): umožňují téměř neomezené použití, i v uzavřených projektech. Obvykle vyžadují uvedení copyrightu a odmítnutí záruk.
Copyleft licence (GPLv3, AGPLv3, LGPLv3): vyžadují, aby odvozená díla zůstala otevřená pod stejnou licencí. Dbejte na definici „odvozeného díla“ a „linkování“.
Síťově zaměřený copyleft (AGPL): zveřejnění změn je třeba i při poskytování jako síťové služby (SaaS), nejen při distribuci binárky.
Hybridy a „source-available“ licence (BSL, BUSL, SSPL, Prosperity, Polyform): kód je sice k dispozici, ale s významnými omezeními (zejména komerčního využití); právně není open-source podle OSI.

MIT: jednoduchá permisivní volba

MIT je nejkratší a nejjednodušší licence s minimálními povinnostmi: zachovat copyright notice a disclaimer. V praxi:

Výhody: rychlá adopce, kompatibilita, jednoduchá integrace do jiných projektů, nízká právní režie.
Nevýhody: umožňuje komerční fork bez povinnosti přispět zpět; riziko „vendor capture“ u populárních projektů.
Pro web3: výborná pro knihovny, SDK, specifikace a nástroje, kde prioritou je síťový efekt.

GPLv3/LGPLv3: reciprocita a hranice „linkování“

GPLv3 vyžaduje, aby odvozená díla byla poskytnuta pod GPLv3 a zdroj byl zpřístupněn. LGPLv3 je mírnější: umožňuje linkování z proprietárního softwaru, ale změny v samotné knihovně musí zůstat otevřené.

Výhody: chrání před přivlastněním inovací; nutí komerční uživatele sdílet vylepšení.
Nevýhody: nižší adopce u některých korporací; právní nejasnosti kolem definice „odvozeného díla“ při mikroservisní a kontraktní architektuře.
Pro web3: vhodné pro core protokoly, které chtějí reciprocitu inovací; LGPL poskytuje flexibilní kompromis pro knihovny.

AGPLv3: když „SaaS = distribuce“

AGPLv3 rozšiřuje copyleft do síťové vrstvy: pokud poskytujete službu nad kódem AGPL, musíte zpřístupnit zdrojové úpravy uživatelům služby. To je klíčové pro hostované indexery, API brány, relaye, sequencery a web3 backend služby.

Výhody: brání „free-ridingu“ poskytovatelů služeb; stimuluje veřejné sdílení patchů.
Nevýhody: odrazuje některé komerční integrace; vyžaduje důslednou compliance v CI/CD.
Pro web3: doporučuje se pro backend komponenty; méně vhodná pro knihovny/SDK.

Apache-2.0: permisivní licence s patentovým grantem

Apache-2.0 je permisivní jako MIT, ale přidává výslovný patentový grant a terminaci, což je důležité v ekosystémech s potenciálními patentovými nároky (např. kryptografické primitiva, zk-SNARKy).

Výhody: chrání komunitu před patent trollingem; dobrá kompatibilita a adopce v enterprise prostředí.
Nevýhody: delší text a mírně vyšší právní režie než MIT.
Pro web3: doporučená volba pro core knihovny kryptografie, klienty a indexační frameworky.

„Source-available“ licence: BSL, BUSL, SSPL a spol.

Licence jako BSL/BUSL/SSPL/Prosperity/Polyform umožňují čtení kódu, ale omezují komerční využití nebo hosting. Nejsou OSI-open-source.

Kdy dávají smysl: pokud chcete zabránit tomu, aby velký poskytovatel „obalil“ váš kód a monetizoval jej bez přínosu zpět.
Trade-off: menší komunitní adopce, konflikty s OSS ekosystémy a distribučními kanály.
Pro web3: použitelné pro doplňkové služby (např. hostované indexery), méně vhodné pro smart kontrakty, kde je klíčová interoperabilita.

Licencování smart kontraktů: co je „odvozené dílo“ na blockchainu?

U smart kontraktů se právní teorie setkává s praxí:

Kompozice a linkování: importy, inheritance a library linking mohou tvořit odvozená díla. U copyleft licencí počítejte s povinností sdílet zdrojové úpravy.
ABI kompatibilita sama o sobě obvykle neznamená odvozené dílo; ale kopírování zdroje nebo inheritance ano.
On-chain bytecode: veřejný bytecode ≠ automatické OSI „otevření“; licence stále rozhoduje, zda je použití povoleno.
Front-end vs. kontrakty: běžná praxe je permisivní licence pro kontrakty (kvůli sdílení standardů) a odlišná licence pro infrastrukturu a UI.

Licence pro NFT a obsah: kód ≠ umělecké dílo

Licence k kódu automaticky neplatí na assety (obrázky, hudba, texty). Pro NFT zvažte:

CC0: svobodná kulturní licence, ideální pro memetiku a deriváty.
CC-BY/CC-BY-SA: vyžaduje uvedení autora, SA zachovává licenční „infekt“.
NFT specifické licence: omezení komerčního použití, povolení merchu do určitého limitu apod.
Ochranné známky: značka není automaticky pokryta OSS licencí; mějte samostatně trademark policy.

Kompatibilita a SPDX: jak se vyhnout licenčním konfliktům

SPDX identifikátory: uvádějte v hlavičce souborů SPDX-License-Identifier (např. MIT, GPL-3.0-or-later).
„Or later“ klauzule: zvyšují kompatibilitu během dlouhého životního cyklu projektu.
Vendorování knihoven: u copyleft závislostí sledujte, zda jejich použití neaktivuje povinnosti na celé repozitář.
Dual-licensing: kombinujte GPL pro komunitu a komerční licenci pro integrátory, kteří nechtějí sdílet změny.

CLA vs. DCO: příspěvky a budoucí možnost relicencování

Chcete-li později změnit licenci nebo vydávat dual-licenci, potřebujete právní jistotu:

CLA (Contributor License Agreement): autor uděluje práva projektu; vyšší administrativa, ale větší flexibilita do budoucna.
DCO (Developer Certificate of Origin): jednodušší proces (Signed-off-by), slabší možnosti relicencování.
DAO správa: pokud vlastníkem copyrightu je nadace/DAO, definujte proces schvalování licenčních změn a správu práv.

Bezpečnost a odpovědnost: disclaimery, audit a záruky

V kryptoprostoru je riziko finanční ztráty přímým důsledkem chyb. Licence typicky vylučují záruky („AS IS“), ale z praxe:

Responsible disclosure a bug bounty programy: definujte kanály, SLA a odměny.
Audit policy: odlište „auditované“ verze (tagy, commit hash, podpisy) od experimentálních.
Semver a upgrade policy: usnadněte downstream projektům bezpečné aktualizace bez způsobení breaking změn.

Byznys modely pro OSS web3: od komunity k příjmům

Open core: jádro pod MIT/Apache, přidané enterprise funkce (observabilita, governance tooling, hosting) pod komerční licencí.
Hosting a správa (SaaS): manažované indexery, archivní noddy, relaye a sequencer služby; vhodné kombinovat s AGPL pro serverovou část nebo s komerční licencí.
Podpora a SLA: placené smlouvy na integrace, prioritní opravy, bezpečnostní backporty.
Audit a bezpečnost: placené audity smart kontraktů, formální verifikace, školení.
Marketplace a ekosystémové poplatky: malé poplatky za prémiové funkce (RFQ routing, MEV ochrana), při zachování OSS jádra.
Dual licensing: GPL/AGPL pro komunitu + komerční licence pro poskytovatele, kteří nechtějí sdílet úpravy.
Nadace a granty: financování z foundation/ekosystémových fondů; transparentní rozpočty a roadmapy.

Strategie proti „bezpříspěvkovému forku“

Silná značka a trademark policy: chrání název a loga; fork nesmí použít identickou značku.
Síťové efekty: datové formáty, indexy, reputační systémy, které ztěžují „drop-in“ náhradu.
Komunitní vazby: granty, governance fórum, transparentní roadmap – fork bez komunity má menší šanci.
AGPL/SSPL pro server-side (pokud akceptujete „ne-OSI“ u SSPL): snižuje motivaci hostovat bez přispění.

Praktický výběr licence podle modulu

Smart kontrakty (core protokol): MIT nebo Apache-2.0 pro maximalizaci interoperability; případně GPLv3, pokud chcete reciprocitu u derivátů.
Knihovny/SDK: Apache-2.0 (patentový grant) nebo MIT; pro „sticky contribution“ LGPLv3.
Backend služby/indexery: AGPLv3 nebo „open core“ s komerční nadstavbou.
Frontend/UX: permisivní licence + ochrana značky; obsah a assety pod CC (např. CC-BY).

Licenční compliance v CI/CD a řetězci nástrojů

SBOM (Software Bill of Materials): generujte SBOM (CycloneDX/SPDX) při buildech; automatické skeny licencí.
Policy gates: blokujte závislosti s nekompatibilní licencí; whitelist OSI licencí.
NOTICE a COPYRIGHT soubory: zachovávejte a agregujte „NOTICE“ u Apache-2.0 závislostí.
Verifikované releasy: podepsané tagy (sigstore/cosign), reprodukovatelné buildy a kontrola hashů auditovaných verzí.

DAO a licence: kolektivní rozhodování o IP

Pokud IP drží nadace nebo DAO, stanovte:

Mandát pro licenční změny: jaké kvórum a procedura jsou potřebné pro relicencování nebo dual-licensing.
Příspěvkové smlouvy: CLA podepsané s entitou (nadace), nikoliv s „kandidátem davu“.
Grantové podmínky: příjemci grantů obvykle musí používat OSI licence a dodat SBOM.

Scénáře: rozhodovací matice

Chci rychlou adopci a minimum právních bariér → MIT/Apache-2.0.
Chci reciprocálně sdílet vylepšení → GPLv3 (aplikace) nebo LGPLv3 (knihovny).
Provozuji službu a nechci „closed forks“ → AGPLv3 (případně dual-licensing).
Chci monetizovat hosting a enterprise → open core + komerční licence, případně „source-available“ pro ne-core moduly.

Časté omyly a úskalí

„AGPL udělá projekt neadoptovatelným“: u backend služeb může být přínosem; zvolte hybrid (SDK MIT, server AGPL).
„MIT je vždy lepší“: ne vždy – pokud vám hrozí komerční „strip-mining“, volte reciprocitu nebo byznys model, který vás ochrání.
biz model GPL kompatibilita licencie MIT open-source OSS licencie pre web3 príspevky