Open Source vs. Closed Source

Wann ein Modell "offen" ist und wann das Wort nur Marketing — eine Bestandsaufnahme.

Grundlagen 12 min Einsteiger 13. April 2026

Jedes Mal, wenn du einen KI-Chatbot benutzt, vertraust du einem System, dessen innere Funktionsweise du nicht einsehen kannst. Du kannst nicht prüfen, mit welchen Daten es trainiert wurde, ob es versteckte Verzerrungen hat oder was es mit deinen Eingaben macht.

Was wäre, wenn du unter die Haube schauen könntest — nicht nur auf die Ergebnisse, sondern auf den Motor selbst? Genau das verspricht Open Source. Am Ende dieses Artikels verstehst du drei Dinge: was Quellcode ist, wie Lizenzen bestimmen, was du damit tun darfst, und warum das alles kritisch wird, wenn die Software eine KI ist.

Was du siehst — und was nicht

Quellcode — Das Rezept hinter der Software

AnalogieDefinition
Open Source ist wie ein veröffentlichtes Rezept: Du kannst die Zutaten lesen, die Schritte nachvollziehen, die Würzung anpassen und deine verbesserte Version teilen. Closed Source ist wie ein versiegeltes Fertiggericht: Du kannst es essen, weißt aber nicht, was drin ist oder wie es gemacht wurde.

Die Rezept-Analogie hat Grenzen: Software kann beliebig oft kopiert werden (Kochen erfordert Zutaten). Ein "Rezept" mit Millionen Zeilen Code ist nur für Fachleute lesbar. Manche Lizenzen erlauben das Lesen, schränken aber die Nutzung ein (Source-Available).

Linux — Open Source

Über 40 Millionen Zeilen Code, öffentlich auf GitHub einsehbar. Jeder kann den Code lesen, Fehler melden oder Verbesserungen einreichen. Begonnen 1991 mit ~10.000 Zeilen.

Windows — Closed Source

Proprietärer Quellcode, den nur Microsoft-Mitarbeiter einsehen können. Nutzer erhalten Installationspakete, keine Quelldateien. Unabhängige Überprüfung ist nicht möglich.

Wichtig: Code auf GitHub ist nicht automatisch Open Source. Ohne eine LICENSE-Datei gilt vollständiger Urheberrechtsschutz — niemand darf den Code kopieren, verändern oder verteilen, selbst wenn er öffentlich sichtbar ist. Öffentliche Sichtbarkeit erteilt keine Nutzungsrechte.

Häufige Irrtümer über Quellcode

"Open Source = kostenlos" — Nicht zwingend. Open Source bedeutet Zugang zum Quellcode und bestimmte Freiheiten, aber Unternehmen wie Red Hat verdienen Milliarden mit Open-Source-Software durch Support und Services.

"Closed Source = professioneller" — Die meisten Webserver (Apache, Nginx), Programmiersprachen (Python) und Cloud-Infrastrukturen basieren auf Open Source. Professionalität hängt nicht vom Lizenzmodell ab.

"Code auf GitHub = Open Source" — Ohne LICENSE-Datei gelten alle Rechte dem Autor. Sichtbarkeit ist nicht gleich Nutzbarkeit.

Die Spielregeln — Softwarelizenzen

Lizenz — Die rechtlichen Regeln von Open Source

AnalogieDefinition
Lizenzen sind wie die Regeln eines Gemeinschaftsgartens. Ein permissiver Garten (MIT) sagt: "Nimm, was du willst, nutze oder verkaufe es — nenne nur, woher es stammt." Ein Copyleft-Garten (GPL) sagt: "Du darfst ernten und neue Sorten züchten, aber deine neuen Sorten müssen auch für alle verfügbar sein." Ein Source-Available-Garten lässt dich schauen und probieren, verbietet aber den Verkauf über bestimmte Grenzen hinaus.

Die Garten-Analogie hat Grenzen: Lizenzen sind rechtlich durchsetzbare Verträge mit echten Konsequenzen. Code wird perfekt kopiert (Pflanzen nicht). Subtile Unterschiede wie Patentklauseln haben kein Garten-Äquivalent.

