Einführung in Open-Source-Lizenzen

Abgeschlossen

Open-Source-Lizenzen sind rechtliche Vereinbarungen, die definieren, wie Open-Source-Software verwendet, geändert und verteilt werden kann. Jedes Open-Source-Projekt enthält eine Lizenz, die die Rechte angibt, die Benutzern gewährt werden, und alle Verpflichtungen, die sie erfüllen müssen. Das Verständnis von Lizenzen ist für die legale und sichere Implementierung von Open Source-Software in Organisationskontexten unerlässlich.

Was Open-Source-Lizenzen definieren

Eine Open-Source-Lizenz ist ein rechtliches Dokument, das Quellcode begleitet und folgendes angibt:

Erteilte Berechtigungen

Lizenzen gewähren Benutzern explizit bestimmte Rechte:

• Nutzungsrechte: Erlaubnis zur Nutzung der Software für jeden Zweck, einschließlich kommerzieller Anwendungen.
• Änderungsrechte: Berechtigung zum Ändern des Quellcodes an bestimmte Anforderungen, Behebung von Fehlern oder Hinzufügen von Features.
• Vertriebsrechte: Berechtigung zum Freigeben der Software für andere Personen, entweder in originaler oder geänderter Form.
• Unterlizenzierungsrechte: In einigen Fällen ist die Berechtigung zum Lizenzieren der Software für andere Personen unter unterschiedlichen Bedingungen zulässig.

Ohne eine explizite Lizenz verbietet das Urheberrecht die Verwendung, Änderung oder Verteilung von Software. Die Lizenz stellt die gesetzliche Berechtigung für diese Aktivitäten bereit.

Auferlegte Verpflichtungen

Lizenzen erzwingen in der Regel Anforderungen an Benutzer:

• Attributionsanforderungen: Copyrighthinweise und Lizenztext müssen in verteilten Kopien beibehalten werden.
• Offenlegung des Quellcodes: Einige Lizenzen erfordern die Bereitstellung von Quellcode beim Verteilen von Binärdateien.
• Lizenzerhaltung: Muss den Lizenztext mit verteilten Kopien enthalten.
• Lizenzierung von abgeleiteten Werken: Einige Lizenzen verlangen, dass abgeleitete Werke dieselbe Lizenz (Copyleft) verwenden.
• Patenterteilungen: Einige Lizenzen umfassen explizite Patenterteilungen oder defensive Kündigungsklauseln.

Haftungs- und Garantieausschlüsse

Fast alle Open-Source-Lizenzen geben Haftung und Garantien frei:

• Keine Garantie: Die Software wird "wie sie ist" ohne Gewährleistungen bezüglich Marktfähigkeit, Eignung für einen bestimmten Zweck oder Nichtverletzung von Schutzrechten zur Verfügung gestellt.
• Keine Haftung: Autoren und Copyrightinhaber sind nicht für Schäden haftbar, die sich aus der Softwarenutzung ergeben.
• Benutzerrisiko: Benutzer akzeptieren alle Risiken, die mit der Verwendung der Software verbunden sind.

Diese Haftungsausschlüsse schützen Open Source-Entwickler vor rechtlicher Haftung, wobei erkannt wird, dass Software in der Regel frei ohne Entschädigung bereitgestellt wird.

Die Open Source-Definition

Die Open Source Initiative (OSI) verwaltet die autorisierende Open Source-Definition , die Kriterien für Lizenzen angibt, die als wirklich open-source betrachtet werden sollen:

Kernanforderungen

Gemäß der Open Source Definition müssen Open Source-Lizenzen:

Freie Umverteilung:

• Keine Einschränkungen: Lizenzen können nicht daran hindern, die Software als Teil einer aggregierten Verteilung zu verkaufen oder zu verschenken.
• Keine Lizenzgebühren: Lizenzen können keine Lizenzgebühren oder Gebühren für solche Verkäufe erfordern.

Einschluss des Quellcodes:

• Verfügbarkeit: Verteilte Programme müssen Quellcode enthalten oder klare Anweisungen für die Beschaffung ohne Kosten bereitstellen.
• Bevorzugtes Formular: Der Quellcode muss sich in der Form befindet, die für Änderungen bevorzugt wird.
• Keine Verschleierung: Absichtlich verschleierter Quellcode erfüllt die Anforderung nicht.

Abgeleitete Werke:

• Änderungen sind zulässig: Lizenzen müssen Änderungen und abgeleitete Arbeiten zulassen.
• Gleiche Begriffe: Lizenzen müssen die Verteilung von Änderungen unter den gleichen Bedingungen wie die ursprüngliche Software zulassen.

Integrität des Quellcodes des Autors:

• Patchdateien: Lizenzen erfordern möglicherweise Änderungen, die zusammen mit der ursprünglichen Quelle als Patchdateien verteilt werden.
• Benennung: Lizenzen können verlangen, dass abgeleitete Werke andere Namen oder Versionsnummern als das Original verwenden.

Keine Diskriminierung von Personen oder Gruppen:

