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

["Bird, Tim" <Tim.Bird@sony.com>]

> -----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.

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

 -- Tim

> copyright in an AI created piece of code,
> actually doesn't exist because a non human entity can't legally hold
> copyright of a work.  The US copyright office has actually issued this
> opinion (huge 3 volume report):
> 
> https://urldefense.com/v3/__https://www.copyright.gov/ai/__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2VMaxMOBIYDHma42N7zDgm5AoJR9Mu4lT0
> _3G6qm0AjSWcqMDjQa7ydTFdLDYUvDE5d9eJtkwIRAO_Kok3fq0KFnCte1js36oeQ$
> 
> But amazingly enough congress has a more succinct summary:
> 
> https://urldefense.com/v3/__https://www.congress.gov/crs-
> product/LSB10922__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2VMaxMOBIYDHma42N7zDgm5AoJR9Mu4lT0_3G6qm0AjSWcqMDjQa7ydTFdLDYUvDE5
> d9eJtkwIRAO_Kok3fq0KFnCte18GKQTDs$
> 
> But the bottom line is that pure AI generated code is effectively
> uncopyrightable and therefore public domain which means anyone
> definitely has the right to submit it to the kernel under the DCO.
> 
> I imagine this situation might be changed by legislation in the future
> when people want to monetize AI output, but such a change can't be
> retroactive, so for now we're OK legally to accept pure AI code with
> the signoff of the submitter (and whatever AI annotation tags we come
> up with).
> 
> Of course if you take AI output and modify it before submitting, then
> the modifications do have copyright (provided a human made them).
> 
> Regards,
> 
> James
>