DE EN FR
Pfad: Hauptseite - Tools/Projekte - MY-no-AI-Lizenz

MY-no-AI-Lizenz

Die derzeitige KI-Entwicklung ist spannend, wirft aber eine Reihe von Fragen auf. Um nicht Teil des Problems zu sein, können Entwickler*innen auf KI-freie Lizenzen zurückgreifen. Dieser Ansatz ist umstritten, aber nicht unmöglich. Diese Seite hostet eine solche Lizenz, die ich von der Apache-Lizenz abgeleitet habe.

Voller Lizenztext

Der volle Lizenztext kann hier als Textdatei (Version 0.9.5, englisch) abgerufen werden.
(alt 0.9.2*, 0.9.3*, 0.9.4 — *: Version 0.9.3 hatte irrtümlicherweise die Versionierung 0.9.2 im Lizenztext.)

Unterschied zur APACHE-2.0-Lizenz

Den Unterschied der englischen Lizenztexte kann man auf einem Terminal ansehen, indem man die MYnoAI-Lizenz 0.9.5 als Textdatei und die APACHE-2.0-Lizenz als Textdatei herunterlädt und auf einem sehr breiten Terminal folgendes Kommando ausführt, oder ein anderes Diff-Tool nutzt:

sdiff -t -w 160 LICENSE-2.0.txt License_MYnoAI_0.9.5.txt

Dies wird folgende Unterschiede sichtbar machen:

Ist das freie Software?

