Open-Source-Lizenzen: Typen und Gegenüberstellung

Nutzer und nicht selten auch Entwickler assoziieren mit dem Begriff „Open Source“ oft die Freiheit, ein entsprechendes Software-Produkt kostenlos nutzen und beliebig vervielfältigen, verändern und verbreiten zu dürfen. Ein weitläufiges Missverständnis, setzen sie das Konzept von Open Source damit doch mit dem von Public-Domain-Software oder Shareware gleich. Auf diese beiden nämlich trifft dies durchaus zu: Ihre Nutzung ist kostenlos, und auch ihre Modifikation ist ohne ausdrückliche Genehmigung oder Lizenzierung gestattet.

Open-Source-Software liegt dagegen zumeist eine bestimmte Lizenzform zugrunde, außerdem ist sie auch nicht unbedingt kostenlos.

Zugleich ist sie aber abzugrenzen von proprietärer Software, deren Hersteller es in aller Regel weder gestatten, den Quellcode einzusehen, noch ihn zu reproduzieren oder zu verändern. Denn bei Open-Source-Software ist die Nutzung und Wiederverwendung des Quellcodes ebenso gestattet wie seine Modifikation etwa zur Verbreitung in Form von Code für andere Programme und Anwendungen. Doch ganz ähnlich wie bei proprietärer Software gelten hierfür verschiedene Bedingungen und Vorgaben, die abhängig vom jeweils zugrunde liegenden Modell der Software-Lizenzierung variieren. Um hier Fallstricke vermeiden und Compliance in punkto Open-Source-Lizenzen gewährleisten zu können, sollten sie diese freilich kennen. Ebenso wie auch die weiteren Risiken im Zusammenhang mit Open-Source-Software.

Letztlich dienen die verschiedenen Lizenzierungsmodelle aber allem voran dazu, die missbräuchliche oder unbefugte Nutzung von Open-Source-Code zu unterbinden und so adäquaten Schutz für seine Urheber und Nutzer zu gewährleisten. Wie sich diese Mechanismen im Einzelnen darstellen, das beleuchten wir im Folgenden.

Was ist eine Open-Source-Lizenz?

Urheber von Open-Source-Software legen über eine Lizenz den Rahmen für die Nutzung, Veränderung und Weitergabe des ihr zugrunde liegenden Programmcodes durch Dritte fest. Gemäß diesem wird ihnen das Recht eingeräumt, den Code in die Umsetzung neuer Anwendungen oder Projekte entweder unverändert oder in abgewandelter Form einfließen zu lassen.

Einer der Kernvorteile in diesem Kontext ist die uneingeschränkte Einsehbarkeit des entsprechenden Codes. Denn dadurch wird nicht nur die Problemidentifikation und -behebung erleichtert, sondern lässt sich auch die Funktionsweise nachvollziehen – selbst wenn diese nur unzureichend oder überhaupt nicht dokumentiert ist.

Weiter besteht ggf. auch die Berechtigung, den Quellcode entsprechend eigener Anforderungen anzupassen oder potenziell vorhandene Fehler zu korrigieren. Ob und zu welchen Bedingungen dies gestattet ist, hängt vom jeweiligen Lizenzmodell ab. Eine Auflage in diesem Kontext kann etwa sein, dass alle entsprechenden Anpassungen veröffentlicht werden müssen.

Zwischen welchen Lizenzmodellen wird bei Open-Source-Software unterschieden?

Insgesamt gibt es zwar rund 80 Varianten, nach denen Open-Source-Software lizenziert wird. Konzeptionell unterliegen diese jedoch im Allgemeinen entweder dem sogenannten Copyleft-Prinzip, oder sie sind der Kategorie der freizügigen bzw. „permissive“ Lizenzen zuzuordnen.

Copyleft\: Lizenzen dieser Kategorie liegt die Kernprämisse zugrunde, dass Derivate des Open-Source-Codes ebenfalls nach diesem Modell lizenziert werden müssen.

Permissive\: Eine solche Vorgabe besteht hier nicht. Es existieren also deutlich mehr Freiheiten im Hinblick auf die Code-Nutzung, -Veränderung und -Weitergabe.

Bedingungen und Vorgaben der gängigsten Copyleft- und Permissive-Lizenzen im Vergleich

Copyleft-Lizenzen

Im Folgenden ein Blick auf die gängigsten Vertreter des Copyleft-Prinzips (in absteigendem Restriktionsgrad):

