Re: [RFC PATCH 1/1] SubmittingPatches: allow responsible AI assistance

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 3306 bytes --]

On 2026-10-08 at 04:49:27, Scott Chacon wrote:
> Again, a lot of my argumentation here was directly taken from the
> SFC's recommendations [1], which Git is a member project of.
> 
> https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

I'm in agreement with most of those policies.  I'm just not in agreement
that we should accept LLM-generated contributions and that document
doesn't say we should.

What it does say is that we shouldn't shun people who submit
LLM-generated contributions even if that violates our policies, and I
think we've respected that.  Every time this comes up—and it comes up
more often than it should, given that we have a documented policy and
that people should know to look for one—we've handled this graciously.
As far as I know, nobody has been blocked or excluded for having sent an
LLM-generated patch to Git and we usually explain the policy in a calm,
rational way.

Section 8 says we should avoid jumping to legal conclusions.  I agree; I
have said consistently on the list that one of the reasons we should
reject LLM-generated contributions is because the legal status is
unclear.  I have strong views that LLMs are unethical because of the way
they've been trained and the lack of credit, among other reasons, but I
have been very clear that the legality is uncertain.

The final thing that it says that kind of supports your argument is §11.
However, it's not the case that accepting LLM-generated contributions
would massively accelerate improvements to our codebase.  Git has a
reputation for high quality and we perform thorough reviews.  Those are
already a bottleneck for us even with only human-generated code and
welcoming LLM-generated code and documentation would submerge us under a
deluge of patches.  As we discussed at the Contributor's Summit, we're
already underwater on the security list due to the flood of LLM-assisted
bug reports, a number of which are of dubious quality, and we shouldn't
replicate that on the public list as well.

One thing that supports my argument is that we should support people who
"outright reject LLM-gen-AI systems."  Because of the way this list
works, if we accept LLM-generated code, contributors who don't want to
work with that content are going to receive unwanted patches that are
CC'd to them and then have to deal with those, whereas in a project like
Rust, one can simply block the LLM bots and then never have to deal with
that content at all.  So I don't think we can honour that term while we
allow LLM-generated content unless we change our development approach.

I would also say that we are not obligated to follow SFC's guidance at
all.  SFC also recommends that we leave GitHub[0], which obviously
neither of us are following, nor are most of our contributors, and many
people would disagree.  Regardless of their guidance, our project can
set our own policies and structure as we see fit.  QEMU is also an SFC
project and has adopted a policy very similar to ours[1], so there is
clearly precedent here.

[0] https://sfconservancy.org/GiveUpGitHub/
[1] https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/code-provenance.rst?ref_type=heads
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]