open source: oupn sórsTakéOpen source licence, OSS licence, Svobodná licenceZákladní
Definice
Licence open source je právní ujednání, kterým autor softwaru dává komukoli právo program používat, studovat, upravovat a šířit dál včetně zdrojového kódu. Autorská práva zůstávají autorovi, licence pouze uděluje oprávnění, obvykle výměnou za povinnost zachovat text licence a uvedení autorství. Typickými zástupci jsou MIT, Apache 2.0 a GPL.
Kategorie: Právo a complianceAktualizováno
Než se na to spolehnete: Wikidata QID pro open-source license jsem neověřoval proti databázi, doporučuji zkontrolovat; obecná tvrzení o vymahatelnosti podle českého práva jsou zjednodušená a nejsou právním poradenstvím.
<h2>Co licence open source vlastně uděluje</h2>
<p>Licence open source stojí na autorském právu, nikoli proti němu. Bez licence platí výchozí stav: kód zveřejněný na GitHubu je stále chráněný a nikdo ho nesmí kopírovat ani upravovat. Licence tento zákaz uvolňuje a vypisuje, co přesně smíte: rozmnožování, úpravy, šíření originálu i odvozených děl, komerční využití. Podmínkou bývá zachování textu licence a copyrightové doložky. Podrobnosti k výchozímu stavu popisuje heslo <a href="/slovnik/autorske-pravo-k-software">Autorské právo k software</a>.</p>
<h2>Permisivní versus copyleftové licence</h2>
<p>Rozdělení licencí na dvě rodiny je pro praxi to nejdůležitější, co si z tématu odnést.</p>
<h3>Permisivní licence</h3>
<p>Permisivní licence (MIT, BSD, Apache 2.0, ISC) říkají v podstatě jediné: dělejte si s kódem, co chcete, jen nechte v balíku původní copyright a text licence a neručím vám za nic. Odvozené dílo smíte uzavřít a prodávat jako proprietární produkt. Apache 2.0 navíc obsahuje výslovné udělení patentových práv a doložku o jejich ukončení při patentovém sporu, což je důvod, proč ji velké firmy preferují před MIT.</p>
<h3>Copyleftové licence</h3>
<p>Copyleftové licence (GPL, LGPL, AGPL, MPL) přidávají reciprocitu: kdo šíří odvozené dílo, musí ho šířit pod stejnou licencí a zpřístupnit zdrojový kód. Silný copyleft GPL se vztahuje na celý slinkovaný program, slabý copyleft LGPL a MPL jen na samotné upravené soubory či knihovnu. AGPL rozšiřuje povinnost i na síťové použití: pokud upravenou verzi provozujete jako webovou službu, uživatelé mají nárok na zdroják, i když jim nic nedistribuujete.</p>
<h2>Kde vzniká právní riziko</h2>
<p>Riziko v komerčním projektu nepramení z toho, že open source použijete, ale z toho, že nevíte, co všechno máte v <code>node_modules</code> nebo ve vendor adresáři. Typické problémy jsou tři: nekompatibilita licencí v jednom binárním celku (GPLv2 a Apache 2.0 spolu nefungují), nesplněná povinnost přiložit texty licencí k distribuované aplikaci a nechtěné vtažení AGPL knihovny do SaaS produktu. Kontrola se dá automatizovat nástrojem, který projde strom závislostí a vypíše licence, případně selže build při zakázané licenci.</p>
<h2>Jak licenci správně nasadit na vlastní projekt</h2>
<p>Vlastní repozitář potřebuje soubor <code>LICENSE</code> v kořeni s doslovným zněním zvolené licence a vyplněným rokem a jménem držitele práv. Balíčkovací manifesty (<code>package.json</code>, <code>pyproject.toml</code>) mají mít pole <code>license</code> s identifikátorem podle seznamu SPDX, aby licenci uměly přečíst nástroje. U firemního projektu s více přispěvateli řeší autorská práva k příspěvkům samostatná dohoda (CLA) nebo certifikace původu (DCO) potvrzovaná podpisem commitu.</p>
<p>Pozor na to, že „zdrojový kód je veřejný“ a „open source“ nejsou synonyma. Licence jako Business Source License nebo SSPL omezují komerční provoz či nabízení služby a v definici open source podle OSI neobstojí, přestože se kód dá číst na GitHubu.</p>
Příklady z praxe
AGPL knihovna v SaaS produktu
Tým nasadí do backendu SaaS aplikace knihovnu pod licencí AGPL a upraví v ní pár funkcí. Protože AGPL považuje síťové zpřístupnění za formu šíření, vzniká povinnost nabídnout uživatelům služby kompletní zdrojový kód upravené verze. Řešením bývá buď dodržení licence, nákup komerční výjimky od autora, nebo výměna za permisivní alternativu.
Deklarace licence a kontrola závislostí v Node.js
Projekt deklaruje vlastní licenci v package.json pomocí SPDX identifikátoru a v CI ověří, že žádná tranzitivní závislost nespadá do zakázané skupiny. Build takto selže dřív, než se GPL knihovna dostane do produkční image.
{ "name": "webzi-app", "version": "1.4.0", "license": "Apache-2.0", "scripts": { "licenses:check": "license-checker --production --onlyAllow 'MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC'" } }
Časté omyly
- MýtusKdyž je kód na GitHubu veřejný, můžu si ho vzít a použít.
- Ve skutečnostiVeřejný repozitář bez souboru LICENSE zůstává plně chráněný autorským právem a jakékoli užití nad rámec prohlížení je bez svolení autora neoprávněné. Chybějící licence znamená zákaz, ne povolení.
- MýtusOpen source znamená, že software je zdarma a nesmí se na něm vydělávat.
- Ve skutečnostiLicence open source výslovně dovolují komerční využití i prodej. Anglické free odkazuje na svobodu nakládat s kódem, ne na nulovou cenu; placená podpora, hosting nebo distribuce jsou zcela legitimní.
- MýtusPoužití GPL knihovny nakazí celý náš firemní produkt.
- Ve skutečnostiCopyleftové povinnosti GPL se aktivují až šířením odvozeného díla mimo organizaci. Interní nasazení bez distribuce povinnost zveřejnit kód nespouští, u AGPL ale za šíření platí i provoz síťové služby.
Časté dotazy
- Jakou licenci open source zvolit pro vlastní knihovnu?
- Volba licence vychází z toho, co od projektu očekáváte. MIT nebo ISC dávají maximální šanci na přijetí ve firemních projektech, protože nikoho k ničemu nezavazují. Apache 2.0 přidává explicitní patentové ustanovení a hodí se tam, kde přispívají zaměstnanci větších firem. GPL nebo AGPL zvolte, pokud chcete, aby se vylepšení vracela komunitě, případně jako základ pro model s komerční výjimkou. Rozhodnutí je prakticky nevratné: změna licence vyžaduje souhlas všech držitelů práv k odevzdanému kódu.
- Musí být u distribuované aplikace přiložen text licence použitých knihoven?
- Prakticky všechny licence open source, včetně MIT a Apache 2.0, podmiňují šíření zachováním copyrightové doložky a znění licence. Povinnost se týká i binární distribuce, tedy desktopové aplikace, mobilní appky nebo Docker image. Obvyklým řešením je vygenerovaný soubor NOTICE nebo obrazovka s licencemi třetích stran, kterou většina ekosystémů umí vytvořit automaticky ze stromu závislostí. Opomenutí je nejčastější reálné porušení licencí a přitom se odstraní během jednoho odpoledne.
- Je licence open source vymahatelná podle českého práva?
- Licence open source je licenční smlouvou podle českého občanského zákoníku a autorského zákona, uzavíranou obvykle konkludentně použitím díla. Porušení podmínek znamená, že oprávnění zaniká a užití se stává zásahem do autorského práva se všemi nároky, včetně zdržení se a náhrady škody. Soudy v Evropě, zejména v Německu, vymahatelnost GPL opakovaně potvrdily. Pro firmu z toho plyne, že licenční audit není formalita, ale běžná součást právní hygieny produktu.
- Co znamená SPDX identifikátor licence?
- SPDX identifikátor je krátký strojově čitelný kód licence, například MIT, Apache-2.0 nebo GPL-3.0-or-later, definovaný ve veřejném seznamu licencí. Balíčkovací manifesty, skenery závislostí i generátory softwarového kusovníku (SBOM) s ním pracují místo volného textu, takže se licence dá spolehlivě vyhodnotit automaticky. Zápis podporuje i logické výrazy typu MIT OR Apache-2.0 pro duální licencování. Vyplnění správného identifikátoru v manifestu je nejlevnější způsob, jak zajistit, že licenci vašeho projektu ostatní nástroje poznají.
Zdroje
- Various Licenses and Comments about Them(otevře se v novém okně)
- GNU General Public License(otevře se v novém okně)
- Open-source license(otevře se v novém okně)
- Zákon č. 121/2000 Sb., autorský zákon(otevře se v novém okně)
Související pojmy