• Universeller Zugriff: Lizenzen können keine Personen oder Personengruppen diskriminieren.
• Gleichberechtigung: Jeder muss die gleichen Rechte haben, um die Software zu nutzen.

Keine Diskriminierung von Bereichen der Bemühungen:

• Jeder Zweck: Lizenzen können nicht einschränken, dass die Software in bestimmten Bereichen wie geschäfts- oder genetischer Forschung verwendet wird.
• Kommerzielle Nutzung: Lizenzen können die Verwendung der Software in kommerziellen Anwendungen nicht verbieten.

Verteilung der Lizenz:

• Automatische Anwendung: Rechte, die dem Programm zugeordnet sind, müssen für jeden gelten, auf den das Programm weiterverteilt wird.
• Keine zusätzlichen Lizenzen: Benutzer sollten keine zusätzlichen Lizenzen ausführen müssen, um diese Rechte zu erhalten.

Die Lizenz darf nicht für ein Produkt spezifisch sein:

• Eigenständige Rechte: Rechte dürfen nicht davon abhängen, dass das Programm Teil einer bestimmten Softwareverteilung ist.
• Unabhängige Ausführung: Wenn sie aus der ursprünglichen Verteilung extrahiert werden, muss die Software dieselben Rechte haben.

Die Lizenz darf keine andere Software einschränken:

• Keine Kontamination: Lizenzen können keine Einschränkungen für andere Software festlegen, die zusammen mit der lizenzierten Software verteilt wird.
• Aggregation zulässig: Lizenzen können nicht verhindern, dass die Software zusammen mit Software unter verschiedenen Lizenzen verteilt wird.

Die Lizenz muss technologieneutral sein:

• Keine Schnittstelleneinschränkungen: Lizenzen können keine bestimmten Technologien oder Schnittstellenformate erfordern.
• Ausführungsmethode agnostisch: Lizenzen sollten sich nicht darum kümmern, ob Software durch Klicken auf Symbole, Befehlszeilen oder Webschnittstellen ausgeführt wird.

Warum diese Anforderungen wichtig sind

Die Open Source-Definition stellt sicher, dass Lizenzen eine sinnvolle Freiheit bieten:

Schützt die Benutzerfreiheit: Anforderungen verhindern, dass Lizenzen ausgeblendete Einschränkungen festlegen, die Open-Source-Prinzipien untergraben würden.

Ermöglicht die kommerzielle Nutzung: Durch das Verbot der Diskriminierung von Unternehmensbereichen stellt die Definition sicher, dass Unternehmen Produkte mit Open-Source-Software erstellen können.

Fördert die Kompatibilität: Anforderungen, die einschränken, wie Lizenzen sich auf andere Software auswirken können, verringern Kompatibilitätsprobleme.

Verhindert Fragmentierung: Durch die Notwendigkeit angemessener Begriffe verhindert die Definition eine Verbreitung von inkompatiblen quasi offenen Lizenzen.

Kategorien von Open Source-Lizenzen

Während viele verschiedene Open-Source-Lizenzen vorhanden sind, fallen sie in der Regel in zwei allgemeine Kategorien:

Zulässige Lizenzen

Zulässige Lizenzen legen minimale Anforderungen an abgeleitete Werke fest:

• Charaktereigenschaften: Erlauben Sie die Einbindung von Code in proprietäre Software, ohne dass die proprietäre Software open-sourced sein muss.
• Anforderungen: In der Regel ist nur eine Zuordnung erforderlich (Wahrung von Copyrighthinweisen und Lizenztext).
• Kommerzielle Nutzung: Vollständig kompatibel mit der kommerziellen Softwareentwicklung.
• Beispiele: MIT License, Apache License 2.0, BSD Licenses.

Zulässige Lizenzen maximieren die Freiheit für Benutzer, sodass sie kommerzielle Closed Source-Produkte mit Open-Source-Code erstellen können.

Copyleft-Lizenzen

Copyleft-Lizenzen verlangen, dass abgeleitete Werke dieselbe Lizenz verwenden.

• Charaktereigenschaften: Stellen Sie sicher, dass geänderte Versionen und abgeleitete Werke open-source bleiben.
• Anforderungen: Sie müssen Quellcode verteilen und dieselbe Lizenz für abgeleitete Werke verwenden.
• Kommerzielle Nutzung: Kann in kommerzieller Software verwendet werden, aber abgeleitete Werke müssen open-sourced sein.
• Beispiele: GNU General Public License (GPL), GNU Lesser General Public License (LGPL), Mozilla Public License (MPL).

Copyleft-Lizenzen priorisieren die Softwarefreiheit gegenüber der Benutzerfreiheit, um sicherzustellen, dass Open-Source-Software auch bei der Weiterentwicklung Open Source bleibt.

Schwacher Copyleft

Einige Lizenzen belegen eine Mitte:

• Bibliotheksverwendung zulässig: Verknüpfungen mit Bibliotheken in proprietären Anwendungen zulassen, ohne die Anwendung zu öffnen.
• Änderungseinschränkungen: Änderungen an der Bibliothek selbst müssen open-sourced sein.
• Beispiele: GNU LGPL, Mozilla Public License.

