Software Licenses und Open Source

Geschlossener Quellcode: Proprietär, Freeware und Shareware

Software ist urheberrechtlich geschützt. Sogenannte Lizenzen regeln wie ein Vertrag, welche Nutzungs-, Verbreitungs- und Bearbeitungsrechte du erhältst. Bei geschlossenen Modellen (Closed Source) hast du keinen Zugriff auf den Quellcode:

• Proprietäre Software: Du kaufst lediglich ein eingeschränktes Nutzungsrecht, das durch einen Endbenutzer-Lizenzvertrag (EULA) streng geregelt ist. Der Quellcode ist ein Geschäftsgeheimnis. Änderungen oder die Weitergabe an Dritte sind verboten (Beispiel: Microsoft Windows oder SAP).
• Freeware: Diese Software darfst du dauerhaft kostenlos nutzen. Der Quellcode bleibt jedoch verschlossen und darf weder verändert noch als eigenes Produkt verkauft werden (Beispiel: Adobe Acrobat Reader).
• Shareware: Du erhältst eine kostenlose Testphase. Danach wird eine Gebühr für die weitere Nutzung fällig. Auch hier bleibt der Code geschlossen (Beispiel: WinRAR).

Open-Source-Software (OSS) und die vier Grundfreiheiten

Im starken Kontrast dazu steht die Open-Source-Software (OSS) (z. B. Linux oder VLC media player). Hier ist der Quellcode offen zugänglich. Damit eine Software offiziell als Open Source gilt, muss sie laut der Open Source Definition (OSD) vier essenzielle Freiheiten garantieren:

1. Verwendung: Du darfst die Software für jeden beliebigen Zweck einsetzen (privat, kommerziell oder in der Forschung).
2. Einsicht: Der Quellcode liegt vollständig offen, damit du die Funktionsweise studieren und verstehen kannst.
3. Änderung: Du darfst den Code verändern, um Fehler zu beheben oder neue Funktionen einzubauen.
4. Weitergabe: Du darfst das Original oder deine veränderte Version an Dritte weiterverbreiten.

Diese Freiheiten sind der Motor der Community-Entwicklung. Sie ermöglichen es Entwickler:innen weltweit, über Unternehmensgrenzen hinweg gemeinsam an Projekten zu arbeiten, Fehler schneller zu finden und Innovationen voranzutreiben.

Copyleft-Lizenzen: Der "virale" Effekt

Innerhalb der Open-Source-Welt gibt es unterschiedliche Regeln für die Weitergabe. Copyleft-Lizenzen (wie die GPL - GNU General Public License) sind sehr streng, um die Freiheit der Software dauerhaft zu schützen.

Sie fordern zwingend: Wenn du eine Copyleft-Software veränderst und weiterverbreitest, musst du dein neues Werk unter exakt derselben Lizenz veröffentlichen. Nimmst du also den Linux-Kernel (GPL), baust ihn um und vertreibst ihn als neues Betriebssystem, bist du rechtlich verpflichtet, auch deinen neu geschriebenen Quellcode offenzulegen. Dieser "virale" Effekt verhindert, dass freie Software von Unternehmen in geschlossene, proprietäre Produkte "eingesperrt" wird.

Permissive Lizenzen: Maximale Freizügigkeit

Permissive Lizenzen (wie MIT oder Apache 2.0) sind deutlich weniger restriktiv und bieten maximale Freiheiten. Sie erlauben dir, den offenen Quellcode zu nehmen, zu verändern und das Ergebnis sogar in ein geschlossenes, proprietäres Produkt einzubauen.

Die einzige wesentliche Bedingung ist meist, dass du den ursprünglichen Urheberrechtshinweis (Copyright) und den Lizenztext im Code belässt. Ein Praxisbeispiel: Du kannst eine nützliche Kalender-Bibliothek, die unter der MIT-Lizenz steht, problemlos in die kommerzielle, geschlossene App deines Unternehmens integrieren. Ihr müsst euren eigenen App-Quellcode danach nicht veröffentlichen.

Lizenzkollisionen und das Infektionsrisiko

In der modernen Softwareentwicklung baust du Projekte oft aus Dutzenden verschiedenen Open-Source-Komponenten zusammen. Dabei musst du die Lizenzkompatibilität zwingend prüfen, sonst drohen rechtliche Konsequenzen:

• Lizenzkollision: Nicht alle Open-Source-Lizenzen lassen sich mischen. Kombinierst du eine Bibliothek unter der strengen GPL mit einer Komponente, deren Lizenz widersprüchliche Bedingungen stellt, entsteht eine Kollision. Das Gesamtwerk darf dann rechtlich nicht vertrieben werden.
• Infektionsrisiko für proprietäre Software: Bindet dein Unternehmen versehentlich eine Copyleft-Komponente (z. B. GPL) fest in seine eigene, proprietäre Software ein, greift der virale Copyleft-Effekt auf das gesamte Projekt über. Das Unternehmen wäre rechtlich gezwungen, den Quellcode seiner teuren, proprietären Software komplett offenzulegen. Bei permissiven Komponenten (z. B. MIT) besteht dieses Risiko nicht. Prüfe daher immer die LICENSE-Dateien von Fremdcode!