Software Licenses und Open Source

Von Proprietär bis Open Source

Software ist urheberrechtlich geschützt, und Lizenzen regeln verbindlich, was Nutzende mit ihr tun dürfen. Wir unterscheiden dabei grundlegend zwischen Modellen, die den Zugriff auf den Quellcode verwehren, und solchen, die ihn öffnen.

• Proprietäre Software (Closed Source): Hier erwirbst du in der Regel nur ein Nutzungsrecht, aber kein Eigentum am Code. Der Quellcode bleibt Geschäftsgeheimnis. Ein Beispiel ist Unternehmenssoftware wie SAP S/4HANA oder das Betriebssystem Windows. Die Nutzung wird streng durch Endbenutzer-Lizenzverträge (EULA) reglementiert; Änderungen oder die Weitergabe sind untersagt.
• Freeware und Shareware: Auch diese sind rechtlich meist proprietär. Freeware ist kostenlos nutzbar, erlaubt aber keinen Einblick in den Code. Shareware (wie WinRAR) bietet eine kostenlose Testphase, erfordert danach aber oft eine Gebühr für die weitere Nutzung.
• Open-Source-Software (OSS): Dieses Modell gewährt weitreichende Rechte. Nutzende dürfen die Software nicht nur verwenden, sondern auch den Code einsehen, anpassen und verbreiten. Prominente Beispiele sind der VLC media player oder das Betriebssystem Linux.

Die vier Freiheiten von Open Source

Damit eine Software offiziell als "Open Source" gilt, muss sie gemäß der Open Source Definition (OSD) vier essenzielle Freiheiten garantieren. Diese Freiheiten sind der Motor für die weltweite Community-Entwicklung, da sie Zusammenarbeit über Unternehmensgrenzen hinweg ermöglichen:

1. Freiheit der Verwendung: Die Software darf für jeden Zweck eingesetzt werden (z. B. auch kommerziell, in der Forschung oder privat).
2. Freiheit des Verstehens (Einsicht): Der Quellcode muss offenliegen, damit man die Funktionsweise studieren kann.
3. Freiheit der Verbesserung (Änderung): Jede:r darf den Code verändern, um Fehler zu beheben oder neue Funktionen einzubauen.
4. Freiheit der Verbreitung (Weitergabe): Das Original oder deine veränderte Version darf an Dritte weitergegeben werden (kostenlos oder gegen Geld).

Stell dir Open Source wie ein Kochrezept vor, das du nicht nur nachkochen, sondern auch verfeinern und an deine Freund:innen weitergeben darfst. Proprietäre Software ist dagegen wie ein Gericht im Restaurant: Du darfst es essen, aber du erfährst nicht das genaue Rezept und darfst es nicht in deiner eigenen Küche verkaufen.

Copyleft vs. Permissive Lizenzen

Innerhalb der Open-Source-Welt gibt es zwei große Lager, die sich darin unterscheiden, wie "streng" sie die Freiheit der Software schützen:

Copyleft-Lizenzen (Der virale Effekt): Diese Lizenzen, wie die GNU General Public License (GPL), sind "streng". Sie fordern, dass jede Weiterentwicklung der Software zwingend unter derselben Lizenz veröffentlicht werden muss. Wenn du den Linux-Kernel (GPL) veränderst und vertreibst, musst du deinen eigenen Quellcode ebenfalls offenlegen. Dies verhindert, dass freie Software in geschlossene Produkte "eingesperrt" wird.

Permissive Lizenzen (Die "Freizügigen"): Lizenzen wie MIT oder Apache 2.0 sind weniger restriktiv. Sie erlauben dir, den Code zu nehmen, zu verändern und das Ergebnis sogar in ein geschlossenes, proprietäres Produkt einzubauen. Du musst meist nur die Urhebenden nennen. Ein Beispiel ist das PHP-Framework Symfony: Dessen Komponenten können problemlos in kommerzielle, geschlossene Webanwendungen integriert werden, ohne dass der Quellcode der Anwendung offengelegt werden muss. Auch moderne KI-Modelle wie die von Mistral AI nutzen oft solche Lizenzen (z. B. Apache 2.0), um eine breite kommerzielle Nutzung zu ermöglichen.

Lizenz-Kompatibilität und der "Lizenz-Dschungel"

In der Praxis werden Softwareprojekte oft aus vielen verschiedenen Komponenten (Bibliotheken) zusammengesetzt. Dabei kann es zu Lizenzkollisionen kommen.

• Inkompatibilität: Nicht alle Open-Source-Lizenzen lassen sich mischen. Eine Bibliothek unter der strengen GPL darf oft nicht mit Komponenten kombiniert werden, deren Lizenzen widersprüchliche Bedingungen stellen.
• Infektionsrisiko bei proprietärer Software: Für Unternehmen ist die Unterscheidung kritisch. Bindet ein Unternehmen eine Copyleft-Komponente (z. B. GPL) fest in seine eigene, proprietäre Software ein, greift der Copyleft-Effekt: Das Unternehmen wäre rechtlich gezwungen, den Quellcode seiner eigenen Software offenzulegen. Bei permissiven Komponenten (z. B. MIT) besteht dieses Risiko nicht. Daher ist eine genaue Prüfung der LICENSE-Dateien vor der Verwendung von Fremdcode unerlässlich.