Verloren im Labyrinth der IT-Begriffe? Hier finden Sie Definitionen und Basiswissen zu Rechenzentrums-IT und -Infrastruktur.

Frei, aber nicht ohne Lizenz Was sind Open-Source-Lizenzen?

Autor Ludger Schmitz

Open Source ist überall, leider mit einer Vielzahl von Lizenzen. Mehr als 80, mehr als 90? Niemand weiß es genau. Die Konsequenzen von allen sind unterschiedlich weitgehend. Gegen Verwirrung und Ängste vor der Nutzung von Open Source hier ein Überblick.

Anbieter zum Thema

Open Source ist überall, leider mit einer Vielzahl von Lizenzen. Mehr als 80, mehr als 90? Niemand weiß es genau. Gegen Verwirrung und Ängste vor der Nutzung von Open Source hier ein Überblick
Open Source ist überall, leider mit einer Vielzahl von Lizenzen. Mehr als 80, mehr als 90? Niemand weiß es genau. Gegen Verwirrung und Ängste vor der Nutzung von Open Source hier ein Überblick
(Bild: © djama - stock.adob.com)

Vor etwa einem Jahr machte – nicht zum ersten und wahrscheinlich nicht zum letzten Mal – eine Klage wegen Verletzung von Open-Source-Lizenzen Schlagzeilen. Derlei ist Wasser auf die Mühlen derer, die Open Source als unsicheres Rechtsgebiet darstellen. Es wirkt noch nach, dass der Ex-Microsoft-Chef Steve Ballmer Linux einst als „Krebsgeschwür“ bezeichnet hat.

Tatsächlich dürfte es erheblich schwieriger sein, Lizenzen für proprietäre Software bis ins Detail zu durchblicken. Es sei nur an den Ärger mit Oracle erinnert, den viele Anwender hatten und haben, sobald sie die Datenbank auf Multi-Core-CPUs und/oder in virtuellen Umgebungen einsetzen. So etwas kann ihnen bei freier Software nicht passieren. Denn deren Nutzung und auch ihre Weiterentwicklung ist grundsätzlich erlaubt.

Der Unterschied zu proprietären Lizenzen

Allerdings hat auch Open Source seine Lizenzen, die vor allem einen wichtigen Punkt regeln, nämlich die Weitergabe von Software, in die Open Source eingeflossen ist. Rechtsabteilungen von Unternehmen wissen das natürlich. Aber sie tun sich damit schwer, genau wie alle anderen, die in dem Metier durchzublicken versuchen. Das gilt auch für den nicht juristisch vorgebildeten Autor dieses Beitrags, weshalb hier gleich die Anmerkung kommt, dass dieser Artikel keine Rechtshilfe darstellt und fehlerhaft sein kann.

Wer sich dem Thema Open-Source-Lizenzen annähert, wird bereits wissen, was Open Source per Definition kennzeichnet, nämlich vier Freiheiten:

  • Der Quellcode ist ungeachtet des Nutzungszwecks offen zugänglich,
  • er darf verändert
  • und in neue Software eingearbeitet werden und
  • er darf schließlich wiederum frei verbreitet werden.

Dabei gelten aber Regeln, die mit dem Verwertungsrecht und in Deutschland mit dem Urheberrecht zu tun haben. Diese Regeln sind in Lizenzen gefasst.

Auf den ersten Blick ein Verhau von Lizenzen

Die Open Source Initiative (OSI) ist die Organisation, welche feststellt, ob die Lizenz zu einer Software den vier Grundregeln von Open Source entspricht. Wer sich jedoch auf der OSI-Website einen Überblick zu schaffen versucht, wird vor ein Rätsel gestellt. Die Organisation hat quasi selbst den Überblick verloren – was nicht wundert. Denn in der Aufzählung „Licenses by Category“ werden 92 Open-Source Lizenzen genannt, von denen fünf seitens der Antragsteller zurückgezogen und zwölf durch neue Versionen abgelöst worden sind.

In der alphabetischen Auflistung sind (ohne die zurückgezogenen) 81 Open-Source-Lizenzen aufgeführt. Zu jeder Lizenz gibt es einen Link auf einen Text, der die jeweiligen Details der Lizenzen auflistet.

So kommt man also nicht sonderlich weiter; es sei denn, man sucht gezielt nach einer spezifischen Lizenz. Es gibt im Internet zahlreiche Listen der „wichtigsten“ Open-Source-Lizenzen, ein Beispiel in deutscher Sprache hier. Die Bewertung widerspiegelt allerdings immer eine Meinung der Autoren.

