Open Weight oder Open Source? Was offene KI-Modelle wirklich offenlegen

Ein Open-Weight-Modell ist ein KI-Modell, dessen Gewichte öffentlich herunterladbar sind – Open Source im Sinne der Open Source Initiative (OSI) ist es damit noch nicht. „Open Source“ ist in der KI-Branche zu einem Marketingbegriff geworden. Viele Anbieter bezeichnen ihre Modelle als offen, weil man sie herunterladen und lokal ausführen kann. Was dabei tatsächlich offengelegt wird – und was man damit tun darf –, unterscheidet sich jedoch erheblich. Für Unternehmen, die Modelle selbst betreiben, feinjustieren oder in Produkte einbauen, ist das keine akademische Frage, sondern eine der Rechtssicherheit und der langfristigen Unabhängigkeit.

Woraus ein KI-Modell besteht

Bei klassischer Software ist die Sache vergleichsweise einfach: Wer den Quellcode hat, kann das Programm verstehen, ändern und neu bauen. Ein Sprachmodell besteht dagegen aus mehreren Bestandteilen:

• Gewichte (Parameter): Die Milliarden von Zahlenwerten, die beim Training gelernt wurden. Sie sind das, was man zum Ausführen herunterlädt.
• Code: Die Software für Datenaufbereitung, Training, Ausführung und Bewertung, einschließlich der Modellarchitektur.
• Trainingsdaten: Die Texte, Bilder oder anderen Daten, aus denen das Modell gelernt hat – samt der Art, wie sie ausgewählt, gefiltert und aufbereitet wurden.

Wer nur die Gewichte hat, kann das Modell nutzen und durch Feinjustierung (Fine-Tuning) anpassen. Nachvollziehen, wie es entstanden ist, oder es von Grund auf neu trainieren, kann er nicht.

Open Weight: Gewichte ja, der Rest oft nicht

Als „Open Weight“ bezeichnet man Modelle, deren Gewichte öffentlich verfügbar sind. Das sagt zunächst nichts über zwei andere Fragen:

1. Unter welcher Lizenz? Die Gewichte können unter einer anerkannten Open-Source-Lizenz stehen – oder unter einer eigenen Lizenz des Herstellers mit Nutzungsbeschränkungen.
2. Was wird noch offengelegt? Trainingscode und Angaben zu den Trainingsdaten fehlen bei vielen Open-Weight-Modellen ganz oder teilweise.

Open Weight ist damit eine Beschreibung des Vertriebswegs, kein Gütesiegel.

Was die Open Source AI Definition verlangt

Die Open Source Initiative (OSI), die seit Jahrzehnten die maßgebliche Open Source Definition für Software pflegt, hat im Oktober 2024 die Open Source AI Definition 1.0 veröffentlicht. Nach Stand der Recherche Ende Oktober 2026 ist dies weiterhin die aktuelle Fassung.

Die Definition überträgt die vier bekannten Freiheiten auf KI-Systeme. Man muss ein System

• nutzen dürfen, für jeden Zweck und ohne um Erlaubnis zu fragen,
• untersuchen dürfen, wie es funktioniert,
• verändern dürfen, für jeden Zweck, auch um seine Ausgaben zu ändern,
• weitergeben dürfen, verändert oder unverändert, für jeden Zweck.

Damit diese Freiheiten praktisch ausgeübt werden können, verlangt die Definition Zugang zur „bevorzugten Form für Änderungen“. Diese umfasst drei Elemente:

• Dateninformationen: Ausreichend detaillierte Angaben zu den Trainingsdaten, damit eine fachkundige Person ein im Wesentlichen gleichwertiges System bauen könnte – einschließlich Herkunft, Auswahl, Kennzeichnung und Aufbereitung sowie Bezugsquellen für öffentliche und Drittanbieter-Daten.
• Code: Der vollständige Quellcode für Datenverarbeitung, Training, Ausführung, Validierung und Tests.
• Parameter: Die Modellgewichte bzw. Konfigurationswerte.

Bemerkenswert und umstritten: Die Definition verlangt nicht die Herausgabe der Trainingsdaten selbst, sondern detaillierte Informationen darüber. Kritiker halten das für zu schwach, Befürworter verweisen darauf, dass Trainingsdaten oft urheberrechtlich oder datenschutzrechtlich nicht weitergegeben werden dürfen.

Für die Praxis wichtig: Die meisten bekannten Open-Weight-Modelle großer Hersteller erfüllen diese Definition nicht, weil Trainingscode oder Dateninformationen fehlen – selbst dann, wenn die Gewichte unter einer freien Lizenz stehen.

Zwei Lizenzwelten im Vergleich

