Lesezeit ca. 12 Min.

Freie Software heißt nicht frei von Problemen


Logo von Computerwoche
Computerwoche - epaper ⋅ Ausgabe 16/2022 vom 22.04.2022
Artikelbild für den Artikel "Freie Software heißt nicht frei von Problemen" aus der Ausgabe 16/2022 von Computerwoche. Dieses epaper sofort kaufen oder online lesen mit der Zeitschriften-Flatrate United Kiosk NEWS.

Linux, Git, MySQL, Node.js, Docker Hadoop – die Verwendung von freier Software in Form unzähliger Libraries, Frameworks und Tools ist selbstverständlich geworden. Open Source Software (OSS) – also in sich geschlossene Code-Einheiten, deren Quelltext frei einsehbar ist – sind aus keinem Projekt mehr wegzudenken.

Der Austausch und die gemeinsame Kreativität sind längst nicht mehr die einzigen Beweggründe, sich der Open Source Community anzuschließen. Kaum ein kommerzielles Produkt der digitalen Sphäre baut nicht auf frei verfügbaren Code, da Code-Qualität, Innovationsorientierung und Sicherheit der kollaborativ entwickelten Software überzeugen. Der Markt bewertet diese Software entsprechend hoch, weshalb auch Unternehmen selbst Projekte samt Quellcode frei zugänglich bereitstellen, um ihre Reputation zu steigern und neue Geschäftsmodelle zu erschließen.

Open Source heißt nicht bedingungslos Dass freie ...

Weiterlesen
epaper-Einzelheft 10,99€
NEWS Jetzt gratis testen
Bereits gekauft?Anmelden & Lesen
Leseprobe: Abdruck mit freundlicher Genehmigung von Computerwoche. Alle Rechte vorbehalten.
Lesen Sie jetzt diesen Artikel und viele weitere spannende Reportagen, Interviews, Hintergrundberichte, Kommentare und mehr aus über 1000 Magazinen und Zeitungen. Mit der Zeitschriften-Flatrate NEWS von United Kiosk können Sie nicht nur in den aktuellen Ausgaben, sondern auch in Sonderheften und im umfassenden Archiv der Titel stöbern und nach Ihren Themen und Interessensgebieten suchen. Neben der großen Auswahl und dem einfachen Zugriff auf das aktuelle Wissen der Welt profitieren Sie unter anderem von diesen fünf Vorteilen:

  • Schwerpunkt auf deutschsprachige Magazine
  • Papier sparen & Umwelt schonen
  • Nur bei uns: Leselisten (wie Playlists)
  • Zertifizierte Sicherheit
  • Freundlicher Service
Erfahren Sie hier mehr über United Kiosk NEWS.

Mehr aus dieser Ausgabe

Titelbild der Ausgabe 16/2022 von Mehr Transparenz für mehr Sicherheit. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Mehr Transparenz für mehr Sicherheit
Titelbild der Ausgabe 16/2022 von IBM soll Cloud-Erlöse künstlich aufgepumpt haben. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
IBM soll Cloud-Erlöse künstlich aufgepumpt haben
Titelbild der Ausgabe 16/2022 von Verdi fordert Aufklärung: Hat SAP seine Mitarbeiter ausspioniert?. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Verdi fordert Aufklärung: Hat SAP seine Mitarbeiter ausspioniert?
Titelbild der Ausgabe 16/2022 von Der Finanzsektor überschätzt seine IT-Sicherheit. Zeitschriften als Abo oder epaper bei United Kiosk online kaufen.
Der Finanzsektor überschätzt seine IT-Sicherheit
Mehr Lesetipps
Blättern im Magazin
Generation z16: Mit KI-Funktionen führt IBM Mainframes in die Zukunft
Vorheriger Artikel
Generation z16: Mit KI-Funktionen führt IBM Mainframes in die Zukunft
Open Source Software – wie stabil bleibt die Software Supply Chain?
Nächster Artikel
Open Source Software – wie stabil bleibt die Software Supply Chain?
Mehr Lesetipps

