Re: [PATCH v2] docs/devel: relax policy on AI-generated contributions

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

On Fri, May 29, 2026 at 04:34:45PM +0100, Peter Maydell wrote:
> On Fri, 29 May 2026 at 10:46, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > Until now QEMU's code provenance policy declined any contribution
> > believed to include or derive from AI-generated content.  A blanket ban
> > was easy to maintain while LLM output was rarely usable on its own, but
> > as the tools improved an absolute prohibition has become harder to
> > justify.
> >
> > The concern that motivated the policy is unchanged, and it is worth stating
> > precisely: the DCO is about whether the submitter has the legal right to
> > contribute the code, not about "creative expression".  While the status of
> > LLM output seems to be converging towards non-copyrightability, questions
> > around unintentional reproduction of copyrighted code are still open.
> > What has shifted is the balance of risk:
> >
> > - projects accepting AI-assisted content have not run into serious
> >   legal trouble so far, which suggests the probability of the risk
> >   materializing is not high;
> >
> > - other organizations, such as Red Hat[1], have assessed the risk as
> >   acceptable -- though a community of individual developers does not
> >   have the legal backing of a company, and even an unfounded dispute
> >   would be a long-lasting distraction from work on QEMU.
> >
> > Nevertheless, even Red Hat mentions that "the possibility of occasional
> > replication cannot be ignored".  In QEMU's view, attentiveness and
> > oversight are not a practical way to address this; yet as a copyleft
> > project, copyright and code provenance are of utmost importance to us.
> > Therefore, it remains prudent to only permit AI assistance where the
> > ramifications of copyright violations are at least easy to revert and
> > unlikely to spread: tests, documentation, mechanical changes, and small
> > bug fixes.  Core code that other things depend on, and that cannot
> > simply be thrown away once a problem is noticed long after the fact,
> > stays off-limits without prior agreement from a maintainer.
> 
> This all makes sense to me, except for the part where we allow
> a maintainer to say "actually it's OK". Where our justification
> for not wanting AI contributions rests on "it's too much burden
> on maintainers to have to deal with and review it", allowing an
> individual maintainer to say "I'm OK with that burden in this case
> or for this particular contribution" logically follows as a
> possible relaxation. But if as a project we want to limit the
> blast-radius if we find we have to rip out a hypothetical tainted
> contribution, shouldn't that mean that we hold that as a project-wide
> line, rather than leaving it up to the opinion of the individual
> maintainer ?

I guess, the maintainer can judge that the code is unique and qemu
specific enough, and follows from what it is doing automatically enough,
that the chances it is accidentally copying something are nil?


> > Related to this, and already visible in the incredible uptick in
> > security reports, is the question of maintainer burnout and the shift in
> > effort from the author to the reviewer of the code.  AI lowers the cost of
> > producing a patch but does nothing to lower the cost of understanding and
> > reviewing one; if anything it raises it, since a reviewer can no longer
> > assume that the submitter has reasoned through every line.  The limits
> > above work just as much to keep the volume of review work sustainable.
> >
> > Revise the policy according to the above considerations, and introduce the
> > "AI-used-for:" trailer as a record of where AI was used.  The standard is
> > slightly different from the more usual "Assisted-by"; the intention is for
> > the metadata to provide more information for reviewers to judge the result.
> >
> > In any case, use of AI does not relax any other contribution requirement:
> > authors still comply with the DCO and take responsibility for the whole
> > patch via Signed-off-by.
> >
> > [Commit message largely based on
> >  https://lore.kernel.org/qemu-devel/ahXbxzB4C_lr6b0N@redhat.com/, by
> >  Kevin Wolf. - Paolo]
> 
> > +**Documentation and code comments**
> > +  While AI can help draft text, it still requires significant human
> > +  oversight.  Pay attention to the organization and flow of the generated
> > +  text, and strictly fact-check all technical details as LLMs are prone
> > +  to being confidently wrong.
> 
> I think the application to documentation and comments is the part
> I'm least enthusiastic about here.

But I am very enthusiastic about less agrammatical english in both.
AI is super helpful for non native speakers.

> For changes to code, we have at
> least some guardrails on the AI output, in the fact that it has to
> compile and to pass tests. For changes to documentation, the
> only guardrails are human eyeballs.
> 
> Also both comments and documentation ideally are a record of
> what we intended the behaviour to be. If an LLM is effectively
> autogenerating something documentation-shaped from the code we
> lose that.
> 
> -- PMM