Human fear in Emacs

Just a few days ago, Human Emacs was published: a declaration signed by more than 50 people from the community, led by technomancy, announcing that if GNU ends up accepting LLM-generated contributions in Emacs, they are prepared to maintain a fork free of AI-generated code. They have also opened a mailing list to discuss the topic and a chat channel on Libera Chat. Naturally, debates have appeared elsewhere too, such as Hacker News, Lobsters and Reddit. The debate is on.

I notice a lot of tension in the community. Every time I leave a comment in a thread supporting some point contrary to Human Emacs, I receive downvotes and flags for off-topic, spam, troll and unkind. That is why I thought it appropriate to develop my opinion on my blog, where there is room for nuance without the pressure of votes and labels.

That said, it is worth separating two debates that are being mixed together. The first one belongs to GNU and the FSF, the legal matter: if LLM-generated code cannot be copyrighted, it could weaken copyleft.

The licensing arguments seem legitimate to me, but easy to get around. Today you can work with a free LLM, with open weights, running on your own machine. If the purity of the tool really mattered, we should not accept patches typed on Windows with a proprietary IDE. If code is the heart of free software, we should only care about it being useful, maintainable and of good quality, regardless of its origin. And if what matters is the person behind it, we are entering territory that has already been settled: contributions developed by private companies are accepted.

The second one belongs to the Human Emacs signatories, and it is purely ethical. They make it clear themselves in their "Not Under Discussion" section:

We are not here to discuss whether LLMs are effective at what they are claimed to be able to do; their effectiveness is not at all relevant to the question of whether their use can be part of a principled software movement dedicated to user empowerment.

This stance has the virtue of being honest: they are not discussing whether LLMs work, they are discussing whether they fit their principles. And there is no possible debate against someone's principles. I will only say that I do not share the premise that LLMs are incompatible with user empowerment: for someone who cannot program, being able to add a complex feature to their editor is precisely empowerment.

I fully understand the right to fork, and I defend it: I maintain emacs-gpu myself. Forking is the essence of free software, and having an Emacs without AI code for those who want it seems healthy to me. What I find harder is the practical side: there is no reliable way to detect LLM-generated code, so the policy can only rest on trust and each contributor's voluntary disclosure. And we already know where that leads: a few weeks ago a 92-line performance patch was rejected on emacs-devel precisely because its author disclosed that it had been drafted by an open-weights model, even though they reviewed it, modified it, tested it and took legal responsibility for it themselves. If they had kept quiet, nobody would have known. A policy that punishes honesty only produces less honest contributors.

Personally, I believe LLMs will improve Emacs in areas where it was not possible before. It is already happening with very complex bugs and with abstraction layers that required an enormous amount of human work that nobody was willing to do. And although I understand that LLM-written code in the core is not the same as human-written packages that use LLMs, such as gptel or agent-shell.el, I struggle to see the coherence between rejecting the former outright and celebrating that the latter is bringing fresh air into the ecosystem. I believe that, deep down, there is more human fear than real problem: perhaps the root lies neither in the LLMs nor in the FSF, but in the uncertainty that such a big change stirs in us. And that fear runs both ways: fear that LLMs will degrade what we love, and fear of falling behind by not using them. The Emacs community has always been very open to new ideas, and I would like it to stay that way.