... und quelloffene Software keine freie, bedingungslose Nutzung bedeutet, muss im kommerziellen Umfeld klar sein. Im kleinen Rahmen, für den Einzelgebrauch eines individuellen Entwicklers, kommen die Rechte der Code-Autoren vielleicht nicht so offensichtlich zum Tragen. Aber sobald ein Geschäftsmodell von Open Source abhängt und ein Wert daraus geschöpft werden soll, müssen die rechtlichen Konsequenzen eindeutig verstanden sein.

Denn die Open-Source-Lizenzen sollen den Gedanken der freien, quelloffenen Software sowie deren Community schützen und die Ausbeutung kostenloser Ressourcen zu kommerziellen Zwecken verhindern.

Der Grundgedanke von Open Source Die Open Source Community, deren Zusammenarbeit vor allem auf Plattformen wie Github stattfindet, schließt dabei jeden Entwickler ein, der selbst schon einmal Fragmente seines Codes – seien es nur kleine Schnipsel, Bugfixes oder auch vollständige Projekte – veröffentlicht hat.

Grundsätzlich erfordert die Definition freier Software gemäß der Open-Source-Initiative (OSI), den Quellcode offenzulegen, Kopien zu erlauben, aber auch den Einsatz sowie Modifikationen oder Erweiterungen ohne Nutzungs- beschränkung und Zahlungsverpflichtung zuzulassen. Das ermöglicht nicht nur freie Distribution und Modifizierung, es verhindert auch die Diskriminierung von Personen, Gruppen oder Verwendungszwecken.

Aufgrund des Diskriminierungsverbots werden folglich weder Nutzergruppen noch Einsatzbereiche eingeschränkt. Ein Ausschluss von kommerzieller, militärischer oder für beispielsweise Firmenangehörige gesonderter Nutzung ist somit nicht mit den Leitlinien der Open-Source-Definition vereinbar. Lizenzen, die eben diese Prinzipien durchsetzen, bieten den rechtlichen Rahmen, Code überhaupt erst als Open Source zu veröffentlichen.

Ohne entsprechende Lizenzierung gilt für den Code andernfalls der Urheberschutz. Denn der Einsatz fremden Codes, ähnlich wie der eines Kunstwerkes, erfolgt auf Basis geltenden Rechts.

Wem gehört der Code?

Im anglo-amerikanischen Rechtsraum, aus dem jede der hier betrachteten Lizenzen stammt, ist eine vollständige Übertragung des Copyrights auf eine andere juristische Person durchaus denkbar. In Deutschland lässt sich das Urheberrecht laut §29 Abs. 1 UrhG hingegen nicht abtreten, sondern lediglich der Anspruch auf einfache oder ausschließliche Nutzungsrechte übergeben.

Demnach kann ein amerikanischer Arbeitgeber das Copyright an einem Open Source Code gemäß der Work-made-for-Hire-Doktrin besitzen, während in Deutschland dem Arbeitgeber nach §69b Abs. 1 UrhG nur die ausschließlichen Nutzungsrechte der Software zustehen. Der Arbeitnehmer bleibt jedoch immer noch der Autor des Codes und besitzt damit ein ideelles Urheberrecht.

In Folge einer Lizenzierung von Softwarecode mit einer Open-Source-konformen Lizenz werden nicht-ausschließliche Nutzungs-und Verwertungsrechte ebenfalls an den jeweiligen Empfänger übertragen. Es muss jedoch sichergestellt sein, dass die Copyright-Informationen über den ursprünglichen Autor bei der Distribution oder Modifizierung übernommen werden und dass der Autor nicht für eventuell entstehende Schäden verantwortlich gemacht werden kann. Dies fällt unter das Schlagwort „no-liability“. Oft wird auch eine „Advertising Clause“ festgelegt, wonach bei der Bewerbung eines Produktes, welches die Open-Source-

Komponente enthält, auf den Inhaber des Copyrights hingewiesen werden muss.

Bei Open-Source-Projekten ist für die Urheberschaft sowohl ein einzelner Urheber als auch die Zusammenarbeit mit Miturhebern oder einzelne Urheber pro geschaffene Sektion des „verbundenen Werks“ im Sinne des §9 UrhG denkbar. Mithilfe eines Contributor License Agreements (kurz CLA) lässt sich sicherstellen, dass der Projektinhaber eines Open-Source- Projekts die Urheberrechte zu beispielsweise einer möglichen Relizenzierung oder der Verfolgung von Urheberrechtsverletzungen vor Gericht erhält und ein „Transfer of Ownership“ vom Urheber des Codes auf den Inhaber des gesamten Projekts erfolgt.

