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

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Tue, 12 Aug 2025 07:42:21 -0700
"Paul E. McKenney" <paulmck@kernel.org> escreveu:

> On Tue, Aug 12, 2025 at 09:38:12AM +0100, James Bottomley wrote:
> > 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), 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://www.copyright.gov/ai/
> > 
> > But amazingly enough congress has a more succinct summary:
> > 
> > https://www.congress.gov/crs-product/LSB10922  
> 
> Indeed:
> 
> 	While the Constitution and Copyright Act do not explicitly define
> 	who (or what) may be an "author," U.S. courts to date have not
> 	recognized copyright in works that lack a human author—including
> 	works created autonomously by AI systems.
> 
> Please note the "U.S. courts *to* *date*".  :-(
> 
> > 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).  
> 
> Except that the USA is a case-law jurisdiction, and changes
> in interpretation of existing laws can be and have been applied
> retroactively, give or take things like statutes of limitations.  And we
> need to worry about more than just USA law.
> 
> And I do agree that many of the lawsuits seem to be motivated by an
> overwhelmening desire to monetize the output of AI that was induced by
> someone else's prompts, if that is what you are getting at.  It does seem
> to me personally that after you have sliced and diced the training data,
> fair use should apply, but last I checked, fair use was a USA-only thing.

Maybe, but other Countries have similar concepts. I remember I saw an
interpretation of the Brazilian copyright law once from a famous layer
at property rights matter, stating that reproducing small parts of a book, 
for instance, could be ok, under certain circumstances (in a concept
similar to US fair use).


Thanks,
Mauro