GPL-Durchsetzung und die Folgen

Nun komme ich doch endlich mal dazu, den Diskussionthread von letzter Woche weiterzuführen, der sich in meinem Blog oder auch bei Kris entwickelt hat. Ich muss ganz offen gesehen, das ich sowohl letzte Woche als auch dieses Wochende nicht die ganz grosse Lust hast, einen längeren Text zu schreiben. Die Erkältung steckt noch zu tief drin. Aber ich kann schlecht eine Diskussion vom Zaun brechen und dann einfach liegen lassen. Zurück zum eigentlichen Thema: Um es gleich am Anfang klar zu stellen: Wer sich der Code-Allmende bedient, hat dieser etwas zurückzugeben. Der Autor einer Entwicklung hat ein Recht darauf, davon zu partizipieren, wenn jemand Nutzen aus seiner Entwicklung zieht, und sei es dadurch, das die Weiterentwicklungen an seinem Code zurückfliessen müssen. Aber: Die GPL hat dadurch kontraproduktive Aspekte. Philip Hofstetter schreibt in seinem Kommentar: Diese Freiheit ist für mich der Grund, die Verbreitung von freier Software zu wünschen. Und genau diese Freiheit ist nicht mehr gegeben, wenn die Hersteller sich nicht GPL komform verhalten, da die resultierenden Systeme ziemlich schnell unmodifizierbar werden. . Aber: Die GPL hat dadurch kontraproduktive Aspekte. Philip Hofstetter schreibt in seinem Kommentar: Diese Freiheit ist für mich der Grund, die Verbreitung von freier Software zu wünschen. Und genau diese Freiheit ist nicht mehr gegeben, wenn die Hersteller sich nicht GPL komform verhalten, da die resultierenden Systeme ziemlich schnell unmodifizierbar werden. . Gerade hier zeigt sich doch ein viel weiter greifendes Dilemma. Es ist klar, das ein System nicht notwendigerweise offener wird, wenn sich dort verschiedene nicht freigegebene Module tummeln. Es ist allerdings ein Trugschluss, das man einen Hersteller durch die GPL in die Offenheit zwingen kann. Er steht immerhin vor mehreren Alternativen: Er kann seine Eigenentwicklungen ebenfalls GPLen. Gut … dann hat die Community gewonnen. Aber er kann auch Alternativen einsetzen, die einer anderen Lizenz unterliegen. OpenSolaris mit CDDL oder auch die BSDs mit ihren entsprechenden Lizenzen. Der Hersteller kann gegebenenfalls auch ein embedded-Betriebsystem einkaufen. Drei Alternativen und nur eine führt zu mehr Offenheit. Anstatt zu mehr Offenheit zu führen, hat das ganze zu weniger Offenheit geführt. Sehen wir es doch mal realistisch, wie gross ist den die Gruppe jener Menschen die in der Lage und Willens ist, auf einem Handy oder einem Router den Kernel auszutauschen. Man fahre doch mal mit einem Notebook durch eine beliebige deutsche Stadt. Die meisten Nutzer eines WLAN-Routers sind nicht mal in der Lage der Anleitung bezüglich der WLAN-Absicherung zu folgen. Es wäre vermessen, zu glauben, das Offenheit ein entscheidender Faktor bei der Kaufentscheidung wäre. Auf die Idee, den Kernel auf ihrem Handy auszutauschen, werden wahrscheinlich noch sehr viel weniger Menschen kommen, besonders wenn man daran denkt, wie selten Betriebsystemupdates für Handys eingespielt werden (Fragt mal bei euch in eurem nicht technikaffinen Bekanntenkreis rum, wann diese das letzte mal ein Update in ihr Handy geflashed haben) . Jetzt fordert diese kleine Gruppe etwas, das wahrscheinlich eine ganze Reihe von Geschäftsgeheimnissen offenlegen würde (schönes Beispiel sind da für mich die Treiber von hochgezüchteten Graphikkarten). Warum sollte eine Firma das tun? Ist es der Firma zu verübeln, Auswege zu suchen, Umwege zu finden und wenn es irgendwie geht, Linux ganz zu vermeiden? Was ist die Konsequenz? Wieder jede Menge Geräte, die vollkommen geschlossen sind, nicht mehr veränderbar sind, nicht mehr erweiterbar sind. Es bleibt da nur zu hoffen, das sich die Hersteller dazu durchringen, auf andere Opensourcealternativen zurückzugreifen und nicht auf vollkommen geschlossene Lösungen schwenken. Ich weiss das das ein Dilemma ist. Das es keine Lösung dafür gibt. Ich weiss aber auch, das dieses Dilemma das Potential hat, der Marktdurchdringung von Linux erheblichen Widerstand zu bieten. Am Ende möchte ich noch einen Punkt anbringen: Das Problem zwischen nicht austauschbaren Treibern ist für mich ein Pseudoproblem. Die Ursache in geschlossenen Treibern zu suchen ist meines Erachtens der Schlag in die falsche Richtung. Man sollte sich fragen, warum man einen Treiber bei einem Betriebsystemupgrade neu compilieren muss. Wie wäre es beispielsweise mit einem stabilen Treibermodell, das es auch über eine Vielzahl von Betriebsystemversionen ermöglicht, einen Treiber zu nutzen. Der es ermöglichen würde, den zugrunde liegenden Kernel auszutauschen, ohne das der Sourcecode des Treibers benötigt wird. Wenn man sich über den Orkus der Opensource-Welt erhebt könnte man zu einer allgemeineren Erkenntnis kommen: Offenheit bedeutet nicht nur Offenlegung mit missionarischem Eifer, sondern auch Kompatibilität mit anderen Modellen. Die Welt ist nicht weiss, die Welt ist nicht schwarz, es ist ein ganz ordinäres Grau, das sie färbt.