Message-ID: <aIKhvubVqgeXIlrj@gallifrey>
Date: Thu, 24 Jul 2025 21:12:30 +0000
From: "Dr. David Alan Gilbert" <linux@...blig.org>
To: Kees Cook <kees@...nel.org>
Cc: Konstantin Ryabitsev <konstantin@...uxfoundation.org>, corbet@....net,
	workflows@...r.kernel.org, josh@...htriplett.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] docs: submitting-patches: (AI?) Tool disclosure tag

* Kees Cook (kees@...nel.org) wrote:
> On Thu, Jul 24, 2025 at 03:07:17PM -0400, Konstantin Ryabitsev wrote:
> > On Thu, Jul 24, 2025 at 06:54:39PM +0100, linux@...blig.org wrote:
> > > From: "Dr. David Alan Gilbert" <linux@...blig.org>
> > > 
> > > It seems right to require that code which is automatically
> > > generated is disclosed in the commit message.
> > 
> > I'm not sure that's the case. There is a lot of automatically generated
> > content being added to the kernel all the time -- such as auto-formatted code,
> > documentation, and unit tests generated by non-AI tooling. We've not required
> > indicating this usage before, so I'm not sure it makes sense to start doing it
> > now.
> > 
> > Furthermore, merely indicating the tool doesn't really say anything about how
> > it was used (e.g. what version, what prompt, what context, etc.) If anything,
> > this information needs to live in the cover letter of the submission. I would
> > suggest we investigate encouraging contributors to disclose this there, e.g.:
> > 
> > | ---
> > | This patch series was partially generated with "InsensitiveClod o4 Hokus"
> > | and then heavily modified to remove the parts where it went completely off
> > | the deep end.
> > 
> > I am also not opposed to having a more standard cover letter footer that would
> > allow an easier way to query this information via public-inbox services, e.g.:
> > 
> > | generated-by: insensitive clod o4 hokus
> > 
> > However, I don't really think this belongs in the commit trailers.
> 
> I agree; I'm not sure I see a benefit in creating a regularized trailer
> for this. What automation/tracking is going to key off of it? It's
> a detail of patch creation methodology,

My logic here is something like:
   a) Some people worry about various issues on AI such as copyright;
so it feels like it should be trackable.
   b) The teams that develop tools that work well deserve credit, so
formalising it seems to make that easier to see; be they AI etc.
   c) There's a general worry about people sending patches without
acknowledging their use of AI, and then not (carefully) checking
the output.  Calling out the need to record it might help get
people to at least acknowledge it.
   d) (a) and (c) are really only about AI, but our previous chat
was wondering if all tools needed it, but calling out anything where
it's code generation seemed to be a reasonable line to me.
   e) If one tool tended to be particularly bad at missing one type
of check, with a tag you could track down what we have from it.
   f) Related to (a), some large open source projects are explicitly
disallowing AI generated contributions; life will get messy for them
if people import kernel code with a compatible license that was
generated by AI.

(I didn't really want to get into the question of whether the use of
AI was good or bad; but people worrying about it isn't unreasonable)

> so the commentary about how
> something was created is best put in the prose areas, like we already
> do for Coccinelle or other scripts. It's a bit buried in the Researcher
> Guidelines[1], but we have explicitly asked for details about tooling:
> 
>   When sending patches produced from research, the commit logs should
>   contain at least the following details, so that developers have
>   appropriate context for understanding the contribution.
>   ...
>   Specifically include details about any testing, static or dynamic
>   analysis programs, and any other tools or methods used to perform the
>   work.
> 
> Maybe that needs to be repeated in SubmittingPatches?

'produced from research' is narrowing things down a bit too much I think
when it's people using the tools as their normal way of working.

Dave

> -Kees
> 
> [1] https://docs.kernel.org/process/researcher-guidelines.html
> 
> -- 
> Kees Cook
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Powered by blists - more mailing lists