Wenn der Arbeitgeber nach deutschem Arbeitsvertrag die Nutzungs-und Verwertungsrechte von Software innehält, steht es als Folge von § 69b Abs. 1 UrhG auch nur ihm zu, ein CLA zu unterzeichnen und diese Rechte abzutreten. Dies bedeutet insbesondere, dass ein Arbeitnehmer selbst keine solche CLA unterzeichnen darf, wenn er keine Prokura seines Arbeitgebers besitzt.

Beschäftigt man sich mit dem Copyright, darf hierbei die Definition von Copyleft nicht fehlen: Ein Copyleft-Effekt stellt sicher, dass Redistributionen und Modifizierungen eines Programms ebenfalls frei bleiben, indem sie unter derselben Lizenz weiter lizenziert werden müssen, unter der sie auch empfangen wurden. Ein starker Effekt schließt dabei im Gegensatz zu einem schwachen Copyleft-Effekt auch zusätzliche weitere Teile eines Projektes ein und greift somit auf den gesamten Quellcode desselben über. Die Konsequenz: Das gesamte Projekt muss unter dieselbe Copyleft- Lizenz gesetzt werden. Ausnahmen sind aggregierte Werke, da diese aus separaten Programmen bestehen, die lediglich miteinander kommunizieren.

MIT, BSD3, Apache 2.0, LGPL 2.1, GPL v2 und GPL v3 – was hinter den Lizenzen steckt Generell spricht die Balance zwischen dem Beitragen zur Open Source Community und gleichzeitig der Möglichkeit, dass der Code in proprietäre Software eingebunden wird, für die Nutzung einer schwachen Copyleft-Lizenz, wie sie auch die Mozilla Public License und die Eclipse Public License darstellen. So verzichten MIT, BSD3 und Apache 2.0 auf den Copyleft-Effekt, legen dem Nutzer also kaum Verpflichtungen auf. LGPL 2.1, GPL v2 und GPL v3 üben hingegen einen Copyleft-Effekt aus.

► BSD3 und MIT – genauer gesagt, die X11- Lizenz – sind beinahe identisch. Sie unterscheiden sich nur in der „non-endorsement clause“ der BSD3. Sie verbietet die Nutzung des Namens des Lizenzgebers bei der Vermarktung abgeleiteter Produkte; außer er hat ausdrücklich zugestimmt.

► Zu Apache 2.0 existieren derweil mehrere Unterschiede. Dazu zählen die explizite Übertragung von Patentrechten und das Auflisten aller signifikanten Modifizierungen am Code.

► Die GPL v3 stellt die aktuelle Version der GPL-Lizenzen dar. Auch bei der Vorgängerversion GPL v2 muss bei der Redistribution eines Programms mit Code, welcher unter GPL lizenziert ist, das gesamte Programm ebenfalls unter die GPL gestellt werden – dazu zählen auch verlinkte Bibliotheken und hinzugefügte Komponenten des Programms.

► Bei der GNU Lesser General Public License 2.1, kurz LGPL, die vor allem auf Bibliotheken angewandt wird, kommt jedoch nur ein schwacher Copyleft-Effekt zum Tragen: Falls die Bibliothek verändert wird, müssen die Veränderungen ebenfalls unter LGPL 2.1 gestellt werden – bei der reinen Nutzung ohne Modifikation der Bibliothek ergeben sich jedoch keinerlei weitere Auswirkungen und das gesamte restliche Programm, welches die Bibliothek benutzt beziehungsweise dynamisch einbindet, darf anderweitig lizensiert werden.

Freizügige Lizenzierungsmodelle

Anhand der beiden Paradebeispiele für Lizenzen, also Apache und MIT, lässt sich leicht die Grundintention hinter den permissiven Lizenzen aufzeigen: Freie Software bereitstellen, wobei eigene Modifizierungen der Nutzer nicht an den Softwaregeber zurückgeschickt werden müssen. Der Lizenztext der Apache 2.0 ist zwar um einiges länger und ausführlicher geschrieben als jener der MIT-Lizenz, beinhaltet aber zusätzlich nur die Bedingung, dass Buch über die vollzogenen Modifikationen geführt werden muss und der eigene Produktname eines Nutzers nicht auf den Namen Apache hinweisen darf.

