Re: on ai generated and code provenance

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

On Tue, May 26, 2026 at 07:43:35PM +0200, Kevin Wolf wrote:
> Am 24.05.2026 um 14:42 hat Michael S. Tsirkin geschrieben:
> > 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.
> > 
> > 
> > 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 never found that blog post particularly convincing, especially because
> they acknowledge a concern:
> 
>     There are two versions of this concern. The first is practical: that
>     an AI tool could covertly insert excerpts of proprietary (or
>     license-incompatible) code into an open source project, potentially
>     creating legal risk for maintainers and users. The second is broader
>     and more philosophical: that large language models, trained on vast
>     amounts of open source software, are essentially misappropriating
>     the community’s work, producing outputs stripped of the obligations
>     that open source licenses require.
> 
>     We think these concerns deserve to be taken seriously.
> 
> The second one is essentially what I understood the QEMU policy to be
> about. Unfortunately, the blog post then goes on to only ever deal with
> the first one and ignore the second one that seems more relevant for us.
> 
> So yes, the DCO isn't about "personal creative expression" or whatever
> (and nobody suggested it is, this is a strawman), but it's about whether
> the submitter has the legal rights to submit the code. And that's
> exactly the question we decided we don't want to take a risk on.
> 
> 
> So if that part isn't helpful, what has changed since we introduced the
> AI policy? It's a few points:
> 
> 1. While AI has been in use for a while now, we haven't seen projects
>    accepting AI generated code/content get into big trouble. While it
>    could still happen in the future, it might be an indication that the
>    probability of the risk hitting us is not that high.
> 
> 2. The useful part of the blog post is that it tells us that Red Hat
>    considers the risk acceptable. This can inform our assessment of the
>    risks, though of course there might be a significant difference in
>    the impact of the risk for a company with a legal department and an
>    open source community consisting mainly of developers acting as
>    individuals.
> 
>    I think it's obvious that if the QEMU project gets involved in a
>    legal case, we have a problem (at the very least long lasting
>    distraction from actual work on QEMU), even if we didn't do anything
>    wrong and a good lawyer would easily win the case.
> 
> 3. It was easy to just outright ban AI while its results were usually
>    not really usable anyway. This has changed meanwhile, so it's much
>    harder to maintain an absolute ban.
> 
>    It's not really the best use of my time to look at the idea in
>    AI-generated test cases and then rewrite them from scratch so I can
>    actually submit them. (On the other hand, I think my rewritten
>    submissions were always better and more maintainable than what AI
>    produced initially, so there's that.)
> 
> So while my perspective is a lot more nuanced than yours, I do see a
> shift in the balance and was actually thinking of suggesting a change of
> the policy myself.
> 
> What I was thinking of was allowing AI-generated content in places where
> it's at least easy to revert if there is ever a problem with it: Tests,
> documentation etc., but not core code that lots of other things depend
> on and that will have evolved a lot when we notice a problem and for
> which throwing away is simply not an option.

OK. what about trivial changes? Using AI as a better sed?

> > I propose adopting linux's rules instead:
> > https://docs.kernel.org/process/coding-assistants.html
> > 
> > which boils down to attribution.
> 
> What would we actually do with the detailed information? Why do we care
> which model was used? Is this helpful commit metadata or is it just free
> advertising for a handful of companies?

I presume, if a specific model is somehow declared "contaminated" so we
can locate its output?

> I think I would see more use in a tag like (better name welcome):
> 
>     AI-used-for: [code|tests|docs|commit message]...
> 
> Kevin

I surely don't mind.

-- 
MST