Die OSI nennt in der Kategorie „Licenses that are popular and widely-used or with strong communities“ neun Lizenzen: die Apache License 2.0, die 2-clause und die 3-clause BSD License, die GNU General Public License (GPL), deren weichere Variante Lesser General Public License (LGPL), die MIT-License (MIT), die Mozilla Public License (MPL), die Common Development and Distribution License (CDDL) und die Eclipse Public License (EPL).

Neuere Lizenzen für Cloud Computing und europäische Behörden

Unter der Rubrik „Uncategorized Licenses“ nennt die OSI noch zwölf Regelwerke, von denen drei bekannter und auch ziemlich verbreitet sind: die European Union Public License (EUPL), Die GNU Affero General Public License (AGPL) und die Microsoft Public License (MS-PL). In Europa verbreitet sich zunehmend die EUPL, welche die EU für Open-Source-Programme geschaffen hat, die in der IT der öffentlichen Verwaltungen entstanden sind, und stark an die GPL angelehnt ist.

Solche Software steht nicht nur Behörden zur Verfügung. Häufig anzutreffen ist die AGPL. Das ist im Prinzip die GPL mit einem zusätzlichen Artikel für die Verbreitung und Nutzung von Open Source in Unternehmens-übergreifenden Netzen, also beispielsweise beim Cloud Computing.

Grundsätzlich verweigern alle Open-Source-Lizenzen eine Garantie auf die Funktionsfähigkeit eines Programms sowie rechtliche Haftung der Entwickler. Der eigentliche Unterschied und Haken – und das übersehen Entwickler manchmal zunächst – bei den Lizenzen besteht darin, dass es etliche Folgen für eine Software haben kann, in die Open Source eingeflossen ist. Wer also eine Open-Source-Software erweitert, kann gezwungen sein, deren Lizenz zu übernehmen. Kann, muss aber nicht.

Deutlich unterschiedliche Lizenz-Grundtypen

Im Prinzip stehen sich zwei Lizenztypen gegenüber: freigiebige – üblicherweise „permissive“ genannte – und nicht-freigiebige („non-permissive“ oder „strongly protective“) Lizenzen. Software unter permissiver Lizenz macht kaum Auflagen, was Lizenzierungsfehler reduziert. Zum ersten Typ gehören Public Domain Software (auch „unlicense“, aber Vorsicht, dies ist ein juristischer Sonderfall und nicht unbedingt Open Source) sowie zum Beispiel die Lizenzen MIT (auch X11), BSD, Apache, PHP License und OpenLDAP Public License.

Bei diesen freigiebigen Lizenzen darf man den Sourcecode auch für neue Produkte verwenden, ohne auf diese die gleiche Lizenz übernehmen zu müssen. Lediglich eine Notiz zur Lizenz und zum Copyright ist erforderlich. Hier kann Open-Source-Software also in ein proprietäres Produkt einfließen; es gibt keinen viralen Effekt.

Auf der anderen Seite stehen die „non-permissive“ Lizenzen. Die bekanntesten davon sind die GPL und die AGPL. Beide Lizenzen kommen von der Free Software Foundation (FSF); deren europäischer Ableger ist die Free Software Foundation Europe (FSFE). Der FSF geht es bei der Lizenz um die Sicherstellung der Freiheit der Anwender. Open Source ist hingegen ein Marketing-Begriff, um Unternehmen nicht durch ideologische Inhalte zu verunsichern. Um die Differenzen zu überbrücken, ist oftmals auch von „Free/Libre and Open Source Software“, kurz FLOSS, die Rede.

Unbestritten ist die GPL die am weitesten verbreitete Open-Source-Lizenz. Nach verschiedenen Einschätzungen im Internet sind 60 Prozent aller Open-Source-Software unter der GPL erschienen. Die GPL ist in den Versionen 2 und 3 verbreitet. Beide sind gekennzeichnet durch ein strenges „Copy-Left“-Prinzip (eine Kampfansage an Copyrights) und nicht-freigiebig. „Protective“ bedeutet: Freie Software (vulgo: Open Source) soll frei bleiben. In der Konsequenz muss von GPL-lizenzierten Programmen abgeleitete Software unter der GPL stehen.

Kompromissformeln zwischen den Polen

Zwischen den beiden Polen permissive und non-permissive gibt es jedoch auch noch etwas. Einige Lizenzen machen die Verlinkung der Libraries sowohl mit proprietären als auch Open-Source-Software möglich. Hier lässt sich also in begrenztem Maße quelloffene Software mit proprietären Produkten unter einen Hut bringen. Das bekannteste Beispiel für solch eine Lizenz ist die LGPL. Ein ähnlicher Fall ist die Mozilla Public License (MPL).