Grundsätzlich eignen sich derart freizügige Lizenzierungsmodelle wie MIT, BSD3 und Apache 2.0 für Projekte von eher geringer Schöpfungshöhe. Also Projekte, für die theoretisch geringere Fähigkeiten und wenig Aufwand notwendig sind, um das Programm von Grund auf selbst neu zu schreiben. Denn dann ist das Interesse der Entwickler, ihren Code explizit zu schützen, meist begrenzt.

Zwischen Kreation und Funktion

Während die kreativen Aspekte von Software diese zu einem Subjekt des Urheberrechts machen, werden die funktionalen Aspekte durch das Patentrecht geschützt. Der Inhaber eines Patents ist befähigt, andere von der Nutzung der Software auszuschließen.

Patentrechtlich relevant wird Software als solche nur, wenn sie „ein Verfahren implementiert, das technischer Natur ist“ beziehungsweise ein „technisches Mittel zur Lösung eines konkreten technischen Problems“ darstellt.

Es muss jedoch im Einzelfall entschieden werden, ob der Open Source Code respektive eine „computerimplementierte Erfindung“ im Fall eines Rechtsstreits als Subjekt des Patentrechts angesehen werden kann oder nicht. Implizit enthalten die von der Open-Source-Initiative gekennzeichneten Lizenzen bereits ein „patent grant“. Jedoch steht bei fehlender expliziter Regelung der Umfang der übertragenen Patentrechte nicht fest, weshalb einige Lizenzen auch explizit den Patentanspruch regeln.

In den Lizenztexten von Apache 2.0 oder auch GPL werden jegliche Patentrechte übertragen, wohingegen sie bei MIT und der BSD3 nicht explizit genannt werden, jedoch sinnhaft durch andere Rechtszugeständnisse ersetzt werden.

Gerade bei umfangreicheren Programmen führt diese Patentbeendigungsklausel der Apache 2.0 daher zu einem Vorteil gegenüber anderen freizügigeren Lizenzen ohne Copyleft-Effekt.

Nutzer und Entwickler müssen keine Klage aufgrund von Patentrechtsverletzungen eines Urhebers befürchten. Entscheidend bei der Lizenzierung von Programmen ist außerdem die Kompatibilität der Non-Copyleft-Lizenzen mit den Copyleft-Lizenzen der GPL-Reihe. Während BSD3 und MIT grundsätzlich mit jeglichen GPL-Varianten vereinbar sind, lässt sich ein Produkt unter Apache 2.0 aufgrund ihrer Patentbeendigungsund Schadensersatzklauseln nicht mit Komponenten unter GPL v2 kombinieren.

Die Unterschiede zwischen den Lizenztexten lassen sich vor allem anhand des Umgangs mit den verschiedenen Nutzungskontexten feststellen (siehe Kasten rechts). Anhand der Einordnung der Nutzung einer Open-Source-Komponente kann man zutreffende Passagen aus dem Lizenztext leichter finden und bestimmte Verpflichtungen ausschließen oder bestätigen.

Da die exakte Wortwahl der englischsprachigen Lizenztexte jedoch in ihrer Bedeutung variieren kann und für Laien auf dem Rechtsgebiet nicht immer eindeutig scheint, ist Genauigkeit bei der Analyse der Lizenzen gefragt. Auch wenn die vorgestellten sechs der gebräuchlichsten Lizenzen gut etabliert und dadurch umfassend aufgearbeitet sind, ist es dennoch wichtig, alle Eventualitäten bei der Auslegung der Lizenztexte zu bedenken, um eine Rechtsverletzung zu vermeiden.

Diese Verpflichtungen entstehen

