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.


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

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



 
 

Top články z OpenOffice.cz

Lukáš Jelínek

Lukáš Jelínek

Dlouholetý člen autorského týmu LinuxEXPRESu a OpenOffice.cz. Vystudoval FEL ČVUT v oboru Výpočetní technika. Žije v Kutné Hoře, podniká v oblasti IT a zároveň pracuje v týmu projektu Turris. Ve volném čase rád fotografuje, natáčí a stříhá video, občas se věnuje powerkitingu a na prahu čtyřicítky začal hrát tenis.


  • Distribuce: Debian, Kubuntu, Linux Mint
  • Grafické prostředí: KDE

| proč linux | blog