KI-Lizenzen für Unternehmen — Apache 2.0, MIT und die Llama-Falle

Unternehmen sollten KI-Modelle nur dann produktiv einsetzen, wenn die Lizenz vorab geprüft wurde. Für die typische Frage "Welche KI-Lizenz passt für Unternehmen?" gilt: Apache 2.0 und MIT sind für den kommerziellen Einsatz meist gut beherrschbar, die Llama Community License dagegen ist keine Open-Source-Lizenz im OSI-Sinn und kann gerade bei Skalierung, Konzernstrukturen und Due-Diligence-Fragen zum Problem werden.

Letzte Aktualisierung: 23. März 2026

Die zentrale Fehlannahme lautet: "Open Weights" sei automatisch "Open Source". Genau das stimmt bei vielen KI-Modellen nicht. Wer Gewichte herunterladen, lokal betreiben und kommerziell testen darf, hat noch lange keine OSI-konforme Open-Source-KI-Lizenz. Für Unternehmen ist dieser Unterschied operativ relevant, weil Lizenzverstöße nicht nur juristische Risiken erzeugen, sondern auch Beschaffung, Freigabe, Lieferantenprüfung und AI-Act-Governance erschweren. Wenn Sie Ihren KI-Einsatz zuerst organisatorisch einordnen wollen, helfen die AI-Act-Checkliste für Unternehmen, der Beitrag zur KI-Policy für Unternehmen und unsere EU AI Act Schulung.

Warum KI-Lizenzen für Unternehmen entscheidend sind

KI-Lizenzen sind kein Nebenthema der Rechtsabteilung, sondern ein Freigabekriterium für jeden produktiven KI-Einsatz. Sobald ein Fachbereich ein Modell in interne Prozesse, Kundenkommunikation, HR-Workflows oder Produkte integriert, entscheidet die Lizenz darüber, was Sie überhaupt dürfen, welche Pflichten Sie weitergeben müssen und welche Einschränkungen ein späteres Rollout blockieren können.

Der Handlungsdruck ist hoch, weil viele Unternehmen die organisatorische Basis noch nicht aufgebaut haben. In den Projekt- und Marktresearches dieser Website taucht wiederholt dieselbe Größenordnung auf: Rund 73 Prozent der betroffenen Unternehmen haben die notwendige Schulung oder Governance noch nicht sauber umgesetzt. Genau in diesem Umfeld werden Lizenzfragen oft vertagt, obwohl sie später über Freigabe, Skalierung und Auditfähigkeit entscheiden.

Die größte Gefahr liegt dabei nicht in absichtlichen Verstößen, sondern in falschen Annahmen. Viele Teams prüfen Datenschutz, Informationssicherheit und Kosten, übersehen aber die Frage, ob ein Modell tatsächlich offen lizenziert ist, ob es Patentzusagen enthält, ob es zusätzliche Nutzungsgrenzen gibt oder ob eine Sondergenehmigung des Rechteinhabers erforderlich wird. Genau dieser blinde Fleck ist bei generativer KI besonders häufig, weil Modellgewichte, Code, Trainingsdaten und Nutzungsbedingungen oft auseinanderfallen. In der Praxis wird die KI-Lizenz im Unternehmen deshalb häufig erst dann geprüft, wenn Beschaffung, Datenschutz, Informationssicherheit oder ein Kunde bereits Nachweise verlangt.

Für Unternehmen entstehen daraus vier konkrete Risikofelder:

1. Haftungs- und Unterlassungsrisiko: Wer ein Modell außerhalb der Lizenzbedingungen nutzt, riskiert Vertrags- und Urheberrechtskonflikte.
2. Beschaffungs- und Auditrisiko: Investoren, Kunden und Konzernmütter fragen bei KI-Projekten zunehmend nach belastbaren Lizenzketten.
3. Produkt- und Exitrisiko: Ein Modell, das heute "frei nutzbar" wirkt, kann sich später als ungeeignet für White-Label, OEM oder stark skalierte Nutzung erweisen.
4. Compliance-Risiko: Unklare Lizenzlagen erschweren die Dokumentation, Rollenklärung und Tool-Freigabe nach Art. 4 der EU-VO 2024/1689.

