Úvahy o hranicích GPL a vývoji ovladačů

20.11.2005 15:08 | Přečteno: 1012× | Rouhání největší | poslední úprava: 21.11.2005 00:22

Nedávno, při diskusích na téma LGPL, tu zazněla důležitá myšlenka - totiž, že najít hranice dosahu GPL (ve smyslu "co všechno je odvozené dílo") není vůbec jednoduché. Co člověk, to názor. A někdy ty rozdílné názory pěkně komplikují práci.

Licence GPL je známa svou nakažlivostí. Pokud někdo chce použít ve svém díle něco, co je licencováno (pouze) pod GPL, musí být toto dílo licencováno stejně. Už jsme tu řešili, jaké dopady to má při používání knihoven. Ale ono to není zdaleka tak jednoduché, jak by se mohlo zdát. Význam pojmu "odvozené dílo" může totiž každý chápat jinak.

Někdo to chápe tak, že ke vzniku odvozeného díla je nutné těsné propojení, kdežto jiný člověk by do toho zahrnul jakoukoli vazbu na GPL-licencované dílo (tedy i to, když jeden program spouští jiný - pod GPL šířený - samostatný program). Že to není jednoduché, můžeme se dočíst i na stránkách Free Software Foundation - a případné spory by mohly dopadat velmi různě.

Specifickým případem je samotné linuxové jádro. Jádro je, jak známo, licencováno pod GPL. A právě výklad pojmu "odvozené dílo" zde hraje klíčovou roli. Vývojáři jádra na to mají různý názor. Obecně jakékoli volání jádra z programu by mohlo být považováno za vytvoření odvozeného díla - to je naštěstí přímo vyloučeno explicitní deklarací Linuse Torvaldse ve zdrojových kódech.

Něco jiného je ovšem tvorba ovladačů pro Linux. User-space ovladače můžeme pustit z hlavy, s těmi problém není. Ovšem ovladače v podobě modulů do jádra jsou komplikovanější případ. Jsou lidé, kteří je považují za odvozená díla, a jiní, kteří je mají za samostatné programy (protože není příliš velkého rozdílu mezi používáním jádra přímo nebo přes syscally). Právní souvislosti nechme právníkům, nás jako techniky zajímají spíše technické aspekty. A v tom je zakopaný pes.

Dokud byl jmenný prostor jádra přístupný bez omezení v rámci celého jádra, byly tyto úvahy bezpředmětné. Nyní se ale symboly exportují explicitně - a zde si může každý autor určit, zda příslušný symbol vyexportuje bez omezení, anebo vynutí použití GPL-kompatibilní licence. To by samo nebylo až tak ukrutné, horší je, že symboly exportované bez omezení mohou být (a často také bývají) v pozdějších verzích exportovány jen pro GPL. To se (zatím) netýká oblasti "core functionality", ale třeba tak podstatná věc, jako je SYSFS, prošla právě tímto procesem.

Zásadní problém pak nastává, když někdo musí (ať už z jakýchkoli důvodů) napsat ovladač, který pod GPL být nemůže. Resp. když už je ovladač napsán, funguje, a pak se v další verzi jádra změní export na GPL-only. Co může člověk v takové situaci učinit?

• Pokusit se přesvědčit zadavatele k přechodu na GPL.To je sice nejčistší řešení, ale v praxi často neúspěšné. Někdo může mít obavy z úniku know-how k HW (i když často zbytečně), a otevření zdrojového kódu nepovolí.
• Ohlásit zadavateli, že je tu tento problém, a doporučit přechod na jiný OS. Také čisté řešení, ale s velkými následky v rovině technické, a často i ekonomické (hlavně pokud se už dříve vyvinulo hodně SW pro GNU/Linux).
• Eliminovat použití daného prostředku jádra a naprogramovat to znovu. Toto řešení pravděpodobně zvolila firma nVidia, proto jsou také její (proprietární) ovladače tak objemné. Problém je, že s další verzí se okruh nucené reimplementace může zase rozšířit. Navíc se zbytečně zabírá paměť.
• Rozdělit ovladač na dva (nebo více) s různými licencemi. Chráněný kód zůstane v proprietárním driveru, kdežto ostatní se přesune do ovladače, který bude pod vhodnou GPL-kompatibilní licencí. Je to podobně špatné řešení, jako to předchozí, navíc generuje další komplikace technického charakteru (závislosti modulů, problém důsledného oddělení různě licencovaných částí atd.).
• Vzít zdrojáky ze starší verze jádra, příp. je poupravit, a jádro znova zkompilovat. Tohle sice technicky umožní provoz ovladače tak, jako s předchozími verzemi, je to však naprosto nechutná prasárna, která je eticky srovnatelná s ukradením kódu z GPL do proprietárního programu.

