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

[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ů.