AbcLinuxu:/ Články / Jaderné noviny 246

Štítky: GNU, grafické karty, KDE, kernel, licence, Linux, nVidia, ovladače, patch, programování, software, souborové systémy, udev, XFS

Jaderné noviny 246

19. 1. 2004 | Robert Krátký | Jaderné noviny | 4849×

Diskuze o binárních modulech; Linus preferuje OSL před GPL. DevFS vs. udev v jádře 2.6. Nová sada patchů -tiny pro zmenšení kernelu. To je celý Larry. Budoucnost -mm stromu během 2.6.

Diskuze o binárních modulech; Linus preferuje OSL před GPL, 276 e-mailů

3. pro - 18. pro

Této diskuze se účastnilo mnoho lidí. Následuje několik menších ukázek.

Kendall Bennett ji začal otázkou:

Slyšel jsem mnoho lidí poukazovat na skutečnost, že ačkoliv je linuxový kernel licencován GNU GPL, existuje k licenci dodatek, který uvádí, že natahovatelné binární moduly GNU GPL být nemusí. Vzhledem k tomu, že existují výrobci dodávající binární moduly (které pochopitelně nejsou podporované vývojáři kernelu), lidé si zjevně myslí, že je to pravda. Nicméně, já byl zvědavý na znění této výjimky, takže jsem se ji začal hledat, ale nemohu ji najít. Stáhl jsem zdrojové kódy kernelu 2.6-test1 a podíval se do souboru COPYING, kde jsem však nic podobného nenalezl (kromě Linusovy poznámky na začátku, že uživatelské programy nepodléhají GPL). Podíval jsem se i na README, ale ani tam o tom není zmínka.

Takže existuje vůbec tato výjimka? Pokud ne, jak je možné, že binární moduly smějí být s Linuxem používány, když jejich zdrojový kód není k dispozici v souladu s GNU GPL?

Navíc jsem si všiml, že několik zdrojových modulů, na které jsem se díval, neobsahuje na počátku souboru tu běžnou GNU GPL preambuli. IMHO musí mít všechny soubory tuto zmínku připojenu, protože jinak by nebyly GNU GPL (pouhé umístění souboru do zip/tar archívu společně se souborem COPYING neznamená licenci GPL). Vzhledem ke všem těm právním záležitostem se SCO bych čekal, že podobnou hlavičku budou mít všechny soubory. Některé soubory, které jsem prohlédl, dokonce neměly ani základní poznámku o copyrightu.

Linus Torvalds odpověděl:

Žádná taková výjimka neexistuje.

Existuje upřesnění, že uživatelské programy využívající standardní systémová volání nejsou považovány za odvozená díla, ale ani to není "výjimka" - je to pouze stanovení hranice toho, co je jasně považováno za "odvozenou práci". Uživatelské programy zjevně nejsou odvozenou prací od kernelu, a tím pádem je jedno, jaká je licence kernelu, protože na tom nezáleží.

A krom toho, když dojde na moduly, tak otázka GPL je úplně stejná. Kernel je pod GPL. Žádné kdyby, ale a možná. V důsledku toho musí být každá odvozená práce pod GPL. Prosté.

Bohužel, otázka "odvozené práce" v copyrightových zákonech je jedinou věcí, která vede k šedým oblastem. Jsou oblasti, které nejsou ani maličko šedé: uživatelské věci jasně nejsou odvozenou prací, zatímco patche pro kernel ano.

Ale šedou oblastí je konkrétně něco jako ovladač, který byl původně napsán pro jiný operační systém (tj. základem určitě není odvozená práce Linuxu). Kdy přesně se to stane odvozenou prací kernelu (a tak začne podléhat GPL)?

TO je šedá oblast a je to ta oblast, u které osobně věřím, že některé moduly mohou být považovány za neodvozenou práci prostě proto, že nebyly navrženy pro Linux a nezávisí na žádném speciálním chování Linuxu.

V podstatě:

Cokoliv co je napsané s ohledem na Linux (ať už to pak funguje na jiném operačním systému nebo ne) je zjevně alespoň částečně odvozenou prací.
Všechno co ví o a hraje si se základním interním linuxovým chováním je zjevně odvozená práce. Když se potřebuješ vrtat v hlavním zdrojovém kódu, jsi odvozený, žádné pochyby.

Dříve jsme měli věci jako třeba původní modul Andrewova filesystému: standardní filesystém, který ani nebyl napsán pro Linux a pouze implentuje unixový filesystém. Je to odvozené jen proto, že byl portován na Linux, který má rozumně podobné VFS rozhraní jako ostatní Unixy? Osobně jsem neměl pocit, že bych tak mohl rozhodnout. Možná ano, možná ne, ale určitě je to šedá oblast.

Myslím, že ten případ nebyla odvozená práce a byl jsem ochoten to těm lidem kolem AFS říct.

Znamená to, že žádný modul pro kernel není odvozenou prací? KRUCI NE! Nemá to co dělat s moduly jako takovými, kromě toho, že to, co modul není, jasně odvozenou prací je (pokud je to tak hluboko v jádře, že to nejde natáhnout jako modul, musí to být odvozená práce prostě proto, že je to tolik blízké - a protože GPL výslovně zmiňuje linkování).

