KDE's "Don't Be Lazy" LLM Guidelines Hit a Wall Before the Ban Campaign Arrived
The petition makes sense only against the policy it answers. GamingOnLinux reports that the latest attempt was "Proposed KDE LLM guidelines" from Nate Graham that was opened for discussion on September 19th, which has now been closed as of September 21st after quite a lot of push-back on it, as Graham suggested they all take 24 hours to cool off. XDA Developers gave the same account: the discussion devolved into a community fight, ending with the thread creator locking it and asking everyone to take 24 hours to cool off.
The draft centred on one principle. According to GamingOnLinux, it read: "The golden rule for LLM usage in KDE is Don't be lazy: Don't try to use a tool to replace your own judgment, interpersonal communication, or learning process. Don't take unsustainable shortcuts. Don't avoid growing as a person. The result will be poor-quality work that eventually becomes someone else's problem."
That is a permissive framework with conditions attached. It assumes contributors will use LLMs and makes them answerable for what they submit. The Hungarian tech site LavX News, which covered the same thread, says Graham is a KDE Plasma developer and CEO of Techpaladin Software. It describes the core idea as treating AI as an aid, not as a substitute for judgment, communication or learning.
LavX says early objections were about wording and whether the draft told maintainers enough about handling AI-generated patches. The argument then widened to whether AI-assisted work belongs in KDE at all, with some participants pointing to the energy and hardware cost of training and running models. LavX also reports that disclosure was still unsettled when the thread closed: whether contributors must say they used an LLM, which parts of a patch came from a model, and whether they checked the output. It adds that KDE planned a second attempt at refining the policy.
What KDE for People Actually Demands for Plasma
The campaign's website states its position directly: "KDE Should place a ban on Generative AI in Plasma and Plasma Components." XDA reports that it came to wider attention when user DownHatter brought people's attention to KDE for People in a post on the r/kde subreddit.
The scope is wider than a code-contribution rule. The site says a ban should include outputs of Generative AI tools in code and assets, as well as using it for MR descriptions, issues or translation (e.g. the .po files). In KDE's workflow, MR descriptions are merge-request descriptions, the write-ups attached to proposed code changes. Issues are bug reports. The .po files are the gettext translation catalogues that localisers edit. Under the proposal, machine-generated text would be excluded at every point where outside contributors touch the project.
The campaign also goes past contributions. It says related community spaces should also be considered, to avoid Vibe-Coding, the introduction of AI topics into Akademy and KDE Planet and more normalization of this practice in the KDE Community. Vibe-coding means generating software mostly by prompting a model, with little human understanding of the result. Akademy is KDE's annual conference, and Planet KDE aggregates contributors' blogs. These are two different kinds of demand. One is a rule about what code and text KDE accepts. The other concerns what KDE's community forums discuss and promote, and it is the more contentious of the two.
The campaign admits a ban can't be enforced perfectly. It says the goal isn't about figuring out the exact percentage of AI in any given commit, things will slip through. The point, it says, is about signaling to the outside what kind of community KDE is. The site also suggests a ban need not be permanent.
Governance, Not Just Code, Is the Real Complaint
The strongest charge on the campaign's site concerns process more than technology. It argues that the proposed policy ignores many of the issues around human rights and many harms of this technology, pushing the responibility to the contributor without addressing their wider-reaching consequences, even outside of KDE Plasma. It goes further, saying the proposal to decide on this policy without wider community involvement works against the interest of the public on the issue and could be seen as malicious.
This complaint goes to the heart of the draft. A "Don't be lazy" rule makes each contributor responsible for their own conduct. The campaign's objection is that the harms it worries about, such as environmental cost, training-data provenance and effects on creative workers, don't go away because one contributor behaved well. A code-review rule can't address them.
The campaign also claims support from inside KDE. Its site says KDE Eco has already declared that a policy which allows for AI use within KDE is incompatible with KDE Eco goals and values. KDE Eco is the project's initiative on the environmental impact of software. That statement comes from the campaign itself; no other outlet has reported a KDE Eco declaration. LavX does connect the energy objections raised in the guidelines thread to KDE Eco's mission.
The campaign cites outside precedent too, saying other projects have shown the way: Zig, elementaryOS, OBS Studio and many more have taken a stance against AI. Those projects' actual policies have not been checked here. Readers should treat the list as the campaign's own framing of its allies.
Petition Support and a Visible Backlash Across Reddit and Lemmy
XDA reports that the KDE for People site has gathered a lot of signatures but also plenty of critics. It says the original r/kde thread had drawn neutral to negative views of the petition at the time of writing. The same argument is running on the fediverse, and the positions there show why a compromise is hard to find.
On a Lemmy thread titled with the claim that KDE is "actively proposing a Pro-AI contribution policy," one commenter pushed back: "I find the proposed policy very nuanced and generally useful. It's not banning LLM usage but still prohibiting mindless vibe-coded contributions." Another objected that the draft makes no distinction between self-hosted LLMs or Corportate LLMs, and disregards the dangers of using LLM code in FLOSS projects due to copyright concerns.
A third group sits between them. One commenter argued that a more effective principled stance would be to ban the use of specific "AI" tools that are proven to be abusive. Another noted that there are models trained on only licensed data, and it's possible to train and run models locally for the specific tasks that it is good for. A tool-specific or provenance-based rule is a genuine third option. Neither the draft guidelines nor the petition as reported takes it up.
One commenter on a mirror of that thread argued that KDE's approach tracks the Software Freedom Conservancy's published recommendations on LLM-backed generative AI in free software. According to the commenter, both are reflected in the SFC recommendations (point 5 on disclosure and point 3 on shunning). That is one reader's interpretation. It does suggest KDE's draft is closer to an existing reference point in free-software governance than the "pro-AI" label implies.
Some reactions show what is at stake in reputation terms. Users on the Lemmy thread said the draft had changed their minds about switching to a KDE-based distribution. Forum reactions are not a measure of KDE's user base, and a Reddit or Lemmy thread is not a poll of KDE contributors. Neither says anything reliable about how a formal decision would go.
Where the Middle Ground Sits in KDE's Next LLM Draft
Setting aside the heat of the threads, the two positions differ over one question: what a contribution policy is for.
| Question | Proposed KDE LLM guidelines (Sept. 19 draft) | KDE for People campaign |
|---|---|---|
| Is generative AI allowed in contributions? | Yes, as an aid under the "Don't be lazy" rule | No, for code, assets, MR descriptions, issues and translations |
| Who carries responsibility? | The individual contributor | The project, through a blanket rule |
| Is enforcement expected to be perfect? | Relies on review and contributor judgment | Openly concedes "things will slip through" |
| Community spaces (Akademy, Planet KDE) | Not addressed in reporting on the draft | Wants AI topics and vibe-coding kept out |
| Disclosure of AI use | Unsettled when the thread closed, per LavX | Moot under a ban |
| Status | Draft under revision | Advocacy petition |
The draft treats AI as a quality and review problem: whether a contributor can explain, test and maintain what they submit. The campaign treats it as an ethical one, and sees accepting any generated output as a statement about what KDE stands for. A rule can satisfy both only if it separates those issues. One way would be firm review requirements for all submissions, combined with a disclosure rule and possibly limits on particular tool classes. LavX's reporting points the same way. It says the next revision has to address both how contributors should use LLMs and whether some AI-assisted work fits KDE's environmental and community standards.
What This Means for Anyone Contributing to KDE Right Now
Nothing has changed yet, whether you contribute code or translations to KDE, run Plasma, or are drafting a similar policy for your own team. No project-wide AI ban has been adopted, and the "Don't be lazy" guidelines have not been ratified. The live rules are KDE's existing ones on licensing, code review and communication. Contributors who use AI tools should expect scrutiny. Reviewers will want them to explain every line they submit, and the disclosure question may yet be decided in favour of mandatory labelling.
- KDE has not banned generative AI; KDE for People is a petition, and its demands are proposals.
- KDE's draft LLM guidelines thread was opened September 19 and locked September 21 for a 24-hour cool-off, with a revised draft expected.
- The campaign's demands extend beyond code to MR descriptions, bug reports, .po translation files, and AI as a topic at Akademy and on Planet KDE.
- Disclosure of AI use in patches was still unresolved when the draft thread closed, so contributors should be ready to say which parts of their work were model-assisted.
- The claim that KDE Eco has declared AI-permissive policies incompatible with its goals comes from the campaign alone.
- Teams writing their own AI contribution rules can learn from KDE's split: a personal-responsibility rule answers code-quality concerns but not ethical or environmental ones, and those need to be handled explicitly.
KDE's next draft now has to answer two constituencies. One wants clear, enforceable review standards for AI-assisted patches. The other won't accept any generated output as a matter of principle. A revision that only rewords "Don't be lazy" won't satisfy the petition's signers. A blanket ban would override maintainers who argue that responsibility, not provenance, is what matters. Whichever way KDE goes, one of the largest free desktop projects will have set a public precedent that other open-source maintainers are likely to cite when the same argument reaches their own issue trackers.