// LINUXNEWS.DE — LINUX & OPEN SOURCE
KDE und GNOME diskutieren unterschiedliche Ansätze zur LLM-Nutzung
Der Umgang mit KI-generiertem Code führt zunehmend zu erhitzten Diskussionen und Spaltung bei freien Softwareprojekten. Zuletzt gab es derartige Zerwürfnisse bei der Einführung von systemd. Nachdem in den vergangenen Monaten bereits Projekte wie der Kernel, Fedora und Jellyfin Regeln für Beiträge mit Large Language Models (LLMs) formuliert haben, wird derzeit auch innerhalb von KDE über entsprechende Richtlinien diskutiert. Ein Vorschlag des KDE-Entwicklers Nate Graham hat nun eine deutlich restriktivere Gegenposition aus dem GNOME-Umfeld hervorgerufen.
Grahams Entwurf entstand ursprünglich aus einer Diskussion über vollständig von LLMs erzeugte Merge Requests. Als Grundprinzip schlägt er für KDE einen »Human in the Loop«-Ansatz vor: LLMs sollen grundsätzlich eingesetzt werden dürfen, solange der Mensch weiterhin eigene Entscheidungen trifft, die erzeugten Ergebnisse versteht und für sie verantwortlich bleibt. Graham fasst die Grundregel mit »Don’t be lazy« zusammen. LLMs sollen weder das eigene Urteilsvermögen noch zwischenmenschliche Kommunikation oder den eigenen Lernprozess ersetzen.
Besonders deutlich wird der Vorschlag bei Programmcode. Beiträge sollen nicht einfach per Prompt erzeugt und anschließend ungeprüft eingereicht werden. Graham spricht sich unter anderem gegen Vibe Coding aus, bei dem Entwickler Änderungen einreichen, die sie selbst nicht verstehen oder nicht selbst umsetzen könnten. Ebenso sollen keine von einem LLM erzeugten Rohfassungen mit der Erwartung eingereicht werden, dass die Maintainer daraus anschließend funktionierenden Code machen.
Noch restriktiver fällt der Entwurf bei Texten aus. Commit-Meldungen, Merge-Request-Beschreibungen oder Antworten auf Kommentare sollen grundsätzlich von den Beteiligten selbst geschrieben werden. Als ausdrücklich akzeptierte Ausnahme nennt der Vorschlag die maschinelle Übersetzung eigener Texte ins Englische, solange dabei Stil und Aussage nicht verändert werden. Bei der Fehlersuche oder Recherche können LLMs dagegen als Hilfsmittel dienen, sofern der Nutzer ihre Ergebnisse anschließend selbst überprüft.
Für Diskussionen sorgte unter anderem die Formulierung, dass andere KDE-Mitglieder im Idealfall gar nicht erkennen sollten, ob ein LLM eingesetzt wurde. Das heißt nicht, dass dessen Einsatz verborgen werden müsse, sondern weil das Ergebnis nicht von selbst erstellter Arbeit zu unterscheiden sein sollte. Graham spricht sich zudem gegen Angaben wie Assisted-by in Commits aus, wie es in ähnlicher Form beim Kernel praktiziert wird. Solche Hinweise seien letztlich kostenlose Werbung für den jeweiligen Anbieter.
Der Vorschlag ist bislang keine offizielle KDE‑Richtlinie. Die Diskussion auf KDE Invent wurde nach teils heftigen Auseinandersetzungen am 21. September zunächst geschlossen. Graham hatte eine Pause vorgeschlagen, nachdem sich die Debatte zunehmend auch um grundsätzliche Fragen zu KI, Transparenz und Nachhaltigkeit drehte.
Jordan Petridis aus dem GNOME-Umfeld reagierte am 23. September mit einem eigenen Entwurf unter dem Titel »The GNOME LLM Policy That I Want«. Er hält bereits die Zielsetzung vieler bisheriger LLM-Richtlinien für falsch. Statt detailliert einzelne erlaubte und unerlaubte Arbeitsabläufe zu definieren, sollten solche Regeln seiner Ansicht nach vor allem soziale Normen für ein Projekt festlegen und deutlich machen, welches Verhalten die Gemeinschaft akzeptiert.
Sein Vorschlag fällt entsprechend deutlich kürzer und wesentlich restriktiver aus: LLMs dürften demnach weder zur Erstellung noch zur Veränderung von Code verwendet werden, der bei GNOME eingereicht oder auf der GNOME-Infrastruktur gehostet wird. Von Entwicklern könnte verlangt werden, nachvollziehbar zu machen, dass ihr Code diese Voraussetzung erfüllt. Versuche, eine solche Regel gezielt zu umgehen, könnten zum Ausschluss aus dem Projekt führen.
Als mögliche Kriterien nennt Petridis unter anderem, dass Entwickler ihre Änderungen selbst erklären und begründen können müssen, das jeweilig