Takže když je něco modul, není to znakem toho, že by to nebyla odvozená práce. Je to pouze fakt, který znamená, že mohou být i jiné důvody pro tvrzení, že to není odvozené.

O několik minut později si sám odpověděl, aby doplnil:

Poznámka: dříve byla modulová rozhraní linuxového kernelu docela slabá, exportovala pouze několik desitek vstupních bodů a ve skutečnosti umožňovala pouze ovladače znakových a blokových zařízení se standardními rozhraními a natahovatelné filesystémy.

Takže protože mohl být dříve modul natažen pouze s pomocí těchto standardních rozhraní, bylo daleko pravděpodobnější, že s jádrem nemusí být příliš těsně spjat.

To se změnilo a modulová rozhraní kernelu, která máme dnes, jsou MNOHEM širší než byla kolem roku 95. Dneska jsou moduly používány skoro pro všechno, včetně věcí, které jsou velmi "interní", v důsledku čehož už nejsou moduly takovou hranicí. Nedá se proto příliš úspěšně argumentovat tím, že když je to modul, je to automaticky neodvozené.

Stejně tak dříve se dalo daleko účinněji tvrdit, že věci jako AFS a některé binární moduly (již dávno zapomenuté) byly vyvinuty zcela nezávisle na Linuxu: byly prostě vyvinuty ještě předtím než Linux vůbec existoval (lidmi, kteří o Linuxu nic nevěděli). To posiluje argument, že nebyly odvozeny.

Naproti tomu, dnes by se těžko tvrdilo, že nový ovladač nebo filesystém byl vyvinut bez pomyšlení na Linux. Myslím, že lidé v nVIDIA mohou pravděpodobně dostatečně čestně říkat, že kód, který portovali, nemá žádný původ v Linuxu. Ale upřímně řečeno, u jiných existujících projektů bych tomu tolik nevěřil.

Jason Kingsland poukázal na to, že pokud "vrtání se v hlavním zdrojovém kódu" znamená odvozenou práci, pak proč byly zavedeny EXPORT_SYMBOL_GPL a MODULE_LICENSE()? Určení jasných hranic pro modulové rozhraní ospravedlnilo binární moduly. To bylo signálem pro vývojáře proprietárního kódu, že binární moduly jsou tolerovány. Přidal také odkaz na článek od Kevina Dankwardta o tomto tématu. Linus odpověděl, že EXPORT_SYMBOL_GPL a MODULE_LICENSE jsou ve skutečnosti pouze dokumentace. A pokračoval:

Tohle je tam právě proto, aby bylo jasnější, kdy je případ černobílý a není třeba o něm ani na vteřinu přemýšlet. Nezbaví nás to té šedé oblasti, ale trochu ji to omezí ("pokud potřebuješ tento export, děláš něco, co vyžaduje GPL").

Poznámka: vzhledem k tomu, že kernel samotný je pod GPL, kdokoliv může řádek s EXPORT_SYMBOL_GPL() upravit a odstranit tu část _GPL. To by nebylo porušením licence. Ale nezpůsobí to, že modul, který ten symbol potřebuje, by nemusel být GPL - právě proto, že ta věc je především velká nápověda a nic moc jiného.

Na jiném místě Linus přidal svůj názor na GPL a OSL (Open Software License). O GPL řekl: Je to velmi kvalitní licence a vaše řeči o ní nejsou nijak podložené. Mně osobně se líbí trochu víc způsob, jak je napsaná OSL.

DevFS vs. udev v jádře 2.6, 107 e-mailů

8. pro - 14. pro

Andrew Walrond se zeptal:

Jak se teď díváte na devfs? Vzpomínám si, že Christoph a další se před šesti měsíci nevyjadřovali zrovna pěkně, ale později to Christoph vzal zpět.

Už jste to vzali na milost?

Greg KH řekl, že kód DevFS je zastaralý a má několik neřešitelných problémů. William Lee Irwin III také Andrewovi napsal: Řekl bych, že zastaralý je slabé slovo. sysfs a udev mají poskytovat stejné funkce, i když trochu jiným způsobem. Andrew poděkoval a zeptal se, jak dobře si udev, coby náhrada DevFS, stojí. Konkrétně, nabízí udev nějakou rozumnou alternativu k MAKEDEV? Rob Landley odpověděl:

Chápu to tak, že udev vezme informace, které poskytuje sysfs o zařízeních v systému a vytvoří soubory zařízení v /dev (to může být připojené jako ramfs nebo jako součást stálého filesystému, udev je to jedno). Hádám, že proleze sysfs, aby zjistilo, co bylo v systému při zapnutí (snad nějaká varianta "find /sys -name device") a pak přijímá události od hotplug při pozdějším přidání dalších zařízení. Kolem a kolem je to fajn, protože si rozumí s hotplug a je to malé a jednoduché. A výsledek vypadá jako normální adresář /dev, takže programy nemusí být upravené pro devfs (což byla podle mě od začátku chyba).

