Einige Debian-Entwickler haben eine General Resolution (GR) angestrebt, um die Nutzung von Large Language Models (LLM) in Debian zu regeln.
Kaum ein Thema spaltet die Free-Software-Community derzeit so sehr wie der Einsatz von Sprachmodellen (LLM) bei der eigenen Arbeit, und bei Debian schwelt die Debatte schon länger. Bereits im April 2025 hatten wir über einen ersten Anlauf zu einer General Resolution (GR) berichtet, der unter dem Titel »Interpretation of DFSG on Artificial Intelligence (AI) Models« mehrere konkurrierende Vorschläge zur DFSG-Konformität von KI-Modellen zur Diskussion stellte. Dieser erste Versuch wurde wegen weiterem Diskussionsbedarf am Ende zurückgezogen, ohne dass es zu einer Abstimmung kam. Bereits seit März laufen die Vorbereitungen für einen zweiten Anlauf.
Zweiter Anlauf
Jetzt startet Debian diesen neuen Anlauf: Am 24. Juli 2026 begann die Diskussionsphase zu einer GR mit dem schlichten Titel LLM usage in Debian. Anders als beim ersten Versuch geht es dieses Mal nicht primär um die Frage, ob KI-Modelle selbst DFSG-konform sein können, sondern darum, ob und wie Debian-Mitwirkende LLM bei ihrer eigenen Arbeit einsetzen dürfen. Zur Abstimmung stehen vier unterschiedliche Vorschläge, die zeigen, wie tief die Gräben im Projekt inzwischen verlaufen.
Vorschlag A: Klares Verbot
Der von Matthias Geiger eingebrachte und von acht weiteren Debian-Entwicklern unterstützte Vorschlag will LLM-unterstützte Beiträge komplett aus Debian verbannen. Betroffen wären Quellpakete, projekteigene Software wie Lintian, Webressourcen, Dokumentation, Übersetzungen und die offizielle Kommunikation. Ausdrücklich ausgenommen bleiben Upstream-Projekte, KI-bezogene Software selbst sowie Patches von Upstream.
Begründung
Die Begründung listet vier Problemfelder auf: Erstens die ungeklärte urheberrechtliche Lage von LLM-generierten Inhalten, die mit den strengen DFSG-Vorgaben zur Lizenzklarheit kollidiere. Zweitens Qualitätsmängel, insbesondere bei der Paketierung, wo LLM laut den Autoren häufig veraltete Praktiken mischen oder erfundene Copyright-Angaben erzeugen. Drittens die Sorge um die Community: Neue Mitwirkende, die auf LLM setzen, würden die Reviewer überlasten und selbst nichts über Debians Prozesse lernen, sodass sie ausgebrannte Maintainer langfristig nicht ersetzen könnten. Viertens werden ethische Bedenken gegenüber KI-Firmen angeführt, die durch aggressives Scraping faktisch wie ein dauerhafter DDoS-Angriff auf Debians Infrastruktur wirken und dazu geführt hätten, dass Teile der Infrastruktur zeitweise nicht erreichbar waren und Schutzmechanismen nötig wurden.
Konkret soll der Social Contract um einen neuen Punkt 6 ergänzt werden, der direkte LLM-Beiträge ausdrücklich untersagt. Die Autoren räumen selbst ein, dass die Durchsetzung eines solchen Verbots schwierig sein dürfte, verstehen den Vorschlag aber vor allem als Selbstverpflichtung der Gemeinschaft.
Vorschlag B: Erlauben mit klaren Richtlinien
Der ehemalige Debian-Projektleiter Lucas Nussbaum und neun weitere Unterstützer schlagen den Gegenentwurf vor: KI-unterstützte Beiträge sollen grundsätzlich erlaubt bleiben, allerdings unter strengen Bedingungen. Mitwirkende müssen sicherstellen, dass die Nutzungsbedingungen des jeweiligen KI-Tools nicht mit einer Weitergabe unter freien Lizenzen kollidieren, und prüfen, ob im generierten Output fremde urheberrechtlich geschützte Inhalte stecken. Sie tragen die volle Verantwortung für ihre Beiträge, müssen den Einsatz eines Tools bei substanzieller Nutzung offenlegen (etwa per Git-Trailer wie Generated-By:), größere automatisierte Änderungen vorab diskutieren und dürfen keine KI-Tools verwenden, die vertrauliche Projektdaten wie unter Embargo stehende Sicherheitsmeldungen an nicht vertrauenswürdige Anbieter übertragen.
Der Vorschlag ist als Grundsatzerklärung nach Verfassungsabschnitt 4.1(5) formuliert, die sich mit der Zeit auch ohne neue GR weiterentwickeln kann. Die Begründung erkennt sowohl die Vorteile als auch die Risiken von KI-Werkzeugen an und verweist darauf, dass viele Debian-Mitwirkende sie bereits produktiv einsetzen.
Vorschlag C: Ablehnung, soweit praktikabel
Ian Jackson und sieben weitere Unterstützer positionieren sich zwischen den beiden Polen. Ihr Vorschlag beschreibt LLM als Ursache zahlreicher Probleme, von Umweltschäden über die Untergrabung der Community-Bildung bis zu Verzerrungen des Hardwaremarkts, hält ein vollständiges Verbot angesichts der Realität vieler Upstream-Projekte aber für derzeit nicht durchsetzbar.
Stattdessen kombiniert der Text Bitten mit verbindlichen Regeln. Man bittet alle Mitwirkenden, auf LLM zu verzichten, Entscheidungsträger im Projekt, deren Einsatz möglichst zu entmutigen, und ruft auch außerhalb von Debian zur Zurückhaltung auf. Verbindlich wird es als Ergänzung zum Code of Conduct: Nachrichten an Menschen, etwa Bugreports, Mailinglisten-Beiträge oder Blogposts auf Planet Debian, müssen ausschließlich von Menschen ohne LLM-Unterstützung verfasst werden. Jede Nutzung von LLM für Debian-Arbeit muss offengelegt werden, einzelne Projekte und Maintainer dürfen KI-Beiträge komplett untersagen, und solche Verbote (auch von Upstream) sind zu respektieren. Verstöße sollen als Verletzung des Code of Conduct behandelt werden. Eine bemerkenswerte Ausnahme: Wer sich auf Englisch ohne Hilfsmittel nicht sicher genug fühlt, darf in seiner Muttersprache schreiben und darauf vertrauen, dass Leser eigene Übersetzungswerkzeuge nutzen, ganz ohne Häme für sprachliche Fehler.
Vorschlag D: Erlauben, aber mit Verantwortung
Der vierte Vorschlag stammt von Pierre-Elliott Bécue. Er nimmt eine Position zwischen striktem Verbot und offener Erlaubnis ein: Debian empfiehlt oder befürwortet die Nutzung generativer KI-Assistenten für die Softwareentwicklung nicht, weil das Thema berechtigte Fragen zu Ethik, Rechtslage und Urheberrecht aufwirft. Gleichzeitig erkennt der Vorschlag an, dass solche Werkzeuge längst im Einsatz sind und sich nicht mehr wegdenken lassen. Statt eines nach Ansicht der Autoren kontraproduktiven und ohnehin nicht durchsetzbaren Verbots verlagert der Text die Verantwortung auf die einzelnen Mitwirkenden.
Wer einreicht, trägt die Verantwortung
Die Regeln gelten ausdrücklich nur für Arbeiten, die direkt für das Debian-Projekt entstehen, wie Pakete, Webseiten, Anwendungen und Ressourcen. Das gilt nicht für Upstream-Arbeit. Jede KI-unterstützte Arbeit muss den Debian Free Software Guide (DFSG) einhalten. Wer etwas einreicht, trägt dafür allein die Verantwortung: Er oder sie muss den eigenen Beitrag ausreichend verstanden haben und ihn erklären und verteidigen können. Alles, was am Ende produktiv in Debians Infrastruktur landet, muss ausdrücklich von der einreichenden Person selbst freigegeben worden sein. KI-unterstützte Arbeit soll an geeigneter Stelle gekennzeichnet werden, etwa in Commit-Nachrichten oder im Changelog, wobei der Vorschlag einräumt, dass leichtgewichtige Werkzeuge wie die Tab-Vervollständigung in Copilot oft unbemerkt zum Einsatz kommen und die Kennzeichnungspflicht im Zweifel eher großzügig ausgelegt werden soll. Und wie schon bei Vorschlag B gilt: Cloud-basierte KI-Dienste dürfen nicht verwendet werden, wenn dabei sensible oder nicht-öffentliche Projektdaten übertragen würden, etwa Sicherheitsberichte unter Embargo oder interne debian-private-Diskussionen.
Wie geht es weiter?
Die Diskussionsphase läuft seit dem 24. Juli 2026. Laut Debian-Verfassung dauert sie 2–3 Wochen, wobei der Projektleiter die Diskussionsphase um bis zu eine Woche verlängern kann. Nach dem Ende der Diskussionsphase folgt direkt das Abstimmungsverfahren, wobei zunächst die vom Projektsekretär vorbereiteten Wahlzettel an alle offiziellen Debian Developer (DD) verschickt werden. Der Wahlzettel enthält neben den zur Wahl stehenden Optionen immer auch die Option »Further Discussion«. Die Entwickler haben zwei Wochen Zeit, ihre Stimme per GPG-signierter E-Mail abzugeben.
Es ist bei diesem GR mit einer hohen Beteiligung zu rechnen. Wir werden die Diskussionsphase weiter verfolgen. Klar ist schon jetzt: Egal welcher Vorschlag am Ende gewinnt, die Entscheidung dürfte für viele kleinere Projekte, besonders bei den Debian-Derivaten, zum Leitfaden werden.
