přejít na obsah přejít na navigaci

Linux E X P R E S, Použití copyleftových licencí v praxi

Použití copyleftových licencí v praxi

open_source_sw.jpg

Copyleftové svobodné licence jsou navrženy tak, aby vynucovaly trvalou svobodnost díla. Jejich použití v praxi může přinášet otázky zejména ohledně podmínek, za kterých lze kombinovat a propojovat různá díla. Pojďme se podívat na některé významné případy.


reklama

Používání copyleftových licencí

Používáme-li copyleftové licence (silné jako GNU GPL nebo AGPL či slabé jako třeba GNU LGPL), v případě izolovaného díla je to jednoduché. Autor si zkrátka zvolí určitou licenci a tím to pro něj „hasne“. Problémy však vznikají v případech, kdy je třeba díla kombinovat – to se v praxi děje velmi často, protože málokdy program nepoužívá žádné knihovny ani nespolupracuje s vnějším prostředím.

Kombinace může mít mnoho podob. Počínaje přímým zkopírováním kódu, přes volání funkcí umístěných v objektových souborech či v knihovnách, přes odvozování v rámci objektového programování (kompozice, dědění apod.), až po komunikaci dvou v zásadě nezávislých entit.

Co lze a co nelze

Kopírování kódu

Zkopírování netriviálního kusu kódu z jednoho programu a vložení do druhého je tím nejjednodušším případem. Bez problémů lze přenášet kód v rámci stejné licence (téže verze) nebo směrem k silnějšímu copyleftu. Na dílo jako celek se uplatní silnější copyleft, vložený kus kódu lze ale stále šířit pod původní licencí.

Kopírování triviálního kusu kódu (inkludovacího příkazu, běžného zavolání jediné funkce, úvodu do cyklu atd.) je právně bezproblémové. Takový kus kódu nesplňuje podmínky, aby mohl být označen za autorské dílo – není autorovým vlastním duševním výtvorem.

Přenést kód z programu pod jinou licencí, než jsou ty zde uvedené, lze jen v případě kompatibility licencí a pro výsledné dílo jako celek bude platit příslušná copyleftová licence.

Co se týká různých verzí copyleftových licencí, tam je situace složitější a přesahuje to rámec tohoto článku. Obecně lze říct, že pokud je licence uvedena stylem „verze x a novější“, lze přenášet kód do programu pod licencí stejné a novější verze (mezi licencemi pak platí výše uvedená pravidla).

Linkování knihoven a další podobná užití

Již z logiky věci vyplývá, že tam, kde lze přímo přenášet kód, jde i linkovat knihovny. Jinak platí, že knihovnu šířenou pod licencí LGPL nebo GPL s linkovací výjimkou lze při dodržení dalších podmínek používat v programu s libovolnou licencí. U knihoven pod licencí GPL a AGPL platí totéž jako v případě přímého přenášení kódu – viz výše.

Zvláštní případ nastává, pokud rozhraní existuje nezávisle na knihovně a její licenci. Pak program není odvozeným dílem knihovny a může mít libovolnou licenci; nelze ho ale šířit s knihovnou jako jeden celek, pokud by licence nebyly kompatibilní. Pokud si komponenty spojí dohromady uživatel, je všechno v pořádku.

Obdobná situace nastává, pokud se přidává do celku ještě nějaké dílo, které má vlastní licenci (nekompatibilní s GPL/LGPL/AGPL), ale opět není od zbývajících částí odvozeno – známým příkladem jsou ovladače grafických karet NVIDIA.

Zejména druhá z těchto kategorií případů ale patří z hlediska svobodného softwaru do kategorie „nedoporučeno“. Nejde jen o filozofickou záležitost, ale i o to, že pokud je některá komponenta proprietární, může být zdrojem prakticky nedohledatelných chyb. Vývojář příslušné svobodné části pak může zcela logicky odmítnout se takovými chybami zabývat, protože nemá k dispozici informace potřebné k jejich hledání.

Propojení „na dlouhé ruce“

Poslední kategorií je takové propojování programů, kde se o odvozeném díle dá hovořit jen stěží. Typickými případy jsou systémová volání u jádra, síťový komunikační protokol nebo datový formát. Tam v drtivé většině případů nezávisí na tom, jaké licence má ta která komponenta a lze kombinovat cokoli s čímkoli.

