Open-source licence pro Web3: MIT, GPL a jejich dopad na podnikatelský model projektu

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

V open-source kultuře Web3 se kód sdílí, forkne 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í zveřejnit své úpravy a zda jsou chráněny patenty. Ve Web3 má volba licence svá specifika: smart kontrakty běží bez povolení, frontend a indexery jsou často oddělené, na scéně jsou tokeny a DAO governance, a produkty jsou často „forkovatelné“ během jednoho víkendu. Tento článek porovná licence MIT a GPL, vysvětlí dopady na architekturu Web3 a naznačí udržitelné obchodní modely, aniž byste museli opustit 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í, včetně uzavřených projektů. Obvykle vyžadují uvedení copyrightu a disclaimerů.
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 povinné i při provozu softwaru jako síťové služby (SaaS), nejen při distribuci binárního kódu.
Hybridní a „source-available“ licence (BSL, BUSL, SSPL, Prosperity, Polyform): kód je sice dostupný, ale s významnými omezeními (zejména komerčního využití); právně nejde o open-source podle OSI.

MIT: jednoduchá permisivní volba

MIT je nejkratší a nejjednodušší licence s minimálními povinnostmi: zachovat copyrightové oznámení a disclaimer. V praxi:

Výhody: rychlá adopce, kompatibilita, snadné začlenění 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: ideální pro knihovny, SDK, specifikace a nástroje, kde je prioritou síťový efekt.

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

GPLv3 vyžaduje, aby odvozená díla byla poskytována pod GPLv3 a zpřístupnila zdrojové kódy. 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 v některých korporacích; právní nejasnosti ohledně definice „odvozeného díla“ u mikroservisní a kontraktní architektury.
Pro Web3: vhodné pro vývoj jádrových protokolů, které chtějí recipročně sdílet inovace; LGPL nabízí flexibilní kompromis pro knihovny.

AGPLv3: když „SaaS = distribuce“

AGPLv3 rozšiřuje copyleft také do síťové vrstvy: pokud provozujete službu postavenou na kódu pod AGPL, musíte uživatelům služby zpřístupnit zdrojové úpravy. To je klíčové pro hostované indexery, API gatewaye, relaye, sequencery a backendové služby Web3.

Výhody: zabraňuje „free-ridingu“ poskytovatelů služeb; podporuje veřejné sdílení změn.
Nevýhody: může odradit některé komerční integrace; vyžaduje důsledné dodržování při CI/CD.
Pro Web3: vhodné pro backendové komponenty; méně vhodné pro knihovny a 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 ukončení licence, což je důležité v ekosystémech s potenciálními patentovými nároky (například kryptografické primitivy, zk-SNARKy).

Výhody: chrání komunitu před patentovým trollingem; dobrá kompatibilita a adopce v korporátním prostředí.
Nevýhody: delší text a mírně vyšší režie než MIT.
Pro Web3: doporučená volba pro klíčové 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í použití nebo hosting. Nejsou OSI-kompatibilní jako open-source.

Kdy dávají smysl: pokud chcete zabránit tomu, aby velký poskytovatel „obalil“ váš kód a monetizoval jej bez přispění 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 potkává s praxí:

Kompozice a linkování: importy, dědičnost a linkování knihoven 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í zdrojového kódu nebo dědičnost ano.
On-chain bytecode: veřejný bytecode ≠ automatické OSI „otevření“; licence stále rozhoduje, zda je použití povoleno.
Frontend 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 na kód automaticky neplatí na assety (obrázky, hudbu, texty). Pro NFT zvažte:

CC0: svobodná kulturní licence, ideální pro memy a deriváty.
CC-BY/CC-BY-SA: vyžaduje uvedení autora, SA udržuje licenční „infekt“.
NFT specifické licence: omezení komerčního využití, povolení merchandisingu do určitého rozsahu apod.
Ochranné známky: značka není automaticky pokryta OSS licencí; mějte zvláštní 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říklad 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í nespouští povinnosti na celé repozitář.
Dual-licensing: kombinujte GPL pro komunitu a komerční licenci pro integrátory, kteří nechtějí měnit kód veřejně.

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

Pokud chcete 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šší administrativní náročnost, ale větší flexibilita pro budoucnost.
DCO (Developer Certificate of Origin): jednodušší proces (Signed-off-by), slabší možnosti relicencování.
DAO správa: pokud je vlastníkem copyright nadace/DAO, definujte proces schválení 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 zpravidla vylučují záruky („AS IS“), avšak z praxe:

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

Biznis modely pro OSS Web3: od komunity ke příjmům

Open core: jádro pod MIT/Apache, přidané enterprise funkce (observabilita, nástroje řízení, hosting) pod komerční licencí.
Hosting a správa (SaaS): spravované indexery, archivační nody, relaye a sequencery; vhodné kombinovat s AGPL pro serverovou část nebo s komerční licencí.
Podpora a SLA: placené smlouvy na integrace, prioritní opravy chyb, 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čemž OSS jádro zůstává zachováno.
Dual licensing: GPL/AGPL pro komunitu + komerční licence pro poskytovatele, co nechtějí sdílet úpravy.
Nadace a granty: financování z nadací a 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žívat totožnou značku.
Síťové efekty: datové formáty, indexy, reputační systémy, které komplikují „drop-in“ náhradu.
Komunitní vazby: granty, governance fórum, transparentní roadmap – fork bez komunity má nižší šanci.
AGPL/SSPL pro server-side (pokud akceptujete „ne-OSI“ u SSPL): snižují motivaci provozovat 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.
Backendové služby/indexery: AGPLv3 nebo „open core“ s komerční nadstavbou.
Frontend/UX: permisivní licence + ochrana značky; obsah a assety pod CC (například CC-BY).

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

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

DAO a licence: kolektivní rozhodování o duševním vlastnictví

Pokud držitelem IP je nadace nebo DAO, stanovte:

Mandát pro licenční změny: jaké kvórum a proces je nezbytný k relicencování nebo zavedení dual-licence.
Příspěvkové smlouvy: CLA podepsané s entitou (nadací), nikoliv „ztracené v davu“.
Podmínky grantů: příjemci grantů často musí používat OSI licence a dodat SBOM.

Případové scénáře: rozhodovací matice

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