Hi Tom, First of all, for transparency: assistive technology was used. Especially to get these tables formatted. Before responding to the substance, I’d like to address one meta point. You wrote that I “don’t seem to have assimilated any of the points of earlier responses.” I don’t think that’s a fair characterisation of my position. I have read every reply carefully, and several have changed my thinking. For example, I started this discussion by questioning whether we even needed an explicit LLM policy. Today, I support Simon’s current draft. Likewise, after Magnus objected to my use of the term “segregation”, I reflected on that criticism, looked into the terminology, and changed how I describe the concern I was trying to express. The reason I have returned to some of the same arguments is therefore not because I ignored the replies, but because I don’t think I have yet succeeded in communicating the distinction I’m trying to draw. Perhaps I have also failed to communicate where I am actually starting from. Roughly speaking, my preferences would look something like this: *Preference* *Position* 1 No policy at all. 2 A lightweight provenance policy (e.g. Ghostty). 3 The current GHC v2 proposal. 4 A more prescriptive policy. 5 A policy expressing an institutional preference between otherwise acceptable workflows. 6 A complete ban. Personally, I would probably choose somewhere between (1) and (2). The current proposal therefore already represents a fairly substantial compromise from my preferred position, and one that I am genuinely happy to support. Interestingly, I think I would even find the Guix proposal [1] easier to agree with than v1 of our proposal, despite disagreeing with many of its conclusions and despite frequently disagreeing with Guix’s broader philosophy. The reason is not that it is less restrictive (it clearly isn’t) but that it explicitly starts with the project’s commitments and values, and only then derives a contribution policy from them. Whether or not one agrees with those values, I find the document internally coherent. The reason I’ve kept reaching for analogies is because I don’t feel I have managed to communicate the distinction I’m trying to draw. The Windows analogy is the closest analogue I have found so far. *GHC proposal* *Windows analogy* LLM-assisted contributions may exhibit different failure modes. Windows-developed contributions may exhibit different failure modes. Contributors disclose LLM assistance. Contributors disclose Windows development. Reviewers may use that information. Reviewers may use that information. *We strongly prefer human-written contributions.* *We strongly prefer Linux-developed contributions.* Up to the third row I can understand the rationale, even if I might not personally agree with every aspect of it. It is the fourth row where I think the character of the policy changes fundamentally. At that point we are no longer talking about provenance. We are expressing an institutional preference between otherwise acceptable workflows. This is the distinction I have been trying to make throughout the discussion. I also realize that analogies can be misleading, and I don’t claim this one is perfect. However, I do think it differs materially from my earlier Emacs/Vim and similar analogies. The point of the Windows analogy is *not* that Windows and LLMs are similar technologies. Rather, it is intended to isolate the policy mechanism I have been trying to discuss throughout this thread: - a workflow is claimed to exhibit different failure modes, - contributors disclose that workflow, - reviewers are free to act on that information, and - the project expresses an institutionalized preference for an alternative workflow. If you believe the analogy fails, I would genuinely appreciate it if you could point out where this structural correspondence breaks down. I suspect that would help me understand your position much better. Julian has probably come closest to engaging with it directly. While I disagree with his conclusion, I genuinely appreciate that he stated his position explicitly. It’s also one of the reasons I deeply value, respect and appreciate Julian. is currently roughly this: - *Julian:* to protect people who cannot or will not use LLMs, and to prevent LLM use from becoming a de facto expectation. - *Tom:* because merged artifacts and project discussion affect everyone; disclosure and individual opt-out cannot fully insulate people who object to LLM-assisted contributions. - *Simon (my understanding):* because personally composing code and documentation is itself believed to encourage engagement, restraint, understanding, and better human communication. Even if I grant all of these concerns, I still struggle to understand why an institutional preference between otherwise acceptable workflows is the appropriate and proportionate mechanism, rather than limiting the policy to provenance, responsibility, quality, direct human communication, and reviewer choice. Perhaps this is where the discussion has been talking past itself all along. It increasingly feels to me that I am arguing against what I would describe as a *soft-ban* policy: not an outright prohibition of LLM-assisted contributions, but a policy that nevertheless creates enough stigma, additional disclosure requirements, institutional distrust, and stated preference that contributors are expected to infer the "correct" workflow. If that is indeed the intended direction, I would rather we say so explicitly and discuss that position on its own merits. If, on the other hand, LLM-assisted contributions are considered acceptable provided they satisfy the project's requirements around disclosure, understanding, responsibility, and quality, then I still do not understand why the project itself should additionally express a preference for a different workflow. Best, Moritz — [1] https://codeberg.org/guix/guix-consensus-documents/raw/commit/a24520c4147ffd... On Sat, Jul 25, 2026 at 2:49 PM <amindfv@mailbox.org> wrote:
Hi Moritz,
Many of your paragraphs here seem to reiterate arguments you've made previously. Additionally, you don't seem to have assimilated any of the points of earlier responses. For example, several days ago you equated pro- and anti-LLM positions with developers debating using Emacs vs. Vim. Several people responded with why that wasn't a helpful analogy for them, and yet in this email you're equating the debate with Linux vs. Windows, seeming not to take on board any of their points.
At this point I think we should focus only on finding how to "disagree agreeably."
I've responded to a few of your points inline:
On 07/25/2026 4:35 AM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:
As I said before, I am agreeable with the revised policy Simon shared. I think it represents a compromise I can support.
Unfortunately it does not represent a compromise that I and many others can. Specifically, it seems slanted in favor of LLM users doing whatever they like, provided they disclose their LLM usage.
There is, however, one part of your response that I still struggle with.
“human-written” means, well, written by a human. I think we probably have a philosophical disagreement here about what writing or authorship is. To me, understanding, judgement, selection, revision, adoption, and taking responsibility for the result are more important than whether I personally produced every character of the final representation. I don’t think we will necessarily resolve that disagreement here, though. More importantly, the revised policy does not require us to. It focuses on understanding, responsibility, quality, and disclosure, which I find quite reasonable.
Please recognize, though, that what you find quite reasonable is exactly the part that I and others disagree with. We haven't found a compromise position by adopting criteria that ignores usage of LLM (other than disclosure).
On this point:
acknowledging that a majority prefer LLMs not to be used. I’m not convinced this conclusion follows from the GitLab discussion itself. The issue was titled “Ban all LLM contributions”. A discussion framed in this way seems inherently self-selecting to me. People who strongly oppose LLM use have an obvious reason to participate. People who use assistive technology, are indifferent to its use, or simply consider the proposed ban unlikely to succeed may just ignore the issue and let those interested in it discuss it. To be clear: I am _not_ claiming that the opposite conclusion follows. I do not know what the majority of GHC contributors thinks about LLM use. My point is only that I don’t think we can infer the preference of the wider contributor community from the people who chose to participate in this particular issue.
This seems like motivated reasoning. Why should we doubt that pro-LLM users would be at least as likely to vote on an issue that would ban their preferred workflow?
Occam's razor is that around 50% of people who care about the issue, want to ban LLM usage entirely.
You will notice, by the way, that my name is not among those voting to ban usage. This is because I feel GHC needs to move forward with a compromise that doesn't leave people feeling totally left out. Unfortunately, the current draft does this in my view, in the other direction.
I would find that objectionable even if a majority of participants in the “Ban all Windows-developed contributions” issue supported it. This is how I see the proposed preference for human-written contributions as well. I don’t object to the present policy stating expectations around responsibility, understanding, quality, and disclosure. As mentioned above, I am agreeable with the revised policy.
What I object to is adding an institutional ranking of otherwise acceptable workflows back into it.
One reason I care about this distinction is that I want GHC to remain an open and welcoming project for contributors.
You seem not to recognize that we cannot have our cake and eat it too. For each person who'd say "Yippee! I can use LLMs!" there is another person who says "Oh no, discussion on important issues is LLM-generated. I don't want to read that."
I'm seeking to find a compromise position here, but for that to work, both sides need to recognize that there is no free lunch: no solution that will be maximally welcoming for all people of all stripes.
By contrast, explicitly declaring one otherwise acceptable workflow to be _preferred_ over another risks sending a different signal. Even if that is not the intention, it creates the impression that some contributors are viewed as inherently more desirable than others despite meeting the same standards of quality and responsibility. That seems misaligned with the kind of welcoming, collaborative, and trust-based project I would like GHC to be. Perhaps some contributors distrust LLM-assisted code. The present disclosure requirement gives them the information necessary to act on that distrust. I don’t think the project additionally needs to adopt that distrust as its own stated preference.
Another "no free lunch" situation: embedded in your view here ("The present disclosure requirement gives them the information necessary to act on that distrust") is that a person who dislikes LLM contributions can remain unaffected by them simply by not reading LLM code or documentation. Your proposal (everybody develops how they please; people who don't like it shouldn't participate) sidelines people and excludes them from meaningful discussion and information about GHC's future. And of course, they'll end up reading LLM-generated code and/or documentation if it's merged in.
As soon as you recognize there's a balancing act here, I think you'll understand more where many of us are coming from.
Thanks, Tom