Auch genannt: Quelloffene Software
Open Source bezeichnet Software, deren Lizenz mehr verlangt als die bloße Einsicht in den Quellcode. Nach der Open Source Definition müssen die Lizenzbedingungen unter anderem Weitergabe, Zugang zum bevorzugten bearbeitbaren Quellcode sowie Änderungen und abgeleitete Werke erlauben. Open Source beschreibt damit vor allem ein Lizenz- und Verteilungsmodell; wie ein Projekt organisiert, finanziert oder unterstützt wird, ist eine davon getrennte Frage.
Wer Software benutzt, erhält meist ein fertiges Programm. Der Quellcode – die für Menschen lesbaren Anweisungen, aus denen ein Programm erstellt wird – bleibt bei proprietärer Software in der Regel unter Kontrolle des Rechteinhabers. Bei Open Source darf der Quellcode nicht nur verfügbar sein: Die zugehörige Lizenz muss bestimmte Freiheiten für Nutzung, Weitergabe und Weiterentwicklung gewähren.
Das ist praktisch relevant, wenn eine Organisation nachvollziehen möchte, wie ein Programm arbeitet, einen Fehler beheben lassen will oder bei einem Dienstleisterwechsel nicht bei null anfangen möchte. Der offen zugängliche Code schafft diese Möglichkeiten, erledigt aber weder Prüfung noch Betrieb automatisch. Wer ihn nicht selbst versteht oder bearbeiten kann, kann dafür Beschäftigte, eine Community oder externe Dienstleister einbeziehen.
Open Source ist kein einheitliches Produktmerkmal. Zwei Programme können beide quelloffen sein und sich dennoch erheblich bei Funktionsumfang, Dokumentation, Sicherheitsprozessen, Lizenz und Support unterscheiden. Deshalb sollte die Frage nicht nur lauten, ob eine Software Open Source ist, sondern auch, welche konkrete Lizenz gilt und ob das Projekt zum eigenen Einsatz passt.
Die Open Source Initiative formuliert in ihrer Open Source Definition Kriterien für Lizenzen. Dazu gehören freie Weitergabe, der Zugang zum Quellcode in einer Form, die sich tatsächlich bearbeiten lässt, und die Erlaubnis, Änderungen sowie abgeleitete Werke zu verteilen. Die Lizenz darf außerdem weder Personen oder Gruppen noch bestimmte Einsatzfelder diskriminieren. Eine Lizenz, die etwa eine kommerzielle Nutzung für eine bestimmte Branche ausschließt, erfüllt diese Definition nicht.
Diese Regeln beziehen sich auf die Lizenzbedingungen, nicht auf eine technische Eigenschaft des Codes. Ein öffentlich einsehbares Repository allein macht ein Projekt deshalb noch nicht zu Open Source. Fehlt eine passende Lizenz oder erlaubt sie keine Änderungen und Weitergabe, ist der Code zwar sichtbar, aber die rechtliche Nutzung bleibt eingeschränkt. Für eine belastbare Einordnung sind Lizenztext, Repository und Veröffentlichungsregeln gemeinsam zu prüfen.
Die Arbeit an der Software kann offen oder eher zentral gesteuert sein. Änderungen werden häufig als Vorschläge eingereicht und von Personen mit Schreibrechten geprüft; ein Projekt kann dabei Beiträge aus einer breiten Gemeinschaft annehmen oder von einem Unternehmen gepflegt werden. Auch die Verteilung unterscheidet sich: Manche Projekte stellen Quellcode und fertige Pakete bereit, andere lassen sich aus dem Code selbst erzeugen. Zur nachvollziehbaren Zusammenarbeit wird oft ein Versionsverwaltungssystem wie Git genutzt, aber Git ist keine Voraussetzung dafür, dass eine Lizenz Open Source ist.
Ein kleines Team setzt für eine interne Anwendung eine quelloffene Webanwendung ein. Es möchte eine Anpassung am Anmeldeablauf vornehmen. Die Mitarbeitenden oder ein beauftragter Dienstleister können den Quellcode untersuchen, die Änderung implementieren und eine eigene Version betreiben – soweit die konkrete Lizenz diese Nutzung abdeckt und die technischen Voraussetzungen vorhanden sind.
Das Team sollte die Änderung dokumentieren und bei Updates prüfen, ob sie mit neuen Versionen zusammenpasst. Entscheidet es sich, die geänderte Software weiterzugeben, greifen zusätzliche Lizenzpflichten. Open Source bedeutet also nicht, dass jede Änderung folgenlos oder ohne organisatorischen Aufwand bleibt. Gerade bei der Weitergabe ist die konkrete Lizenz maßgeblich.
Quelloffene Software findet sich in vielen Bereichen: bei Betriebssystemen, Webservern, Datenbanken, Entwicklungswerkzeugen, Office-Anwendungen und Bibliotheken, die andere Programme verwenden. Einzelpersonen können sie lokal einsetzen; Organisationen können sie selbst betreiben, anpassen oder Support einkaufen.
Der Nutzen hängt vom Kontext ab. Für Entwicklungsteams kann es wichtig sein, Fehler zu analysieren oder Schnittstellen anzupassen. Für öffentliche Stellen oder Unternehmen können Rechte zur Prüfung, Weiterentwicklung und zum Anbieterwechsel in eine Beschaffungsentscheidung einfließen. Ein Beitrag von Digital-Magazin zu „Open Source First“ behandelt Auditierbarkeit, Anpassbarkeit und Abhängigkeiten in der öffentlichen Beschaffung. Daraus folgt aber keine pauschale Wahlpflicht: Kompatibilität, Sicherheitsupdates, Kompetenzen, Support und Gesamtkosten müssen für den jeweiligen Einsatz separat bewertet werden.
Auch Unternehmen entwickeln Open-Source-Software. Sie können etwa kostenpflichtigen Support, Hosting, Beratung oder zusätzliche Dienste anbieten. Die Offenheit der Lizenz und ein kommerzielles Geschäftsmodell schließen sich daher nicht aus.
In der Beschaffung hilft es, Rechte und Leistungsversprechen getrennt zu erfassen. Eine Open-Source-Lizenz beantwortet, was mit der Software rechtlich möglich ist. Sie sagt noch nicht, wer bei einem Ausfall reagiert, wie lange Updates bereitstehen oder ob ein bestimmtes Fachverfahren unterstützt wird. Diese Punkte gehören in einen eigenen technischen und vertraglichen Vergleich.
„Open Source“ bedeutet nicht einfach „kostenlos“. Eine Lizenz kann die Weitergabe ohne Lizenzgebühr ermöglichen; Aufwand für Einführung, Betrieb, Anpassungen, Schulung, Infrastruktur und Support kann trotzdem entstehen. Umgekehrt ist kostenlose Software nicht automatisch Open Source.
Ebenso ist sichtbar gemachter Code nicht automatisch prüfbar oder sicher. Quellcodezugang kann Audits und unabhängige Analyse ermöglichen, ersetzt aber keine regelmäßigen Updates, sichere Konfiguration, Tests oder Verantwortlichkeiten. Sicherheitslücken können in offenen wie in proprietären Programmen auftreten.
Ein weiteres Missverständnis betrifft die Begriffe „offene Gewichte“ und Open Source bei KI-Modellen. Dass Modellgewichte heruntergeladen werden können, beantwortet noch nicht die Frage, ob Trainingsdaten, Trainingscode, Nutzungsrechte und Lizenzbedingungen die Anforderungen einer Open-Source-Lizenz erfüllen. Hier lohnt eine genaue Prüfung der veröffentlichten Lizenz statt einer Einordnung nach Werbeaussage.
Open Source ist nicht gleichbedeutend mit proprietärer Software: Dort liegen Quellcode und Änderungsrechte gewöhnlich beim Rechteinhaber. Auch „Source Available“ ist kein Synonym, denn verfügbarer Code kann einer Lizenz unterliegen, die Weitergabe, Änderung oder einzelne Nutzungen beschränkt. Freie Software und Open Source überschneiden sich in vielen Lizenzen, setzen aber unterschiedliche Schwerpunkte in ihrer Begründung. Für die praktische Lizenzprüfung zählt der konkrete Lizenztext.