Ovšem pozor – někdy se právě toto zneužívá pro obcházení GNU GPL. Někdo vezme program či knihovnu pod GPL, obalí ji tenkou komunikační vrstvou a využívá takto vzniklý celek z proprietárního programu. Obě součásti si přitom vyměňují složitě strukturovaná binární data, odpovídající vnitřním datovým strukturám. Tady by se už mohlo často jednat o případ, že by pro takové použití bylo potřeba dodržet podmínky stanovené GNU GPL, protože navzdory způsobu implementace by šlo o odvozené dílo.

Z právního pohledu je opravdu zcela lhostejné, jakým způsobem se díla kombinují. Zda jde o volání funkcí nebo třeba komunikaci přes síťový socket, je záležitost technická, nikoli právní.

Shrnutí

V krátkém článku se samozřejmě nedá ani poměrně zběžně popsat složitá problematika copyleftových licencí a jejich kombinací s licencemi ze stejných i jiných kategorií. Navíc na řadu otázek neexistují zatím jednoznačné odpovědi, lišící se ještě podle právního řádu v určité zemi a určitém čase. Důležité ale je správně chápat podstatu této třídy licencí – proč vznikla a co je jejím smyslem; totéž se týká i jednotlivých copyleftových licencí.

Příště přijdou na řadu permisivní licence – známé například pod názvy jako BSD, MIT nebo Apache. Tam sice neplatí tak přísné podmínky jako u licencí copyleftových, ale ani u nich nelze s kódem dělat úplně cokoliv.

Nahoru

(Jako ve škole)
Průměr: 1,00 | Hodnotilo: 7
 

Top články z OpenOffice.cz

Příspěvky

Použití copyleftových licencí v praxi
sarimak 25. 01. 2015, 19:51:54
Odpovědět  Odkaz 
Bylo by prosim mozne upresnit sekci o linkovani s GPL knihovnami pro skriptovaci jazyky (napr. proprietarni kod v Pythonu ktery importuje GPL licenci) a spousteni GPL executable (napr. proprietarni kod ktery pomoci volani OS zavola EXE nebo ELF binarku, preda ji beznym zpusobem argumenty pro volani z prikazove radky a odchyti jeji standardni vystup ktery rozparsuje, popr. dale zpracovava soubor ktery GPL binakra vytvorila/upravila)?
Lukáš Jelínek Re: Použití copyleftových licencí v praxi
Lukáš Jelínek 25. 01. 2015, 20:36:48
Odpovědět  Odkaz 
Skriptovací (interpretované) jazyky jsou úplně stejné jako jazyky kompilované.

„proprietarni kod v Pythonu ktery importuje GPL licenci“

Co si mám pod tím představit? Proprietární kód importující nějakou knihovnu pod licencí GPL? Pokud ano, tak u klasické GPL (bez linkovací výjimky) nelze takto vzniklý program šířit (lze ho používat pro vlastní potřebu, ale pro šíření se musí GPL vztáhnout na celek). S linkovací výjimkou ho šířit lze, protože se GPL na tu proprietární část nevztahuje.

„spousteni GPL executable“

Ve většině případů to není problém. Ten program pod GPL se pouze používá, nestává se součástí jiného díla a tedy není nutné použít GPL pro ten druhý program. Někdy to ale neplatí - typicky když se předávají složitější datové struktury (lhostejno, zda jsou třeba nějak serializované apod.), které jsou charakteristické pro ten program pod GPL. Zejména se to týká situace, kdy to takhle někdo řeší vysloveně v úmyslu obejít GPL u nějaké knihovny tím, že knihovnu zabalí do jednoduchého programu a ten pak spouští místo toho, aby volal API té knihovny. Záleží na konkrétním případu, není tam žádná ostrá hranice.

Přidat názor

Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích a pravidlech najdete v nápovědě.
Diskuzi můžete sledovat pomocí RSS kanálu rss



 
 

Lukáš Jelínek

Lukáš Jelínek

Šéfredaktor LinuxEXPRESu a OpenOffice.cz. Vystudoval FEL ČVUT v oboru Výpočetní technika. Žije v Kutné Hoře a podniká v oblasti informačních technologií. Ve volném čase rád fotografuje, natáčí a stříhá video a také se věnuje (v Čechách poměrně málo známému) powerkitingu.


  • Distribuce: Debian, Kubuntu
  • Grafické prostředí: KDE
  • Hodnocení autora: ***

| proč linux | blog



Public Relations

Extrémní virtuální servery s SSD úložištěm

Pojmy, jako jsou cloud a virtualizace, na nás v dnešní době vykukují zpoza každého rohu. A není divu. Služby založené na virtualizaci fyzického hardwaru se těší velké oblibě a často jsou vnímány jako levnější alternativa k fyzickému serveru. Dedikované virtuální servery od Coolhousingu jsou však jiné.

Pokračování ...