Re: on ai generated and code provenance

[Kevin Wolf <kwolf@redhat.com>]

Am 26.05.2026 um 20:03 hat Michael S. Tsirkin geschrieben:
> 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?

The above is just what I was thinking of suggesting myself. I didn't
mean to imply that I'm opposed to anything else, but just thought I'd
post it as an example of fairly obvious things we could allow.

Of course, it also shows my own pain points. I don't see that much use
in it for generating code for QEMU proper, because these changes tend to
be few lines and I have an opinion on each of the lines - tests are the
opposite, lots of boilerplate and I don't care much how elegant they
are because nothing else will build on them anyway.

So yes, trivial patches is another obvious starting point. The challenge
there is defining the line where a patch stops being trivial. So I'm not
completely sure if making this distinction in a policy is a good idea;
maybe practically speaking it has to be all or nothing in terms of
creativity (for lack of a better word).

As an aside, personally, I'm not convinced that AI can be a "better
sed". If it's really about mechanical changes, I think the resulting
patch is much more reviewable if the agent doesn't modify the code, but
just generate the sed command line or the Coccinelle patch and that is
included in the commit message. Reviewers can then just review that and
then reproduce the result themselves for comparison. This is impossible
with AI prompts and agents do tend to forget an instance of something to
replace here and there, so you do have to review the result carefully.

But none of these "better sed" problems need to handled in an AI policy.
If a patch is hard to review, the maintainer will already reject it on
those grounds.

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

Contaminated in what respect?

Quality? Might be because of malicious intentions or just because the
model happens to be bad at a specific question. Review and testing must
be able to catch quality problems. I don't think this is different from
any other contributions.

Copyright? If so, then we're back to "can you really sign the DCO?"

Something completely different?

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

Great. Let's see what others think.

Kevin