Open Source ist mehr als sichtbarer Quellcode

24.07.2026

Open Source ist mehr als sichtbarer Quellcode. Die zehn Kriterien der OSI, die häufigsten Missverständnisse und warum echte Lizenzen Souveränität sichern.

Inhaltsverzeichnis

Das häufigste Missverständnis

Frag zehn Entwicklerinnen und Entwickler, was Open Source bedeutet, und die häufigste Antwort lautet: „Der Quellcode ist einsehbar.” Das klingt naheliegend, ist aber falsch, oder zumindest weit unvollständig. Sichtbarer Quellcode ist eine notwendige, aber längst nicht hinreichende Bedingung.

Der Unterschied ist kein akademisches Detail. Er entscheidet darüber, ob du eine Software in fünf Jahren noch zu deinen Bedingungen betreiben kannst, oder ob ein einzelner Hersteller die Regeln in der Zwischenzeit neu schreibt. Genau diese Frage steht hinter jedem Werkzeug, auf dem du deine Plattform aufbaust.

Was die Open Source Definition wirklich verlangt

Es gibt eine verbindliche Referenz dafür, was Open Source ist: die Open Source Definition der Open Source Initiative (OSI). Sie stellt schon in der Präambel klar, dass Open Source mehr verlangt als den Zugang zum Quellcode. Der Zugang ist nur eines von zehn Kriterien, und die anderen neun betreffen fast alle die Nutzung, nicht die Sichtbarkeit.

Die zehn Kriterien im Überblick

  1. Freie Weitergabe: Die Lizenz darf den Verkauf oder die Weitergabe der Software nicht einschränken und keine Gebühr dafür verlangen.
  2. Quellcode: Der Quellcode muss verfügbar sein, in der bevorzugten, nicht absichtlich verschleierten Form.
  3. Abgeleitete Werke: Änderungen und darauf aufbauende Werke müssen erlaubt sein und unter derselben Lizenz weitergegeben werden dürfen.
  4. Integrität des Autoren-Quellcodes: Die Lizenz darf die Weitergabe geänderter Quellen nur dann einschränken, wenn sie die Verteilung von Patch-Dateien erlaubt.
  5. Keine Diskriminierung von Personen oder Gruppen: Niemand darf von der Nutzung ausgeschlossen werden.
  6. Keine Diskriminierung von Einsatzgebieten: Die Nutzung in einem bestimmten Bereich, etwa kommerziell oder in der Forschung, darf nicht verboten werden.
  7. Weitergabe der Lizenz: Die Rechte gelten automatisch für jeden, der die Software erhält, ohne dass eine zusätzliche Vereinbarung nötig wird.
  8. Keine Bindung an ein Produkt: Die Rechte bleiben erhalten, auch wenn die Software aus ihrem ursprünglichen Paket herausgelöst wird.
  9. Keine Einschränkung anderer Software: Die Lizenz darf keine Bedingungen an andere, unabhängig weitergegebene Software stellen.
  10. Technologieneutralität: Keine Klausel darf von einer bestimmten Technologie oder Schnittstelle abhängen.

Das entscheidende Muster: Fast jedes dieser Kriterien schützt deine Freiheit, die Software zu benutzen, zu verändern und weiterzugeben. Sichtbarkeit allein steht nur in Punkt 2. Eine Lizenz, die dir den Code zeigt, aber die Nutzung beschränkt, erfüllt die Definition nicht.

Die vier Missverständnisse

Sichtbarer Quellcode genügt

Für Lizenzen, bei denen man den Code sehen, aber nicht frei nutzen darf, gibt es einen eigenen, präzisen Begriff: source-available. Der Code liegt offen, doch die Lizenz beschränkt, wer ihn wie einsetzen darf. Bekannte Beispiele sind die Business Source License (BSL), die SSPL oder die Elastic License. Sie sind ausdrücklich kein Open Source im Sinne der OSI, weil sie an Kriterium 6 scheitern, der Nichtdiskriminierung von Einsatzgebieten.

„Ich kann es auf GitHub lesen” sagt also nichts über die Lizenz aus. Ein öffentliches Repository kann proprietär, source-available oder echtes Open Source sein. Der Blick gehört in die Datei LICENSE, nicht auf den Sichtbarkeitsstatus des Repos.

Open Source heißt kostenlos

Kriterium 1 erlaubt ausdrücklich, Open-Source-Software zu verkaufen. „Frei” in „freie Software” meint Freiheit, nicht den Preis. Ganze Geschäftsmodelle, von Support über Hosting bis zu Distributionen, bauen genau darauf auf. Wer Open Source mit „gratis” gleichsetzt, verwechselt eine Eigenschaft der Lizenz mit einem Preisschild.