Die berühmte Grafik von David Wheeler. Die Pfeile zeigen auf die Lizenz, welche bei Verbindungen von zwei Open-Source-Programmen zu nehmen ist
Die berühmte Grafik von David Wheeler. Die Pfeile zeigen auf die Lizenz, welche bei Verbindungen von zwei Open-Source-Programmen zu nehmen ist
(Bild: David Wheeler 2017)

Wegen der lizenzrechtlichen Wirkung auf das Endprodukt ist es nicht so einfach, kurzerhand Softwareteile unter den Lizenzen x, y oder z zu einem neuen Produkt zu integrieren. Ein schon berühmtes Schaubild, was und mit welche Konsequenzen geht, hat David Wheeler vorgelegt (siehe Grafik).

Die Pfeile zeigen an, welche Lizenz bei Verbindungen das Ergebnis sein muss. Wird eine BSD-Software mit einem LGPL- oder GPL-Programm verbunden, muss das Ergebnis unter der LGPL beziehungsweise der GPL stehen. Im Prinzip läuft das also darauf hinaus, das am Ende immer die weniger freigiebige Lizenz steht.

Insgesamt sind die Lizenzen auch für Nichtjuristen hinreichend verständlich formuliert. Allerdings ist die Lizenzfrage keineswegs bis ins feinste Detail der technischen Umstände geklärt. Zum Beispiel ist nicht unumstritten, was bei dynamischer Verlinkung gilt. Dies ist ein „grauer Bereich“, wie Linus Torvalds dazu bemerkt hat. Jedoch werden solche Fälle in der Praxis weniger relevant sein. Das liegt natürlich an der weiten Verbreitung der GPL, die deswegen sehr oft ins Spiel kommt und entsprechend Konsequenzen hat.

Hier gibt es Hilfestellungen

Ein aufschlussreicher Artikel zum Open-Source-Lizenzrecht und zur Vermischung von Open-Source-Lizenzen ist auch in der Schwesterpublikation „Dev-Insider“ erschienen. Dort ist auch auf weitere Informationsquellen verlinkt. So bietet „choosealicense“ für Einsteiger einen ersten, leicht verständlichen Überblick über die Anforderungen wichtiger Lizenzen.

Eine wichtige Hilfestellung für die Auswahl der richtigen Lizenz bietet der „Open Source Compliance Advisor“ mit einem Online-Tool, das genauer nach Umständen und Zielen einer Nutzung von Open Source fragt.

Beratung suchende können sich auch an die deutsche Open Source Business Alliance wenden. In ihr gibt es eine Working Group Recht. Wer ganz sicher gehen möchte, findet im Internet leicht einige Anwälte (es gibt inzwischen mehr als den bekannten Till Kreutzer), die auf Open-Source-Lizenzen spezialisiert sind und über deren Web-Präsenzen wiederum etliche in die Details gehende Aufsätze.

Oder man wende sich an das Institut für Rechtsfragen der Freien und Open Source Software. Schon allein dessen Website ist sehr umfangreich und geht über den Bereich der Software hinaus, bietet nämlich auch Informationen zu den Creative Commons Lizenzen, bei denen es gar nicht um Sourcecode geht.

Letztlich macht der Umgang mit Open-Source-Lizenzen nicht unbedingt Anwälte erforderlich, denn die Lizenzen sind sprachlich möglichst einfach gehalten. Ebenso ist der kreative Umgang mit Open Source, also das Programmieren, kein Spiel für Mutige. In der Open-Source-Gemeinde gibt es eine Grundregel: Man darf Fehler machen. Und das gilt auch in Lizenzfragen.

Die Linux Foundation, die Free Software Foundation oder andere Lizenzgeber aus der Community zerren niemanden gleich vor den Kadi. Im Falle einer Lizenzverletzung wird immer zuerst der Verletzer kontaktiert und in einer Frist von 30 Tagen eine Übereinkunft dahingehend angestrebt, dass die Lizenzbedingungen erfüllt werden.

So war es dann auch im eingangs erwähnten Fall. Der Kläger, ein ehemaliger Kernel-Mitentwickler zog seine Klage zurück. Die Linux Foundation hatte zwischenzeitlich eine Einigung mit dem Beklagten erzielt.

* Ludger Schmitz ist freiberuflicher Journalist im „Un-Ruhestand“ in Kelheim.

(ID:45828706)