Debian diskutiert Regeln für KI/LLM‑Beiträge.
In Kürze
- Vier Optionen: Verbot bis zulässige Nutzung
- Rechts-, Qualitäts- und Community‑Risiken prägen die Debatte
- Abstimmung aller Debian‑Entwickler nach zweiwöchiger Diskussion
Debian diskutiert: Wie geht das Projekt mit Beiträgen um, die mit großen Sprachmodellen (LLM) oder anderer generativer KI erstellt wurden?
Seit dem 24. Juli 2026 debattiert die Debian‑Community intensiv über eine Frage, die in vielen Open‑Source‑Projekten jetzt ansteht: Sollen Beiträge, die ganz oder teilweise mit LLMs produziert wurden, akzeptiert werden — und wenn ja, unter welchen Bedingungen? Auf dem Tisch liegen vier Gegenvorschläge, die von einem kompletten Verbot bis zu einer pragmatischen Zulassung reichen. Nach mindestens zwei Wochen Diskussion folgt eine Abstimmung aller aktiven Debian‑Entwickler per signierter E‑Mail mit Präferenzwahl.
Kurz zur Vorgeschichte
Die Auseinandersetzung ist kein Neuland: Bereits 2024 fand eine ausführliche Debatte auf der Mailingliste statt. Ein Versuch, 2025 eine Generalresolution zu verabschieden, scheiterte und wurde zurückgezogen. Anfang 2026 wurden Vorbereitungen für eine Resolution mit dem Titel „Allow AI‑Assisted Contributions“ getroffen; das Projekt entschied sich damals, vorerst weiter fallweise mit KI‑Beiträgen umzugehen. Nun liegen vier konkrete Vorschläge (A–D) zur Abstimmung vor.
Die vier Vorschläge im Überblick
Proposal A — Vollständiges Verbot (Matthias Geiger)
- Fordert ein ausdrückliches Verbot aller Beiträge, die mithilfe von LLMs oder generativer KI erzeugt wurden.
- Gilt für Debian‑Quellpakete, projekteigene Tools (etwa Lintian), Dokumentation, Übersetzungen und offizielle Kommunikation. Ausgenommen bleiben Upstream‑Projekte, KI‑Software selbst und Upstream‑Patches.
- Begründung: Risiken durch „Halluzinationen“ (falsche oder erfundene Informationen), vermischte Praktiken, rechtliche und lizenzielle Unsicherheit, Gefährdung des Lernprozesses neuer Mitarbeitender sowie ethische Fragen.
- Soll als neuer Punkt in der Debian‑Satzung verankert werden; die Autoren räumen ein, dass Durchsetzung schwierig ist und stark auf Goodwill der Community setzt.
Proposal B — Pragmatische Zulassung mit Bedingungen (Lucas Nussbaum)
- Erlaubt KI‑assistierte Beiträge unter sechs Bedingungen, unter anderem: Kompatible Nutzungsbedingungen des KI‑Dienstes, geklärte Lizenz‑ und Urheberfragen für KI‑erzeugten Code und volle Verantwortung der Beitragenden für Qualität und Lizenzkonformität.
- Signifikant KI‑erzeugte Inhalte sollen offengelegt werden, etwa per Git‑Trailer wie Generated‑By: oder Assisted‑By:.
- Statt Satzungsänderung schlägt der Entwurf eine veröffentlichte Erklärung nach der Debian‑Verfassung vor, die flexibler anpassbar ist. Ziel ist, Bedenken zu berücksichtigen, ohne nützliche Werkzeuge grundsätzlich zu verbieten.
Proposal C — Ablehnung „sofern praktikabel“ + strenger CoC‑Ansatz (Ian Jackson)
- Lehnen LLM‑Nutzung grundsätzlich ab, soweit praktikabel — mit Argumenten wie Untergrabung von Community‑Mechanismen, Umweltkosten, problematischem Scraping und Verbreitung falscher Informationen.
- Erkennt an, dass ein Totalverbot praktisch schwierig sein kann; fordert deshalb, LLM‑Nutzung so weit wie möglich zu vermeiden und dies verbindlich im Code of Conduct (CoC) festzuschreiben.
- Kernregeln: Alle Nachrichten an Menschen (Bugreports, Mailinglisten‑Beiträge, Blogposts) sollen ohne LLM‑Hilfe verfasst sein; jede KI‑Nutzung muss offengelegt werden; Teams dürfen LLM‑Beiträge komplett verbieten; Verstöße gelten als CoC‑Verstöße.
- Für Nicht‑Englisch‑Sprechende sieht der Vorschlag vor, Beiträge in der Muttersprache zu erlauben und Lesende zu ermutigen, Übersetzungstools zu nutzen.
Proposal D — Pragmatische Akzeptanz mit Vorgaben
- Debian soll generative KI nicht aktiv empfehlen, aber anerkennen, dass Nutzung verbreitet ist und ein Verbot kaum durchsetzbar wäre.
- KI‑Beiträge sind akzeptabel, wenn sie den Debian Free Software Guidelines (DFSG) entsprechen und als KI‑unterstützt kenntlich gemacht werden.
- Beitragende tragen die volle Verantwortung, müssen KI‑Output verstehen und verteidigen können; Inhalte sollen eigenhändig über Debian‑Infrastruktur hochgeladen werden. Cloudbasierte KI‑Dienste für sensible Inhalte sollen verboten werden. Upstream‑Projekte bleiben ausgenommen.
Wesentliche Streitpunkte in der Debatte
- Rechts- und Lizenzfragen: Wer besitzt Rechte an KI‑generiertem Code, wie wirken sich KI‑modell‑lizenzierte Trainingsdaten auf Debian‑Lizenzen aus?
- Qualität und Korrektheit: „Halluzinationen“ von LLMs und ungeeignete Vorschläge könnten Paketqualität und Sicherheit gefährden.
- Community‑Lernen: Befürchtet wird, dass weniger direkte menschliche Beteiligung Lernchancen und Wissenstransfer reduziert.
- Operative Folgen: „AI slop“ — eine Flut unbrauchbarer Beiträge oder Bugreports — sowie Scraping, das Ressourcen bindet.
- Ökologische und ethische Fragen: Trainingsdaten, Datennutzung und die Umweltkosten großer Modelle stehen ebenfalls auf der Agenda.
- Gegensicht: Andere sehen Chancen, etwa bessere Übersetzungen, verbesserte Usability oder niedrigere Einstiegshürden — Beispiele wie Fedora zeigen, dass einige Projekte aktiv an KI‑Integration arbeiten.
Wie andere Open‑Source‑Projekte damit umgehen
Einige Projekte haben bereits Regeln erarbeitet: Gentoo, GNOME und Codeberg besitzen Richtlinien; FreeBSD lehnt LLM‑generierten Quellcode klar ab, vor allem aus Lizenzgründen. Fedora arbeitet hingegen aktiv an KI‑Optimierungen, etwa für Desktop‑Features mit lokalen KI‑Stacks.
Was als Nächstes passiert
Die Mailinglisten‑Debatte läuft mindestens zwei Wochen. Danach beginnt die Abstimmungsphase: Alle gültigen Debian‑Entwicklerinnen und Entwickler entscheiden per signierter E‑Mail‑Stimme in einer Präferenzwahl über einen der vier Vorschläge. Das Ergebnis wird zeigen, welchen Weg Debian formal vorgibt — von strikter Ablehnung bis zu regulierter Akzeptanz.
Quellen
- Quelle: Debian-Projekt
- Der ursprüngliche Artikel wurde hier veröffentlicht
- Dieser Artikel wurde im Podcast KI-Briefing-Daily behandelt. Die Folge kannst du hier anhören.
