Open Source Lizenzen und ihre Auswirkungen
Open Source hat viele Vorteile sowohl für Anwender als auch Anbieter. Die freie Verfügbarkeit einer Software bedeutet jedoch nicht immer, dass man mit dem Code machen kann, was man will. Auch in freier Software steckt jede Menge Wissen und Arbeit. Mit Open Source Geld verdienen zu wollen ist ebenfalls legitim. Die Leistung anderer ist keine All-Inclusive-Freifahrt.
Es gibt unterschiedliche Open-Source-Lizenzmodelle. Jedes Modell gibt eigene Bedingungen für die Verwendung, Modifikation und Weiterverbreitung von Software vor. Eines haben alle Modelle gemeinsam: Der Code ist offen, einsehbar und verwendbar. Es gibt aber noch eine weitere Gemeinsamkeit. In fast allen Lizenzmodellen müssen Urheberrechtshinweise beibehalten werden. Einige Modelle verbieten eine kommerzielle Nutzung, andere geben die Beibehaltung der Lizenz für Änderungen oder Erweiterungen des Codes vor. Das Lizenzmodell entscheidet auch, ob ein Code später gar nicht, komplett oder nur in Teilen proprietär sein darf. Nur sehr wenige Lizenzmodelle sind wirklich uneingeschränkt in ihrer Nutzung und weiteren Verwendung.
Die gängigsten Lizenzmodelle und ihre Unterschiede
Die einzelnen Lizenzmodelle unterscheiden sich im Wesentlichen im Umgang mit dem Lizenzgegenstand. Es gibt die Copyleft-Lizenzen (non-permissive Lizenz), bei denen Bearbeitung und Weitergabe nur unter den gleichen Lizenzbedingungen erlaubt sind und so genannte Akademiker-Lizenzen (permissive oder Non-Copyleft-Lizenz) mit größeren Freiheiten bei der Verbreitung. Akademiker-Lizenzen erlauben u. a. die Einbettung und kommerzielle Nutzung; manchmal muss noch nicht einmal der Quellcode öffentlich zugänglich sein oder mitausgeliefert werden.
GNU General Public License (GPL)
Bei diesem Lizenzmodell müssen abgeleitete Werke unter derselben Lizenz veröffentlicht werden. Software oder Teile des Codes können verwendet, modifiziert und verbreitet werden – vorausgesetzt, dass die Änderungen ebenfalls unter der GPL veröffentlicht werden.
MIT-Lizenz
Das MIT-Lizenzmodell ist einfach und freizügig. Software oder Teile des Codes können verwendet, modifiziert und verbreitet werden. Allerdings müssen bei Änderungen sowohl Copyright-Hinweis als auch Lizenzbedingungen beibehalten werden.
Apache-Lizenz
Auch dieses Lizenzmodell ermöglicht die Verwendung der Software für jeden Zweck, erfordert jedoch das Beibehalten von Urheberrechtshinweisen und Haftungsausschlüssen.
BSD-Lizenz:
Dieses einfache Lizenzmodell erlaubt ebenfalls Verwendung, Modifikation und Weiterverbreitung – vorausgesetzt, dass der Copyright-Hinweis und die Lizenzbedingungen beibehalten werden.
Creative Commons-Lizenzen:
Die Besonderheit dieses Lizenzmodells ist, dass es nicht nur für Software, sondern auch für kreative Werke angewendet werden kann. Verschiedene Lizenzmodule haben unterschiedliche Freiheiten und erlauben die kommerzielle Nutzung oder die Erstellung abgeleiteter Werke. Sehr beliebt ist ist das Modul CC0 (CC Zero oder CC Null). Es besagt soviel wie „keine Rechte vorbehalten“ – also das genaue Gegenteil von „all rights reserved“. Damit können Inhalte ohne Nachfrage zu beliebigen Zwecken kopiert, veröffentlicht oder auf andere Weise (auch kommerziell) verwendet werden.
Mozilla Public License (MPL)
Dieses Modell ist eine so genannte Hybridlizenz: Damit wird der Quellcode offengelegt, es sind jedoch proprietäre Erweiterungen zulässig. Verwendung, Modifikation und Weiterverbreitung erfordern die Veröffentlichung von Änderungen an MPL-lizenziertem Code ebenfalls unter der MPL.
Die Qual der Wahl
Die Auswahl einer Lizenz hängt von den Zielen des Softwareprojekts (Zielgruppe, Verwendungszweck) sowie den Präferenzen des Anwenders bzw. Entwicklers ab. Bei der Auswahl spielen auch Betriebssysteme und Anwendungsumgebungen (z. B. Mobilgeräte, PCs oder Rechenzentrum) eine Rolle. Im Vorfeld sollten auch Fragen wie Wie offen will ich wirklich sein?, Will ich die Lizenzen verkaufen?, Will ich der Community etwas zurück geben und wieviel? oder Will ich auch an meiner Entwicklung Änderungen erlauben?. Einige Lizenzen sind strenger und erfordern beispielsweise, dass abgeleitete Werke auch Open Source bleiben, während andere mehr Freiheiten für die Verwendung in geschlossenen Systemen zulassen.
Schwarze Schafe…
Die gibt es leider auch. Die schwarzen Schafe nehmen frei verfügbaren Code und verkaufen ihn als ihren eigenen. Das ist nicht nur gegenüber den ursprünglichen Entwicklern unfair. Auch Kunden, die Produkte von solchen Anbietern kaufen, sind oft benachteiligt. Nicht selten fehlt bei solchen Anbietern die Expertise, auch entsprechenden Support zur Verfügung zu stellen oder die Firmen verschwinden schnell wieder vom Markt. Käufer müssen dann noch mehr Budget aufbringen, um weiteren Schaden abzuwenden.
… und wie Anbieter sich wehren
Immer mehr Anbieter von freier Software und offenem Code greifen daher zu einer Maßnahme, welche die Älteren noch von Sun Microsystems kennen. Sun Microsystems entwickelte verschiedene Technologien und Programme, darunter das Betriebssystem Solaris oder die Laufzeitumgebung und Programmiersprache Java. Sun kreierte dafür eine eigene Lizenz: die Sun Microsystems Public License (SPL). Das Unternehmen verwendete die SPL für einige ihrer Open-Source-Projekte, einschließlich Teilen von Java. Nachdem Oracle im Jahr 2010 Sun übernahm, gingen auch die Rechte und Verpflichtungen in Bezug auf die von Sun verwendeten Lizenzen, einschließlich der SPL, auf Oracle über. Oracle nahm einige Veränderungen an der Lizenz vor. Heute verwendet Oracle seine eigene Oracle Binary Code License Agreement (BCA) für Produkte wie Java.
Das Besondere an Lizenzmodellen wie der Oracle BCA ist, dass sie für die Produkte eines Unternehmens entwickelt wurden. Solche unternehmensspezifischen Lizenzen regeln die Bedingungen für die Nutzung, Modifikation und Weiterverbreitung speziell der eigenen Produkte. So stellt z. B. Oracle bestimmte Anforderungen für die Verwendung von Java in kommerziellen Umgebungen. Entwickler müssen sicherstellen, dass sie den Vorgaben entsprechen. Änderungen müssen die ursprüngliche Lizenz beibehalten und diese auch im Code mitführen. Damit soll u. a. sicher gestellt werden, dass Open-Source-Software oder -Code nicht in Drittprodukten eingebettet oder gar als zum Original konkurrierende Lösung eingesetzt wird. Dem Beispiel von Sun und Oracle folgen immer mehr Firmen. Jüngstes Beispiel ist HashiCorp mit ihrem Produkt Terraform.
Allerdings kann oder möchte nicht jedes Unternehmen seine eigene Lizenz kreieren und pflegen. Auch HashiCorp wollte sich das nicht antun. Hier kommt ein relativ junges Lizenzmodell ins Spiel:
Die Business Source License
Die BSL ist eine Hybridlizenz aus Open-Source- und Endnutzer-Lizenz. Im Rahmen der Quelloffenheit kann jeder BSL-lizenzierten Code einsehen sowie für eigene (interne) Zwecke oder zum Testen verwenden. Es gibt jedoch strikte Einschränkungen für die kommerzielle Nutzung des Codes. Erlaubt sind i. d. R. Kopieren, Modifizieren, Redistribuieren und die nichtkommerzielle Verwendung. Eine kommerzielle Nutzung ist meist untersagt oder nur unter sehr spezifischen Bedingungen möglich. Kreiert wurde die Lizenz von den Entwicklern der Datenbanken MySQL und MariaDB (Michael Widenius und David Axmark; zusammen mit Linus Nyman).
Im Beispiel HashiCorp und Terraform erhalten Anwender und Entwickler das Recht zur Vervielfältigung, Änderung sowie der Erstellung abgeleiteter Werke. Die Weiterverbreitung und produktive Nutzung des verwendeten Codes und eventueller eigener Erweiterungen sind allerdings ganz klar geregelt. So darf z. B. der Lizenzgegenstand Dritten nicht auf gehosteter oder eingebetteter Basis angeboten werden, wenn dies eine kostenpflichtige Version des Lizenzgegenstandes und in Konkurrenz mit den Angeboten von HashiCorp steht. HashiCorp definiert ein konkurrierendes Angebot in seiner Lizenz klar als „ein Produkt, das Dritten auf kostenpflichtiger Basis angeboten wird, einschließlich kostenpflichtiger Supportvereinbarungen, und das sich erheblich mit den Fähigkeiten der kostenpflichtigen Version(en) des Lizenzgegenstandes von HashiCorp überschneidet.“
In der Lizenz heißt es auch: „Wenn dein Produkt bei seiner erstmaligen allgemeinen Bereitstellung kein konkurrierendes Angebot ist, wird es auch später nicht zu einem konkurrierenden Angebot, wenn HashiCorp eine neue Version des Lizenzgegenstandes mit zusätzlichen Funktionen herausbringt. Außerdem sind Produkte, die nicht gegen Bezahlung angeboten werden, nicht wettbewerbsfähig.“ Service Provider können also die Software ihren Kunden weiterhin zur Verwaltung in ihren eigenen Umgebungen anbieten oder als Service auf gehosteter Basis zur Verfügung stellen. Die Lizenz gibt es zum Nachlesen auf der Website des Herstellers.
Seriöse Anbieter erkennen
Egal ob freie oder geschäftsmäßige Lizenz: Anwender tun gut daran, ihre Anbieter sorgfältig auszuwählen. Unsere kleinen Checkliste hilft, die Spreu vom Weizen zu trennen:
- Welche Rechtsform hat der Anbieter?
- Wie lange ist der Anbieter schon am Markt?
- Gibt es überprüfbare Referenzen?
- Wie ist der Gesamteindruck? (Büro, Mitarbeiter, Vertragswerke, Angebotsform,…)
- Ist eine Testversion verfügbar? Gibt es auch während des Testzeitraums Unterstützung vom Anbieter?
- Wie wird die VerteilungSoftware verteilt? Wie funktioniert der Update Mechanismus?
- Wie oft gibt es Updates? Von wann ist das Letzte?
- Betreibt der Anbieter eigene Updateserver inkl. Hashes und eigenen Signaturen zur Überprüfung der Integrität und Echtheit?
Fazit
Open Source, ganz gleich unter welcher Lizenz, bietet Anwendern mehr Sicherheit. Der Code ist jederzeit einsehbar (und überprüfbar). Es gibt weder Vendor-Lockins noch sind teure Escrow-Vereinbarungen nötig. Anbieter wiederum profitieren von der Transparenz und dem damit verbundenen Qualitätsversprechen.
