Kontroverse um ndiswrapper
Seit drei Jahren konnten Anwender mit dem freien Modul ndiswrapper proprietäre Windows-Treiber für Wireless LAN in den Linux-Kernel laden, Änderungen in der Testversion von Kernel 2.6.19 verhindern dies jedoch.
ndiswrapper wurde im Jahr 2003 erstmals vorgestellt und sollte eine freie Alternative zum kommerziellen DriverLoader darstellen. Im Gegensatz zu DriverLoader, das jede Art von Netzwerkkarten unterstützen wollte, für die es einen NDIS-konformen Windows-Treiber gibt, wollte sich ndiswrapper auf Wireless LAN beschränken, denn zum damaligen Zeitpunkt wurden nur wenige dieser Geräte von Linux-Treibern unterstützt. Auch heute noch halten die meisten Hersteller ihre Schnittstellen geheim, was jedoch diverse Projekte nicht daran hindert, trotzdem die Entwicklung freier Treiber zu versuchen.
Da ndiswrapper hauptsächlich dazu verwendet wird, proprietären Code in den Kernel zu laden, hielten es einige Kernel-Entwickler für angemessen, das Taint-Flag des Kernels zu setzen, wenn der Wrapper geladen wird. Diese Änderung fand in Kernel 2.6.16 statt und hatte offenbar zunächst keine Auswirkungen. Erst in den Testversionen für Kernel 2.6.19 kam es durch eine weitere Änderung dazu, dass ndiswrapper nicht mehr geladen werden konnte. Dem Modul wurde nun nämlich der Zugriff auf Funktionen verwehrt, die nur GPL-Modulen zur Verfügung stehen sollen.
ndiswrapper selbst steht allerdings unter der GPL, weshalb sich sein Autor auch darüber beschwerte. Der Sinn der ausschließlich für GPL-Module verfügbaren Funktionen sollte sein, zu verhindern, dass proprietärer Code erstellt werden kann, der von Kernel-Code abgeleitet ist. Die Module, die der ndiswrapper lädt, sind jedoch nicht unter Verwendung von Kernel-Code geschrieben und rufen auch keine Kernel-Funktion direkt auf.
Manche Kernel-Entwickler fürchten, dass Module wie ndiswrapper zur Umgehung der Beschränkung auf GPL-Module verwendet werden könnten. Ein Modul, das unter GPL steht und damit Zugriff auf alle Kernel-Funktionen hat, könnte ein proprietäres Modul laden, das diese Funktionen dann ebenfalls benutzen kann. Doch scheint es technisch unmöglich, solche Module zu verhindern, denn sie können offenbar nur an ihrem Namen erkannt werden, der beliebig änderbar ist.
Eine Lösung scheint sich nun abzuzeichnen, nachdem Andrew Morton sich in die Diskussion eingeschaltet und die Änderung als Fehler bezeichnet hat. Somit könnte in Kernel 2.6.19 das Modul wieder funktionieren, und kein Endanwender hätte von der Diskussion etwas mitbekommen.
Im Verlauf der Diskussion wurde allerdings ein anderes Problem des ndiswrappers deutlich. Es kursieren zuviele Anleitungen im Netz, wie man ndiswrapper mit verschiedener Hardware zum Laufen bringt - speziell mit Hardware, für die es inzwischen einen echten Linux-Treiber gibt. Einige Kommentatoren sind der Ansicht, dass mit den Treibern für Centrino und Broadcom bereits 90% aller Wireless-Hardware abgedeckt ist. Der Broadcom-Treiber, der durch Reverse Engineering entstanden ist, sei zwar noch nicht perfekt, aber benutzbar. Der in vielen Fällen nun unnötige Einsatz von ndiswrapper entziehe den freien Projekten Tester und schade mehr oder weniger der ganzen freien Softwarewelt. Als erstes seien die Distributoren gefordert, den Einsatz von ndiswrapper auf das absolute Minimum zu reduzieren und ihre Dokumentation entsprechend zu verbessern.
