Debian erlaubt KI-Code und verzichtet auf eine Kennzeichnungspflicht - News

Das Debian-Projekt hat entschieden, wie es mit Beiträgen umgeht, die mit generativer KI entstanden sind. Die Abstimmung über die General Resolution zur LLM-Nutzung lief vom 15. bis zum 28. August 2026 und endete um 23:59:59 UTC. Durchgesetzt hat sich Option 5 mit dem Titel Responsible Use of Generative AI. Sie erlaubt den Einsatz solcher Werkzeuge, ohne ihn zu empfehlen, und verlangt keine Kennzeichnung.

Wie deutlich das Ergebnis ausfiel

An der Abstimmung nahmen 425 von 1.045 stimmberechtigten Entwicklern teil, also gut 40 Prozent. Das erforderliche Quorum lag bei 48,49 Stimmen und wurde von allen acht inhaltlichen Optionen erreicht. Gewählt wird bei Debian nach der Condorcet-Methode, bei der jede Option paarweise gegen jede andere antritt.

Option 5 setzte sich in jedem dieser Duelle durch. Die Schwartz-Menge, aus der der Sieger bestimmt wird, enthielt am Ende nur diese eine Option. Gegen den nächststärksten Vorschlag, Allow AI-Assisted Contributions with conditions, gewann sie mit 203 zu 148 Stimmen, gegen A cautious approach to generative AI mit 210 zu 130.

Die beiden restriktiven Vorschläge kamen nicht durch:

Ban LLM contributions from Debian via Social Contract hätte den Gesellschaftsvertrag geändert und brauchte deshalb eine Dreiviertelmehrheit. Erreicht wurden 144 zu 257 Stimmen, ein Verhältnis von 0,560 statt der nötigen 3,0. Die Option wurde vor der Auswertung verworfen.
Reject LLMs as far as practical, update Code of Conduct scheiterte schon an der einfachen Mehrheit, mit 176 zu 230 Stimmen.

Auch die Option Debian is created by humans und ein Vorschlag, der LLMs wegen ihres Energieverbrauchs ablehnen wollte, blieben deutlich hinter dem Sieger zurück.

Was in der beschlossenen Fassung steht

Der Text ist ausdrücklich als Positionsbestimmung formuliert, die sich weiterentwickeln kann, ohne dass es dafür eine neue Abstimmung braucht. Die Kernaussagen:

Debian befürwortet den Einsatz generativer KI nicht und verbietet ihn nicht, weder in der Entwicklung noch in Wartung oder Dokumentation. Solche Werkzeuge könnten die Produktivität von Freiwilligen deutlich erhöhen, wenn sie verantwortungsvoll genutzt werden.
Für alle Beiträge gelten unverändert dieselben Maßstäbe bei Qualität, Korrektheit, Wartbarkeit und Rechtskonformität, unabhängig davon, wie und womit sie entstanden sind.
Die Verantwortung bleibt beim Menschen. Beitragende sollen KI-Ausgaben verstehen, prüfen, testen und wo nötig anpassen, bevor sie sie übernehmen. Ungeprüftes Hochladen von KI-Material bezeichnet der Text als unvereinbar mit Debians Entwicklungspraxis.
Offenlegung wird ermutigt, aber nicht verlangt. Der entscheidende Satz lautet sinngemäß: Wir ermutigen unsere Beitragenden offenzulegen, ob ein Beitrag mit KI-Unterstützung entstanden ist, verlangen es aber nicht.
Zu den ungeklärten urheberrechtlichen Fragen bezieht das Projekt bewusst keine Position. Es verlässt sich stattdessen auf die Sorgfalt der Einzelnen; die bestehenden Regeln zu Lizenzierung, Urheberrecht und Softwarefreiheit gelten unverändert weiter.
Vertrauliches darf nicht an Dienste Dritter gehen. Genannt werden private Kommunikation, noch nicht veröffentlichte Informationen zu Sicherheitslücken, kryptografische Schlüssel und Zugangsdaten.
Massenaktionen brauchen vorher Konsens. Wer Fehlerberichte, Patches oder Code-Änderungen in großem Umfang automatisiert einspielen will, soll das vorab in den zuständigen Projektkanälen diskutieren. Für jeden automatisierten Vorgang muss ein Mensch verantwortlich bleiben.

Rust hat drei Wochen vorher anders entschieden

Der Beschluss ist besonders aufschlussreich, weil ein anderes großes Open-Source-Projekt kurz zuvor die gegenteilige Antwort gegeben hat. Am 5. August 2026 haben fünf Teams des Rust-Projekts, darunter Compiler, Bibliotheken und Rustdoc, eine LLM-Richtlinie für das Hauptrepository rust-lang/rust verabschiedet.

Deren Leitsatz zieht die Grenze nicht bei der Erlaubnis, sondern bei der Rolle des Werkzeugs: LLMs dürfen Fragen beantworten, analysieren, zusammenfassen, prüfen und Vorschläge machen, aber nichts erschaffen. Von LLMs verfasster Code ist nicht vollständig verboten, aber an enge Bedingungen geknüpft. Die Änderung muss vorher mit einem namentlich benannten Reviewer abgestimmt, für die Korrektheit des Compilers unkritisch, gut getestet und gut geprüft sein.

Vor allem aber gilt bei Rust genau das, worauf Debian verzichtet: eine Offenlegungspflicht. Sie greift auch bei maschinellen Übersetzungen, trivialen Änderungen, mit LLM gefundenen Fehlern und Review-Bots, die zudem über eigene, klar gekennzeichnete Konten laufen müssen.

Was sich daraus für eine eigene Richtlinie ablesen lässt

Beide Projekte beantworten dieselbe Frage, ziehen die Linie aber an unterschiedlichen Stellen. Die Frage stellt sich inzwischen in fast jedem Team, das KI-Programmierassistenten einsetzt. Nützlich für die eigene interne Regelung ist vor allem, dass sich die Entscheidung in zwei voneinander unabhängige Achsen zerlegen lässt:

Erlaubnis. Darf KI für welche Art von Beitrag eingesetzt werden? Debian regelt das gar nicht, Rust unterscheidet zwischen unterstützen und erschaffen und bindet das Erschaffen an eine Vorabfreigabe.
Offenlegung. Muss der Einsatz dokumentiert werden? Debian empfiehlt es, Rust verlangt es.

Die Punkte, in denen sich beide einig sind, sind die belastbarsten Kandidaten für eine eigene Richtlinie: Die Verantwortung bleibt bei der Person, die etwas einreicht. Die Qualitätsanforderungen ändern sich durch das Werkzeug nicht. Vertrauliches gehört nicht in fremde Dienste. Und automatisierte Massenänderungen brauchen eine vorherige Absprache und einen verantwortlichen Menschen.

Quellen

Debian Project: General Resolution: LLM usage in Debian, Ergebnis und Beat-Matrix
Debian Project: Liste der abgegebenen Stimmen
Inside Rust Blog vom 5. August 2026: rust-lang/rust is adopting an LLM policy