Mit Open Source darf man kein Geld verdienen

Dieses Missverständnis ist die Kehrseite des vorigen und wird durch Kriterium 6 direkt widerlegt: Eine Open-Source-Lizenz darf die kommerzielle Nutzung nicht verbieten. Sobald eine Lizenz „nur für nicht-kommerzielle Zwecke” sagt, ist sie per Definition kein Open Source. Der kommerzielle Einsatz ist nicht geduldet, er ist garantiert.

Der Hersteller kann die Lizenz jederzeit zurücknehmen

Das ist der wichtigste Punkt, und hier liegt der eigentliche Wert einer echten Open-Source-Lizenz. Was einmal unter einer OSI-anerkannten Lizenz veröffentlicht wurde, lässt sich für diese Version nicht rückwirkend einkassieren. Kriterium 3 sichert das Recht auf abgeleitete Werke. Deshalb kann die Gemeinschaft eine Software forken, wenn ein Eigentümer die Richtung ändert.

Was ein Hersteller sehr wohl tun kann: künftige Versionen unter eine andere, restriktivere Lizenz stellen. Die bereits freigegebene Version bleibt frei, die Weiterentwicklung wandert hinter die neue Lizenz. Genau dieser Mechanismus macht den Unterschied zwischen „der Code gehört einer Firma, die den Stift hält” und „der Code steht auf einem Fundament, das niemand allein zurückdrehen kann”.

Warum das für deine Plattform zählt

Eine Plattform, die im Unternehmen tragen soll, braucht ein Fundament aus zwei Säulen. Die erste ist tiefes technisches Verständnis: die Fähigkeit, die Software im Ernstfall selbst zu betreiben. Die zweite ist die Open-Source-Lizenz: die Garantie, dass dir dieses Betreiben nicht von außen entzogen werden kann. Fehlt die erste Säule, hast du Software, die du nicht beherrschst. Fehlt die zweite, bist du trotz aller Kompetenz an einen Hersteller gefesselt.

Die Lizenzfrage ist damit keine juristische Randnotiz, sondern eine Architektur-Entscheidung. Für kritische Infrastruktur, die du über Jahre betreibst, gerade im regulierten europäischen Kontext, ist ein stiftungsgetragener, echt quelloffener Stack nicht Ideologie, sondern die vernünftige Standardwahl.

Ein aktueller Fall aus der Praxis

Das ist kein theoretisches Szenario. Im August 2023 hat HashiCorp die Lizenz von Terraform von der quelloffenen MPL 2.0 auf die source-available BSL umgestellt. Die letzte unter einer echten Open-Source-Lizenz veröffentlichte Version ist Terraform 1.5.7. Alles danach ist sichtbar, aber nicht mehr Open Source im Sinne der Definition oben.

Die Reaktion der Gemeinschaft ist das perfekte Lehrstück für Kriterium 3: Aus dem letzten freien Stand entstand OpenTofu, ein Fork unter dem Dach der Linux Foundation. Möglich war das nur, weil die alte Lizenz genau die Freiheit garantierte, die eine source-available-Lizenz nicht mehr gibt.

Wie dieser Wechsel technisch abläuft, was beim Umzug wirklich passiert und welche Fallen dabei lauern, zeige ich demnächst in einem Video Schritt für Schritt. Die Grundlagen dafür stehen schon hier im Blog: Terraform nach OpenTofu migrieren.

Fazit

Open Source ist eine Aussage über Freiheit, nicht über Sichtbarkeit. Die vier Merksätze aus diesem Beitrag:

  1. Sichtbarer Code allein ist noch kein Open Source, das nennt sich source-available.
  2. Open Source darf verkauft werden, „frei” meint Freiheit, nicht den Preis.
  3. Kommerzielle Nutzung ist garantiert, nicht bloß geduldet.
  4. Was einmal frei ist, bleibt für diese Version frei und lässt sich forken.

Prüfe bei jedem Werkzeug, auf dem deine Plattform steht, nicht nur, ob du den Code siehst, sondern ob die Lizenz von der OSI anerkannt ist. Dieser eine Blick in die LICENSE-Datei entscheidet über deine Souveränität mehr als jedes technische Feature.

Newsletter

Erhalte praxisnahe Tutorials, Best Practices und echte Lösungen für die häufigsten DevOps-Probleme direkt in Dein Postfach.

Datenschutz: Deine E-Mail-Adresse wird DSGVO-konform in Deutschland gespeichert. Keine Spam, nur relevante Inhalte. Eine E-Mail alle 1 bis 2 Wochen.