Ptáme-li se, proč podpora HW v Linuxu není taková, jakou bychom si přáli, musíme část odpovědi hledat i zde. Jádra 2.6 sice přinesla (oproti těm starším) lepší a hlavně systematičtější API pro vývoj ovladačů, ale současně se tu objevil uvedený problém. Těžko s tím něco naděláme, ale je potřeba si uvědomit, že snaha fanaticky bojovat za svobodu softwaru se může projevit velmi nepříjemnými efekty.

       

Komentáře

[Robert Krátký]

Linus tohle už hodněkrát objasňoval a pokaždé uvádí rozumné příklady, které lze použít při posuzování jako vodítko. Google ví víc.

V podstatě se to dá shrnout do tohoto citátu:

I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (ie it is _not_ acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel.

Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work.

What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-containted that doesn't really have any impact on the rest of the kernel. A device driver that was originally written for something else, and that doesn't need any but the standard UNIX read/write kind of interfaces, for example.

Linus Torvalds

[Luk]

I personally consider anything a "derived work" that needs special hooks in the kernel to function with Linux (ie it is _not_ acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs "help" from the main kernel.

Tohle mi připomíná někdejší debaty vývojářů, zda ponechat v hlavním stromě nějaký takový hook pro konkrétní proprietární ovladač. Mám dojem, že zvítězilo odebrání.

Similarly, I consider anything that has intimate knowledge about kernel internals to be a derived work.

No jo, ale to už je právě záležitost subjektivního pohledu. Ostrou dělicí čáru nelze udělat.

What is left in the gray area tends to be clearly separate modules: code that had a life outside Linux from the beginning, and that do something self-containted that doesn't really have any impact on the rest of the kernel. A device driver that was originally written for something else, and that doesn't need any but the standard UNIX read/write kind of interfaces, for example.

O to tu právě jde. Předpokládejme, že ovladač byl původně pro Windows a dělá se verze pro Linux. Nepotřebuje prakticky nic víc, než "standardní" věci (I/O operace, obsluha přerušení, DMA apod.). Na tohle může mít každý jiný názor.

Ale je tu ještě ten "další krok". Aby byl ovladač rozumně použitelný, měl by být schopen spolupracovat s udev - a to nelze bez použití SYSFS. Proto ano, samotnou funkcionalitu ovladače zajistit lze, ale jeho rozumné použití v praxi už nikoliv. Muselo by se použít nestandardní řešení.

[Robert Krátký]

Tohle mi připomíná někdejší debaty vývojářů, zda ponechat v hlavním stromě nějaký takový hook pro konkrétní proprietární ovladač. Mám dojem, že zvítězilo odebrání.

Zvítězilo. Ale v tomto případě to IMO bylo dobré rozhodnutí. Vyžaduje-li ovladač pro svou funkci háčky v jádře, nechť je otevřený. Pokud si vystačí sám, pak ať si má licenci jakou chce. Jde jen o to, jakým způsobem ovladač napíšeš. nVIDIA dělá poměrně úspěšné uzavřené ovladače a žádné spory kvůli tomu vedeny nejsou. Ovladač nevyžaduje, aby kvůli němu bylo jádro jakkoliv jiné. Vystačí si sám, a proto má plné právo být uzavřený.

Ostatně je to s tou nVIDIA zároveň příkladem toho, co zmiňuješ dále:

Předpokládejme, že ovladač byl původně pro Windows a dělá se verze pro Linux.

To je přesně ten případ. Zatím jsem neslyšel, že by si někdo stěžoval na licenci nVIDIA -- tím myslím s ohledem na to, jestli není GPL porušována, ne že by si nikdo nestěžoval na jejich uzavřenost z praktických důvodů.