• GNU General Public License (GPL)\: Bei dieser Variante sind Lizenzhinweise und urheberrechtliche Bestimmungen im aus dem Code entstehenden Produkt beizubehalten, unabhängig davon, ob es für eine kommerzielle, patentgeschützte oder private Nutzung vorgesehen ist. Die Nutzung von gemäß GPL lizenziertem Code in einer Software hat zur Folge, dass ihr gesamter Quellcode unter derselben Lizenz weitergegeben werden muss. Beinhaltet Ihre Anwendung also entsprechend lizenzierten Code (z. B. über eine Bibliothek), müssen Sie ihren gesamten Quellcode unter der GPL-Lizenz verfügbar machen, wenn Sie sie weitergeben bzw. vertreiben möchten. Aufgrund dieser Auflage sind GPL-Lizenzen eher dem restriktiven Pol des Copyleft-Kontinuums zuzuordnen.

• Affero GPL (AGPL)\: Diese unterscheidet sich von der Vorgenannten nur durch eine einzelne Klausel, die in bestimmten Fällen aber extrem wichtig ist. Denn die GPL-Lizenz greift nur, wenn die Software weitergegeben wird. Wird sie dagegen nur über ein Netzwerk verfügbar gemacht, gilt dies nicht im eigentlichen Sinne als „Weitergabe“. Dieses Schlupfloch schließt die AGPL-Lizenz mit einer Bestimmung zur Remote-Netzwerkinteraktion. Dieser gemäß gilt die GPL-Lizenz auch für Software, die über ein Netzwerk genutzt wird.

• Lesser General Public License (LGPL)\: Im Hinblick auf die ihr zugrunde liegenden Bestimmungen und der Beibehaltung der Copyright- und Lizenzhinweise ist diese Lizenz mit der AGPL und GPL identisch. Freizügiger gestaltet sie sich jedoch im Hinblick auf die Weitergabebestimmungen: Bei kleineren Projekten und Objekten, bei denen der Zugriff über übergeordnete lizenzierte Open-Source-Elemente erfolgt, muss das breiter gefasste Projekt nicht weitergegeben werden. Dabei ist zudem auch keine Weitergabe des abgeänderten Quellcodes unter den ursprünglichen Lizenzbedingungen vorgesehen.

• Eclipse Public License (EPL)\: Anzutreffen ist die EPL in der Regel bei Business-Software. Bei dieser Lizenz darf unter ihr entwickelte Software mit unter anderen Varianten lizenzierter sowie auch proprietärer Software zusammengeführt und auch unter Sublizenzen vertrieben werden. Einzige Bedingung dafür ist, dass alle Elemente, die keiner EPL-Lizenz unterliegen, als eigenständige Module oder Objekte vorliegen müssen. Auch im Rahmen von EPL-Lizenzen sind Änderungen möglich. Diese unterliegen dann jedoch denselben Bedingungen.

• Mozilla Public License (MPL)\: Als die am wenigsten restriktive Software-Lizenz unter den Copyleft-Varianten ist die MPL offen dafür, Code in Closed-Source- bzw. proprietärer Software zu nutzen. Voraussetzung hierfür ist nur, dass er in separaten Dateien festgehalten und gemeinsam mit der Software weitergegeben wird. MPL-Lizenzen beinhalten außerdem die Gewährung von Patentrechten und sehen die Beibehaltung von Copyright-Hinweisen vor.

Permissive-Lizenzen

Zu den am weitesten verbreiteten Permissive-Lizenzen für Open-Source-Software gehören:

• Apache License\: Bei dieser Variante ist die Angabe von Lizenz- und Copyright-Hinweisen bei der Weitergabe des Codes und/oder innerhalb der Software vorgesehen. Derivate des Open-Source-Codes, unter seiner Nutzung entwickelte Projekte größeren Umfangs oder Modifikationen desselben dürfen jedoch durchaus unter abweichenden Bedingungen lizenziert werden. Auch muss der Quellcode des entsprechenden Produkts nicht zwingend öffentlich gemacht werden. Die Apache License beinhaltet zudem die Gewährung von Patentrechten.

• MIT License\: Diese Variante, benannt nach der renommierten US-Universität, an der sie entwickelt wurde, lässt sich ob ihrer enorm weiten Verbreitung wohl als Branchenprimus bezeichnen. Grund für ihre Popularität dürfte sein, dass sie besonders klar verständlich angelegt ist. In ihrem Rahmen darf der Originalcode beliebig weiterverwendet werden; einzig die Angabe der ursprünglichen Copyright- und Lizenzhinweise ist vorgeschrieben. Für Autoren ist ein Haftungsausschluss vorgesehen, eine Gewährung von Patentrechten ist nicht ausdrücklich festgehalten.

• Berkeley Source Distribution (BSD) License\: Auch bei dieser Variante der Permissive-Lizenzen ist die Angabe von Copyright- und Lizenzhinweisen vorgeschrieben, umfangreichere oder lizenzierte Projekte dürfen aber auch ohne Veröffentlichung des Quellcodes sowie zu abweichenden Lizenzbedingungen vertrieben werden. Unterschieden wird bei der BSD License zudem zwischen einer Variante mit zwei Klauseln, die weitgehend mit der MIT License vergleichbar ist, sowie einer mit drei bzw. vier Klauseln. Diese sehen eine Reihe weiterer Bestimmungen im Zusammenhang mit der Weiterverwendung und anderen Fragestellungen vor. 

