Re: on ai generated and code provenance

[Kevin Wolf <kwolf@redhat.com>]

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.

> 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 think I would see more use in a tag like (better name welcome):

    AI-used-for: [code|tests|docs|commit message]...

Kevin