Linux unter der GPL
Wenn man sich die Nachrichten auf Pro-Linux im letzten Monat anschaut, fällt einem schnell eine Meldung ins Auge, die eine besonders hohe Anzahl an Kommentaren provoziert hat: Den Bericht über eine Änderung im USB-Subsystem, welche bestimmte Funktionen nur noch GPL-Modulen zur Verfügung stellt. Diese veranlasste einen Entwickler der Firma AVM zum Kommentar, dann in Zukunft verschiedene Hardware nicht mehr unter Linux unterstützen zu können, für die die Firma AVM momentan proprietäre Closed-Source-Module zur Verfügung stellt.
Zu diesem Artikel entwickelte sich im Kommentarbereich dazu eine lebhafte Diskussion, die den Anstoß zu diesem Editorial gab. Denn der größte Teil der Diskussion bestand zum einen aus Postings enttäuschter Besitzer von betroffener Hardware, die den Kernelentwicklern die Schuld an dieser Entwicklung zuwiesen, zum anderen aus Meinungen, dass proprietäres Modul oder nicht vollkommen egal sei - Hauptsache, die Hardware läuft. Die GPL (General Public License, Wikipedia-Eintrag zur GPL) wurde dazu häufig kritisiert, denn da der Kernel unter dieser Lizenz verbreitet werde, gäbe es erst diese Schwierigkeiten.
Auf welcher Seite der Diskussion man auch stehen mag, es sollte klar geworden sein, dass die Tatsache, dass der Linux-Kernel und auch ein sehr großer Anteil Open-Source-Software (OSS) der GPL unterliegt, nicht vernachlässigt werden darf.
Was bezwecken die Entwickler nun mit dieser GPL? Salopp gesagt, jeder soll Linux für seine Zwecke einsetzen dürfen. Es soll sogar jeder den Linux-Kernel für seine Zwecke anpassen, verändern oder erweitern können. Wenn allerdings das Ergebnis dieser Arbeit weiter verbreitet werden soll, müssen die Änderungen/Erweiterungen im Quellcode verfügbar gemacht werden, und zwar wiederum unter der GPL. Auf diese Weise »bezahlt« jeder mit seinen eigenen Verbesserungen für den freien Zugriff auf die Linux-Quellen. Diese Änderungen kommen nun allen Linux-Anwendern zu Gute und können durch diese weiter fehlerbereinigt oder weiterentwickelt werden. Software, die nach diesem Modell entwickelt wird, kann sich durch diese Feedback-Schleife stetig verbessern, sei es in der Leistungsfähigkeit, der Stabilität, der Anwendbarkeit auf anderen Architekturen und vielem anderen mehr.
Betrachten wir nun den Fall AVM. Statt eines unter GPL stehenden freien Moduls, welches auch in den Kernel direkt hätte aufgenommen werden können, entschied sich die Firma, diverse Hardware nur durch ein Closed-Source-Kernelmodul (CS-Kernelmodul) zu unterstützen. Auf den ersten Blick scheint doch alles wie gewünscht zu sein: Die Hardware funktioniert unter Linux.
Aber schon an dieser Stelle kann man den Entwicklern den Vorwurf machen, den Linux-Kernel zwar einzusetzen, aber nicht dafür »bezahlen« zu wollen. Linus Torvalds selbst räumt aber ein, dass es eine Grauzone gibt, ob ein Kernelmodul im Sinne der GPL ein »abgeleitetes Werk« darstellt. (Weitere interessante diesbezügliche Mails.) Daher wird dieses Verhalten bisher toleriert, dabei jedoch ausdrücklich betont, dass auf proprietäre Module in der Weiterentwicklung des Kernels keine Rücksicht genommen wird. Dies weiß jeder Entwickler, der die Linux-Kernel-Mailing-List mitliest oder sich zumindest auf Seiten wie lwn.net, kerneltrap.org oder kerneltraffic.org (die leider vor kurzem den aktiven Betrieb eingestellt hat) auf dem Laufenden hält.
Aus technischer Sicht bemerkt man schnell, dass die Unterstützung nur für kleine Mengen von »Linux« gilt. Das Kernelmodul ist, da nur in Binärform verfügbar, auf die angebotene Hardware-Plattform beschränkt und das sind meist nur die x86-kompatiblen Prozessoren. Doch Linux läuft auch auf PowerPC-Prozessoren, auf SPARC-Rechnern und weiteren Architekturen... Dass es sich für eine Firma nicht lohnen mag, für diese vergleichsweise kleine Anwenderzahl mehrere CS-Module für die jeweiligen Architekturen anzubieten, ist unbestritten. Doch muss sich die Firma daran messen lassen, was möglich ist, wenn ein Modul im Sourcecode verfügbar ist: Jeder Besitzer der passenden Hardware kann es dann für sein System übersetzen, ganz egal, auf welcher Plattform. Sollten Anpassungen nötig sein, reicht es, wenn ein einzelner Programmierer - der nicht bei der Firma angestellt sein muss! - sie vornimmt. Alle anderen Anwender der »exotischen« Plattform wären Nutznießer.
Wobei die Portierung eines Treibers auf eine andere Plattform schon einen Spezialfall darstellt. Im rauhen Alltag ist es viel wahrscheinlicher, dass einfach nur ein Bug im Treiber auftritt. Bei einem CS-Modul ist kein Kernelentwickler außer dem Hersteller in der Lage, den Fehler zu beheben. Da Module den Kernel nicht unerheblich beeinflussen können, weigern sich die meisten Kernelentwickler, einen Linux-Bugreport zu bearbeiten, wenn ein proprietäres Modul geladen und der Kernel damit »befleckt« wurde (tainted). Das ist kein Schmollen oder Zanken, sondern es fehlen ihnen schlicht die Möglichkeiten, dem Fehler auf den Grund gehen zu können.
Auf der anderen Seite entwickelt sich der Kernel selbst natürlich auch weiter. Die im Kernelsource enthaltenen Treiber können bei - die Möglichkeit, die interne Arbeitsweise des Kernels umstellen zu können, wenn es notwendig oder besser erscheint - ist im Übrigen ein Ergebnis der offenen Quellen. (Weshalb der in diesem Zusammenhang immer wieder auftauchende Vorschlag eines stabilen Binär-APIs innerhalb des Linux-Kernels Unsinn ist, hat Greg Kroah-Hartmann in »stable-api-nonsense.txt« übrigens sehr schön dargelegt. Diese Datei ist Bestandteil der Linux-Dokumentation!) Außerhalb des Kernels gepflegte OS-Module können ebenfalls angepasst werden - nicht nur durch den eigentlichen Programmierer, sondern auch durch andere Entwickler. Ein CS-Modul dagegen ist darauf angewiesen, dass der Hersteller die notwendigen Änderungen vornimmt. Das mag nach einer Selbstverständlichkeit klingen, aber was passiert, wenn der Hersteller dieser Verpflichtung nicht nachkommt?
Dafür kann es leider viele Gründe geben: Die Hardware wird nicht mehr hergestellt, also auch der Treiber dazu nicht mehr gepflegt. Oder der Hersteller ist pleite gegangen. Oder eine Unterstützung wurde für neuere Versionen nie zugesagt und daher auch nicht programmiert. Oder der zuständige Programmierer hat die Firma verlassen oder er ist unabkömmlich in anderen Projekten beschäftigt oder, oder, oder...
