
Neshody svobodných licencí
Svobodný software dovoluje uživatelům a vývojářům své užívání, šíření,
upravování a šíření upravených verzí. I ve svobodném světě však existují
rozdílné názory. Mají-li autoři dvou svobodných programů rozdílné názory na
svobodné užívání a upravování softwaru, propojení těchto programů již svobodným
softwarem být nemusí a dokonce ani nemusí být dovoleno.
Autor stanoví podmínky užívání svého programu v jeho licenci.
Ve světě svobodného softwaru existuje různých licencí celá řada. Každá z nich
uživatelům uděluje odlišná práva a klade na ně při používání a šíření kódu
odlišné povinnosti. Do licencí se mnohdy promítají osobní názory autorů,
tvořivost všeho druhu, neznalost, nedomyšlenost důsledků svých rozhodnutí,
komerční zájmy a pojistky právních oddělení. Jednou z důležitých vlastností
svobodného softwaru je přitom možnost využívat existující kód v jiných
svobodných programech. Pokud však licence částí kombinovaného kódu obsahují
ustanovení, která nelze splnit současně, dochází při využívání cizího kódu
k nepříjemné nekompatibilitě licencí.
Nekompatibilita kódu nemusí u svobodného softwaru vzniknout pouze z licenčních
důvodů. Může vzniknout i použitím rozdílných programovacích jazyků, zaměřením
softwaru pouze na určitou množinu operačních systémů či z jiných technických
důvodů. Avšak zatímco překážky technického rázu jsou většinou více či méně
překonatelné, licenční problémy často bývají tvrdším oříškem. V případě
rozdílných programovacích jazyků lze kód přepsat nebo zkonvertovat do jiného
programovacího jazyka s využitím kódu stávajícího, v případě potíží
s přenositelností lze problematické části kódu opravit a zbytek kódu bez dalších
úprav využít. Pokud ale dojde na licenční překážky, pak může být jediným
řešením část kódu, za jiných okolností beze změny využitelnou, kompletně
přepsat, a to dokonce bez studia onoho kódu, aby nedošlo k porušení autorských
práv podvědomým okopírováním programových konstrukcí.
Asi k nejčastějším licenčním konfliktům ve svobodném softwaru dochází při
kombinací programů, z nichž je jeden šířen pod GNU General Public
License (GPL), a to ze dvou důvodů:
- GPL obsahuje podmínku, že jí pokrytý software smí být dále šířen jen za
podmínky, že je šířen pod
tou samou licencí. Ke konfliktu tedy dochází automaticky v případě, kdy druhá licence
klade omezení, která GPL nedovoluje.
- Pod GPL je šířeno velké množství softwaru, často velmi důležitého a
rozšířeného, a proto je při vzniku praktického problému pravděpodobnější,
že jedna z částí kódu bude pod GPL, než že bude pod nějakou podobnou, ale
méně používanou licencí.
Uvedeme si proto několik známých případů, kdy dochází ke konfliktu některé ze
svobodných licencí právě s GPL. V konfliktech se přitom nejedná až tak
o nějakou konfliktní podstatu GPL spočívající ve zmíněné podmínce možnosti
dalšího šíření programu pouze pod tou samou licencí. Některé licence,
nejznámější jsou v tomto směru licence ze skupiny BSD licencí, mezi něž patří
z dále zmíněných BSD licence a licence Pythonu, tento požadavek neobsahují. To
znamená, že při dalším šíření lze na program uvalit dodatečná omezení, a to
mnohdy i taková, která mění software na nesvobodný (například nezveřejnění
zdrojového kódu). Právě omezení svobody
softwaru chce GPL zabránit, a proto zavádí onen požadavek neměnnosti podmínek
šíření. GPL uživateli garantuje jakousi minimální množinu
práv a zakazuje tato práva uživatele omezovat. Licence s touto vlastností se
někdy nazývají copyleftové, jako slovní hříčka a narážka na
copyright, který mnohdy bývá používán přesně naopak k omezování uživatelských práv.
Mezi copyleftové licence patří z níže uvedených licencí Mozilla Public License.
Dojde-li ke kombinaci GPL s licencí, která není v žádném rozporu s požadavky
GPL (například dovoluje uživateli všechno), konflikt nevzniká, kód pod oběma
licencemi lze zkombinovat a dále šířit pod podmínkami GPL. Potíže vznikají pouze
v případě, že licence druhého programu obsahuje ustanovení, které je v rozporu
s požadavky GPL. V případě konfliktu se na vzniku rozporu podílí obě licence
-- každá obsahuje nějaké ustanovení neslučitelné s ustanoveními druhé licence.
Na několika známých příkladech konfliktu GPL s jinými svobodnými licencemi si
konkrétně ukážeme, z čeho takové konflikty mohou vznikat, jaké mohou být jejich
důsledky a jak je lze řešit.
Notoricky známým příkladem licenčního konfliktu je konflikt GPL se starou
BSD licencí. Tato BSD licence, ač jinak velmi benevolentní, obsahovala
klauzuli nařizující ve všech reklamních materiálech zmiňujících rysy nebo
používání daného softwaru uvést předepsaný text. Tento požadavek kromě své
určité nepraktičnosti (narůstání množství povinného textu v reklamách při
stejném požadavku všech přispěvatelů) přesahuje povinnosti uživatele stanovené
GPL (nebo jinými slovy: omezuje svobody uživatele garantované GPL), a proto je
tato BSD licence s GPL nekompatibilní. Protože pod BSD licencí je šířeno také
velké množství důležitého svobodného softwaru, byl tento konflikt velmi
citelný. Proto před několika lety došlo k tomu, že autoři BSD licence
zmíněnou klauzuli ze své licence vypustili a tuto změnu aplikovali na veškerý svůj kód
šířený pod BSD licencí. Podobně se mohou zachovat i jiní autoři
používající tuto licenci.
Dalším známým licenčním konfliktem byla licence Pythonu 1.6. Do licence nejpoužívanější implementace
překladače a knihoven programovacího jazyka Pythonu byla svého času přidána
klauzule, že licence se řídí zákony amerického státu Virginia. Jedná se opět
o požadavek nad rámec podmínek GPL a tudíž jsou licence nekompatibilní. V čem
by mohl vzniknout reálný praktický problém zde? Stejně jako mohou být
nekompatibilní licence, mohou být nekompatibilní i právní systémy jednotlivých
států. Objeví-li se software s licencí jinak totožnou, avšak odkazující se na jiný,
nekompatibilní právní systém, dochází tím ke zřejmému rozporu, licence nemohou
být shodné a vzniká přinejmenším zmatek. Protože toto licenční ustanovení znamenalo potíže s použitím
knihoven chráněných GPL (jako je například populární knihovna
readline), bylo později toto ustanovení na nátlak mnoha vývojářů
softwaru z licence Pythonu odstraněno. Současná
licence Pythonu s GPL již znovu kompatibilní je.
Velmi zajímavým konfliktem s GPL byla Q Public Licence (QPL) oblíbené knihovny Qt pro
programování grafických uživatelských rozhraní. QPL ve své verzi 1.0
definovala některé požadavky, které jsou v rozporu s GPL, například že se řídí
zákony Norska nebo že za určitých okolností smí původní autoři celého softwaru využít kódu přispěvatelů
v proprietárním kódu. Potíže s nekompatibilitou
se po praktické stránce projevily v případě populárního desktopového prostředí KDE. Velká
část kódu KDE byla totiž šířena právě pod GPL, přičemž ovšem bylo využíváno
knihovny Qt. Vzhledem k nekompatibilitě obou licencí nebylo možno šířit
slinkovaný kód a například vývojáři distribuce Debian GNU/Linux proto odmítli
KDE do svého systému zařadit. I když vývojáři KDE mohli u svého kódu k licenci
přidat ustanovení o výjimce v případě linkování s Qt, nemohli tak učinit u GPL
kódu převzatého z jiných produktů. Po dlouhých sporech byla situace nakonec
vyřešena tak, že autoři Qt umožnili šíření své knihovny nejen pod QPL,
ale i pod GPL. Díky tomu lze nyní knihovnu Qt využívat i v GPL programech, avšak
licence QPL a GPL zůstávají, na rozdíl od předchozích příkladů vyřešených konfliktů,
nadále nekompatibilní.
Jako poslední příklad licenčního konfliktu uvedeme případ Mozilla Public
License 1.1 (MPL). Licence opět obsahuje ustanovení nekompatibilní s GPL,
například povinnost veřejně distribuovat změny provedené v kódu chráněném MPL.
Jedná se opět o požadavek nad rámec GPL, jejímž cílem je mimo jiné chránit
soukromí uživatele a tudíž povinnost zveřejňovat i privátní, dále nešířené,
změny je s ní v rozporu. Tento rozpor, pokud je mi známo, dosud vyřešen není.
Musí být tedy řešen na straně GPL kódu. Například autoři webového prohlížeče
Galeon, šířeného pod GPL, k licenci prohlížeče přidávají speciální výjimku
povolující jeho linkování s vyjmenovanými knihovnami. Jako autoři kódu mohou
toto svolení dát, nemohou však již ve svém kódu využít GPL kód jiných vývojářů
bez jejich explicitního svolení.
Ve všech uvedených případech se jednalo o konflikt GPL s licencemi, které lze
bez větších potíží považovat za svobodné. Má-li být naplněn smysl svobodného
softwaru, mělo by se konfliktům způsobujícím nemožnost kombinace kódu krytého
různými licencemi předcházet.
Nejjednodušším a nejspolehlivějším postupem je, aby problém vůbec nevznikl.
Jak jsme viděli, konflikt může vzniknout jak mezi licencemi copyleftovými (MPL), tak i mezi licencemi necopyleftovými (BSD licence, licence Pythonu).
Píšete-li tedy vlastní svobodný software, věnujte pozornost i licenci, pod
kterou jej šíříte. Nemáte-li pádný důvod se zachovat jinak, je obvykle
nejlepší použít některou z dlouhodobě osvědčených licencí.
Záleží-li vám na zachování svobody vašeho softwaru, je nejjednodušší volbou
GPL. První důvod je praktický -- pod GPL je distribuováno obrovské množství
kódu, které je obtížné ignorovat a vyloučit. Dokazují to případy, kdy v prominentních
situacích (viz výše uvedené BSD, Python a Q licence) po dlouhých tahanicích
nakonec došlo k nápravě nekompatibility s GPL ze strany autorů druhých licencí. Druhý
důvod je pak filozofický -- GPL definuje velmi rozumnou množinu práv z hlediska
vývojáře i uživatele. Stojí za zvážení, zda potřeba
stanovit konkrétní jurisdikci, umožnit jednosměrnou možnost využívání kódu druhé strany
v nesvobodném softwaru nebo narušení práva uživatele na soukromí nad uvedenými
dvěma důvody opravdu převažuje.
Jde-li vám naopak o co nejširší využití vašeho softwaru, můžete sáhnout po BSD
licenci bez reklamní klauzule nebo jej šířit jako Public Domain, tj. jako
software, u kterého se zcela vzdáváte svého nároku na jakákoliv omezení
jeho používání. Jedná-li se o knihovnu nebo program podobného charakteru
a chcete aplikovat kombinovaný přístup, kdy je garantována svoboda kódu
knihovny, ale knihovna jako taková má být využívána co nejvíce, je dobrou
volbou GNU
Lesser General Public License (LGPL).
Pokud z nějakého důvodu potřebujete přeci jen vybavit svůj program licencí
nekompatibilní s GPL, může být vhodné umožnit jeho šíření pod více licencemi.
Chce-li autor uživateli nabídnout jiné podmínky, než jaké stanoví GPL, bez
zavedení nekompatibility s ní, může mu ponechat volbu mezi
licencí vlastní a GPL (jako se stalo v případě Qt), případně i jinými
licencemi. Takové řešení umožňuje v mnoha případech určité lavírování,
například knihovnu, u které si smíte vybrat mezi QPL a GPL, můžete využít jak
pro QPL, tak i pro GPL aplikace. Nejedná se však o řešení optimální, neboť
hrozí "licenční rozdvojení" softwaru.
Pokud chcete šířit kód pod GPL a přitom využít knihovny pod GPL nekompatibilní
licencí, můžete ke svému kódu připojit výjimku, která nad
rámec GPL linkování s touto knihovnou umožňuje. Jedná se o poměrně častý
postup a zmínili jsme jej v souvislosti s webovým prohlížečem Galeon. Avšak
jak již bylo naznačeno, tímto postupem sice zpřístupňujete svůj kód vývojářům
jiných GPL aplikací, avšak cizí GPL kód bez explicitního svolení jeho autorů
využívat nemůžete. Je tedy na zvážení, zda raději v takovém případě nesáhnout
po jiné, s GPL kompatibilní knihovně.
Nakonec je tu i možnost celý problém ignorovat a svůj kód šířit například pod
GPL, přestože používá knihovnu s GPL nekompatibilní. Nedopouštíte-li se
porušení autorských práv z hlediska použitého kódu, nevzniká pro vás licenční
problém, neboť nemůžete porušit licenční podmínky sám sobě. Příjemce kódu je
však již vázán všemi licencemi a může kvůli konfliktu ztratit možnost
takový software dále distribuovat a tudíž je software ve skutečnosti
nesvobodný.
Závěrem poznamenejme, že mnoho licenčních konfliktů ve svobodném softwaru
vzniká nechtěně, licenční nekompatibilita jako taková je cílem jen velmi
zřídka, pokud vůbec někdy. Není tomu tak však v případě softwaru
proprietárního. Dochází-li k jeho kombinaci s copyleftovou licencí, je vzniklá
nekompatibilita ze strany obou licencí záměrná: Autor proprietárního kódu chce
využít práci někoho jiného bez toho, aby na oplátku svůj kód zveřejnil za
stejných podmínek jako kód využitý; autor copyleftového kódu se mu pak v tomto
chování snaží zabránit. Vhodnost takového přístupu obou stran nechť
posoudí každý sám.
|