Die großen Institutionen, z. B. die Free Software Foundation (FSF) vertreten die Position, dass Software nur frei ist, wenn sie ohne Restriktion verändert und verteilt werden kann. Ein KI-Verbot ist eine solche Restriktion, weswegen ein entsprechend lizensiertes Projekt z. B. in den Debian-Repositories unter non-free eingeordnet wird. (Im Debian-Projekt sind die Positionen zum Thema noch nicht ganz gefestigt; die Information es stellt den heutigen Stand, 27. August 2026, dar. // 29. 8.: Die Resolution, bei der Vorschlag E gewonnen hat, hat dies leider deutlich bestätigt.)

Wenn man das Fernhalten von KI-Systemen als notwendige Bedingung, die freie Software und ihre Communities zu schützen, betrachtet, so ist es nicht ganz von der Hand zu weisen, dass eine entsprechend lizensierte Software auch als freie Software angesehen werden könnte.

Eine mit MYnoAI lizensierte Software hat weiterhin alle denkbaren Freiheiten wie bei Open Source bekannt, darunter folgende, jedoch unter der zusätzlichen Bedingung, dass sie nicht auf einem KI-System stattfinden:

Verhindert das nicht den Fortschritt?

Die Technik, den Computer lernen zu lassen, ist nicht neu und schon immer faszinierend gewesen. Es lassen mit lernenden Systemen vielversprechende Lösungen schaffen, z. B. die Kategorisierung von E-Mails.

Die Chatbots und Generatoren, wie sie uns heute präsentiert werden, weisen jedoch Klimaschädigung, Ressourcenverbrauch und eine Reihe weiterer negativer Eigenschaften auf, die keine verantwortbare Nutzung zulassen.
Das pauschale Verbot von KI/LLM ist eine provisorische Lösung, die vielleicht später mal von präziseren Regelungen je nach Schadensklassen o. ä. abgelöst werden kann.

Bei allem Fokus auf linearem „Fortschritt“ sollte der Blick dafür klar bleiben, dass vor allem Nicht-KI-Techniken, -Tricks und -Kniffe die tatsächlichen Effizienzgewinne und schonenderen Nutzungsweisen der Zukunft realisieren werden.

Warum in der Lizenz, nicht im README?

Opt-Out-Vermerke im Readme können von allen forkenden Projekten und sogar den Mitgliedern des Hauptprojekts selbst entfernt werden, wodurch sie mittel-/langfristig wirkungslos werden.

Sollen die Projekte (auch/stattdessen) technischen Hürden einbauen?

Die Projekte können technische Hürden gegen die KI-Scraper einbauen. Unabhängig davon ist jedoch die Deklaration, dass das Projekt nicht mit KI-Systemen in Berührung kommen soll, auf jeden Fall per Lizenz vorzunehmen.

Die technischen Hürden wirken nur im beschränkten Umfang, nämlich im Projekt-Repository. Veröffentlicht jemand den Code an anderer Stelle ohne diese Maßnahmen, ist das Ziel, KI-Systeme vom Code fernzuhalten, verloren.

Ich möchte auch ergänzen, dass diese Maßnahmen auch seltene und veraltete Browser und Rechner, die zu schwach für proof-of-work sind, ausschließen. Ein Kernanliegen von FLOSS ist jedoch, dass so viele Personen wie möglich erreicht werden können.

Ausgereiftheit

Bisher nutzt kein Projekt die Lizenz, und ich habe bisher nur beschränkt über die Ziele und Aufbau der Lizenz geredet, auch nicht mit Jurist*innen. Ich hoffe, der Lizenztext drückt trotzdem klar aus, was gemeint ist.

Es gibt jedoch derzeit noch ungelöste Probleme. Sie werden in den folgenden Kapiteln beschrieben:

Problem: Opt-out-Mechanismen

Ein ungelöstes Problem ist der Opt-Out-Mechanismus, wie er von Artikel 4, Absatz 3. der EU Directive on copyright and related rights in the Digital Single Market gefordert wird. Es gibt einen Standard, /.well-known/tdmrep.json, aber der passt nicht ganz auf FLOSS-Projekte, da er eine*n(!) explizite Rechteinhaberin mit Adresse registriert fordert und nicht die Möglichkeit bietet, KI von anderem Daten-Mining zu unterscheiden.
Die Lizenz-Version 0.9.4x ist ein eher fehlgeschlagener Versuch, die tdmrep.json-Datei einzubeziehen.
Meine persönliche Erwartung ist, dass es eine zentrale Anti-AI-Plattform geben wird, auf der man die Lizenzen so wie die MYnoAI-Lizenz registrieren kann und dass im Projekt die alleinige Nennung der MYnoAI-Lizenz KI-Systeme verpflichtet, von der Nutzung des Projekts abzusehen.

Problem gelöst: Definition von KI/LLM

Die Definition von KI ist bis Version 0.9.4 unscharf gewesen. Mittlerweile ist die Defintion identisch zum EU AI Act, Artikel 3.

Problem: U-Boote

KI-„U-Boote“ stellen ein Problem dar. Ein Spaßvogel kann Code, der von einem KI-System ausgegeben wurde, in das Projekt einbringen, ohne die KI-Nutzung zu deklarieren. Nachdem das Projekt eine größere Verbreitung erreicht hat, wird die KI-Nutzung deklariert, was selbst das Starten der MYnoAI-lizensierten Software illegal machen könnte.
Es ist nicht leicht, dafür eine Lösung zu finden, besonders, da die Mitwirkenden in ihrer Haftbarkeit beschränkt sind und es nicht leicht ist, den Schaden, der eher ideeller Natur ist, zu quantifizieren.

Problem gelöst: Relizensierung

Es könnte möglich sein, dass KI-Firmen den Code leicht modifizieren und das abgeleitete Program (Derivative Work) ohne die Anti-KI-Klauseln relizensieren.
Dieses Problem ist mit der Einschränkung der permissiven Weitergabe-Klausel nach 0.9.4 gelöst.

Problem: Inkompatibilität zu GPL und Copyleft

Copyleft-Lizenzen sind allgemein inkompatibel zur MYnoAI-Lizenz.

Es gibt Befürworter der GPL-Kompatibilität, siehe z. B. diesen englischen Artikel: Make Your Open Source Software GPL-Compatible. Or Else.

Obwohl die MYnoAI-Lizenz inkompatibel ist, erlauben GPLv2/GPLv3 jedoch folgende Ausnahmen:

  1. Falls eine MYnoAI-Bibliothek ein integraler Bestandteil des Systems ist („System Library“), kann gegen sie gelinkt werden. Was genau dazu zählt, habe ich per Websuche nicht klar definiert rausfinden können. Dazu zählen auf jeden Fall Betriebssystem-Kernel, Grafiktreiber und C-Runtimes.
  2. Darüber hinaus kann man beim Start eines frischen GPL-Projekts eine explizite Ausnahme für einen Projektbestandteil, der unter der MYnoAI-Lizenz steht, ergänzen. Siehe dazu GPL-incompatible libraries in den GPL-FAQ. Dann kann z. B. von einem GPL-Programm eine MYnoAI-Bibliothek verlinkt werden.
    [An dieser Stelle stand eine fehlerhafte Aussage zum Einfluss auf solche GPL-lizensierten Dateien; sie ist nun gestrichen.]
TODO

Ich denke, man kann die Lizenz jetzt auf mehr oder weniger sichere Weise nutzen.

Trotzdem ist die Lizenz und Website nicht fertig:

Lizenz der Lizenz

Diese Lizenz is von der Apache-2.0-Lizenz adaptiert, wie in https://www.apache.org/foundation/license-faq.html#mod-license thematisiert.

Diese MY-no-AI-Lizenz 0.9.2-0.9.5 kann direkt genutzt oder modifiziert werden; ich veröffentliche meine Modifikationen unter CC‑BY‑SA 4.0.



Backlink: Fediverse

Dokument vom 23. August 2026, letzte Änderung am 16. September 2026. Seitenquelltext

Hintergrundbild: Schräge Vorderansicht der Lok 1142.562-9