Permissiv (MIT, Apache 2.0)

Maximale Freiheit. Code sichtbar, Änderungen erlaubt, kommerzielle Nutzung erlaubt. Einzige Pflicht: Urhebernennung beibehalten. Änderungen müssen nicht geteilt werden.

Copyleft (GPL)

Gleiche Freiheiten, aber mit einer Bedingung: Abgeleitete Werke müssen ebenfalls unter GPL stehen. Wenn du den Code veränderst und weitergibst, musst du deinen Quellcode offenlegen.

Die dritte Familie heißt Source-Available: Der Code ist sichtbar, aber die kommerzielle Nutzung oder Weitergabe ist eingeschränkt. Wichtig: Source-Available ist nicht das Gleiche wie Open Source — die OSI erkennt solche Lizenzen nicht als Open Source an.

Fallstudie: LLaMA vs. Mistral

Meta nannte seine LLaMA-Modelle "Open Source", aber die Llama Community License schränkt Unternehmen mit über 700 Millionen monatlich aktiven Nutzern ein und erfordert eine separate Lizenzierung. Das verstößt gegen OSI-Kriterien, die keine Diskriminierung gegen bestimmte Nutzer erlauben.

Im Vergleich: Mistral veröffentlicht Modelle unter Apache 2.0 — echtes Open Source mit uneingeschränkter kommerzieller Nutzung. Der LLaMA-Fall zeigt, warum man die tatsächliche Lizenz lesen muss, nicht nur das Marketing.

Häufige Lizenz-Irrtümer

"GPL verbietet kommerzielle Nutzung" — Nein. GPL erlaubt kommerzielle Nutzung, verlangt aber, dass abgeleitete Werke ebenfalls den Quellcode offenlegen.

"Keine Lizenz = Public Domain" — Nein. Ohne Lizenz gilt vollständiger Urheberrechtsschutz. Niemand darf den Code nutzen.

"Open Weights = Open Source" — Nein. Modellgewichte ohne offene Trainingsdaten und OSI-anerkannte Lizenz sind eine andere Kategorie. LLaMA ist ein Beispiel.

Interaktiv: Open Source, Free Software & Proprietär

Klicke auf die Bereiche des Venn-Diagramms, um die Überschneidungen zwischen Open Source, Free Software und proprietärer Software zu erkunden. Die Schnittmengen zeigen hybride Modelle wie Dual Licensing oder Open Core.

Klicke auf einen Bereich im Venn-Diagramm, um seine Bedeutung zu sehen.
Nur Open SourceNur Free SoftwareNur ProprietärOpen Source ∩ Free SoftwareOpen Source ∩ ProprietärFree Software ∩ ProprietärAlle dreiOpenSourceFreeSoftwareProprietär

Klicke auf einen Bereich

Klicke auf einen der Kreise oder Schnittflächen, um zu erfahren, welche Software dort eingeordnet wird und was die Kategorie bedeutet.

Warum das für KI wichtig ist — Transparenz

Ein geschlossenes KI-System ist wie ein Auto mit versiegelter Motorhaube: Du kannst es fahren, aber du kannst den Motor nicht inspizieren, die Sicherheitsbewertungen nicht unabhängig überprüfen und es nicht selbst reparieren. Du musst den Behauptungen des Herstellers vollständig vertrauen.

Ein offenes KI-System lässt dich die Haube öffnen, jeden Bolzen prüfen und sogar einen besseren Motor bauen. Allerdings: Die meisten Nutzer können Quellcode nicht lesen, selbst wenn er verfügbar ist. Und offene Projekte haben manchmal nicht die Ressourcen für gründliche Überprüfungen.

Sicherheit: Offener Code ermöglicht Community-basierte Schwachstellenentdeckung. Aber das ist keine Garantie — der Heartbleed-Bug versteckte sich über 2 Jahre in OpenSSL, obwohl der Code offen war.

Vertrauen: Unabhängige Audits können Behauptungen über Sicherheit und Fairness überprüfen. Bei geschlossenen Systemen musst du dem Anbieter blind vertrauen.