• Unlicense: Wie der Name bereits nahelegt, ist diese Open-Source-Lizenz am freizügigsten angelegt. So nähert sie sich de facto bereits den Prinzipien von Public-Domain-Software an: Bedingungen legt sie keine zugrunde, ermöglicht somit also auch die Weitergabe ganz ohne Veröffentlichung des Quellcodes sowie zu von ihr abweichenden Lizenzbestimmungen.

Welche Open-Source-Lizenz ist am besten?

Diese Frage hängt vor allem davon ab, wie die auf Grundlage des jeweiligen Open-Source-Produkts entwickelte Software lizenziert bzw. genutzt werden soll. Berücksichtigen sollten Sie bei der Wahl der Lizenzvariante etwa folgende Punkte:

• Bei Copyleft-Lizenzen ist gewisse Vorsicht geboten. Denn ist die Lizenzierung des Open-Source-Codes eher freizügig angelegt, gilt dies in gleicher Weise für das unter seiner Nutzung entstehende Produkt. Und das ist nicht unbedingt im Interesse seines Entwicklers.

• Im Allgemeinen ist das Copyleft-Prinzip jedoch mit mehr Restriktionen und dementsprechend potenziell weniger Verpflichtungen verbunden als Permissive-Lizenzen.

• Wird eine unkomplizierte Nutzung und Weitergabe des Codes beabsichtigt, ist eine der Varianten aus dem Permissive-Lager womöglich die beste Wahl.

• Wer Software für den Einsatz im Netzwerk entwickelt, fährt tendenziell mit der AGPL-Lizenz am besten. Ein gängiger Use Case wären hier etwa Open-Source-Datenbanken. Denn sind diese nicht unter der AGPL lizenziert, steht es theoretisch jedem beliebigen Unternehmen (z. B. auch einem der großen Cloud-Provider) offen, das Produkt zu modifizieren und kommerziell zu vertreiben, ohne den Quellcode verfügbar machen zu müssen.

• Bei der GPL-Lizenz wird zwischen der GPLv2 und GPLv3 unterschieden. Diese weisen zahlreiche Unterschiede auf, wobei Version 3 der GPL umfangreicher ist und beispielsweise auch Patentfragen regelt. Die GPLv3 zeichnet sich zudem durch bessere Kompatibilität mit anderen Open-Source-Lizenzen aus, so etwa auch Apache v2. Zu beachten ist allerdings, dass die beiden GPL-Varianten untereinander nicht kompatibel sind.

• Für die MIT License spricht ihre besonders weite Verbreitung. Sie kann daher als allgemein anerkannt angesehen werden und wird weithin verstanden. Zudem ist die Nutzung von unter ihr lizenzierter Software mit keinerlei Restriktionen im Hinblick auf Weitergabe und Monetarisierung verbunden – ein äußerst attraktiver Vorteil für verschiedenste Use Cases. Hierbei kommt noch hinzu, dass sie mit einer Vielzahl anderer Open-Source-Lizenzen kompatibel ist. Dementsprechend kann Code, der einer MIT License unterliegt, auch in anderen Open-Source-Projekten verwendet werden, die unter anderen Varianten lizenziert sind.

Klarheit im Dickicht genutzter Open-Source-Lizenzen

Ob in der Software-Branche oder anderen Bereichen, die Auswahl an genutzten Lizenzvarianten nimmt häufig ganz ähnliche Ausmaße an wie die Bandbreite der Open-Source-Tools, auf die sich Entwickler bei der Umsetzung ihrer Anwendungen stützen. Entsprechend komplex gestaltet es sich, den Überblick über eine Reihe von für Entwicklung und Einkauf wie auch den Vertrieb von Software unabdingbare Faktoren zu behalten. Dazu gehören:

• Erfüllung von Copyright- und patentrechtlichen Bestimmungen

• Management von Derivaten der ursprünglichen Lizenzvarianten

• Klarheit über Gültigkeitsdaten und Verlängerungsfristen

All dies lässt sich mit Snyk kompakt in einer Lösung umsetzen. Mit unserem umfassenden Tooling gewährleisten Sie Compliance für sämtliche Open-Source-Lizenzen übergreifend für alle Ihre Projekte, ohne dabei die Feature-Entwicklung auszubremsen.

„Mit Snyk decken unsere Entwickler potenzielle Fallstricke rund um Open-Source-Lizenzen nicht nur punktgenau auf, sondern können diese Insights auch direkt in einem kompakten Report an unser Legal-Team übermitteln. Im Dev-Prozess sparen wir dabei leicht mehrere Tage an Arbeit ein.“

Scott Mitchell, Application Security Manager bei Blue Prism