"Human Emacs": Proposal for an Emacs Fork Without LLM Contributions

--> Human Emacs emacs-devel [Top][All Lists] Advanced [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Human Emacs From: Phil Hagelberg Subject: Human Emacs Date: Thu, 29 Oct 2026 08:50:58 -0700 User-agent: mu4e 1.12.9; emacs 30.1 I'm writing on behalf of a group of Emacs developers and users who share concerns about the future of the project. As we see other projects adopting policies which accept LLM contributions, it's encouraged us to see that the current Emacs policy disallows them. Our concerns stem from the temporary nature of the current policy, and its apparent focus on resolving legal uncertainty surrounding the copyright status of LLM-generated source code. Ensuring that the copyright of Emacs is legally defensible is of course important, but the way it appears to form the crux of the decision overlooks the harm posed to users and communities by acceptance of LLM-generated code. It would be a mistake to say that because something is legally allowable it must be acceptable, and for many of us who are deeply invested in Emacs, it's not a mistake we'd expect from this project's leadership. Free Software is more than just code. It's built on a foundation of trust and solidarity. The greatest strength of Emacs is not its technology but the user base which shares and works together. As we watch this discussion play out in other communities which have not taken a strong stance, we've seen the corrosive effect that LLMs have on trust and solidarity as soon as they are allowed in. We still have the chance to avoid that in the Emacs community and learn from the mistakes of others! (At this point I should clarify that an argument about whether these harms are serious is not my interest; so if you are opening your MUA to compose a reply on these lines, please consider that we've heard all the arguments already and remain unmoved by them. We're not interested in arguments about how powerful they are, nor about how local models will some day address the problems, nor about how people can lie about the provenance of their patches; none of these are relevant. You're welcome to discuss this on a separate thread.) In a previous thread[1] that raised the question of the Emacs policy, one of the Emacs maintainers wrote: > Such policy discussions and decisions are not for the Emacs project to > make, they are global for all the GNU packages, and so here is the wrong > place to look for them. While it's true that this mailing list cannot make policy decisions for all of GNU, there is no reason that Emacs could not hold itself to a higher standard than the rest of GNU. If the GNU-wide ban is relaxed, that is not the same thing as GNU demanding that all projects accept LLM-generated contributions; it only means that they *may* if they so decide. Our goal in reaching out is twofold: First, we want the maintainers of Emacs to be aware of our intention to use a version of Emacs which is fully free from LLM contributions regardless of whether the current ban is made permanent or lifted. We invite those making the decision to look beyond copyright and weigh ALL the harms that lifting such a ban would inflict. Our fond hope is that upon consideration of the issues, Emacs maintainers will replace the temporary policy with a commitment to comprehensive prohibition of all LLM contributions including but not limited to code, documentation, commit messages. We consider this a necessity for a piece of software which is central to our freedom and our participation in the technology commons. In the unfortunate event that we cannot get such a commitment from the Emacs maintainers, we will use an LLM-free Emacs regardless; it just won't be GNU Emacs. Forks of Emacs have a poor track record, but this is a case where we are left without much choice. There is too much at stake: giving up using Emacs for many of us would feel tantamount to giving up on computing altogether, or at least giving up on the parts of computing that bring us joy. Therefore we are committed to build and maintain the Emacs we need to exist. We sincerely hope that this will mean a renewed and re-invigorated commitment to GNU Emacs. Our second goal is to reach others who feel this same concern, so you know you are not alone. We have seen too many other communities fail to meet the challenge of this moment, and we can't stand aside and observe the outcome of this policy decision with cool detachment. If you feel the same way, join us in solidarity. Visit https://human-emacs.org where you can read more information and see the list of supporters so far; we would love to add your name to the list or hear your voice in our IRC channel and mailing list. My sincere thanks goes out to everyone who has brought Emacs to where it is today and especially to those who have helped institute the policy that has protected Emacs from LLM contributions so far. Emacs means too much to me to see it share the same fate as Vim, Linux, rsync, and countless other disappointments; we have to do better. -Phil Hagelberg (aka technomancy), on behalf of the Human Emacs signatories 1: https://lists.gnu.org/archive/html/emacs-devel/2026-03/msg00425.html signature.asc Description: PGP signature reply via email to [Prev in Thread] Current Thread [Next in Thread] Human Emacs, Phil Hagelberg <= Re: Human Emacs, Dr. Arne Babenhauserheide, 2026/10/29 Re: Human Emacs, Eli Zaretskii, 2026/10/29 Re: Human Emacs, Gabriel Santos, 2026/10/29 Re: Human Emacs, bjc, 2026/10/29 Re: Human Emacs, tomas, 2026/10/29 Re: Human Emacs, Eli Zaretskii, 2026/10/29 Re: Human Emacs, Jean Louis, 2026/10/29 Prev by Date: Re: Implementation of the Kitty Keyboard Protocol for Emacs Next by Date: Re: Implementation of the Kitty Keyboard Protocol for Emacs Previous by thread: Need to bump Xref from 1.7.0 to 1.8.0 Next by thread: Re: Human Emacs Index(es): Date Thread