Why was an Emacs patch rejected for being LLM-assisted, and what does this reveal about open-source contribution policie

Why the Emacs patch was rejected

The patch wasn’t thrown out because of honesty or poor quality—it was because the contributor used a large language model (LLM) after having been explicitly told not to. [1] [3] The GNU project has well‑known, spelled‑out rules against LLM‑generated code, and Emacs co‑maintainer Eli Zaretskii has confirmed they don’t accept such contributions “as a precaution.” [3] [7] That strict line is rooted in Richard Stallman’s view that LLMs merely spit out text without actual knowledge, and that calling them intelligent is harmful. [13]

What this reveals about open‑source contribution policies

More projects are writing down clear rules about AI‑assisted work

The Emacs rejection isn’t an isolated case. A growing number of open‑source communities are adopting formal policies:

• The Electronic Frontier Foundation (EFF) recently introduced a policy specifically for LLM‑assisted contributions to its projects. [8]
• The Scientific Python community has proposed guidelines asking contributors to be transparent about AI use and to take full responsibility for the final code. [11]
• Some projects now reject AI‑generated patches outright unless the contributor clearly states how the AI was used. [14]
• Others have implemented a “human in the loop” requirement because a flood of low‑quality AI patches is overwhelming maintainers. [15]

The practical and philosophical reasons behind these rules

The Emacs incident and the policies that surround it point to several deeper concerns:

• Licensing trouble – LLMs can produce code that is derived from training sources with licenses that are incompatible with the project you’re contributing to. [9]
• Hidden bugs and maintenance overload – AI‑generated contributions often lack whole‑system awareness, introducing subtle bugs that are hard to track down. [10] The sheer volume of low‑quality patches also puts extra strain on volunteer maintainers. [15]
• The verification puzzle – Once a contributor admits to using an LLM for one part of a patch (for example, only for comments), it becomes very hard for the project to prove the rest of the code is genuinely human‑written. [2] In the Emacs case, the submitter had used an LLM just for Doxygen comments in otherwise manually‑written C++ code. [5] That admission made the entire patch suspect, raising the uncomfortable question of how any developer can prove their code is original when public‑repository‑trained LLMs could have memorized similar patterns. [6]
• Culture and collaboration – Some maintainers believe that the success of projects like NumPy and SciPy comes from humans working together and enjoying the process. AI‑generated contributions can feel like a threat to that collaborative spirit. [12]

Taken together, the Emacs rejection shows that open‑source communities are actively drawing boundaries around AI use, driven by legal caution, code quality, the difficulty of verifying originality, and a desire to keep the human element at the centre of collaboration.