Debian und Codeberg regeln KI-Beiträge

Innerhalb von zwei Tagen haben zwei Open-Source-Institutionen dasselbe Problem angefasst, von zwei verschiedenen Enden. Codeberg hat am 23. Juli entschieden, Debian hat am 24. Juli die Debatte eröffnet. Es geht in beiden Fällen um die Frage, was passiert, wenn Beiträge schneller entstehen, als Menschen sie prüfen können.

Codeberg: entschieden

Die Mitgliederversammlung des Codeberg e.V. hat zwei Anträge angenommen. Der erste hält fest, dass weder Quellcode noch Nutzer- und Projektdaten für das Training von LLMs oder anderen generativen Systemen verwendet werden. Der zweite ändert die Nutzungsbedingungen und erlaubt es, Repositories auszuschließen, deren Inhalt überwiegend von LLMs oder autonomen Agenten stammt und die von Menschen nicht geprüft, weiterentwickelt und langfristig gepflegt werden.

Der zweite Antrag war der umstrittene. Er ging mit 358 Ja-Stimmen, 144 Nein-Stimmen und 14 Enthaltungen durch, bei einer Beteiligung von rund der Hälfte der aktiven Mitglieder. Ein Drittel Gegenstimmen ist kein Durchmarsch.

Wichtiger als der Beschluss selbst ist die Abstufung, die Codeberg im Blogpost beschreibt. Es gibt keine Schwelle "so viel Prozent KI ist zu viel", sondern drei Kategorien:

Kategorie	Was darunter fällt
Willkommen	Projekte mit aktiver Community, Projekte mit nennenswerter Vor-LLM-Historie, Maintainer die unwissentlich KI-Beiträge angenommen haben
Geduldet	Nebenprojekte mit geringem Ressourcenverbrauch, Nischenwerkzeuge ohne Community-Aussicht
Unerwünscht	Von autonomen Agenten erstellte Projekte, überwiegend per LLM gepflegte Repositories, Projekte deren Ressourcenverbrauch in keinem Verhältnis zu den Menschen dahinter steht

Zur Durchsetzung sagt Codeberg deutlich, dass es kein automatisches Scannen und keine kurzfristige Massenlöschung geben wird. Die Regeln sollen an konkreten Fällen ausbuchstabiert werden, durch Menschen, nicht durch einen Algorithmus. Das ist die ehrlichste Aussage im ganzen Beschluss, denn "überwiegend KI-generiert" lässt sich technisch nicht sauber messen.

Debian: noch offen

Bei Debian läuft der Prozess anders. Dort steht eine General Resolution zur Abstimmung, und auf dem Wahlzettel stehen vier konkurrierende Anträge. Die Diskussionsphase hat am 24. Juli begonnen und dauert mindestens zwei Wochen, danach wird per Präferenzwahl entschieden. Ein Ergebnis gibt es also noch nicht.

Antrag	Eingebracht von	Kern
A	Matthias Geiger	Vollständiges Verbot LLM-gestützter Beiträge in Paketen, offizieller Debian-Software, Dokumentation, Übersetzungen und Web-Inhalten
B	Lucas Nussbaum	Erlaubt unter sechs Bedingungen, darunter Lizenzverträglichkeit der Werkzeuge, Verantwortung beim Beitragenden, Offenlegung und vorherige Absprache bei automatisierten Massenänderungen
C	Ian Jackson	LLM-Einsatz unerwünscht, soweit praktikabel. Menschengerichtete Kommunikation ohne KI, Offenlegungspflicht, Verstöße als Sache des Code of Conduct
D	Pierre-Elliott Bécue	Angenommen für Debian-eigene Projekte, unter Bedingungen: DFSG-Konformität, Verständnis und Verantwortung des Beitragenden, Kennzeichnung in der Commit-Message, keine Cloud-KI mit sensiblen Daten

