Re: on ai generated and code provenance

["Alex Bennée" <alex.bennee@linaro.org>]

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

>
>
> 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 said for personal scripts or random experiments the ability to
quickly get to a PoC is pretty great.

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.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro