Open Source – unterstützend, unvermeidlich, unübersichtlich Sind Open-Source-Lizenzen wirklich kompliziert?

Anbieter zum Thema

msg systems ag

Windhoff Group

Open Source regiert die digitalisierte Welt. Wie jede Regierung legt auch Open Source dabei bestimmte Rechte und Pflichten fest. Welche das sind, welche Auswirkungen diese haben und wie mit ihnen umzugehen ist, erläutert dieser Artikel.

Mindset von Open Source

Open Source ist mehr als nur eine Art und Weise, Quelltext bereitzustellen. Es ist einerseits eine Form zur Regulierung, andererseits eine Form der Gemeinschaft. Allem voran ist es aber eine Grundeinstellung. Zusammenarbeit, Geben und Nehmen sowie Transparenz sind die Werte dieser Grundeinstellung.

Zu dieser Open-Source-Gemeinschaft dürfen sich alle zählen, die jemals in irgendeiner Form an einem quelloffenen Projekt mitgewirkt haben. Die Höhe des Beitrags ist dabei irrelevant. Es können eine einfache Problemmeldung sein, ein Beitrag in Form von einem Code-Fragment oder mehrere selbst initiierte Projekte. Die so geleisteten Beiträge stehen allen zur Verfügung.

Die „Open Source Initiative“ definiert für quelloffene Software wiederum bestimmte Prinzipien, etwa den Quellcode offen zu legen oder Veränderungen, Modifikationen, Ableitungen und Kopien zu erlauben. Dabei darf weder eine Nutzungsbeschränkung noch eine Zahlungsverpflichtung entstehen.

Ein sich aus diesen Prinzipien für Open-Source-Software ergebender Vorteil ist, dass Open Source grundsätzlich die Diskriminierung von Personen, Gruppen oder Einsatzzwecken verhindert. Alle dürfen Open-Source-Software für jeden erdenklichen Zweck einsetzen. Letzteres lässt sich allerdings auch als Nachteil verstehen. Denn selbst für an sich diskriminierende oder schädigende, kommerzielle oder militärische Zwecke gilt per se kein Einsatzverbot.

Lizenzen setzen die Prinzipien durch

Lizenzen sollen die Prinzipien von Open Source rechtlich durchsetzen. Wie vieles andere auch unterliegen diese Prinzipien einer Interpretation und je nach Betrachter einer unterschiedlichen Gewichtung. Das ist auch der Grund, warum sich im Laufe der Jahrzehnte viele verschiedene Lizenzen ergeben und entwickelt haben. Sie alle bilden das Grundgerüst und Vertragswerk zur Veröffentlichung von Open Source.

Notwendig sind die Lizenzen für beide Seiten– sowohl für die Open-Source-Beitragenden (Contributors) als auch die Open-Source-Nutzenden. Ohne eine Open-Source-Lizenz gilt nämlich andernfalls der Urheberschutz. Das wäre mitunter nicht nur kompliziert, das könnte sogar fatal enden. Denn jedes Land der Welt regelt den Urheberschutz individuell und unterschiedlich. Der veröffentlichte, fremde Code lässt sich dann nicht mehr beliebig verwenden, ähnlich wie bei einem Kunstwerk oder Schriftstück.

Gleiche und unterschiedliche Verpflichtungen

Drei Lizenzen kommen besonders häufig zum Einsatz: die Apache-Lizenz, die GPL sowie die MIT-Lizenz. Auch wenn Apache-Lizenz, GPL und MIT-Lizenz sehr ähnlich sind und die gleichen Verpflichtungen vorsehen, unterscheiden sie sich doch in einigen der spezifischen, entstehenden Verpflichtungen. Folgende Gemeinsamkeiten bestehen und bilden damit die Grundlinie.

Copyright Notice und Licence Text: Alle drei Lizenzen verpflichten dazu, den vollständigen Lizenztext und den originalen Urheberrechtshinweis bereitzustellen.

Lizenzgebühren: Für die Verschaffung von Nutzungsrechten an der Open-Source-Software dürfen keine Lizenzgebühren erhoben werden.

Disclaimer: Die Autoren des Codes respektive Urheber der Open-Source-Software dürfen nicht für resultierende Schäden verantwortlich oder haftbar gemacht werden. Hier wird es jedoch schon schwierig. Der Haftungsausschluss ist mit dem deutschen Recht nicht vereinbar, weil die dauerhafte Überlassung von Open-Source-Code zwar üblicherweise als Schenkung ausgelegt wird, sich nach deutschem Recht aber dennoch eine Haftung im Falle von Vorsatz oder grober Fahrlässigkeit nach §521 BGB nicht ausschließen lässt.

Use, modify and redistribute: Der Open-Source-Code darf der Apache-Lizenz, GPL und MIT-Lizenz nach beliebig verwendet, verändert oder verteilt werden.

Auf Basis der Gemeinsamkeiten lassen sich die im Folgenden beschriebenen Unterschiede besser nachvollziehen.

MIT-Lizenz

Es hat einen Grund, warum die MIT-Lizenz bei so vielen Open-Source-Komponenten zum Einsatz kommt. Sie ist unter den drei Verbreitetsten schlicht die Genügsamste. Daher eignet sie sich grundsätzlich für alle Open-Source-Komponenten, insbesondere aber für solche mit geringer Schöpfungshöhe. Mit geringer Schöpfungshöhe ist gemeint, dass die Neuentwicklung der Open-Source-Komponente kaum bis geringen Aufwand – sowohl fachlicher als auch technischer Natur – bedeuten würde.

Apache 2.0

Die Apache-Lizenz enthält Vorgaben zur Benennung, die es bei Modifizierung oder Redistribution der Komponente einzuhalten gilt. So darf die sich ergebende Komponente namentlich nicht darauf hindeuten oder suggerieren, dass die Lizenzgebenden University of California oder Apache Software Foundation direkt beteiligt oder anderweitig involviert wären. Ein Präfix wie „Apache“ ist also ausgeschlossen, ein Suffix in Form von „basierend auf Apache Hadoop“ hingegen erlaubt.

Eine weitere Besonderheit der Apache-Lizenz 2.0 ist die Dokumentationspflicht in Form der NOTICE-Datei. Alle Änderungen des Quellcodes müssen notiert und dann in der NOTICE-Datei dokumentiert werden. Die NOTICE-Datei muss der abgeleiteten Komponente beigelegt und mit ausgeliefert werden. Existiert bereits eine solche NOTICE-Datei aus vorherigen Ableitungen, muss sie ergänzt und ausgeliefert werden, falls sich die Inhalte des Dokuments auch auf verwendete Bestandteile des genutzten Codes beziehen.

GPL v3

Die aktuelle GPL v3 zeichnet sich durch ihren starken Copyleft-Effekt aus. Copyleft bedeutet, dass wiederverteilte oder modifizierte Open-Source-Komponenten unter derselben Lizenz stehen müssen, unter der sie auch empfangen wurden, also der GPL v2 oder GPL v3. Stark ist der Copyleft-Effekt in diesem Fall, weil er sich auf das gesamte abgeleitete Werk auswirkt. Dieses muss also unter derselben Copyleft-Lizenz stehen, darauf aufbauender und entstehender proprietärer Source Code offengelegt werden. Es spielt keine Rolle, ob die Open-Source-Komponente dynamisch oder statisch gelinkt wurde.

Eine Ausnahme bilden aggregierte Werke, bei denen unterschiedliche Komponenten als eigenständig und lediglich miteinander kommunizierend betrachtet werden, etwa durch den Einsatz von Pipes, Sockets oder Kommandozeilenaufrufe. Das wäre eine reine interne Distribution oder das reine Ausführen des Codes und führt zum Entfall jeglicher Lizenzverpflichtungen.

Die GPL ist insbesondere für Werke mit wesentlicher Schöpfungshöhe geeignet, also bei Werken, deren Neuentwicklung sowohl fachlicher technischer aufwändig ist.

Weniger kompliziert als gedacht

Trotz der Vielfalt der Lizenzen haben alle dasselbe Ziel: ein rechtliches Gerüst für die Open-Source-Prinzipien schaffen. Die Lizenzen wollen also positiv wirken. Größtenteils kommen die Apache-Lizenz 2.0, die MIT-Lizenz und die GPL v3 zum Einsatz, die viele Gemeinsamkeiten und nur wenig Unterschiede teilen.

Für eigene Open-Source-Projekte bieten sich alle drei Lizenzen an, im Zweifelsfall ist die MIT-Lizenz immer eine gute Wahl. Wer auf die Apache-Lizenz stößt, sollte dringendst an die Dokumentationspflicht denken. Und geht es um die GPL v2, GPL v3 oder gar die LGPL, dann gilt es, die Architektur und die Komposition der Komponenten des abgeleiteten Werks auf die Wirkweise des Copyleft-Effekts genau zu prüfen. Schon ein kleiner Umbau kann die Verpflichtungen aus der GPL aufheben.

* Mark Lubkowitz ist Lead IT Consultant bei msg. Er ist Software-Entwickler sowie Journalist und ausgewiesener Experte für die Themen Digitale Souveränität, Open Source, Webtechnologien und Digitale Transformation.

(ID:48263457)