Re: on ai generated and code provenance

["Michael S. Tsirkin" <mst@redhat.com>]

On Sun, May 24, 2026 at 06:06:46PM +0100, Alex Bennée wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > So, I had to reject a perfectly reasonable patch:
> > https://lore.kernel.org/qemu-devel/20260320193746.242704-1-jinpu.wang@ionos.com/
> > just because of a tool used to make it.
> >
> >
> > 	How contributors could comply with DCO terms (b) or (c) for the output of AI
> > 	content generators commonly available today is unclear.  The QEMU project is
> > 	not willing or able to accept the legal risks of non-compliance.
> 
> In the linked case the LLM is basically doing a glorified search and
> replace. There seems to be no danger of accidentally regurgitating any
> training data which is where the worry about inadvertent copyright
> infringement comes from.
> 
> That said in my experience generally any code that does come out from
> these tools tends to match the local code style and patterns pretty
> well.

Making the code original, too.

> As a general purpose boilerplate generator they are probably
> better than a lot of people at this point.
> 
> There has been some case law now that says LLM output could be
> un-copyrightable depending on how involved the user was in the iteration
> of the code. I suspect there is still more to come.

Waiting for courts to settle anything means waiting years, while
the industry has mostly moved on.

> >
> >
> > But, since this was written, Red Hat's Richard Fontana and Chris Wright
> > published this piece:
> > https://www.redhat.com/en/blog/ai-assisted-development-and-open-source-navigating-legal-issues
> >
> >
> > Saying, in particular "
> > 	We understand this concern, but the DCO has never
> > 	been interpreted to require that every line of a contribution must be
> > 	the personal creative expression of the contributor or another human
> > 	developer. 
> > "
> >
> > I propose adopting linux's rules instead:
> > https://docs.kernel.org/process/coding-assistants.html
> >
> > which boils down to attribution.
> 
> attribution and *ownership*. I think the key point of the policy is to
> make the actual engineer signing the DCO the responsible one for
> generating, testing and validating the code. It is strongly trying to
> suggest that vibe-coded slop isn't wanted.
> 
> I still have concerns about the quality of the code and the
> "understanding" these models have. They can generate very convincing
> rationales for their decisions but they also are prone to being
> over-verbose and over-complicating the solutions. They have a tendency
> to chase down rabbit holes in the code and get lost while making wilder
> and more invasive changes to try and get things working.


That's up to maintainers though.

> That said for personal scripts or random experiments the ability to
> quickly get to a PoC is pretty great.

Patch above is beyond that.

> I think there is also scope for using LLMs for things that aren't
> directly writing code:
> 
>   - code review
>   - investigation
>   - generating test cases
>   - polishing documentation
> 
> and I wonder if we should spend some more time investigating the
> performance and pitfalls of LLMs before we open the flood gates to the
> code.

Who would do the investigating?

> -- 
> Alex Bennée
> Virtualisation Tech Lead @ Linaro