Die grundsätzlichen Verpflichtungen, die aus jeder der betrachteten Open-Source-Lizenzen entstehen, sind das Bereitstellen des kompletten Lizenztextes und des originalen Urheberrechtshinweises (Copyright Notice), sowie die Bedingung, dass der Autor des Codes nicht für daraus resultierende Schäden verantwortlich gemacht werden kann. Außerdem dürfen keine Lizenzgebühren für die Verschaffung von Nutzungsrechten erhoben werden. Für den Verkauf der Software selbst kann theoretisch ein Entgelt verlangt werden, jedoch darf ein Käufer diese kopieren und Kopien des Codes weiterverbreiten, ohne dem Lizenzgeber dafür etwas zu bezahlen.

Der Haftungsausschluss ist mit deutschem Recht jedoch nicht vereinbar, da eine Haftung im Fall von Vorsatz und grober Fahrlässigkeit nach §521 BGB nicht auszuschließen ist, wenn man die dauerhafte Überlassung von Open Source Code als Schenkung auslegt.

Apache 2.0 fordert Dokumentation

Bei den permissiveren Lizenzen kommen nicht mehr allzu viele Verpflichtungen dazu, da die Nutzung des Codes sowohl Modifizierungen, Redistributionen als auch die kommerzielle Verwendung einschließt. Sowohl Apache 2.0 und BSD3 fordern, dass der Name der Komponente bei Modifizierung und Redistribution geändert werden muss. So lässt sich bei der Namensgebung oder Bewerbung des Produkts eines Nutzers nicht darauf schließen, dass die Lizenzgeberin University of California, Berkeley beziehungsweise die Apache Software Foundation an diesem direkt beteiligt ist. Namenszusätze wie beispielsweise „basierend auf Apache Hadoop“ sind jedoch erlaubt.

Eine Besonderheit der Apache 2.0 ist zudem, dass die durchgeführten Veränderungen des Codes notiert werden müssen und wenn bereits eine „NOTICE-Datei“ mit einer solchen Dokumentation vorliegt, dieses zusammen mit dem abgeleiteten Werk ebenfalls mitzuliefern ist, sofern sich die Inhalte des Dokuments auch auf verwendete Bestandteile des genutzten Codes beziehen.

Die aktuelle Version der GPL-Lizenzen – GPL v3 – zeichnet sich durch ihren umfassenden Copyleft-Effekt aus. Wie ihre Vorgängerversion GPL v2 erfordert sie somit, dass abgeleitete Werke als Ganzes auch wieder unter dieselbe Lizenz gestellt werden müssen und greift in ihrem Wirkungsraum somit auch auf zusätzliche Teile eines aggregierten Programms über.

Dieser virale Effekt hat zur Folge, dass auch darauf aufbauender und daraus entstehender proprietärer Source Code offengelegt werden muss – unabhängig davon, ob die Open-Source- Komponente dynamisch oder statisch gelinkt wird.

Sieben klassische Use Types

Je nach Nutzungskontext unterscheiden sich die Lizenztexte. Herauskristallisiert haben sich folgende Use Types:

► Bereitstellung der Open-Source- Komponente im Source-Code- Format oder kompiliert;

► Abhängigkeit des Produkts von der Komponente oder optionales Laden, sodass das Produkt auch ohne Komponente funktioniert;

► Interne Nutzung ohne Distribution über die Grenzen einer legalen Entität hinaus oder Distribution;

► Lokaler Aufruf der Komponente oder Remote Call (SaaS);

► Kommunikation mit der Komponente über In-Process- Mechanismus, wie einen Funktionsaufruf, oder über ein System oder einen Netzwerk- Dienst, wie eine Pipe oder ein Socket;

► Sichtbarkeit der Komponentenartefakte als noch eigenständige Teile oder Einbettung in das Produkt, sodass die Komponente nicht mehr offensichtlich als solche erkennbar ist;

► Vorliegen der Artefakte als unverändert, wie vom Anbieter empfangen oder modifiziert.

Eine Ausnahme hiervon machen die beiden Lizenzen dann, wenn die Komponente sowieso im Source-Format übermittelt wird. Außerdem führt bei GPL v2 eine lediglich interne Distribution oder das reine Ausführen des Codes – also wenn ein Programm eine für sich eigenständige Open-Source-Komponente optional laufen lässt – zu einem Wegfallen jeglicher Lizenzverpflichtungen. Ob die Komponente hierbei lokal oder remote aufgerufen wird, spielt keine Rolle – wichtig ist nur, dass sie nicht in ein Programm eingebunden, sondern über Kommunikationsmechanismen wie „pipes“, „sockets“ oder per „command-line“ genutzt wird.