Besonders heikel wird es, wenn Unternehmen Llama pauschal als "Open Source" behandeln und deshalb dieselben internen Freigaben anwenden wie bei Apache- oder MIT-lizenzierten Komponenten. Genau das ist zu kurz gedacht. Wenn Sie zunächst die regulatorische Grundlogik hinter produktiv eingesetzten Modellen verstehen wollen, lesen Sie auch unseren Beitrag Was ist ein KI-System im EU AI Act? und ergänzend die Einordnung zu ChatGPT im Unternehmen.

Apache 2.0: Der Enterprise-Standard erklärt

Apache 2.0 ist für Unternehmen meist die robusteste offene Lizenz im KI-Kontext. Der Hauptgrund ist nicht nur die breite Nutzung, sondern die Kombination aus weitgehenden Nutzungsrechten und einer ausdrücklichen Patentlizenz. Genau diese Patentklausel fehlt bei MIT und ist für kommerzielle KI-Projekte oft der entscheidende Unterschied.

Die Lizenz erlaubt Ihnen, ein Werk zu nutzen, zu vervielfältigen, zu verändern, weiterzugeben und auch kommerziell zu vertreiben. Für interne Plattformen, eingebettete KI-Funktionen, Kundenprojekte und eigene Derivate ist das ein starker Ausgangspunkt. Hinzu kommt: Abschnitt 3 der Apache License 2.0 gewährt eine Patentlizenz der Beitragenden, solange Sie selbst keine Patentklage wegen des Werks anstrengen. Für Unternehmen mit größerem Vertrieb, OEM-Modellen oder konzernweiten Rollouts reduziert das ein wichtiges Unsicherheitsmoment.

Die Freiheiten kommen allerdings nicht ohne Pflichten. Wenn Sie Apache-2.0-lizenzierte Komponenten weitergeben, müssen Sie die Lizenz beilegen, geänderte Dateien kenntlich machen und bestehende Copyright-, Patent-, Marken- und Attributionshinweise erhalten. Wenn ein NOTICE-File existiert, muss dessen Inhalt in geeigneter Form mitgeführt werden. Für reine interne Nutzung ist das oft unkompliziert; für eingebettete Produkte, API-Plattformen oder On-Prem-Distribution sollten diese Pflichten aber in den Build- und Release-Prozess eingebaut werden.

Für KI-Modelle ist Apache 2.0 attraktiv, weil sie wirtschaftliche Nutzung grundsätzlich nicht beschränkt. Einzelne Modellreleases aus der Mistral- oder Qwen-Welt werden genau deshalb von Unternehmen bevorzugt: Die Lizenz ist bekannt, juristisch eingespielt und leichter in Open-Source-Scans, Einkaufsrichtlinien und Software Bills of Materials abzubilden als proprietäre Community-Lizenzen.

Praktisch bedeutet das: Apache 2.0 ist dann besonders sinnvoll, wenn Sie ein Modell nicht nur testen, sondern in Governance, Beschaffung und Produktstrategie sauber integrieren wollen. Wenn Sie intern erst den organisatorischen Unterbau schaffen müssen, ist die Reihenfolge meist sinnvoll: Modellinventar aufbauen, Freigabekriterien definieren, Lizenzpflichten dokumentieren und danach Teams schulen. Genau dafür ist die Verbindung aus KI-Policy, Checkliste und Schulung in vielen KMU die pragmatischste Linie.

MIT-Lizenz: Maximale Freiheit, minimale Pflichten

Die MIT-Lizenz ist noch einfacher als Apache 2.0. Sie gibt Ihnen weitgehende Rechte zur Nutzung, Änderung, Veröffentlichung, Unterlizenzierung und zum Verkauf, verlangt im Kern aber nur eines: Copyright-Hinweis und Lizenztext müssen erhalten bleiben.