Schwache Copyleft-Lizenzen ausgleichen die Förderung der Open Source-Entwicklung mit der Aktivierung kommerzieller Nutzung.

Lizenzauswahl nach Projekten

Open-Source-Projekte wählen Lizenzen basierend auf ihren Zielen aus:

Maximieren der Akzeptanz: Projekte, die eine weit verbreitete Einführung priorisieren, wählen in der Regel eingeschränkte Lizenzen aus, die keine erheblichen Verpflichtungen für Benutzer auferlegen.

Gewährleistung der Freiheit: Projekte, die die Software-Freiheit priorisieren, wählen Copyleft-Lizenzen, die sicherstellen, dass abgeleitete Werke quelloffen bleiben.

Verhindern von proprietären Forks: Copyleft-Lizenzen verhindern, dass Unternehmen proprietäre Versionen von Open-Source-Software erstellen.

Patentschutz: Projekte, die sich um Patente kümmern, wählen Lizenzen mit expliziten Patenterteilungen (wie Apache 2.0) aus, die klarere Patentrechte bieten.

Kompatibilität: Projekte können Lizenzen auswählen, die mit anderen Software kompatibel sind, von denen sie abhängig sind oder in die sie integriert werden möchten.

Mehrere Lizenzen

Einige Projekte verwenden mehrere Lizenzierungsstrategien:

Duale Lizenzierung: Bieten Sie Software sowohl unter Open Source- als auch kommerziellen Lizenzen an, sodass Benutzer auswählen können, welche Bedingungen gelten.

Lizenzstapelung: Möglicherweise verfügen unterschiedliche Komponenten eines Projekts über unterschiedliche Lizenzen.

Lizenzentwicklung: Projekte ändern lizenzen manchmal im Laufe der Zeit, obwohl dies eine Vereinbarung von allen Mitwirkenden erfordert.

Das Transparenz-Paradox

Die Transparenz des Quellcodes schafft sowohl Sicherheitsvorteile als auch Risiken:

Sicherheitsvorteile der Transparenz

Öffentlicher Quellcode ermöglicht Sicherheitsverbesserungen:

• Viele Augen: Tausende von Entwicklern können Code auf Sicherheitsrisiken überprüfen und die Wahrscheinlichkeit der Ermittlung erhöhen.
• Schnellere Offenlegung: Wenn Sicherheitsrisiken gefunden werden, können sie öffentlich offengelegt und gepatcht werden und alle Benutzer informieren.
• Community-Patches: Sicherheitsbewusste Entwickler tragen Patches zur Behebung von Sicherheitsrisiken bei.
• Überwachungsfunktion: Organisationen können Open-Source-Abhängigkeiten auf Sicherheitsprobleme überwachen, was mit geschlossener Software unmöglich ist.

Sicherheitsrisiken der Transparenz

Der öffentliche Quellcode unterstützt auch Angreifer:

• Erkennung von Sicherheitsrisiken: Böswillige Akteure können Quellcode analysieren, um exploitable Sicherheitsrisiken zu finden.
• Exploit-Entwicklung: Das Verständnis der Implementierungsdetails hilft Angreifern, Exploits zu entwickeln.
• Zielidentifikation: Angreifer können identifizieren, welche Anwendungen anfällige Versionen von Open-Source-Komponenten verwenden.
• Zero-Day-Ausbeutung: Angreifer können Sicherheitsrisiken entdecken und ausnutzen, bevor sie öffentlich offengelegt werden.

Der Saldo

Forschung schlägt vor, Transparenz bietet Nettosicherheitsvorteile:

Linus's Gesetz: "Angesichts einer ausreichenden Anzahl von Augen sind alle Fehler oberflächlich." Offene Überprüfung findet und behebt Sicherheitsanfälligkeiten in der Regel schneller als die Closed-Source-Entwicklung.

Obscurity ist keine Sicherheit: Das Aufbewahren des Quellcodegeheimnisses verhindert keine Sicherheitsanfälligkeiten – es blendet sie einfach aus, bis Angreifer sie schließlich entdecken.

Verantwortungsvolle Offenlegung: Die Open-Source-Community hat verantwortungsvolle Offenlegungspraktiken entwickelt, die sicherheit mit Transparenz in Einklang bringen.

Praktische Realität: Die meisten schwerwiegenden Sicherheitsverletzungen umfassen Closed-Source-Software oder Fehlkonfiguration, nicht Open-Source-Sicherheitsrisiken, was bedeutet, dass Transparenz die Sicherheit nicht inhärent verringert.

Das Verständnis von Open Source-Lizenzen und deren Kategorien bietet die Grundlage für die Auswertung bestimmter Lizenzen. In der nächsten Lektion werden allgemeine Open-Source-Lizenzen ausführlich untersucht, sodass Sie verstehen können, welche Begriffe beliebte Lizenzen auferlegen und wie sie unterschiedlich sind.