Antrag A begründet das Verbot mit vier Punkten: unklarer urheberrechtlicher Status der Ausgaben, Qualitätsprobleme in einer auf Stabilität ausgelegten Distribution, Belastung der Reviewer und fehlender Kompetenzaufbau bei neuen Beitragenden, und schließlich das aggressive Crawling der KI-Anbieter, das die Debian-Infrastruktur gestört hat.

Bemerkenswert ist, was die Anträge trotz aller Gegensätze teilen. B, C und D verlangen alle drei eine Offenlegung. Uneinig ist man sich über das Ob, nicht über die Frage, ob Transparenz nötig ist.

Die eine Sache, die sofort nutzbar ist

Antrag B schlägt einen Mechanismus vor, der unabhängig vom Abstimmungsergebnis funktioniert und den jedes Team heute übernehmen kann: Git-Trailer in der Commit-Message.

Assisted-By: Claude Opus 5
Generated-By: GitHub Copilot

Das ist dieselbe Mechanik wie Signed-off-by oder Co-authored-by, also nichts Neues im Werkzeugkasten. Der Unterschied zwischen den beiden Trailern ist die Beteiligungstiefe: assistiert heißt, ein Mensch hat geschrieben und ein Werkzeug geholfen. Generiert heißt, das Werkzeug hat geschrieben und ein Mensch hat geprüft.

Der praktische Nutzen liegt weniger in der Moral als in der Nachvollziehbarkeit. Wenn in einem halben Jahr auffällt, dass ein bestimmtes Muster reihenweise Fehler produziert hat, ist die Frage "welche Commits sind so entstanden" mit einem git log --grep beantwortet statt mit Rätselraten.

Worum es wirklich geht

Beide Debatten werden schnell als Anti-KI-Bewegung gelesen. Das trifft nicht zu, und der Blick auf die Begründungen zeigt warum.

Codeberg argumentiert mit Infrastrukturlast und Ressourcenverbrauch, Debian mit Reviewer-Belastung und Lizenzherkunft. Keine der beiden Organisationen behauptet, KI-gestützter Code sei grundsätzlich schlecht. Was beide adressieren, ist ein Verhältnis, das aus dem Gleichgewicht geraten ist: Beiträge lassen sich in Minuten erzeugen, aber die Prüfung kostet weiterhin Stunden menschlicher Aufmerksamkeit. Wer massenhaft einreicht, verschiebt Aufwand auf Leute, die dafür nicht bezahlt werden.

Das ist kein neues Problem, es hat nur eine neue Größenordnung erreicht. Und es ist dasselbe Problem, das in Firmen auftaucht, sobald ein Team anfängt, Pull Requests schneller zu produzieren, als das Review sie aufnehmen kann. Wir haben das in KI-Code: Fast richtig reicht nicht aus der Qualitätsperspektive beschrieben. Debian und Codeberg beschreiben dieselbe Sache aus der Kapazitätsperspektive.

Was Teams jetzt mitnehmen

Einordnung

Was bei Debian herauskommt, ist offen, und die vier Anträge decken das gesamte Spektrum ab. Wahrscheinlich ist ein Ergebnis in der Mitte, weil Präferenzwahl Extreme selten belohnt. Das Verbot aus Antrag A hat ein praktisches Problem, das die Antragsteller selbst kennen: Es ließe sich kaum überprüfen. Man kann einem Patch nicht ansehen, wie er entstanden ist, jedenfalls nicht zuverlässig.

Genau deshalb ist die Offenlegung der interessantere Teil dieser Debatte. Sie verlagert die Frage von der Kontrolle zur Ehrlichkeit, und das ist die einzige Variante, die ohne Erkennungstechnik funktioniert, die es nicht gibt.

Für Teams im DACH-Raum ist die Nachricht damit weniger dramatisch, als die Schlagzeilen nahelegen. Niemand verbietet hier Werkzeuge. Zwei Projekte haben festgestellt, dass Beitragen und Prüfen auseinandergelaufen sind, und ziehen daraus Konsequenzen. Wer die eigenen Review-Kapazitäten schon einmal an einer Woche mit zu vielen Pull Requests gemessen hat, kennt das Gefühl.