Open source draws hard lines on AI text and AI tooling

Open source projects are no longer debating whether machine learning tools belong in the development loop. They are drawing sharper boundaries around where those tools may speak, what they may author, and what risk they introduce when they sit between a contributor and a maintainer. In the same stretch of weeks, LLVM advanced an RFC to forbid AI-generated project communication, Emacs maintainers wrestled with whether an LLM-assisted package belongs on NonGNU ELPA, and security lists carried news that a widely used AI coding extension had been compromised to drop a remote access trojan. The common thread is not abstract philosophy about authorship. It is the practical cost of reviewing other people's machine output, and the new attack surface that appears when maintainers adopt the same tools.

LLVM's existing AI policy, as nikic summarized it when opening the RFC, has been fairly liberal: essentially all uses are allowed so long as there is a "human in the loop" who takes responsibility. Experience with that model has soured on one class of contribution in particular. The RFC does not touch allowable uses of AI for code. It instead proposes to "ban the use of AI-generated or substantially AI-assisted textual communication," including pull request descriptions and RFC texts. The stated motive is reviewer bandwidth. Nikic described a flood of low-quality, extremely verbose PR writeups, thick with routine testing boilerplate and gratuitous formatting, that act as a "drain on our limited reviewer bandwidth" both to read and to massage into mergeable form. There is also a process claim: AI-written descriptions "deprive the contributor of the opportunity to understand what a PR does by themselves," which nikic treats as an important sanity check for the human-in-the-loop model.

Support for a harder line has been broad. Jrtc27 pointed to heavy endorsement on the original post and urged adoption sooner rather than later, hoping the project could "spend less of our time fending off the slop." Aaron Ballman, describing the usual RFC cadence, indicated the project council was more likely to take a decision after discussion settled, with AI policy already a recurring council topic.

The dissent is less about whether slop is real than about where the ban should cut, and how to live with the volume either way. Arsenm argued that not all communication carries equal weight: substantial RFCs are a clearer case for a ban than review comments or trivial commit messages for mechanical, repetitive changes. Facing "overwhelming numbers of PRs," arsenm admitted that "LLM review of the LLM PRs can be helpful, if frustrating," and resisted a world of doing AI reviews of AI code that the submitter could have pre-reviewed. Disclosure tags were offered as a middle ground, then dismissed as something "very EU-brained" that "nobody will follow in practice," with enforcement itself framed as more reviewer burden. Reinterpretcast pushed back on the mutual-AI equilibrium as close to saying "we can have the LLMs just talk to each other," and defended disclosure as expectation-setting: without it, "the reader should be entitled to see the nonsense as a reflection of the so-called author’s abilities." Rnk cast the practical etiquette as separating human conversation from "instructions passed back and forth between agents," including blockquoting agent output rather than laundering it into a human voice. Separately, rengolin kept returning to automated fuzzer and auto-fix traffic as the larger volume problem behind much of the same pain. The unresolved LLVM question is therefore not only whether to ban AI prose, but whether policy can be enforced without witch hunts, and whether reviewer load from agent-shaped text and agent-shaped patches can be reduced without merely relocating the work.

Emacs is fighting a related but legally flavored battle on the package boundary. Lucius Chen sought NonGNU ELPA inclusion for Clutch, an interactive database client, and disclosed development with OpenAI Codex and Claude Code via Assisted-by headers. That candor triggered the policy argument. Richard Stallman restated a cautious GNU stance focused on provenance and copyleft: the project is concerned that "copyleft may not be enforcible on code that has no human author," and until that is ascertained, policy is not to include LLM-generated code in GNU packages. He was explicit about asymmetric treatment: "We are discriminating between packages offered for addition and those already added." New offerings with LLM-generated code are refused for now; already-present code should be recorded, and removal can wait until legal risk is clearer. He also objected to marketing language, preferring "Machine Learning" over "AI," and pressed for finer lines on rewritten drafts and code completion when contributors asked where assistance ends and generation begins.

Eli Zaretskii and others on emacs-devel treated the operational problem as incomplete communication of an evolving rule. Johan Myréen argued that sporadic "did you use AI" interrogations punish transparency and waste effort when people learn the answer only after heavy work, and that CONTRIBUTE should state the policy up front. Eli doubted a long policy document would be read, while agreeing documentation could be added; Stallman drafted text for CONTRIBUTE explaining the legal concern, the freeze on new LLM-generated inclusions, and the request to report unmarked LLM-origin code already in the tree. Stefan and Eli's NonGNU framing in the wider thread underscored that distribution channel and GNU package status are not identical, which only sharpens the contributor-facing confusion: what is refused for GNU purity may still be argued under different NonGNU expectations, yet submitters encounter the questions the same way.

The third incident reframes the same tooling as infrastructure risk. On oss-security, Valtteri Vuorikoski reported that the official Claude Code extension for VS Code on the Open VSX marketplace (used by VS Code-derived editors such as Cursor, and distinct from Microsoft's marketplace) was compromised. Version 2.1.313 was pulled after it was used to drop a remote access trojan; auto-update may have spread it widely, with social reports of organizational impact. The note was framed explicitly for open source maintainers who rely on Anthropic products in day-to-day work: the assistant is not only a source of patches and prose, but a privileged component in the developer workstation supply chain. Detection and mitigation guidance circulated via a Phorion advisory and a Cursor security notice, while official detail remained thin.

Read together, the three threads mark a shift from permissive "human takes responsibility" norms toward selective prohibitions and provenance freezes, just as the tools themselves become high-value compromise targets. LLVM is trying to protect scarce review attention from extractive text while leaving AI-written code in a different bucket. Emacs is trying to protect legal enforceability and future maintainability by stalling undisclosed or LLM-authored additions without a full historical purge. Security practitioners are warning that the same coding agents maintainers use to keep up can be subverted under them. What remains unsettled is the workable boundary: which machine outputs must be banned, which must be labeled, which may be rewritten into human responsibility, and how projects enforce any of that without multiplying the burden they set out to reduce, especially when the assistant channel is itself untrusted.