Debian erlaubt KI-Code, Offenlegung freiwillig

Debian hat abgestimmt. Seit dem 29. August, 00:01 UTC, liegt das Ergebnis der General Resolution zum LLM-Einsatz vor, und es lautet: erlaubt. Gewonnen hat Antrag E, auf dem Wahlzettel Option 5, eingebracht vom deutschen Debian Developer Marc Haber unter dem Titel "Responsible Use of Generative AI". Er war am Ende die einzige Option in der Schwartz-Menge, also der einzige Vorschlag, der alle anderen im Paarvergleich schlägt.

Wir hatten die Debatte Ende Juli beschrieben, damals mit vier Anträgen und offenem Ausgang. Am Ende standen acht auf dem Zettel, plus "None of the above".

Was jetzt gilt

Knapp zwei Seiten lang ist der Beschlusstext. Für die Praxis sind davon fünf Punkte relevant:

Am schärfsten formuliert ist der Satz zur Verantwortung: "Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices." Blindes Übernehmen ohne Prüfung ist also nicht bloß unerwünscht, sondern laut Beschluss unvereinbar mit der Arbeitsweise des Projekts.

Bemerkenswert ist auch, was der Text bewusst offenlässt. Zum Urheberrecht schreibt Debian, dass der rechtliche Status KI-erzeugter Ausgaben in vielen Rechtsordnungen weiter diskutiert wird, und dass diese General Resolution die offenen Fragen ausdrücklich nicht klärt. Stattdessen verlässt sich das Projekt auf das Urteil der einzelnen Beitragenden, die abschätzen sollen, ob sie die Herkunft ihres Materials rechtlich begründen können. Das ist ehrlich und unbequem zugleich: Die Frage, die Antrag A als Verbotsgrund angeführt hatte, wird an die Einzelperson weitergereicht.

Die Verlierer sind die eigentliche Nachricht

Wer nur die Überschrift liest, hält das für einen knappen Sieg der KI-Befürworter. Aus der Auszählung liest sich das anders. Sie besteht aus Paarvergleichen, jede Zeile zählt, wie viele Stimmzettel Option X über Option Y gesetzt haben:

Die beiden strikten Verbotsanträge haben es nicht einmal an "None of the above" vorbei geschafft. Sie wurden nach den Debian-Regeln wegen verfehlter Mehrheit aussortiert, bevor die eigentliche Rangfolge überhaupt berechnet wurde. Ein Verbot war also nicht knapp unterlegen. Eine deutliche Mehrheit der abstimmenden Developer fand es schlechter als gar keinen Beschluss.

Eng war das Feld trotzdem, aber in der Mitte. Zwischen Option 2 und Option 6 lagen im direkten Vergleich fünf Stimmen. Gestritten wurde am Ende über den Formalismus, nicht mehr über die Erlaubnis selbst.

Der Absatz, den auch Firmen brauchen können

Außerhalb von Debian steckt der brauchbarste Teil des Beschlusses im Absatz zu vertraulichen Daten. Er benennt konkret, was nicht an Dritt-KI-Dienste gehen darf: vertrauliche Informationen, private Kommunikation, sicherheitsrelevante Informationen wie noch nicht veröffentlichte Angaben zu Sicherheitslücken, kryptografische Schlüssel, Zugangsdaten und sonstiges nicht-öffentliches Material zum Projekt, seiner Infrastruktur und seiner Community. Ausnahme nur bei ausdrücklicher Freigabe.

Am häufigsten fehlt dabei der Punkt mit den embargierten Sicherheitsinformationen. Wer eine noch nicht veröffentlichte Lücke in einen Cloud-Chat kippt, um sich beim Patch helfen zu lassen, hat das Embargo praktisch aufgehoben, unabhängig davon, was in den Nutzungsbedingungen des Anbieters steht. Wie schnell so ein Zeitfenster heute schließt, haben wir an einem OCaml-Maintainer beschrieben, dessen Security-PR nach zehn Minuten gescannt war.

Übertragbar ist auch der Absatz zu Massenaktionen. Wer breit angelegte Änderungen fährt, also Massen-Bugreports, großflächige Codeänderungen oder automatisierte Anfragen über viele Pakete hinweg, soll das vorher abstimmen, und der Prozess braucht einen Menschen, der für Verhalten und Ergebnis geradesteht. Das ist genau die Regel, die in Firmen fehlt, sobald jemand einen Agenten über ein Monorepo laufen lässt.

Nicht alle sehen das so

Debian ist mit dieser Linie nicht repräsentativ, und das gehört zur Einordnung dazu. Otto Kekäläinen hat einen Tag vor dem Ergebnis eine Bestandsaufnahme veröffentlicht und kommt auf 37 von 120 untersuchten Projekten mit einem vollständigen KI-Verbot. Er nennt namentlich GCC, QEMU, SDL, Gentoo, Zig und Ghostty, dazu Codeberg, Sourcehut und Flathub auf Plattformseite. Der Linux-Kernel verlangt stattdessen eine Kennzeichnung.

Erhoben hat er das selbst, die Methodik legt er nicht offen, die Zahl ist also eine Autorenangabe und keine Studie. Die Richtung deckt sich aber mit dem, was wir seit Juli beobachten: Die großen, formal organisierten Projekte mit gewählten Gremien entscheiden sich für Verantwortung statt Verbot, kleinere Projekte und Hosting-Plattformen ziehen eher die Reißleine.

Für Beitragende heißt das leider: Es gibt keine allgemeine Regel, die man einmal lernt. Ein Patch, der bei Debian sauber durchgeht, kann bei QEMU regelwidrig sein.

Was Teams jetzt mitnehmen

Einordnung

Der Beschluss löst kein einziges der Probleme, die in der Debatte genannt wurden. Beim Urheberrecht bleibt alles offen, weil Debian es ausdrücklich offenlässt. An der Reviewer-Belastung ändert sich nichts, weil eine Erlaubnis das Einreichvolumen eher erhöht als senkt. Und die Offenlegung bleibt freiwillig, weil eine Pflicht nicht überprüfbar wäre.

Was der Beschluss stattdessen tut, ist eine Zuständigkeit festzulegen. Er sagt nicht, welche Werkzeuge gut sind. Er benennt, wer geradesteht, wenn etwas schiefgeht. Für ein Projekt, das von Freiwilligen getragen wird und keine Erkennungstechnik hat, ist das vermutlich die einzige Regel, die sich überhaupt durchhalten lässt.

Interessanter als der Sieg von Option 5 ist deshalb die Deutlichkeit, mit der die Verbote gescheitert sind. Vor einem Jahr wäre das Ergebnis wahrscheinlich anders ausgefallen. Nicht weil die Argumente gegen KI-Beiträge schwächer geworden wären, sondern weil inzwischen zu viele Developer selbst mit diesen Werkzeugen arbeiten. Ein Verbot hätte sich gegen die eigene Praxis der Abstimmenden gerichtet, und das gewinnt selten eine Wahl.