GNOME's Jordan Petridis Wants an Outright LLM Ban

GNOME contributor Jordan Petridis wants a rule that reads, in full: "LLMs ('AI') can not be used to create or modify anything submitted to GNOME, or hosted on GNOME infrastructure." He published the proposal on his own blog on Sept. 23, framing it explicitly as his personal opinion rather than adopted GNOME policy, three days after a far milder KDE attempt at the same idea was pulled down entirely.

Petridis, a member of GNOME's Release Team, backs the ban with five specific expectations for contributors: they must be able to personally reason through and explain their own changes, demonstrate they understand the problem they are fixing, address root causes rather than symptoms, respect the time of the people reviewing their work, and never use a chatbot or agent to impersonate themselves in a discussion. He describes the point as social signaling rather than strict enforcement, writing that the rule "makes it explicit that we do not welcome these careless submissions." His post also waves off comparable policies at other projects as missing the point, without naming which ones, while pointing to Debian's own 2026 vote as the closest precedent he considers worth following.

That framing matters because Petridis is not GNOME's release manager or a Foundation board member acting in an official capacity; he is one contributor publishing a personal blog post, the same format Graham used for his own account of KDE's collapse. Neither project has a standing mechanism for turning a popular blog post into binding policy, which is itself part of why KDE's attempt spent five weeks in drafts, workshops and a locked discussion thread without landing anywhere.

What sank KDE's version three days earlier

Nate Graham, chief executive of Techpaladin Software and a longtime KDE Plasma contributor, opened a discussion thread titled "Proposed KDE LLM guidelines" on Sept. 19, according to GamingOnLinux. Its core line asked contributors not to be lazy: submissions with "obvious and lazy LLM usage may be ignored or closed," while output indistinguishable from a careful human's work would pass without comment. The thread drew 37 comments before Graham closed it on Sept. 21, after objections shifted from wording toward the ethics and environmental cost of LLMs generally.

That was already Graham's second attempt, he wrote in his own follow-up post. His first draft, written weeks earlier after a KDE developer flagged a wave of AI-generated merge requests, had gotten a positive reception. Between the two drafts, KDE accepted a conference talk pitching "a lovable, sovereign, AI-native KDE" for Akademy 2026, and both the talk and a related workshop landed badly with attendees. When Graham reopened the guidelines discussion afterward on KDE's Gitlab instance, people from outside the project piled in, someone was doxxed, both the person who did it and the person targeted were banned, and a pressure site called kdeforpeople.com sprang up demanding a total ban. "A bunch of people mostly outside of KDE who disapprove of LLM usage derailed KDE's attempt to add restrictions," Graham wrote. The draft was deleted and the whole thread hidden.

Project	Rule as proposed	Status as of Sept. 24
GNOME	Flat ban on any LLM-authored or LLM-modified contribution	Personal post by Jordan Petridis; not put to a vote
KDE	Restrict "obvious and lazy" LLM use, not the method itself	Draft deleted Sept. 21, thread hidden
Debian	A vote on a similar contribution policy, per Petridis's post	Vote referenced; outcome not yet published

The same problem, two incompatible fixes

The two projects read the same year of AI-assisted drive-by contributions and drew opposite lessons. Graham's draft tried to describe quality rather than method: a human who quietly used an LLM to write good code would never be flagged, and the rule existed only to give maintainers cover to close obviously careless submissions. That nuance is exactly what a public comment thread turned into a referendum on AI's environmental footprint instead. Petridis's flat ban removes the nuance Graham was defending, at the cost of also blocking the careful, invisible use his draft would have let through.

Whether that trade is worth it depends on which failure mode a project fears more: Graham's approach risks looking permissive to anyone who wants a bright line, while Petridis's risks being unenforceable, since a maintainer cannot reliably tell a human-written patch from an LLM-assisted one after the fact. Petridis's post does not propose a detection mechanism; it relies entirely on contributors disclosing their own tool use honestly, which is the same trust assumption Graham's draft made, and the same assumption that OpenClaw's maintainers have said leaves their own project's security review perpetually behind its growth. Neither GNOME nor KDE pays contributors to police the difference; both rely on volunteers, the same structural gap a donor-funded maintainer's first year at Servo was meant to address for a narrower problem.

What would show either project got it right

Petridis's post points to Debian, which he says is running its own 2026 vote on a similar policy, as evidence the argument is not confined to two desktop projects. He does not say when GNOME's own proposal might move from a personal blog post to something the Foundation board actually votes on, and as of Sept. 24 no such vote has been scheduled. KDE's experience suggests the harder test is not the wording of either policy but whether either community can hold a public debate about it without an outside pile-on forcing the whole page down again.