The debate over whether AI-generated code belongs in open-source projects has moved from discussion forums to formal policy proposals. KDE recently made headlines with a controversial plan to define an official stance on large language models. Now, a contributor to the GNOME Project has published a detailed proposal arguing that the movement should go further, explicitly banning LLM-generated content from its codebase and infrastructure.

The Core Proposal

The proposal, published on the GNOME blog by contributor Alatiera, lays out a clear position. LLMs cannot be used to create or modify anything submitted to the GNOME Project or hosted on GNOME infrastructure. Contributors could be asked to demonstrate that their code meets this requirement and could be banned for attempting to circumvent it. The proposal is explicitly modeled after how KDE's controversial stance has been discussed, but argues that existing efforts across the open-source world miss the deeper purpose of such policies.

The author's central argument is that policy documents of this kind should shape social norms rather than micro-manage individual developer workflows. They are signals about what kind of behavior a project values and what kind it rejects. The author contends that most existing statements focus on process details while ignoring the human and social dimensions that make collaborative projects viable.

What the Policy Would Require

Beyond the blanket ban, the proposal includes a set of draft criteria that could be used to evaluate whether a contribution fits the policy's spirit. A contributor must be able to personally reason through and explain every change they submit. They must demonstrate genuine knowledge of the problem space they are working on. The solution must address the underlying issue rather than just its symptoms. They must respect the time of fellow contributors. And they must not impersonate themselves through chatbots, agents, or other automated systems.

The author acknowledges that enforcement is practically impossible. People will still submit LLM-generated code. The policy, they argue, functions the same way as a code of conduct: roughly 80 percent of its value is in signaling what the project stands for, and 20 percent is about handling unwanted behavior when it occurs. If someone lies about not using an LLM, the author compares it to the existing problem of code authorship in the copyright sense, where projects must assume good faith and make their best judgment about who actually wrote what.

The Deeper Argument About Community

The proposal goes well beyond a technical policy. It makes a case about what GNOME is and why it matters. The author argues that GNOME is not simply software that ships on a six-month cycle but a collective of people who find value in reaching beyond individual limitations to achieve something larger. The project's success metric, in this view, is the community and social bonds it creates, not the volume of merged pull requests.

The author frames the current moment as a challenge to that collective identity. The phrase "come do free labor for a handful of corporations by reviewing chatbot output in your free time" is described as an unattractive proposition for young, talented people in 2026. If the project wants to survive, the argument goes, it needs to create a social space where people are valued as people rather than treated as a cost center to be optimized.

The proposal also notes a parallel shift in how GNOME is funded. The Foundation has been moving toward individual donations to reduce dependence on a small number of corporate sponsors, following instances where companies abandoned significant portions of the project. The author extends this logic to labor, arguing that the project needs the next 100 people willing to donate small amounts of their time rather than relying on a handful of overworked engineers at corporations that may walk away at any time.

The Context Behind the Proposal

The proposal arrives during a period when open-source projects are grappling with how to respond to the rapid adoption of AI coding tools. Some projects have embraced them as productivity multipliers. Others have imposed restrictions or outright bans. The KDE proposal that prompted this response was itself controversial, splitting the community over whether such a stance was too restrictive or insufficiently protective.

The GNOME proposal does not attempt to solve the practical problem of detecting LLM-generated code. Instead, it frames the question as a values statement about what the project represents and who it is for. Whether that framing gains traction within the GNOME community or remains a personal opinion piece is an open question. But it contributes to a conversation that is spreading across the open-source world: not just how AI tools are used, but what the communities that use them are willing to accept in exchange for their continued participation.