Proč je open-source právně citlivý v komerčním produktu
Open-source neznamená „bez pravidel“. Každý použitý balíček, knihovna nebo framework je licencovaný software a licence určuje, co smíte, musíte a nesmíte. V praxi se nejčastěji řeší dvě roviny: licenční kompatibilita a povinnosti při distribuci. U webových aplikací je situace specifická tím, že část softwaru běží na serveru, část v prohlížeči a část je součástí build procesu, takže se snadno přehlédne, kde vlastně vzniká povinnost uvést autora, zveřejnit zdrojový kód nebo dodat kopii licence.
Riziko roste s velikostí produktu. Moderní frontend nebo backend projekt běžně obsahuje desítky až stovky závislostí. Podle různých analýz otevřeného ekosystému tvoří většinu kódu v běžných aplikacích právě open-source komponenty. To je skvělé pro rychlost vývoje, ale z právního hlediska to znamená, že produkt není „jen váš“. Je to složenina licencí, které musíte umět řídit stejně jako bezpečnost nebo výkon.
Nejčastější licenční typy a co po vás požadují
Ne všechny open-source licence jsou stejné. Nejpraktičtější je rozdělit je do několika skupin podle míry povinností:
- Permisivní licence – MIT, BSD, Apache 2.0. Obvykle dovolují komerční použití, úpravy i uzavření vlastního produktu, ale vyžadují zachování copyright notice a textu licence. Apache 2.0 navíc řeší patentová práva a je obecně považovaná za velmi vhodnou pro komerční software.
- Copyleft licence – GPL, LGPL, AGPL. Tyto licence jsou právně citlivější, protože mohou ukládat povinnost zpřístupnit zdrojový kód odvozeného díla nebo jeho části.
- Slabší copyleft – LGPL. Typicky je použitelná pro dynamicky linkované knihovny, ale je nutné hlídat způsob integrace.
Největší praktické riziko u komerčního produktu představuje GPL a AGPL. U GPL může být problém, pokud do vlastního produktu přímo integrujete GPL komponentu způsobem, který vytvoří odvozené dílo. AGPL jde ještě dál: řeší i software poskytovaný přes síť, takže může dopadnout na SaaS produkt. Pokud například použijete AGPL databázový nástroj nebo analytickou komponentu uvnitř webové aplikace, může vzniknout povinnost nabídnout zdrojový kód celé odvozené části i uživatelům služby.
Apache 2.0 je z pohledu firem často bezpečnější než GPL, ale i zde je potřeba uchovat oznámení o licenci a případně upozornění na změny. U MIT bývá problém spíš organizační: firmy zapomenou přibalit text licence do distribuce nebo do dokumentace.
Kde firmy nejčastěji chybují: 5 praktických scénářů
Právní průšvih často nevznikne z jednoho velkého rozhodnutí, ale z drobné nepozornosti v běžném vývoji. Typické scénáře:
- Frontend knihovna s GPL/AGPL licencí – vývojář ji přidá do npm, protože „funguje nejlíp“, ale nikdo nezkontroluje dopad na distribuci klientského kódu.
- Copy-paste úryvků kódu z GitHubu – i krátký snippet může být chráněn autorským právem, pokud není jasně licencovaný.
- Zapomenuté licence v buildu – aplikace se nasazuje do produkce, ale neobsahuje soubor LICENSE ani seznam třetích stran.
- Dodávka zákazníkovi on-premise – v SaaS bývá riziko jiné než u instalace u klienta. Jakmile dodáváte binárky nebo container image, přichází do hry distribuce v plné síle.
- Forkování knihovny bez kontroly změn – interní úpravy mohou vytvořit odvozené dílo, které stále podléhá původní licenci.
Velmi častá je také chyba v tom, že firmy sledují jen „hlavní“ licenci projektu a ignorují závislosti druhého a třetího řádu. Typická React aplikace může mít stovky transitive dependencies. Stačí jedna problematická knihovna a celý release může být právně napadnutelný.
Jak si nastavit kontrolu licencí v produktu
Nejspolehlivější přístup je kombinace procesů, automatizace a odpovědnosti. Nestačí jednou za rok udělat audit. Licence se mění s každou novou závislostí v repozitáři.
V praxi doporučuji tento postup:
- Vytvořit software bill of materials (SBOM) – seznam všech komponent a verzí. Pro SBOM se používají formáty SPDX nebo CycloneDX.
- Zavést license scanning v CI/CD – při každém buildu kontrolovat, zda nová závislost neobsahuje zakázanou licenci.
- Definovat whitelist/blacklist licencí – například povolit MIT, BSD, Apache 2.0 a explicitně zakázat AGPL bez právního schválení.
- Udržovat third-party notices – soubor s přehledem použitých knihoven, licencí a požadovaných textů.
- Mít právní review pro nové komponenty – hlavně u frameworků, SDK, fontů, ikon a AI nástrojů.
Konkrétní nástroje, které dávají smysl v běžném vývoji: FOSSA, Black Duck, Sonatype Nexus Lifecycle, WhiteSource (Mend), ale i open-source nástroje jako ScanCode Toolkit nebo OSS Review Toolkit (ORT). Pro menší týmy stačí často kombinace npm audit, pnpm licenses, pip-licenses nebo cargo deny, ale je nutné chápat, že bezpečnostní audit není totéž co licenční audit.
Dobrá praxe je také držet interní dokumentaci: kdo schvaluje novou licenci, kde se evidují výjimky, jak se řeší release notes a jak se archivují použité verze. Při investiční due diligence je to často rozdíl mezi hladkým procesem a týdny právních dotazů.
Specifika SaaS, webových aplikací a distribuovaného software
U SaaS produktu se často argumentuje tím, že „nic nedistribuujeme, takže licenci moc neřešíme“. To je ale zjednodušení. U permisivních licencí to většinou nevadí, ale u AGPL už samotné poskytování služby přes síť může spustit povinnosti. Pokud tedy stavíte webovou aplikaci, API platformu nebo interní nástroj pro klienta, je nutné posoudit, zda se software jen provozuje, nebo i distribuuje.
U container image, desktop aplikací, mobilních aplikací nebo on-premise instalací je riziko vyšší. Jakmile zákazník obdrží binárku, image nebo install balíček, musíte počítat s povinnostmi podle dané licence. To se týká i méně zjevného softwaru, jako jsou:
- fonty a ikony,
- JS knihovny a UI frameworky,
- interní CLI nástroje dodávané zákazníkům,
- embedded komponenty v IoT nebo kioskových systémech.
Praktický příklad: firma vyvine B2B platformu na Next.js a použije několik open-source UI komponent. Pokud aplikace běží čistě jako SaaS, obvykle je problém menší než u distribuce desktop klienta. Jakmile ale zákazník dostane lokální instalaci nebo offline balíček, musí být připravené licenční balíčky, texty licencí a seznam třetích stran. V opačném případě hrozí porušení licence i reputační škoda.
Co mít pod kontrolou před uvedením produktu na trh
Před release je vhodné projít si kontrolní seznam, který sníží právní i provozní riziko:
- Inventura závislostí – víte přesně, co produkt obsahuje?
- Kontrola licencí všech přímých i transitive dependencies – nejen hlavní balíčky, ale i jejich podzávislosti.
- Uložení textů licencí – v repozitáři, v build artefaktu nebo v instalačním balíčku.
- Právní posouzení copyleft komponent – hlavně GPL, AGPL a kombinace s proprietárním kódem.
- Evidence změn – kdo přidal knihovnu, proč, kdy a na základě jakého schválení.
Vyplatí se zavést i jednoduché pravidlo: každý nový open-source balíček musí projít technickým i licenčním review před sloučením do main branch. V praxi to lze automatizovat přes pull request checklist a CI gate. Pokud produkt prodáváte enterprise klientům, bývá standardem poskytnout na vyžádání seznam použitých open-source komponent a jejich licencí. To zvyšuje důvěru a usnadňuje nákupní proces.
Open-source je pro komerční produkt výborný nástroj, pokud se s ním zachází systematicky. Jakmile má firma přehled o licencích, SBOM, schvalovacím procesu a nástrojích pro scanning, výrazně snižuje riziko sporů, blokace release i problémů při právním auditu. V prostředí, kde se software skládá z desítek externích knihoven, je licenční hygiena stejně důležitá jako bezpečnostní patchování nebo monitoring výkonu.
