Open Source Software: exponentielles Wachstum, weniger Copyleft

Vor einiger Zeit berichtete Matthew Aslett am 451 CAOS Theory Blog in einer Serie von Einträgen über den zwischen 2008 und 2012 sinkenden Anteil an Open-Source-Software, der unter der GNU General Public License (GPL) veröffentlicht wird (siehe Abbildung).

GPLusage_08-12
Anteil GPL-lizenzierter Open-Source-Software in ausgewählten Datensätzen zwischen 2008 und 2012 (Quelle: Aslett 2012, 451 CAOS Theory)

Die Besonderheit der GPL ist ihr auch als „Copyleft“ bezeichneter „viraler“ Charakter: Weiterentwicklungen auf Basis von GPL-lizenzierter Software dürfen nur unter derselben Lizenz weiterverbreitet werden; das bekannteste Beispiel für GPL-lizenzierte Software ist der Linux-Kernel. Aber auch jenseits von Software findet das Copyleft-Prinzip Anwendung – so ist zum Beispiel die Creative-Commons-Lizenz der Wikipedia eine Copyleft-Lizenz.

Im Bereich von Open-Source-Software ist allerdings Aslett zu Folge ein relativer Anstieg der Nutzung solcher Lizenzen zu beobachten, die auf eine Copyleft-Klausel verzichten (z.B. Apache-, BSD- oder MIT-Lizenz). Wichtig ist zu betonen, dass es sich dabei um relative Verschiebungen handelt, in absoluten Zahlen wächst auch der Pool an GPL-lizenziertem Software-Code weiterhin.

In einem Aufsatz für die 9th International Conference on Open Source Systems (OSS 2013) haben sich Gottfried Hofmann, Dirk Riehle, Carsten Kolassa und Wolfgang Mauerer jetzt noch einmal eingehend die Lizenz-Entwicklung in der Zeit vor 2008 – konkret zwischen 1995 und Juni 2007 – vorgenommen (siehe Abbildung).

Untersuchungszeitraum der Studie von Hofmann u.a. (2013, S. 2)

Der am Blog von Dirk Riehle im Volltext (PDF) verfügbare Beitrag bestätigt auf Basis eines Samples, das ca. 30 Prozent des Source-Codes aller aktiven Open-Source-Projekte umfasst, den Trend hin zu Lizenzierung ohne Copyleft in den letzten Jahren. Außerdem identifizieren die Autoren die Zeit rund um 2000/2001 als Wendepunkt in der Entwicklung: seit damals wächst Open-Source-Software ohne Copyleft stärker als Copyleft-Open-Source, (siehe Abbildung, außen vor blieben in der Analyse Mischformen wie die LGPL-Lizenz).

log-scale-SLoC-95-07
Logarithmisch skaliertes Wachstum von nicht-Copyleft- (links) und Copyleft-lizenzierten (rechts) Zeilen von Open-Source-Softwarequelltext zwischen 1995 und 2007 (aus: Hofmann u.a. 2013, S. 8)

Die Ergebnisse belegen darüberhinaus für den Untersuchungszeitraum ein ungebrochen exponentielles Wachstum des Pools an Open-Source-Software-Quellcode. Nicht kontrolliert wird in der Studie jedoch für Copy-Paste von Quellcode zwischen unterschiedlich lizenzierten Projekten; da ein solches Copy-Paste aber vor allem in eine Richtung möglich ist (von nicht-Copyleft zu Copyleft-Projekten), dürfte der Anteil von Copyleft-Software in der Studie deshalb eher noch überschätzt werden.

Was die Erklärung für den beobachteten Wandel im Lizenzierungsverhalten betrifft, so führen die Autoren diesen in erster Linie auf eine Zunahme an kommerziell finanzierter Open-Source-Softwareentwicklung zurück. Sie verweisen in diesem Zusammenhang auf weitere, noch unpublizierte Forschungsergebnisse, die eine solche Erklärung stützen würden.

