Re: Group policy on commercial LLM-generated content

Thanks, Norm, for starting this conversation with some excellent links.

A few of the positions and arguments I find unpersuasive, and a meager few
of my own ideas about LLMs are not reflected. However, I do
enthusiastically support a strict policy against any LLM-created PRs,
comments, tests, code, etc. I find CapyPDF's and Zig's statements the best,
because they simply state the policy.

I look forward to this morning's conversation, with you and other friends.

Best wishes,

Joel

On Tue, May 19, 2026 at 7:50 AM Norm Tovey-Walsh <norm@saxonica.com> wrote:

> Hello,
>
> Since I put the LLM policy item on the agenda, I think I should try to
> make my position clear. I don’t think there’s any ethical way to use
> commercial LLMs. They are destructive in any dimension you choose to
> measure: to the open web, to users, to creators, to communities, to our
> global financial system, and to the ecosystem of the planet we live on.
>
> I think that we should join GIMP[1], Servo[2], Loupe[3], Asahi Linux[4],
> CapyPDF[5], Zig[6], Gentoo Linux[7], OpenJDK[8], Linux Man Pages[9], and
> many others[10] in asserting a strict policy rejecting from our
> specifications, out of hand and without consideration, any content created,
> edited, summarized, formatted, or otherwise exposed to the output of LLMs.
>
> Bethan, who writes far more eloquently than I do, has recently written
> about the corrosive role of LLMs on our communities:
> http://linguacelta.com/blog/2026/05/LLMs.html
>
> I’m aware that there’s a lot of work we need to do to polish our
> specifications, but I’m very strongly of the opinion that human beings
> should do that work, not LLMs. In particular, I note that the single,
> primary function of an LLM is to take some input and generate *plausible*
> results. That plausibily is a statistical fact, but it is not reflective of
> any truth or understanding or comprehension.
>
> Even if you find none of the arguments against using LLMs (ethical,
> financial, environmental, etc.) persuasive, consider, at least, that adding
> a bunch of plausible text to our specifications will not, in the long run,
> make them easier to read or understand, or easier to polish.
>
> [1]
> https://gitlab.gnome.org/GNOME/gimp/-/blob/master/.gitlab/merge_request_templates/default.md?plain=1#L11-12
> [2]
> https://book.servo.org/contributing/getting-started.html#ai-contributions
> [3]
> https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-contributions/27327
> [4] https://asahilinux.org/docs/project/policies/slop/
> [5] https://github.com/jpakkane/capypdf/
> [6] https://ziglang.org/code-of-conduct/
> [7] https://wiki.gentoo.org/wiki/Project:Council/AI_policy
> [8] https://openjdk.org/legal/ai
> [9]
> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING.d/ai
> [10] https://codeberg.org/brib/slopfree-software-index
>
> Written in a purely personal capacity,
> Norm
>
>

-- 
Joel Kalvesmaki
kalvesmaki.com