Genau diese Einfachheit macht MIT so beliebt. Rechtlich ist sie schlank, operativ leicht zu handhaben und für interne wie externe Nutzung sehr flexibel. Wer Prototypen baut, Modelle feinjustiert, Bibliotheken integriert oder eigene Produkte aufsetzt, kann mit MIT-lizenzierten Komponenten meist ohne großen Lizenzapparat arbeiten. Auch deshalb finden sich in der KI-Welt immer wieder Modelle, Tools oder Distillate mit MIT-artiger oder sehr schlanker Lizenzlogik, etwa in Teilen des DeepSeek-Ökosystems rund um Code und Hilfskomponenten.

Der Preis dieser Einfachheit ist allerdings, dass MIT keine ausdrückliche Patentlizenz wie Apache 2.0 enthält. Für viele kleinere Anwendungsfälle ist das kein Ausschlusskriterium. Für größere Enterprise-Deployments, Partnervertrieb oder sensible M&A-Prüfungen kann es aber ein Argument sein, Apache 2.0 zu bevorzugen, wenn dieselbe technische Qualität verfügbar ist.

Der Vergleich lässt sich nüchtern zusammenfassen:

Für Unternehmen ist MIT deshalb nicht "schlechter", sondern nur weniger abgesichert. Wenn Sie schnell, offen und mit minimalem Lizenzaufwand arbeiten wollen, ist MIT oft ideal. Wenn Sie dagegen komplexe Lieferketten, Plattformprodukte oder Patentfragen im Blick haben, ist Apache 2.0 meist die konservativere Wahl.

Die Llama-Falle: Warum Metas Lizenz KEIN Open Source ist

Die Llama Community License ist keine Open-Source-Lizenz im Sinn der Open Source Initiative. Der entscheidende Punkt ist nicht, dass die Modelle heruntergeladen oder kommerziell genutzt werden können, sondern dass die Lizenz zusätzliche Beschränkungen enthält, die mit der Open Source Definition nicht vereinbar sind.

Die wichtigste Klausel ist die bekannte 700-Millionen-MAU-Grenze. Wer am Veröffentlichungsdatum des jeweiligen Llama-Modells oder -Dienstes mehr als 700 Millionen monatlich aktive Nutzer hat, darf die Modelle nicht einfach unter denselben Standardbedingungen ausrollen, sondern muss eine gesonderte Lizenz von Meta beantragen. Genau diese zusätzliche Genehmigungspflicht diskriminiert bestimmte Nutzergruppen und passt deshalb nicht zur OSI-Definition, die keine Benachteiligung bestimmter Personen, Gruppen oder Nutzungsfelder zulässt. Wer nach "llama lizenz kommerziell" sucht, landet deshalb oft bei einer verkürzten Antwort: kommerzielle Nutzung kann erlaubt sein, ohne dass die Lizenz Open Source ist.

Hinzu kommen weitere Meta-spezifische Bedingungen, die für klassische Open-Source-Freigaben untypisch sind. Die Lizenz verlangt bei Weitergabe bestimmter Produkte und Dienste einen sichtbaren Hinweis "Built with Meta Llama 3", sie verlangt bei abgeleiteten Modellen die Bezeichnung mit vorangestelltem "Llama 3" und sie untersagt, die Llama-Materialien zur Verbesserung anderer großer Sprachmodelle zu verwenden. Schon diese Zusatzregeln zeigen, dass es sich nicht um eine neutrale Open-Source-KI-Lizenz wie Apache 2.0 oder MIT handelt, sondern um eine proprietäre Community License mit eigenen Geschäftsbedingungen.

Für Unternehmen ist das mehr als ein theoretischer Lizenzstreit. Die Llama-Falle besteht aus fünf sehr praktischen Missverständnissen:

1. Downloadbarkeit ist keine Open-Source-Freiheit. Dass Gewichte verfügbar sind, beantwortet nicht die Frage, ob die Lizenz OSI-konform ist.
2. Kommerzielle Nutzung ist nicht gleich uneingeschränkte Nutzung. Eine Community License kann kommerziell nutzbar sein und trotzdem nicht offen sein.
3. Konzernstruktur zählt mit. Die Prüfung, ob Sie in besonders große Nutzerkategorien fallen, ist für Tochtergesellschaften und Plattformunternehmen relevant.
4. Freigabeprozesse werden komplizierter. Einkauf, Legal und Compliance müssen Sonderklauseln prüfen, statt mit einer Standard-Open-Source-Lizenz zu arbeiten.
5. Exit-Szenarien werden unsauber. Was heute für ein KMU unkritisch wirkt, kann bei Partnerschaften, Übernahmen oder internationaler Skalierung plötzlich neu bewertet werden.

Wichtig ist dabei die saubere Tatsachenlage: Die von Meta veröffentlichten Llama-3-Lizenzfassungen stellen vor allem auf Zusatzbeschränkungen wie die 700-Millionen-MAU-Schwelle, Branding-Vorgaben und Nutzungsgrenzen ab. Eine oft pauschal behauptete allgemeine Revenue-Share-Klausel ist in diesen Standardtexten nicht der Kern der praktischen Risikoanalyse. Rechtlich entscheidend ist nicht ein einzelnes Schlagwort, sondern die Summe der Zusatzbedingungen. Genau deshalb verwendet Meta gerade keine standardisierte Open-Source-KI-Lizenz wie Apache 2.0 oder MIT.

Deshalb ist die korrekte Einordnung für Unternehmen: Llama ist zugänglich, breit nutzbar und in vielen Szenarien wirtschaftlich interessant, aber rechtlich kein Open Source im klassischen OSI-Sinn. Wenn Sie diesen Unterschied im Management oder Einkauf erklären müssen, ist die präziseste Formulierung meistens: "Llama ist ein Open-Weight-Modell unter einer Community License, nicht ein OSI-konformes Open-Source-Modell."

EU AI Act Art. 2(12): Open-Source-Ausnahme nur für echtes Open Source

Art. 2 Abs. 12 der EU-VO 2024/1689 nimmt KI-Systeme aus, die unter freien und Open-Source-Lizenzen veröffentlicht werden, solange sie nicht als Hochrisiko-Systeme auf den Markt gebracht oder in Betrieb genommen werden und auch nicht unter Art. 5 oder Art. 50 fallen. Für Unternehmen ist daran ein Punkt entscheidend: Die Ausnahme knüpft an freie und Open-Source-Lizenzen an, nicht an bloß verfügbare Modellgewichte oder Marketingbegriffe wie "open".

Genau deshalb ist die OSI-Definition hier praktisch relevant. Der Gesetzestext nennt die Open Source Initiative nicht ausdrücklich. In der Praxis ist die OSI-Definition aber der naheliegende Referenzrahmen, wenn Unternehmen zwischen echter Open-Source-Lizenz und bloß "offen" vermarkteten Modellen unterscheiden müssen. Diese Definition verlangt unter anderem, dass eine Lizenz niemanden diskriminiert, keine bestimmten Personen oder Gruppen ausschließt und keine Nutzungsfelder verbietet. Eine Lizenz, die für bestimmte Größenordnungen nur mit Sondergenehmigung gilt und zusätzliche produktbezogene Bedingungen vorgibt, passt gerade nicht sauber in diese Logik.

Die Folge ist für Unternehmen klar: Llama sollte jedenfalls nicht vorschnell als Modell behandelt werden, das unter die Open-Source-Ausnahme des Art. 2 Abs. 12 fällt. Das ist keine bloß akademische Feinheit, sondern eine Governance-Frage. Wer intern argumentiert, ein Llama-basiertes System sei "open source und deshalb aus dem AI Act praktisch raus", baut seine Compliance auf eine instabile Prämisse.

Für die Praxis sollten Sie drei Dinge sauber trennen:

