Re: [MAINTAINERS SUMMIT] Annotating patches containing AI-assisted code

["Paul E. McKenney" <paulmck@kernel.org>]

On Mon, Aug 18, 2025 at 11:12:23PM +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 12 Aug 2025 13:15:33 +0000
> "Bird, Tim" <Tim.Bird@sony.com> escreveu:
> 
> > > -----Original Message-----
> > > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > On Mon, 2025-08-11 at 14:46 -0700, Paul E. McKenney wrote:  
> > > > On Fri, Aug 08, 2025 at 10:31:27AM +0200, Krzysztof Kozlowski wrote:  
> > > > > On 05/08/2025 19:50, Sasha Levin wrote:  
> > > > > > On Tue, Aug 05, 2025 at 05:38:36PM +0200, Jiri Kosina wrote:  
> > > > > > > This proposal is pretty much followup/spinoff of the discussion
> > > > > > > currently happening on LKML in one of the sub-threads of [1].
> > > > > > >
> > > > > > > This is not really about legal aspects of AI-generated code and
> > > > > > > patches, I believe that'd be handled well handled well by LF,
> > > > > > > DCO, etc.
> > > > > > >
> > > > > > > My concern here is more "human to human", as in "if I need to
> > > > > > > talk to a human that actually does understand the patch deeply
> > > > > > > enough, in context, etc .. who is that?"
> > > > > > >
> > > > > > > I believe we need to at least settle on (and document) the way
> > > > > > > how to express in patch (meta)data:
> > > > > > >
> > > > > > > - this patch has been assisted by LLM $X
> > > > > > > - the human understanding the generated code is $Y
> > > > > > >
> > > > > > > We might just implicitly assume this to be the first person in
> > > > > > > the S-O-B chain (which I personally don't think works for all
> > > > > > > scenarios, you can have multiple people working on it, etc),
> > > > > > > but even in such case I believe this needs to be clearly
> > > > > > > documented.  
> > > > > >
> > > > > > The above isn't really an AI problem though.
> > > > > >
> > > > > > We already have folks sending "checkpatch fixes" which only make
> > > > > > code less readable or "syzbot fixes" that shut up the warnings
> > > > > > but are completely bogus otherwise.
> > > > > >
> > > > > > Sure, folks sending "AI fixes" could (will?) be a growing
> > > > > > problem, but tackling just the AI side of it is addressing one of
> > > > > > the symptoms, not the underlying issue.  
> > > > >
> > > > > I think there is a important difference in process and in result
> > > > > between using existing tools, like coccinelle, sparse or even
> > > > > checkpatch, and AI-assisted coding.
> > > > >
> > > > > For the first you still need to write actual code and since you are
> > > > > writing it, most likely you will compile it. Even if people fix the
> > > > > warnings, not the problems, they still at least write the code and
> > > > > thus this filters at least people who never wrote C.
> > > > >
> > > > > With AI you do not have to even write it. It will hallucinate,
> > > > > create some sort of C code and you just send it. No need to compile
> > > > > it even!  
> > > >
> > > > Completely agreed, and furthermore, depending on how that AI was
> > > > trained, those using that AI's output might have some difficulty
> > > > meeting the requirements of the second portion of clause (a) of
> > > > Developer's Certificate of Origin (DCO) 1.1: "I have the right to
> > > > submit it under the open source license indicated in the file".  
> > > 
> > > Just on the legality of this.  Under US Law, provided the output isn't
> > > a derivative work (and all the suits over training data have so far
> > > failed to prove that it is),  
> > 
> > This is indeed so.  I have followed the GitHub copilot litigation
> > (see https://githubcopilotlitigation.com/case-updates.html), and a few
> > other cases related to whether AI output violates the copyright of the training
> > data (that is, is a form of derivative work).  I'm not a lawyer, but the legal
> > reasoning for judgements passed down so far have been, IMHO, atrocious.
> > Some claims have been thrown out because the output was not identical
> > to the training data (even when things like comments from the code in
> > the training data were copied verbatim into the output).  Companies doing
> > AI code generation now scrub their outputs to make sure nothing
> > in the output is identical to material in the training data.  However, I'm not
> > sure this is enough, and this requirement for identicality (to prove derivative work)
> > is problematic, when copyright law only requires proof of substantial similarity.
> > 
> > The copilot case is going through appeal now, and I wouldn't bet on which
> > way the outcome will drop.  It could very well yet result that AI output is deemed
> > to be derivative work of the training data in some cases.  If that occurs, then even restricting
> > training data to GPL code wouldn't be a sufficient workaround to enable using the AI output
> > in the kernel.  And, as has been stated elsewhere, there are no currently no major models restricting
> > their code training data to permissively licensed code.  This makes it infeasible to use
> > any of the popular models with a high degree of certainty that the output is legally OK.
> > 
> > No legal pun intended, but I think the jury is still out on this issue, and I think it
> > would be wise to be EXTREMELY cautious introducing AI-generated code into the kernel.
> > I personally would not submit something for inclusion into the kernel proper that
> > was AI-generated.  Generation of tools or tests is, IMO, a different matter and I'm
> > less concerned about that.
> > 
> > Getting back to the discussion at hand, I believe that annotating that a contribution was
> > AI-generated (or that AI was involved) will at least give us some assistance to re-review
> > the code and possibly remove or replace it should the legal status of AI-generated code
> > become problematic in the future.
> 
> Heh, it could produce exactly the opposite effect: anyone that may have
> a code that slightly resembles a patch stating that AI was used could try
> to monetize from such patch merge.

This is one of my concerns as well.

							Thanx, Paul

> > There is also value in flagging that additional scrutiny may be warranted
> > at the time of submission.  So I like the idea in principal.
> 
> 
> Thanks,
> Mauro