Übrigens ist auch jenseits von Software im Bereich von Creative Commons ein leichter Trend hin zu weniger restriktiven Lizenzversionen zu beobachten, die letzten Daten stammen hier allerdings aus dem Jahr 2010 (siehe Abbildung; als „fully free/libre/open“ zählen hier jedoch auch Copyleft-Lizenzen, die vor allem von NonCommercial- und NoDerivatives-Lizenzen abgegrenzt werden).

Zahl Creative-Commons-lizenzieter Werke und Anteil frei lizenzierter Werke zwischen 2003 und 2010 (Quelle: http://wiki.creativecommons.org/Metrics)
Zahl Creative-Commons-lizenzieter Werke und Anteil frei lizenzierter Werke zwischen 2003 und 2010 (Quelle: http://wiki.creativecommons.org/Metrics)

Jenseits von der Suche nach den Ursachen für diese Entwicklung hin zu weniger restriktiven Lizenzbedingungen bei offen lizenzierten Inhalten stellt sich die Frage, ob diese Entwicklung zu begrüßen ist? Einerseits führt sie dazu, dass die Rekombination unterschiedlich lizenzierter Inhalte tendenziell einfacher möglich ist. Andererseits, vor allem im Softwarebereich, besteht beispielsweise bei BSD-Lizenzen die Möglichkeit, dass Firmen sich an Open-Source-Quellcode bedienen aber nicht zu dessen Weiterentwicklung beitragen bzw. eigene Weiterentwicklungen nicht zurückspeisen.

Vielleicht ist es aber inzwischen so, dass die Bedeutung von Copyleft-Klauseln im Softwarebereich einfach nicht mehr so groß ist wie noch in den 1990er Jahren, weil auch auf Seite kommerzieller Akteure Open-Source-Prinzipien besser verstanden werden. Hinzu kommt, dass selbst bei Fehlen einer Copyleft-Klausel die simple „Privatisierung“ des Quellcodes oft keine Option ist – im Gegenteil: was passieren kann, wenn sich die Community der freiwillig Beitragenden von einem Unternehmen mit Zugriff auf den Quellcode unfair behandelt fühlt, ließ sich 2010 am Beispiel der Spaltung zwischen OpenOffice.org und Libre Office beobachten. Wichtiger als die Frage Copyleft oder nicht sind offensichtlich transparente und als fair empfundene Governance-Strukturen.

Wenn Ihr unsere Arbeit unterstützen wollt, freuen wir uns über eine Spende oder ein freiwilliges Abo in Form einer Dauerüberweisung.

9 Ergänzungen

  1. Ein wichtiger und hochinteressanter Bericht, der mir die zeigt wie wichtig es ist anderen Leuten, „Copyleft“ und „Copyright“ zu erklären.
    Und zu erklären welche überragend wichtige Rolle, offenes und freizugängliches Wissen und Inhalte, für eine friedfertige, ausgeglichene und humane Gesellschaft, ist.

    Eine Kritik an die Betreiber sei mir hier gestattet, ich fände es besser wenn „netzpolitik.org“ in Zukunft auf das NC – Attribut verzichten würde.

    liebe grüße
    lisa

    1. Und auf die bald einrollenden Millionen durch das Leistungsschutzrecht verzichten? Ich bitte dich!

  2. Tatsächlich gibt es, glaube ich, auch einen Mentalitätswandel. Die politischen Ziele von Copyleft sind dem Entwicklernachwuchs nicht mehr so wichtig, wie Kompatibilität mit der kommerziellen Sphäre, was ja auch bessere Karrierechancen bedeutet. Aber auch da steht vermutlich die heute größere Bedeutung von firmenfinanzierter Open-Source-Software dahinter.

  3. nahezu jeder Programmierer den ich kenne und mit dem ich gesprochen habe bevorzugt Open-Source, von daher gibt es meiner Meinung nach ein technisches Verständnis von Open-Source. Zwei Aspekte gehen in meiner Wahrnehmung etwas unter, zum einen der kulturförderliche Aspekt und zweitens der der Wichtigkeit von Lizenzen als Juristischer Schutz..

    Firmen neigen dazu gut funktionierende Modelle, Software etc. für ihre Profiinteressen einzunehmen, es ist dadurch sehr wichtig klar und deutlich zu machen wie mit dem Werk umzugehen ist. Ich nutzte dazu den Begriff der „Einhegung“. (vgl. MySQL – SUN/Oracle)

  4. Grundsätzlich traue ich mal keiner Lizenz, die nicht ins 80×25 Zeichen Raster passt. Allein schon weil ich zu faul bin die zu Lesen.

    Abgesehen davon sprechen für mich noch andere Argumente gegen die GPL:
    a) Ich denke nicht, dass das Patentproblem mit Lizenzen gelöst werden sollte.
    b) Ich kann per Lizenz nicht aus einem rücksichtslosen Menschen ein sozial engagiertes Wesen machen.
    c) Bei Gerichtsverfahren gewinnt immer der Anwalt. Und mal ehrlich, es gibt deutlich mehr Abmahner und Patentanwälte als es Markus Kompa gibt.

  5. Ich mag für meinen Code einen Lizenztext verwenden, den ich selbst verstanden habe. Das seitenlange juristische Geschwurbel der GPL, das sich auch noch am US-Recht orientiert, ist da nicht geeignet.

  6. Ich denke, der GPL-Rückgang könnte partiell damit zusammenhängen, dass die GPL viele Varianten hat die nur teilweise zueinander kompatibel sind, und noch nich genau feststeht wie der Nachfolger der GPLv3 denn aussehen soll (als außenstehendem erscheint mir das so, als gäbe es da zwei Gruppen von Leuten die an GPLv4/“Copyleft-Next“ arbeiten, zum einen die FSF, zum anderen eine Gruppe unabhäniger(?) Freiwilliger unter Richard Fontana). Da noch nicht abzusehen ist wie kompatibel das alles sein wird (GPLv2 und GPLv3 sind ja auch nur eingeschränkt miteinander kompatibel), und die Leute sich nicht einschränken wollen, gehe ich davon aus, dass man für Wiederverwendbarkeit des Codes lieber das geringere Risiko eingeht und seinen Code unter permissiveren Bedingungen zu Verfügung stellt.

    Außerdem weiß ich aus persönlicher Erfahrung, dass viele Software-Autoren die Lizenz-Entscheidung als „Bikeshed“ ansehen, das eigentlich eher Anwälte als sie selbst betrifft. Da man später die Lizenz nur schwer ändern kann, ist eine Möglichkeit hier, zuerst eine permissivere Lizenz zu benutzen, und wenn sich herausstellt, dass andere Leute zu sehr asoziales Verhalten dem eigenen Code gegenüber an den Tag legen, kann man bsp. von 2-clause-BSD auf LGPL oder GPL umstellen. Wenn das Projekt aber schon größer ist, und man auf einer GPL-Codebase sitzt, an der hunderte Menschen mitgearbeitet haben, muss man jede einzelnen der zwei Zeilen Code geschrieben hat fragen, ob er einer Lizenzänderung zustimmt. Das ist nur schwer möglich, wie man gut an z.B. dem Linux-Kernel sieht.

    Ich persönlich lehne ich Copyright ab, und würde meinen Code tendenziell als Public Domain zur Verfügung stellen, wenn das in Deutschland möglich wäre. Ich habe mir viele Gedanken darüber gemacht, dass das Urheberrecht nach deutschem Recht eigentlich kein Recht, sondern eine Pflicht für den Urheber darstellt (Hier sind doch sicher Anwälte anwesend, eure Meinung dazu würde mich interessieren). Dazu müsste sich aber der generelle Standpunkt der Bevölkerung gegenüber offener Entwicklung ändern. (Also beispielsweise das Patentsystem, aber ich sehe eher wenig Chancen, dass das schnell genug passiert)

    Was haltet Ihr eigentlich von der Sleepycat/Berkeley DB License, die mir in mehreren Punkten als Kompromiss zwischen BSD und GPL erscheint, insofern, dass man als Autor einer Software die Code unter der Sleepycat-Lizenz benutzt zwar gezwungen ist, den Code bereitzustellen, aber nicht spezifiziert ist, unter welcher Lizenz das geschehen muss. Ist euch das zu vage?

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.