Innovation: Offene Modelle erlauben es jedem, auf bestehender Arbeit aufzubauen. Die Geschichte von GNU/Linux beweist, dass Open-Source-Kollaboration Systeme hervorbringt, die die Welt antreiben.

Geschlossen

GPT-4, Claude: Nur per API zugänglich. Kein Quellcode, keine Trainingsdaten. Du kannst das Modell nutzen, aber nicht inspizieren, lokal ausführen oder verändern.

Open Weights

LLaMA: Modellgewichte zum Download, aber mit eingeschränkter Lizenz (700-Mio.-Nutzer-Grenze). Du kannst das Modell lokal nutzen, aber nicht frei weiterverbreiten oder für bestimmte Unternehmen einsetzen.

Open Source

Mistral (Apache 2.0): Volle Freiheit. Quellcode und Gewichte verfügbar, keine Nutzungseinschränkungen. Du kannst das Modell nutzen, verändern, verkaufen und weitergeben.

Hugging Face Zentrale Plattform für KI-Modelle, Datensätze und Demos
Ollama Sprachmodelle lokal auf deinem Computer ausführen
LM Studio Grafische Oberfläche für lokale Sprachmodelle
Stable Diffusion Open-Source-Bildgenerierung auf deiner eigenen Hardware
n8n Open-Source-Automatisierung mit KI-Integration

"Bei genügend Augenpaaren werden alle Bugs offensichtlich" — so formulierte Eric S. Raymond das Prinzip, das nach Linus Torvalds benannt ist. Die Idee: Je mehr Menschen den Code lesen, desto wahrscheinlicher werden Fehler gefunden.

Die Realität ist komplizierter. Der Heartbleed-Bug versteckte sich über 2 Jahre in OpenSSL, einer der meistgenutzten Sicherheitsbibliotheken der Welt — obwohl der Code offen war. Die "vielen Augen" schauten offenbar woanders hin.

2024 wurde eine raffinierte Backdoor im xz-Komprimierungswerkzeug entdeckt — ein gezielter Supply-Chain-Angriff, bei dem ein Angreifer über Jahre das Vertrauen der Maintainer gewann. Der offene Code wurde zum Angriffsvektor.

Die Schlussfolgerung: Transparenz ist notwendig, aber nicht hinreichend. Sie muss begleitet werden von aktiver, finanzierter Sicherheitsüberprüfung. Open Source gibt die Möglichkeit zur Inspektion — aber jemand muss sie auch tatsächlich durchführen.

Das Wichtigste auf einen Blick

  1. Quellcode ist das menschenlesbare Rezept; eine Binärdatei ist das versiegelte Produkt. Open Source gibt dir das Rezept; Closed Source gibt dir nur das Produkt.
  2. Eine Lizenz macht aus sichtbarem Code rechtlich nutzbaren Code. Ohne LICENSE-Datei gilt Code auf GitHub als vollständig urheberrechtlich geschützt.
  3. Permissive Lizenzen (MIT, Apache) erlauben fast alles. Copyleft (GPL) verlangt, Änderungen zu teilen. Source-Available erlaubt das Lesen, schränkt aber die Nutzung ein.
  4. "Open Weights" (wie LLaMA) sind nicht dasselbe wie "Open Source" — ohne offene Trainingsdaten und OSI-Lizenz fehlt entscheidende Transparenz.
  5. Für KI-Systeme ist Transparenz kein Luxus — sie ermöglicht unabhängige Sicherheitsaudits, Erkennung von Verzerrungen und reproduzierbare Forschung.

Quiz: Open Source vs. Closed Source

Frage 1 / 4
Noch offen

Was bewirkt eine LICENSE-Datei in einem GitHub-Repository?

Wählen Sie eine Antwort
Auflösung: 1) B · 2) B · 3) C · 4) B

Checkpoint: Teste dein Wissen

  • Warum reicht es nicht aus, dass Code auf GitHub sichtbar ist, um von "Open Source" sprechen zu können?
  • Was ist der Hauptunterschied zwischen einer permissiven Lizenz (wie MIT) und einer Copyleft-Lizenz (wie GPL)?
  • Nenne einen Vorteil und eine Einschränkung von Open-Source-KI-Modellen im Vergleich zu geschlossenen Modellen.