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/a24520c4147ffd67bb696c71f15ed4fb8521a791/008-genai.md On Sat, Jul 25, 2026 at 2:49 PM <[email protected]> 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 <[email protected]> > 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 >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
