GPL - Grenze des Wachstums?

Kris hat die Diskussion zum Thema GPL-Violations in einem sehr guten Artikel weitergeführt. Stellen wir es am Anfang noch mal klar: Wer Code nutzt, der unter einer Lizenz liegt, muss sich dieser Lizenz unterwerfen. Sei es die normale Löhnware-Lizenz, sei es CDDL, sei es die GPL. Wer dagegen wissentlich oder aus Dummheit verstoesst, ist selber schuld, wenn ihm dann qua Gerichtsbeschluss die Geschäftsgrundlage entzogen wird. Das ist am Ende auch gar nicht der Punkt auf den ich hinauswill. Ich vermute regelmaessig, das die Diskussion GPL oder eine differierende Lizenz eher eine weltanschauliche, denn eine an praktischen Dingen orientierte Sicht geht. Der eigentliche Punkt sind die Grenzen des Wachstums, welche sich die GPL-Ecosphere sich durch ihr Lizenzschema gibt. Kann es sich sich eine Benutzercommunity am Ende leisten, Personen von der Weiterentwicklung ihrer Umgebung auszuschliessen. Denn genau das vermag die GPL zu tun. Ich möchte nur noch mal auf das von mir genannte Beispiel der Erweiterung eines Opensource-Tools geben. Es gibt ein Problem mit einer bestimmten Kombination aus Tool und kommerziellen Produkt. Lösen lässt es sich nur durch eine sehr nahtlose Integration. Die GPL erzwingt jetzt, das sämtliche Libraries, die dazu benötigt werden, ebenfalls offengelegt werden. Unter anderem ist das eine Library, die Bestandteil eines Produktes ist. Kann es sinn der Weiterentwicklung der Codeallmende sein, das eine Weiterentwicklung des Codes des Opensource-Tools nicht Teil der Codeallmende werden kann, weil der Anspruch der Allmende über das hinausgeht, was ihr entspringt. Der Code der propritären Library hat nichts zu tun mit dem, was im Opensource-Tool steht. Klar … es gäbe Alternativen. RPC und ein Wrapperdaemon. Aber hier erzwingt der Anspruch der Codeallmende Lösungen, die ineffizienter sind … die letztlich der Nutzercommunity schaden. Und am Ende fordert der letztlich doch virale Charakter der GPL die Beschäftigung von Rechtsanwälten ein, um einen Weg zu finden, um etwas zu tun, was eigentlich im Sinne der GPL ist: Weiterentwicklungen am Code der Allmende der Codeallmende zurückzuführen. Das ist kein aus der Luft gegriffenes Beispiel, sondern Praxis mit der Kollegen zu tun haben. Und wohlgemerkt: Wir reden hier nicht davon, das hier geistiges Eigentum eines GP-lizenzierenden Entwicklers verletzt wird. Die Änderungen am Code kommen aus Sicht des geistigen Eigentums von der selben juristischen Person, wie die Library, die dazugelinkt werden soll. Die Änderungen sollen freigegeben werden, die Bibliothek aber nicht. Man kann dieses der Realität entstammende Beispiel ja sogar noch weiterspinnen: Was macht man, wenn man Teile der Library selber nur lizensiert hat, zur Verwendung in Form eines Binaries. Selbst wenn man will, ist dann eine Freigabe des Codes nicht moeglich. Auch das Argument, das es etwas Gutes ist, Firmen die Entwicklung von Closed Source Treibern zu erschweren, ist mir als User nur schwer verständlich. Wo sind die Rechte der Codeallmende verletzt, wenn sie stabile Interfaces bietet. Es wäre eine Schnittstelle, um beide Parteien zu integrieren. Darf eine Firma gezwungen werden, ihr Know-How offen zu legen, wenn sie den Nutzern eines Betriebsystems ihre Hardware nutzbar machen moechte. Es gibt schliesslich noch neben der Lager derjenigen die ihr geistiges Eigentum offenlegen und jenen die es aus irgendwelchen Gründen schützen wollen oder müssen, eine dritte Partei, um derer aller Wohl es eigentlich geht. Die Community der Nutzer. Es mag sein, das Marktdurchdrinung nicht alles ist. Die Codeallmende allerdings auch nicht. Denn ohne Nutzer ist alles nichts. Ihnen ist egal, warum ein Treiber in einem Betriebsystem nicht vorhanden ist, beziehungsweise nur mäßig funktioniert. Er wird sich abwenden. Wenn die entsprechende Opensource-Community Glück hat, von der Hardware … wenn sie Pech hat, nunja … dann von der Betriebsystemumgebung. Man stelle sich vor, das man einen Treiber für eine Karte oder eine Kernelerweiterung, die man in eine grosse Anzahl von Linux-Releases laden könnte, beispielsweise in 2.2, 2.4 und 2.6. Nicht mehr Schnittmengenbildungen zwischen verschiedenen Versionanforderungen, bei denen dann plötzlich 0 herauskommt (so gehabt vor einiger Zeit bei einem kommerziellen iSCSI-Produkt und RedHat auf Sun Hardware). Das ist übrigens der häuftigste Grund, den ich höre, wenn es um Unzufriedenheit mit und Abkehr von Linux geht. Warum muss ich einen Treiber der sich als stabil erwiesen hat, durch etwas anderes austauschen, nur weil sich wieder mal die Interfaces geändert haben. Ich als Nutzer habe ein Interesse daran, das ich für meine Hardware Treiber habe. Das diese Treiber möglichst stabil sind. Der Rest ist mir als Nutzer ziemlich egal. Und da glaube ich letztlich die Grenze des Wachstums: Die Marktdurchdringung eines Produktes, das es seinen Nutzern schwerer macht, es möglichst effizient zu nutzen, weil dahinter weltanschauliche Überlegungen steht (und das Erschweren von closed-source-Treibern hat für mich keine technische Notwendigkeit, das es anders geht, zeigt Solaris), wird letztlich an sich selbst scheitern. Ich glaube, um auf Dauer erfolgreich zu sein und um nicht im Kraftfeld zwischen weltanschaulicher Reinheit und den Rechten der geistigen Eigentümer des Kernels auf der einen Seite und der der wirtschaftlichen Bedeutung von Linux und deren Protagonisten zerrissen zu werden, muss sich Linux eine Schnittstelle geben, die gleichberechtigt die Integration von Systembestandteilen erlaubt, die einer anderen Lizenz unterliegen. Ich denke, der weiteren Verbreitung von Linux kann diese Koexistenz nur helfen. Eine Verneinung dieser Koexistenz ist mit Sicherheit negativ für die Linux-Ecosphere. Es ist mit Sicherheit kein Effekt, der schnell zu einer Verschiebung der Nutzerlandschaft führt. Aber ich denke, das er wirksam werden wird.