Open Source regt die Technologiewelt an und formt sie sogar 90 % des modernen Software-Stacks über Frameworks; Bibliotheken; Datenbanken; Betriebssysteme; und unzählige eigenständige Anwendungen.
Die Vorteile von Open-Source-Software sind allgemein bekannt und versprechen mehr Kontrolle und Transparenz. Es gibt jedoch einen beständigen Kampf zwischen dem Open-Source-Bereich und dem proprietären Bereich, der viele Unternehmen dazu veranlasst, sich aus Open-Source-Lösungen zurückzuziehen, um ihre kommerziellen Interessen zu schützen. Im Mittelpunkt all dessen steht die heikle Frage der Lizenzierung.
Es gibt zwei große Arten von Lizenzen, die dem formalen Open Source entsprechen Definition wie von der Open Source Initiative dargelegt (OSI). „Permissive“ Lizenzen enthalten nur wenige Einschränkungen hinsichtlich der Art und Weise, wie Benutzer die Software ändern und verbreiten können, was sie bei Unternehmen beliebt macht, die sie kommerziell nutzen möchten. Und dann gibt es noch „Copyleft“-Lizenzen, die ähnliche Freiheiten bieten, jedoch mit einer bemerkenswerten Einschränkung: Jede geänderte Version der Software muss auch unter derselben ursprünglichen Copyleft-Lizenz vertrieben werden. Dies ist für Unternehmen, die ihre geschützten Werke schützen möchten, nicht so attraktiv.
Aber es steckt noch mehr dahinter: In jedem Bucket sind verschiedene Lizenzen vorhanden. Darüber hinaus gibt es unzählige Lizenzen, die zwar nicht unbedingt Open Source sind, aber dennoch wissenswert sind.
Freizügig
MIT
Das in den 1980er-Jahren am Massachusetts Institute of Technology entstandene Programm trägt den treffenden Namen MIT Die Lizenz ist nach den meisten Maßstäben die beliebteste Open-Source-Lizenz und liegt im Spitzenplatz in der GitHub-Entwickler-Community für viele Jahre.
Wird von Projekten verwendet, darunter Reagieren (Front-End-JavaScript-Bibliothek) und Rubin (Allgemeine Programmiersprache) erlaubt die MIT-Lizenz Entwicklern, Software nach Belieben zu verwenden. Wie bei den meisten Lizenzen dieser Art erfolgt die Bereitstellung ohne Gewährleistung, d. h. die Autoren sind von jeglicher Haftung für durch ihre Software verursachte Schäden (z. B. Datenverlust) befreit. Alles, worüber sich Entwickler Sorgen machen müssen, ist die Einbeziehung des Original-Urheberrechtsvermerks und der MIT-Lizenz in alle abgeleiteten Werke.
Doch die MIT-Lizenz hat einen Mangel: Sie gewährt keine expliziten Patentrechte. Das heißt, wenn eine bestimmte Software auf patentierter Technologie basiert, kann dies zu Rechtsunsicherheit für Entwickler führen, die die Software bereitstellen, ohne separate Genehmigungen für die patentierte Technologie einzuholen.
Dies unterstreicht jedoch eines der wichtigsten Verkaufsargumente der MIT-Lizenz: mit gerade 200 Wörterdie Sprache ist einfach und prägnant. Die Verunreinigung der Dinge durch mehrdeutiges, aus Wortsuppe bestehendes Patentgeschwafel würde die Komplexität von Projekten unnötig erhöhen, bei denen es unwahrscheinlich ist, dass sie sich mit Patenten befassen, wie z. B. höhere Programmiersprachen oder Web-Frameworks.
Aber viele Open-Source-Projekte überschneiden sich mit patentierten Technologien, etwa mit hardwarezentrierter Software wie Android.
Apache-Lizenz 2.0
Die Apache Software Foundation hat die veröffentlicht Apache-Lizenz 2.0 im Jahr 2004 ein Update einer früheren Lizenz mit einer ausdrücklichen Patenterteilung, um Benutzer vor Rechtsstreitigkeiten zu schützen. Wenn ein Entwickler beispielsweise einen einzigartigen Bildverarbeitungsalgorithmus zu einem unter Apache 2.0 lizenzierten Projekt beitragen würde, werden alle Patente, die der Entwickler an diesem Algorithmus besitzt, automatisch an alle Benutzer der Software lizenziert.
Die meisten Menschen werden mit der Android-Marke von Google vertraut sein, die über einen App Store und eine Reihe selbst entwickelter Tools und Dienste verfügt. Aber das zugrunde liegende Android Open Source Project (AOSP) ist im Wesentlichen unter der Apache 2.0-Lizenz verfügbar, ein bewusster Schritt von Google im Jahr 2008, um Apple zu bekämpfen und Telefonhersteller zu ermutigen, Android anstelle der anderen proprietären etablierten Anbieter (z. B. Symbian) der damaligen Zeit zu verwenden. Und es hat funktioniert. Samsung, HTC, LG und alle anderen sind auf Android umgestiegen.
Ein Nebenprodukt davon ist jedoch, dass die Apache-Lizenz 2.0 rund fünfmal so viele Wörter des MIT, unter anderem aufgrund des Patenterteilungstextes und anderer Ergänzungen und Klarstellungen. Aber das ist der Kompromiss, und er verdeutlicht die wesentlichen Unterschiede zwischen den beiden häufigsten freizügigen Open-Source-Lizenzen.
Andere freizügige Lizenzen
Die BSD-2-Klausel-Lizenz ähnelt MIT, weist jedoch wesentliche Unterschiede in der verwendeten Sprache auf. Es legt beispielsweise fest, dass eine Kopie der Lizenz sowohl im Quellcode als auch in der kompilierten Binärform enthalten sein muss. Und dann ist da noch das BSD-3-Klausel-Lizenzdie eine zusätzliche „No Endorsement“-Klausel enthält, die die Verwendung der Namen der Urheberrechtsinhaber und Mitwirkenden für Werbezwecke in abgeleiteten Projekten einschränkt.
Es gibt auch die MIT Keine Namensnennungslizenz (MIT-0), das einfacher ist als das MIT, da in abgeleiteter Software keine Quellenangabe erforderlich ist. Dies zu nutzen kommt einer öffentlichen Veröffentlichung von Software nahe, mit der Ausnahme, dass der Autor das Urheberrecht und die Möglichkeit behält, Dinge in der Zukunft zu ändern.
Copyleft
GNU General Public License (GPL) v. 2.0 und 3.0
Die Free Software Foundation (FSF) veröffentlichte 1989 die GNU General Public License (GPL) und war eine der ersten Copyleft-Lizenzen für den allgemeinen Gebrauch.
Copyleft-Lizenzen eignen sich häufig besser für Projekte, die den Input der Community erfordern, als für Projekte, die von einer einzelnen Unternehmenseinheit unterstützt werden. Durch die Anforderung, dass alle Modifikationen unter derselben Open-Source-Lizenz verfügbar bleiben müssen, wird den Mitwirkenden die Gewissheit gegeben, dass ihre harte Arbeit nicht in proprietärer Software verwendet wird, ohne dass auch die breitere Community davon profitiert – zumindest theoretisch, da es schwierig sein kann, alle zu entdecken Zuwiderhandlung und dann Durchsetzung der Lizenzbedingungen.
2007 ins Leben gerufen, GPL 3.0 ist die drittbeliebteste Lizenz, laut GitHub-Daten. Die Lizenz führte zu bemerkenswerten Aktualisierungen GPL 2.0einschließlich Bestimmungen zur Patenterteilung und verbesserter Kompatibilität mit anderen Open-Source-Lizenzen. Es verbietet auch die sogenannte „Tivoisierung“, bei der Hardwarehersteller, die von GPL-lizenzierter Software profitieren, Benutzer mithilfe von DRM-Mechanismen (Digital Rights Management) daran hindern, modifizierte Versionen dieser Software zu installieren.
Zu den bemerkenswerten GPL-Anwendern gehört WordPress, das unter einer GPL 2.0-Lizenz „oder höher“ verfügbar ist, sodass es dem Entwickler überlassen bleibt, zu entscheiden, unter welcher Lizenz er Änderungen vertreibt.
Linux wiederum gehört zu den erfolgreichsten Open-Source-Projekten aller Zeiten und wird in Servern, Cloud-Infrastrukturen, eingebetteten Systemen und sogar Android eingesetzt. Der zugrunde liegende Linux-Kernel ist jedoch nur unter einer GPL 2.0-Lizenz verfügbar Der Linux-Erfinder Linus Torvalds ist gegen einige der Bestimmungen in Version 3.0 der Lizenz hinzugefügt – einschließlich der Tivoisierungsklausel.
GNU Affero General Public License (AGPL) 3.0
Die Affero General Public License (AGPL) ähnelt GPL 3.0, insofern es sich um eine „starke“ Copyleft-Lizenz handelt, die Softwarefreiheiten fördert und sicherstellt, dass modifizierte Versionen Open Source bleiben. Ein wesentlicher Unterschied zu AGPL besteht jedoch darin, dass es sich auf webbasierte Dienste und Anwendungen konzentriert, bei denen die Software von Servern ausgeführt und nicht als ausführbare Dateien verteilt wird.
Unter einer GPL 3.0-Lizenz sind Entwickler nicht verpflichtet, den Quellcode für geänderte Software freizugeben, wenn diese über ein Netzwerk ausgeführt wird, wie dies bei SaaS-Anwendungen der Fall ist. Die AGPL-Lizenz schließt diese Lücke und verpflichtet Dritte, den Quellcode auch dann zur Verfügung zu stellen, wenn die geänderte Software nur auf einem Server läuft.
Die 2007 von der Free Software Foundation veröffentlichte AGPL 3.0-Lizenz erfreut sich vor allem aufgrund des Aufstiegs von Cloud Computing und SaaS immer größerer Beliebtheit und ist heute die fünftbeliebteste Open-Source-Lizenz.
GNU Lesser General Public License (LGPL)
Auch ein Produkt der Free Software Foundation, das GNU Lesser General Public License (LGPL) ist eine „schwache“ Copyleft-Lizenz, da sie geschäftsfreundlicher ist und weniger strenge Anforderungen an die Weitergabe stellt. LGPL wird normalerweise für Softwarebibliotheken verwendet, in denen Projektautoren Beiträge aus der Community fördern möchten, ermöglicht jedoch die Verknüpfung proprietärer Software mit den Bibliotheken, ohne dass der gesamte proprietäre Code als Open Source bereitgestellt werden muss. Wenn jemand die Open-Source-Bibliothek selbst ändert, muss er diese Änderungen nur unter der LGPL-Lizenz veröffentlichen.
Mozilla Public License 2.0
Veröffentlicht von der Mozilla Foundation im Jahr 2012 Öffentliche Mozilla-Lizenz (MPL) 2.0 ist heute die zehntbeliebteste Open-Source-Lizenz GitHubs Lizenzmetrik. MPL ist ebenfalls eine schwache Copyleft-Lizenz, die dazu dient, proprietären Code zu schützen und gleichzeitig Entwicklern die Möglichkeit zu geben, von Open-Source-Software zu profitieren.
Während sich LGPL jedoch auf die Bibliotheksebene und GPL auf Projektebene konzentriert, arbeitet MPL auf der Ebene einzelner Dateien, sodass der Benutzer einen engeren Codesatz gemeinsam nutzen muss.
Public Domain und Creative Commons
Während eine „Open-Source-Lizenz“ bestimmte Rechte gewährt, sind sie immer an Bedingungen geknüpft. Wer seine Software jedoch ohne Vorbehalte vollständig gemeinfrei machen möchte, kann dies auch auf andere Weise tun.
Es reicht nicht aus, Software einfach ohne Lizenz zu veröffentlichen; Das Urheberrecht gilt standardmäßig für die meisten kreativen Werke, einschließlich Software. Hier kann eine „gemeinfreie Widmung“ Abhilfe schaffen.
Speziell für Software entwickelt, die Ohne Lizenz ist die neuntbeliebteste Lizenz auf GitHub (ob sie tatsächlich als „Lizenz“ bezeichnet werden kann, ist allerdings umstritten). Obwohl das OSI genehmigt Als das Dokument im Jahr 2020 eine Lizenz erhielt, stellte es fest, dass das Dokument „schlecht formuliert“ sei, und stellte seine rechtliche Wirksamkeit in Gerichtsbarkeiten (z. B. Deutschland) in Frage, in denen es nicht möglich ist, Werke als öffentliches Eigentum zu spenden.
Wie die Unlicense, Creative Commons‘ CC0-1.0 ist ebenfalls ein gemeinfreies Widmungstool, obwohl der Schwerpunkt eher auf kreativen Werken liegt. Es verwendet eine klarere, professionellere Rechtssprache, die möglicherweise besser mit dem Völkerrecht übereinstimmt. Es ist erwähnenswert, dass Creative Commons beantragte die Genehmigung von CC0-1.0 als Open-Source-kompatible Lizenz im Jahr 2012, aber hat den Antrag zurückgezogen nachdem das OSI Bedenken geäußert hatte, dass es Patenterteilungen ausdrücklich ausschloss.
Es gibt andere öffentliche Widmungsinstrumente, wie z Null-Klausel-BSDwas gefallen könnte, da es eine noch einfachere Sprache hat. Es besteht jedoch kein Konsens über den besten Mechanismus, um alle Rechte an einer bestimmten Software abzugeben.
Quelle „Faux-pen“.
Es gibt unzählige weitere Lizenzierungsparadigmen im gesamten Softwarespektrum.
In einigen Fällen veröffentlichen Unternehmen Software unter einem Doppellizenzmodellwobei der Benutzer je nach seinen Absichten zwischen einer anerkannten Open-Source-Lizenz und einer kommerziellen Lizenz wählen kann. Dann gibt es „Open Core“, das die Software unter einer Open-Source-Lizenz anbietet, aber mit kostenpflichtigen Hauptfunktionen. In anderen Fällen könnte ein Unternehmen einen Zusatz zur Commons-Klausel zu einer ansonsten freizügigen Open-Source-Lizenz hinzufügen und so kommerzielle Beschränkungen einführen.
Es gibt auch viele Lizenzen, die wie Open Source aussehen und riechen, aber letztendlich nicht mit der Open Source-Definition kompatibel sind.
Im Jahr 2018 wechselte der Datenbankgigant MongoDB von einer Copyleft-AGPL-Lizenz zu einer serverseitigen öffentlichen Lizenz (SSPL), A Lizenz der eigenen Kreation von MongoDB. Während die SSPL noch ziemlich „offen“ ist, handelt es sich um eine sogenannte „Quelle verfügbar“, da der Code zwar zugänglich ist, aber erheblichen kommerziellen Einschränkungen unterliegt großes Nein-Nein soweit es das OSI betrifft.
Die Leute bei MariaDB haben einen ähnlichen Weg mit der Business Source-Lizenz (BUSL) eingeschlagen, die kommerzielle Beschränkungen auferlegt, bevor nach einer festgelegten Anzahl von Jahren auf eine echte Open-Source-Lizenz umgestellt wird. Es gibt eine weitere ähnliche Bewegung, die darauf abzielt, „faire Quelle„Eine Sache lizenzieren.“ Hierzu gehört auch die Functional Source License, die als einfachere Alternative zu BUSL angepriesen wird.
Möglicherweise stoßen Sie auch auf sogenannte „ethische Quelle”Lizenzen von Zeit zu Zeit, wie zum Beispiel die Hippokratische Lizenzdas die Verwendung von Software verbietet, die gegen international anerkannte Menschenrechte verstößt. Ebenso der offene Standard JSON Das Dateiformat hat eine äußerst freizügige Lizenz, abgesehen von einer urkomischen Klausel am Ende: „Die Software soll zum Guten und nicht zum Bösen genutzt werden.“