Die Konsequenz für Cloud Computing

Die Nachfolgelizenz GPL v3 stellt hierauf aufbauend explizit klar, dass es nicht als Redistribution gilt, wenn die Interaktion mit einem Programm per Computernetzwerk erfolgt und betitelt die bloße Bereitstellung von Kopien ohne den tatsächlichen Transfer einer Kopie als „Propagation“ statt als Akt der Distribution („Conveying“). Die bloße Nutzung einer Open-Source-Komponente, indem diese remote aufgerufen wird, ohne eine Kopie des Codes zu übertragen, ist somit ohne zusätzliche Verpflichtungen erlaubt. Wie auch bei der GPL v2 kommt es bezüglich der Lizenzverpflichtungen nur auf die tatsächliche Distribution an, da das Ausführen des Codes ja nicht eingeschränkt ist.

Bei der Bereitstellung durch einen Application Service Provider (ASP) oder einen cloudbasierten Einsatz besteht keine Pflicht zur Offenlegung des Source Codes – der Copyleft- Effekt greift in diesem Fall nicht auf ein gesamtes Produkt über, das lediglich die Open- Source-Komponente remote aufruft. Dies hat vor allem in Bezug auf Cloud Computing Bedeutung.

Wie bereits vermerkt, ermöglicht der neuere Lizenztext von GPL v3 außerdem die Kompatibilität mit beispielsweise Apache 2.0.

Eine zusätzliche Verpflichtung der Lizenz trifft für die Verbreitung modifizierter Versionen zu: Es müssen demnach Hinweise zur Installation der veränderten Software an die „Third Party“, die die Software erhält, weitergegeben werden.

Alles eine Frage des Zugriffs

Die LGPL 2.1 findet vor allem bei Programmbibliotheken Anwendung, die unmodifiziert aufgerufen und nicht obligatorisch in ein Programm eingebunden werden. Solange der Open Source Code demnach nicht mit dem Programm übergeben wird, sondern die Bibliothek nur dynamisch gelinkt wird, greift der Copyleft-Effekt der Lizenz nicht auf das komplette Programm über, sodass dieses nicht unbedingt unter LGPL lizenziert werden muss.

Dieser Unterschied macht den schwächeren Copyleft-Effekt der LGPL 2.1 im Vergleich zu den reinen GPL-Lizenzen aus: Nur bei Veränderung der Open-Source-Komponente selbst muss deren Source Code offengelegt werden.

Der schwache Copyleft-Effekt von LGPL greift also nicht auf das Gesamtwerk über, sondern betrifft nur die modifizierte Komponente selbst. Wenn Abschnitte des Codes jedoch als Teil eines Ganzen, welches auf dem Open Source Code basiert, eingebettet publiziert oder Teile einer Bibliothek mit übergeben werden, muss auch die entsprechende Distribution in Übereinstimmung mit dem Lizenztext von LGPL 2.1 geschehen.

Beim statischen Linken einer Bibliothek gestaltet es sich jedoch etwas anders: Es muss entweder sowohl proprietärer (eigener) Code, als auch die Bibliothek unter LGPL lizensiert sein, oder es muss bei Distribution sichergestellt werden, dass der Nutzer auch mit einer anderen Version des LGPL Source Codes die Bibliothek neu linken kann. Somit muss zwar kein Source Code der proprietären Software übergeben werden, aber die Object Files.

Insofern verhält sich die Lizenz bei einer rein internen Nutzung und der bloßen Ausführung der unmodifizierten Open-Source-Komponente durch dynamisches Linken sehr freizügig:

Jegliche Verpflichtungen des Lizenztextes entfallen. Das eröffnet die Möglichkeit, Programme unter GPL v2, GPLv3 oder LGPL 2.1 durch SaaS-Produkte zugänglich zu machen, ohne die weiteren Lizenzbedingungen wie die Offenlegung des Source Codes und ähnliches einhalten zu müssen. Die GNU Affero General Public License (kurz AGPL) schließt diese Schwachstelle, indem sie auch als SaaS bereitgestellte Open Source Software als „conveying“ betitelt.