sysfs zatím bohužel nepodává informace o všem v systému (nejsou například žádné /sys/cdev, /sys/devices/legacy nebo /sys/devices/system). Už je ale připravených několik patchů, které přidají další.

Pravděpodobně někdy kolem 2.6.4 až 2.6.6 bude už sysfs mít podporu pro všechna zařízení, která udev potřebuje (alespoň pro ta, na jejichž absenci si někdo stěžoval). Do té doby... nevím. Možná bys mohl používat /dev na stálém filesystému, kde by sis mohl vytvořit další zařízení sám.

Nová sada patchů -tiny pro zmenšení kernelu, 7 e-mailů

11. pro - 12. pro

Matt Mackall oznámil:

Toto je první vydání nového stromu kernelu nazvaného '-tiny' (někdo už zabral -mm). Cílem tohoto stromu je sbírat patche snižující velikost diskového prostoru a paměti, které jádro potřebuje. A zároveň shromažďovat nástroje pro fungování na malých systémech - oblast, od které se Linux vzdaluje od té doby, co má Linus opravdové zaměstnání. Cílovými uživateli jsou embedded systémy a malé, postarší desktopy.

Pro začátek jsem vybral asi 50 patchů, které zeštíhlují různé části kernelu. Téměř vše je konfigurovatelné a mnohé z nich by nakonec mohly být vhodné i pro hlavní vývojový směr. Všechny konfigurační volby jsou momentálně zařazeny do CONFIG_EMBEDDED a mnoho menších změn je ukryto pod volbami CONFIG_CORE_SMALL, CONFIG_NET_SMALL a CONFIG_CONSOLE_SMALL.

Jak malé je -tiny? Je těžké to vyčíslit, protože všechno je konfigurovatelné a některé věci jsou důležitější než jiné, ale moje aktuální testovací konfigurace má plné IPv4 a většinu důležitých funkcí a pohodlně naběhne na 4M x86 stroji se 2M volné + buffery + keš.

Patch najdete na:

http://selenic.com/tiny/

To je celý Larry, 33 e-mailů

14. pro - 21. pro

Larry McVoy oznámil:

Mám funkční prototyp doplňku k BitKeeperu, který poskytuje tarbally a patche. Cílem je umožnit u všech stromů hostovaných na bkbits.net přístup k datům s free klientem.

Systém je jednoduchý, poskytuje pouze možnost získat nejnovější zdrojáky jako tarball a pak další aktualizace jako patche. Není tam možnost vytvářet diffy, slučovat, editovat soubory, atd. To všechno si můžete sami napsat s pomocí standardních nástrojů.

Než to spustím, chtěl bych vědět, jestli to (konečně) umlčí všechny stížnosti na BK (že není open source, že není na všech platformách, atd.). Doufám, že chápete, že víc už nedostanete. Už to nebudeme rozšiřovat, takže nepůjde dělat nic jiného než přesně sledovat nejnovější zdrojáky. Žádné diffy. Nic mimo nejnovější verze. Žádná historie revizí.

Chcete-li cokoliv jiného než pouze nejnovější verze, máte na výběr mezi samotným BitKeeperem nebo, pokud chcete hlavní větve linuxového kernelu, BK2CVS exporty. Tohle není gateway - je to způsob umožňující vývojářům sledování všech novinek s free klientem (se zdrojáky).

Bude-li většina reakcí kladných, přidám to na bkbits.net a možná nakonec přímo do BK.

Chris Frey a Pavel Machek upozornili na licenci, kterou pro software Larry použil:

Licencováno NWL - No Whining License (Licence zakazující stěžování).

Můžete to používat, upravovat a redistribuovat, za předpokladu, že souhlasíte s tím, že:

si nebudete stěžovat na tento nebo jakýkoliv jiný produkt od BitMover, Inc.
neexistuje žádná záruka.
budete citovat tento copyright v plném znění.

Budoucnost -mm stromu během 2.6, 17 e-mailů

17. pro - 19. pro

Andrew Morton vydal 2.6.0-test11-mm1 a Andrew Walrond se zeptal: Jaké máš plány s -mm po té, co převezmeš 2.6? Dostane se něco z -mm do 2.6 před vydáním 2.6.0? Nebo je to nachystané pro 2.6.1? Christiana Axelssona to také zajímalo a Andrew M. odpověděl: Začneme to slučovat po vydání 2.6.0. Bude to dost práce - v -mm teď čeká mnoho věcí už delší dobu. Některé pravděpodobně nebyly dostatečně testovány (hlavně na jiných architekturách než i386). Budu muset původní autory a další lidi požádat, aby všechno znovu ověřili.

Thomas Molina měl obavy, že kvůli tolika nahromaděným věcem bude 2.6.1 daleko méně stabilní než 2.6.0. Ale Andrew M. řekl, že většina jsou skutečné opravy skutečných problémů a jde jen o to vymyslet, jak je sloučit, aniž by se něco pokazilo. Také připomněl, aby lidé co nejvíce testovali -mm, protože tam budou nové patche předtím než se objeví v 2.6.

V originálu Kernel Traffic 246 vyšla navíc ještě tato témata: