Open Source-Lizenzen¶

Im der Entwicklung von Forschungssoftware gibt es keinen Weg an Open Source Lizenzen herum, sei es weil die Wissenschaftler:innen für Publikationen und den Austausch mit Kollegen bzw. Kolleginnen die Software im Sinne der open Science zugänglich halten wollen (siehe dazu die Relevanz von Softwarelizenzen), als auch weil sehr viele Softwarekomponenten die verwendet werden bereits Open Source lizensiert sind. Daher soll im folgenden genauer auf die Merkmale, Rechten und Pflichten der Open Source Lizenzen eingegangen werden.

Bei Open Source Lizenzen unterscheidet man zwischen drei Gruppen, welche sich in der Art unterscheiden, wie diese nach der Modifikation oder Kombination weiter lizensiert werden müssen:

Starke Copyleft-Lizenzen¶

Lizenzen mit Copyleft Effekt zielen darauf ab, dass bei einer Weitergabe des originalen oder auch des modifizierten Codes der Quellcode den entsprechenden Dritten gegenüber zugänglich gemacht und damit frei verfügbar wird (frei bezieht sich in diesem Kontext auf die Zugänglichkeit, nicht auf den Preis). Alle Nutzer sollen die Freiheit haben, Software weiterzuverbreiten und ändern zu können. Copyleft bedeutet somit, dass jeder Mensch der Software mit oder ohne Änderungen weiterverbreitet, diese zusammen mit der Freiheit weitere Kopien und Änderungen machen zu dürfen, übergeben muss¹.

Eine Veröffentlichung des Codes als Folge des Copyleft Effekts bedeutet in diesem Zusammenhang nur, dass der Code gegenüber einer dritten Person, an die dieser weitergegeben wird, offengelegt werden muss. Copyleft bedeutet nicht, dass eine Modifikation immer automatisch an “alle” veröffentlicht (z.B. durch eine Publikation im Internet) werden muss. So kann beispielsweise Fremdcode, welcher unter einer Copyleft Lizenz im Internet veröffentlicht wurde, im eigenen Haus genutzt und modifiziert werden, ohne dass diese Änderungen veröffentlicht werden müssen. Dies ist allerdings nur solange möglich, wie der Code nicht an Dritte weitergegeben wird. Bei der Weitergabe muss der Code samt Modifikationen unter der vorherigen Copyleft Lizenz, und damit für den Dritten, jedoch nicht automatisch für “alle”, einsehbar und mit den weiteren Rechten der Lizenz (z.B. erneute Modifikation, Weitergabe) verfügbar sein.

Starke Copyleft Lizenzen erlauben eine Modifizierung und Weitergabe eines ursprünglichen Codes nur unter der Bedingung, dass jegliche verbundene Programmteile ebenfalls unter dieser Lizenz zur Verfügung gestellt und damit veröffentlicht werden müssen. Dies gilt zum Beispiel auch bei der Einbindung eines einzelnen Pakets mit einer Copyleft Lizenz - in diesem Fall muss das komplette Programm, welches dieses eine Paket nutzt, ebenfalls unter der mit dem Paket mitgelieferten Copyleft Lizenz veröffentlicht werden.

Open-Source-Lizenzen mit starkem Copyleft-Effekt sind:¶

GPL v2
GPL v3
AGPL 3.0
EUPL 1.2

Lizenzempfehlung für den wissenschaftlichen Softwaretransfer: Für den wissenschaftlichen Softwaretransfer, bei dem eine starke Copyleft Lizenz zum Einsatz kommen soll, wird die Nutzung der EUPL v1.2 bzw. der GPL v3 empfohlen. Die EUPL v1.2 hat den Vorteil, dass sie explizit für europäisches Recht entwickelt wurde. Im Gegensatz zur GPL v3 erlaubt sie außerdem explizit eine Sublizenzierung des Codes und erfordert darüber hinaus die Offenlegung des Codes für SaaS Anwendungen (z.B. Bereitstellung von kostenpflichtigen Webservice Anwendungen). Bei der Wahl der Copyleft Lizenz muss, wie in den folgenden Punkten beispielhaft dargestellt, die anvisierte Nutzung des Codes betrachtet werden: 1. Wird eine eigene Sublizenzierung angestrebt, bzw. soll Dritten eine Sublizenzierung gestattet werden? Dann ist es empfehlenswert die EUPL v1.2 zu wählen. 2. Soll verhindert werden, dass Dritte den Code sublizenzieren können? Dann ist die GPL v3 zu wählen. 3. Für SaaS Nutzungen muss evaluiert werden, welches Ziel der Softwaretransfer verfolgt: Geheimhaltung des Webservice Codes (GPL v3) oder maximale Transparenz mit Schutz vor späterer Closed-Source Nutzung (EUPL v1.2).

Schwache Copyleft-Lizenzen¶

Im Unterschied zu Lizenzen mit starkem Copyleft Effekt ist bei Lizenzen mit schwachem Copyleft eine Veröffentlichung des restlichen Programms unter einer anderen Lizenz erlaubt, allerdings nur unter der Bedingung, dass die beiden Programmteile klar voneinander abgegrenzt sind. Modifikationen am Originalcode unterliegen somit nach wie vor der Veröffentlichungspflicht, aber nicht das restliche Programm. So ist es zum Beispiel, möglich ein Paket mit schwachem Copyleft in ein proprietäres Programm einzubinden, welches ansonsten nicht Open Source zur Verfügung gestellt werden soll. Copyleft Lizenzen sind somit besonders für Pakete und Module (ggf. sogar einzelne Dateien - siehe MPL 2.0) geeignet, die üblicherweise als Basis für größere Entwicklungen dienen und seltener nur eigenständig angewendet werden.

Open-Source-Lizenzen mit schwachem Copyleft-Effekt sind:¶

LGPL 2.1
LGPL 3.0
MPL 2.0

Bei der Integration von Code mit schwachem Copyleft machen die verschiedenen Lizenzen unterschiedliche Vorgaben, inwiefern Code nur dynamisch oder auch statisch eingebunden werden kann. Während MPL 2.0 auch eine statische Integration erlaubt, ist die LGPL strikter: hier wird eine dynamische Verlinkung bevorzugt, eine statische Einbindung ist nur mit zusätzlichen Auflagen erlaubt².

Statische Verknüpfung:
alle im Programm befindlichen Bibliotheksmodule werden im letzten Schritt der Kompilierung in die ausführbare Datei kopiert
bei Code in Source Form: der Inhalt eines Pakets wird komplett kopiert hinterlegt
statisch verknüpfte Dateien haben größere Dateigrößen und benötigen längere Ladezeiten

Dynamische Verknüpfung:
Verknüpfung erfolgt zu Laufzeit, wenn sowohl die ausführbaren Dateien als auch die Bibliotheken im Speicher abgelegt werden
bei Code in Source Form: das Paket wird über einen Import Befehl integriert und erst zur Laufzeit abgerufen
dynamisch verknüpfte Dateien haben kleinere Dateigrößen und benötigen kürzere Ladezeiten

Lizenzempfehlung für den wissenschaftlichen Softwaretransfer: Für den wissenschaftlichen Softwaretransfer, bei dem eine schwache Copyleft Lizenz zum Einsatz kommen soll, wird je nach Anwendungsfall die Nutzung der LGPL 3.0 (Sublizenzierung des Codes, bzw. von Derivaten verboten), oder die Nutzung der MPL 2.0 (Sublizenzierung des Codes, bzw. von Derivaten erlaubt) empfohlen.

Permissive Lizenzen¶

Permissive Lizenzen sind die freizügigsten Lizenzarten, die den Nutzer:innen einer Softwareentwicklung vielfältige Möglichkeiten zur Weiternutzung und Veränderungen erlauben, ohne daran weitere Bedingungen zu knüpfen. Gleichzeitig ermöglichen sie die Zurverfügungstellung der Software, ohne dass darauf Garantie und/oder Gewährleistungsansprüche erhoben werden können. Sie schützen damit vor allem die ursprünglichen Entwickler:in.

Code (Fremdcode, Eigenentwicklung) unter einer permissiven Lizenz kann somit eine gute Basis für Neu-/Weiterentwicklungen sein, die leicht in kommerzielle/proprietäre Produkte integriert werden sollen, ohne dass deren Quellcode zu einem späteren Zeitpunkt offengelegt werden muss.

Verbreitete permissive Lizenzen sind:¶

MIT
BSD-3
Apache 2.0

Lizenzempfehlung für den wissenschaftlichen Softwaretransfer: Soll eine permissive Lizenz zum Einsatz kommen, wird die Nutzung der Apache 2.0 empfohlen. Im Gegensatz zu MIT und 3-clause BSD Lizenz (BSD-3) beinhaltet sie klare Regelungen zur Nennung von Namen und Trademarks, sowie Patentrechten. Sollte eine Kompatibilität zu GPL v2 notwendig sein (nicht erlaubt mit Apache 2.0), sollte auf die 3-clause BSD Lizenz zurückgegriffen werden.

Rechte der Open-Source-Lizenzen¶

In der Regel erlauben alle Open-Source-Lizenzen die Nutzung der Software. Dies schließt in der Regel auch die integrierte Nutzung ein, was bedeutet, dass die Software in andere Anwendungen oder Systeme integriert werden darf. Darüber hinaus gewähren alle Open-Source-Lizenzen die Rechte an den zustimmungsbedürftigen Handlungen: Vervielfältigung, Bearbeitung und Verbreitung. Die Vervielfältigung gibt den Nutzern das Recht, Kopien der Software anzufertigen, die Modifikation erlaubt die Anpassung des Quellcodes an individuelle Bedürfnisse und die Verbreitung erlaubt die Weitergabe modifizierter oder unveränderter Versionen der Software.

Ein Sonderfall stellen die Patentrechte da. Ein Patent gewährt der Inhaber:in das Recht andere von der Herstellung, der Nutzung und des Verkaufs der beanspruchten Erfindung auszuschließen. Im Gegensatz dazu erlauben Open Source Lizenzen weitreichende Rechte zur Modifikation, Kompilierung, Verbreitung und Nutzung von Software. Damit besteht scheinbar eine Diskrepanz zwischen dem patentbezogenen Ausschlussrecht und dem Open-Source gewährten Nutzungsrecht.

Um in diesem Konflikt Klarheit zu schaffen, beinhalten viele der Open Source Lizenzen explizite Klauseln zur Regelung von Patentrechten. Die ausdrückliche Gewährung von Patentrechten bedeutet hierbei, dass die Enwickler:innen, die den Code erstellt oder dazu beigetragen haben, auf ihre Patentrechte im Hinblick auf jede spätere Wiederverwendung der Software verzichten. Zu den Lizenzen, welche diese Rechte gewähren gehören Apache 2.0, MPL 2.0, LGPL 2.1, LGPL 3.0, GPL 3.0, AGPL 3.0 und die EUPL 1.2. Eine Explizite Ausnahme davon macht die BSD3 Lizenz!

Allerdings bedeutet eine Abwesenheit der Patentregelung in einem Lizenztext nicht, dass automatisch keine Patentrechte gewährt werden. Nach Auffassung der Open Source Initiative beinhalten beispielsweise alle Open Source Lizenzen eine Patenterteilung³. Darüber hinaus muss beachtet werden, dass der Umfang von Patenterteilungen in verschiedenen Lizenzen nicht klar definiert sind, bzw. gibt es unterschiedliche Regelungen hinsichtlich der Patenterschöpfung.

Pflichten der Open-Source-Lizenzen¶

Diese rechte sind so essentiell für den Open Source Gedanken, dass in den entsprechenden Communites generell erwartet wird, dass es auch technisch möglich sein muss, diese Handlungen auch durchzuführen, weshalb es üblich ist, sofern nicht eh von den Lizenzen vorgeschrieben, dass alles was zur Installation Für die Nutzung einer Software benötigt man generell die Erlaubnis des Urhebers bzw. des Rechteinhabers, welches besonders für die zustimmungsbedürftigen Nutzungshandlungen gilt. Diese Erlaubnis wird in der Regeln durch eine Lizenz ermöglicht, weswegen es wichtig ost, dass zu jeder Software oder Code eine Lizenz vorhanden ist, da sonst die Nutzung nicht erlaubt ist. Im folgenden werden die Zustimmungsbedürftigen Handlungen aufgeführt, die durch eigentlich alle Open Source Lizenzen gewährt werden:


Kurzübersicht wichtiger Lizenzpflichten gängiger Open Source Lizenzen. Die genauen Bedingungen wie diese Pflichten erfüllt werden können sollten in den Liznztexten nachgelesen werden.

Insbesondere die Pflichten haben starke auswirkung darauf, welche Open Source Lizenzen miteinander kombiniert werden können, weswegen sich schon früh Gedanken über die Kompatibilität gemacht werden sollte.

Creative Common Lizenzen für Software¶

Creative-Commons-Lizenzen (CC) sind rechtliche Instrumente, die es Urhebern ermöglichen, ihre Werke flexibel zu lizenzieren und anderen Nutzern bestimmte Rechte einzuräumen. Die wichtigsten CC-Lizenzen erlauben eine breite Palette von Nutzungen, von der einfachen Weiterverbreitung über die Bearbeitung bis hin zur kommerziellen Nutzung, je nach den vom Urheber festgelegten Bedingungen. Diese Lizenzen sind in erster Linie für kreative Werke wie Texte, Bilder, Musik und Videos gedacht, nicht aber für Software.

Beide Lizenztypen zielen darauf ab, die Freiheit und die Zusammenarbeit zwischen verschiedenen Werken zu fördern, indem sie die Regeln dafür festlegen. Der Hauptunterschied zwischen Creative Commons und Open Source liegt jedoch in den Zielen und der Art der kreativen Werke, für die sie gedacht sind. Software erfordert spezifischere Bedingungen, wie die Offenlegung des Quellcodes und klare Anweisungen für Modifikationen, um die Integrität und Funktionalität des Codes zu gewährleisten. Creative Commons fehlen die rechtlichen Instrumente, um den besonderen Anforderungen der Softwareentwicklung gerecht zu werden.

Open-Source-Lizenzen hingegen sind speziell auf Software zugeschnitten. Diese Lizenzen erlauben nicht nur die Freigabe und Weiterverbreitung des Quellcodes, sondern gewähren auch das Recht zur Veränderung, Weiterentwicklung und freien Verwendung in anderen Projekten.

Daher sind Creative-Commons-Lizenzen für Software nicht geeignet, da sie nicht die genauen Bedingungen und Garantien bieten, die für eine erfolgreiche und kollaborative Entwicklung von Softwareprojekten erforderlich sind.