1. Lizenzstatus des Modells: Ist die Lizenz wirklich frei und Open Source oder nur community-basiert?
2. Regulatorischer Status des Systems: Fällt Ihr konkreter Einsatz vielleicht trotzdem unter Hochrisiko-, Verbots- oder Transparenzregeln?
3. Unternehmensrolle: Auch bei zulässigen Modellen bleiben Betreiberpflichten, Schulung, Dokumentation und Freigaben relevant.

Gerade der dritte Punkt wird oft übersehen. Selbst wenn eine Open-Source-Ausnahme greift, verschwindet damit nicht jede Governance-Aufgabe im Unternehmen. Für den praktischen Mindeststandard sind weiterhin KI-Kompetenz nach Art. 4, eine belastbare KI-Policy und ein sauberer Nachweis über Rollen und Schulung entscheidend.

Lizenz-Checkliste für Ihren KI-Einsatz

Die beste Schutzmaßnahme gegen Lizenzfehler ist ein kurzer, verbindlicher Vorab-Check. Bevor ein Modell produktiv genutzt, feinjustiert oder in Kundenprozesse eingebaut wird, sollten Sie diese fünf Fragen dokumentiert beantworten:

1. Welche Lizenz gilt genau? Prüfen Sie den exakten Lizenztext des Modells, nicht nur die Kurzbeschreibung im Modellkatalog.
2. Ist die Lizenz OSI-konform oder nur "open" vermarktet? Trennen Sie Open Source, Open Weights und proprietäre Community-Lizenzen sauber.
3. Welche Pflichten entstehen bei Weitergabe oder Produktintegration? Lizenzbeilage, Hinweise, NOTICE, Markenregeln und Dokumentation müssen in den Release-Prozess.
4. Gibt es Zusatzklauseln für Größe, Vertrieb, Plattformnutzung oder Sondergenehmigungen? Genau hier scheitert die Llama-Gleichsetzung mit Apache oder MIT.
5. Ist das Modell für Ihren AI-Act-Kontext geeignet? Lizenzfreigabe, Rollenklärung, Schulung und risikobasierte Nutzung müssen zusammenpassen.

Ein einfacher Entscheidungsbaum sieht in der Praxis so aus: Wenn die Lizenz Apache 2.0 oder MIT ist, prüfen Sie Weitergabepflichten und Patentfragen und können oft zügig freigeben. Wenn die Lizenz zusätzliche Nutzungsbedingungen enthält, behandeln Sie das Modell nicht als Standard-Open-Source-Komponente, sondern als gesonderten Legal- und Compliance-Fall. Wenn das Modell außerdem in HR, Kundenscoring, wesentliche Dienstleistungen oder andere sensible Prozesse eingebunden wird, gehört zusätzlich eine AI-Act-Prüfung dazu.

Für viele KMU ist genau hier der sinnvolle operative Standard: erst Modellinventar, dann Lizenzfreigabe, danach Nutzungsregeln und erst dann breiter Rollout. Wenn Sie diesen Prozess nicht manuell aus Einzelmails, PDFs und Tool-Freigaben zusammensetzen wollen, ist unsere EU AI Act Schulung der schnellste nächste Schritt. Sie vermittelt die Betreiberlogik aus Art. 4, typische Fehler bei KI-Einsatz im Unternehmen und einen dokumentierbaren Nachweis mit Schulungszertifikat.

Die kurze Management-Zusammenfassung lautet deshalb: Apache 2.0 ist für Unternehmen meist der belastbarste offene Standard, MIT ist maximal flexibel mit weniger Schutz bei Patenten, und Llama ist gerade nicht dasselbe wie Open Source. Wer diese drei Kategorien trennt, reduziert nicht nur Rechtsrisiken, sondern schafft die Grundlage für saubere Beschaffung, tragfähige Freigaben und eine belastbare KI-Governance.

Quellen

• Apache License 2.0
• MIT License (OSI)
• Open Source Definition (OSI)
• Meta Llama 3 Community License / offizielles Meta-Repository
• Art. 2 EU AI Act
• Art. 4 EU AI Act