Anerkannte Open-Source-Lizenz: Apache 2.0

Die Apache License 2.0 ist eine von der OSI anerkannte, sogenannte permissive Lizenz. Sie erlaubt Nutzung, Veränderung und Weitergabe – auch kommerziell und in proprietären Produkten. Pflichten bestehen vor allem darin, Lizenztext und Urheberhinweise mitzuliefern und Änderungen kenntlich zu machen. Zusätzlich enthält sie eine ausdrückliche Patentlizenz.

Beispiele (Stand Ende Oktober 2026, jeweils Modellkarte prüfen):

• Gemma 4 von Google erschien im April 2026 unter Apache 2.0 – ein Wechsel gegenüber früheren Gemma-Generationen, die unter eigenen Nutzungsbedingungen standen.
• Die Qwen3-Modelle wurden 2025 unter Apache 2.0 veröffentlicht.
• Laut Mistral AI stehen die meisten offenen Mistral-Modelle unter Apache 2.0.

Eigene Community-Lizenzen mit Auflagen

Andere Hersteller verwenden eigene Lizenzen. Das bekannteste Beispiel ist die Llama 4 Community License von Meta. Sie erlaubt kommerzielle Nutzung, enthält aber unter anderem:

• eine Acceptable Use Policy, die bestimmte Nutzungen untersagt und per Verweis Vertragsbestandteil ist,
• die Pflicht, bei Weitergabe deutlich „Built with Llama“ anzuzeigen,
• die Vorgabe, dass Namen abgeleiteter Modelle mit „Llama“ beginnen müssen,
• eine Sonderregel: Wer am Veröffentlichungstag Produkte mit mehr als 700 Millionen monatlich aktiven Nutzern betreibt, braucht eine gesonderte Lizenz von Meta.

Auch Mistral nutzt für einige Modelle eine modifizierte MIT-Lizenz, die Unternehmen mit mehr als 20 Millionen US-Dollar Monatsumsatz zu einer kommerziellen Lizenz verpflichtet.

Solche Bedingungen widersprechen der Open-Source-Grundidee, dass Nutzung für jeden Zweck und durch jeden erlaubt ist. Sie sind deshalb nicht Open Source im Sinne der OSI – auch wenn die Modelle für viele Mittelständler in der Praxis gut nutzbar sind.

Übersicht

Was das für Unternehmen bedeutet

1. Unterscheiden Sie Nutzung und Weitergabe. Wer ein Modell nur intern einsetzt, ist von vielen Lizenzauflagen weniger betroffen als jemand, der ein feinjustiertes Modell an Kunden ausliefert oder in ein Produkt einbaut. Hinweis- und Namenspflichten greifen typischerweise bei der Weitergabe.

2. Prüfen Sie verwiesene Dokumente. Eine Acceptable Use Policy ist oft ein separates Dokument. Klären Sie, welche Fassung gilt und ob sich Ihr Anwendungsfall damit verträgt.

3. Rechnen Sie mit Lizenzwechseln zwischen Versionen. Das Beispiel Gemma zeigt, dass Hersteller ihre Lizenzpolitik von einer Generation zur nächsten ändern – in beide Richtungen. Die Lizenz gilt für die konkrete Version, die Sie einsetzen.

4. Dokumentieren Sie die Herkunft. Halten Sie fest, welches Modell in welcher Version aus welcher Quelle unter welcher Lizenz stammt. Das hilft bei Audits, bei Kundenanfragen und bei Pflichten aus der KI-Verordnung, die wir in EU AI Act für Betreiber beschreiben.

5. Transparenz ist ein eigenes Kriterium. Ein Modell mit offengelegten Trainingsdaten-Informationen lässt sich besser auf Verzerrungen, Urheberrechtsrisiken und Eignung prüfen. Für sensible Einsatzfelder kann das schwerer wiegen als ein paar Prozentpunkte in einer Bestenliste.

6. Offenheit sichert den Ausstieg. Auch ein Open-Weight-Modell unter restriktiver Lizenz verbessert Ihre Lage gegenüber einem reinen Cloud-Dienst: Die Gewichte liegen bei Ihnen, der Hersteller kann den Zugang nicht nachträglich abschalten. Eine Open-Source-Lizenz geht weiter, weil sie auch Weiterentwicklung und Weitergabe ohne Rückfrage erlaubt.

Grundlagen zu Softwarelizenzen allgemein – Copyleft, permissive Lizenzen, Source-Available-Modelle – finden Sie in Open-Source-Lizenzen für Entscheider. Wie Sie offene Modelle praktisch betreiben, erklärt der Leitfaden Lokale Sprachmodelle betreiben.