Damit sind auch die regulären Pflichten wie die Weitergabe des Source Codes einzuhalten.

Unwissenheit schützt vor Strafe nicht

Zum Jahresbeginn 2021 ließ sich Spannendes beobachten. Elasticsearch wechselte von Apache 2.0 hin zur Server Side Public License (kurz SSPL). Die SSPL stellt keine von der Open Source Initiative akzeptierte Open-Source-

Lizenz dar. Auch andere Open-Source-Programme gingen von einer permissiven Lizenz zu einer Lizenz mit weitgreifenden Copyleftbeziehungsweise Nutzungsrechtseinschränkungen über. Die Intention hinter diesen Relizenzierungen ist, ASPs und Cloud Provider wie Amazon Web Services daran zu hindern,

Freizügigkeiten der Apache 2.0 für gehostete Versionen auszunutzen und somit die Open- Source-Programme zu verwenden, ohne wiederum selbst einen Beitrag zur Community zu leisten. So passten neben Elastic auch Grafana,

Redis Labs, Mongodb, Timescale und Cockroach Labs ihre freien Lizenzen an.

Lediglich Grafana ging zu der von der OSI als Open-Source-Lizenz gelisteten AGPLv3 über, um dem Ideal der fairen Open-Source-Nutzung treu zu bleiben und das Prinzip der Nichtdiskriminierung – weder von einzelnen Personen, Regierungen, religiösen Organisationen oder eben auch der „Trillion Dollar Corporation“ Amazon – beim Wort zu nehmen.

Mongodb begründet den Wechsel von AGPL zu der von ihr 2018 publizierten SSPL vor allem damit, das Potenzial eines Open-Source-Ansatzes bezüglich der Robustheit und Sicherheit der Software nutzen zu wollen. Gleichzeitig will das Unternehmen verhindern, dass die großen Cloud-Anbieter Open-Source-Produkte als SaaS bereitstellen, ohne einen eigenen Beitrag zu den Community-Projekten zu leisten. Die AGPL, unter der die Datenbankdienste von Mongodb zuvor lizenziert waren, sah im Vergleich dazu lediglich vor, dass dem Kunden modifizierter Code zugänglich gemacht werden muss, sobald die Software „as a service“ bereitgestellt wird.

SSPL basiert auf GPLv3 und unterscheidet sich nur insofern, dass sich die Lizenzbedingungen auch auf die Distribution der Software als Dienst ausweiten. Als Konsequenz muss der komplette Source Code inklusive zugehöriger Teile des Dienstes wie Schnittstellen, Speicher und Hosting Software – quasi der „Service Source Code“ – der Öffentlichkeit zugänglich gemacht werden. Das steht im Gegensatz zu AGPL, auch wenn die Open-Source-Komponente unmodifiziert verwendet wird.

Ergebnislose Diskussionen sind absehbar Gerade an diesem Punkt lässt sich über das zukünftige Verfahren mit dem Open-Source- Konzept diskutieren: Unterliegt der reinen Open-Source-Definition auch eine normative, wenn es darum geht, wer von dem Code profitieren darf und sollte das Diskriminierungsverbot weiterhin durchgesetzt werden? Oder ist es gerade in Anbetracht der Veränderungen des Marktes hin zu der Nutzung jeglicher Software als Dienst wichtig, doch Unterscheidungen innerhalb der Gruppe der Profiteure und der Community zu treffen?

Wie die jeweiligen Lizenztexte im Ernstfall ausgelegt werden, muss entsprechend in jedem Fall einzeln untersucht werden, da es sich beim Urheber-und Patentrecht von Software genauso verhält, wie bei jenem für Kunst oder Musik. Jedoch lässt sich sagen, dass die generellen Ziele der Open Source Community bekannt sind und die Grundintention hinter den Lizenzen bereits einen Hinweis darauf geben kann, ob man sich mit der spezifischen Nutzung von Open Source Code rechtlich gesehen in sicheren Gewässern oder einer Grauzone befindet.

Es ist demnach eine Good Practice, bereits vor dem Verbauen einer Komponente zu prüfen, ob die Einbindung in Anbetracht des Nutzungsziels überhaupt möglich ist und keine eventuell schwerwiegenden Verpflichtungen nach sich zieht. (mb)