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

[Kevin Wolf <kwolf@redhat.com>]

Am 30.09.2026 um 14:54 hat Philippe Mathieu-Daudé geschrieben:
> Hi,
> 
> On 30/9/26 10:54, Paolo Bonzini 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 and enforce.
> > 
> > Even a simple code review task these days may result in the agent
> > suggesting code changes, or producing a useful test case to verify the
> > presence or absence of a bug.  A hardline interpretation of the policy
> > makes it hard to use AI even for tasks that are explicitly allowed.
> > 
> > On top of this, several maintainers have pointed out that contributions
> > that can be reasonably suspected to be AI-assisted or more have been
> > posted and included.  Some of these contributions are actually of very
> > high quality; it seems that the mailing list-based contribution process
> > has mostly protected QEMU from low quality patches.  A prohibition on
> > AI puts maintainers in a difficult position: on one hand the DCO process
> > lets them rely on the submitter's certification of origin, on the other
> > hand maintainers are supposed to know and implement the process policies.
> > 
> > Since the policy has been written, other projects have discussed and
> > taken their stance on AI contributions.  These vary from full prohibition
> > (though typically motivated by social reasons rather than legal, e.g.
> > for Zig) to limited use (e.g. GCC, allowing small contributions and
> > tests to use AI), to cautious experimentation.
> > 
> > This proposed policy seeks to implement the cautious experimentation
> > approach, inspired mostly by the Rust project's policy and by Software
> > Freedom Conservancy's own recommendations on LLMs and generative AI.
> > 
> > Relying on Conservancy's legal guidance allows us to focus on the
> > interaction between contributors and maintainers.  Conservancy in
> > particular provides this point to alleviate the concern that motivated
> > the policy, about whether the submitter has the legal right to contribute
> > the code and about unintentional reproduction of copyrighted code:
> > 
> >     "Copyleft Everything" remains the best viable and safest approach
> >     Certainly those who want to release FOSS under non-copyleft licenses
> >     have more to worry about when using these tools.
> > 
> > While we shouldn't treat copyleft as a silver bullet, it is effective
> > as part of a defense in depth strategy that includes, for example,
> > "de minimis" thresholds and `AGENTS.md` instructions that encourage user
> > participation in the design.
> > 
> > Therefore, the revised policy considers QEMU's copyleft to be a viable
> > approach to any unanswered legal questions about AI-generated
> > contributions and their copyright status.  This lets the policy
> > focus on the topic of what AI-assisted contributions require of
> > maintainers.
> > 
> > In that respect, the Rust project's policy combines two unusual ideas.
> > One is to hold them to a higher standard, in the spirit of using AI to
> > work "better, not faster"; the other is to require "pre-arrangement" for
> > "changes that are originally created by an LLM".  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.
> > Pre-arrangement is an attempt to balance the shift of effort from the
> > developer to the maintainer, and the QEMU policy includes the same
> > provision.
> > 
> > Going full circle to the reason why we might need to review the
> > policy, there is the question of how to make sure policy is applied.
> > QEMU maintainers have already experimented with using AGENTS.md files;
> > subsequent patches will also try to embody the "work better, not faster"
> > mantra into an AGENTS.md file.  Nevertheless, some explicit prohibitions
> > should be included in the policy, and they are indeed.  The list is short
> > and based on the Rust policy and the GStreamer AGENTS.md file.
> > 
> > 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,
> > and to scope areas for which Signed-off-by cannot guarantee full control
> > of provenance.
> > 
> > In any case, use of AI does not relax any other contribution requirement:
> > authors still need to comply with the DCO (declaring that they have
> > corporate authorization to contribute, for example) and take technical
> > responsibility for their work.
> > 
> > [Commit message largely based on discussions with Daniel Berrangé,
> >   Alistair Francis, Peter Maydell, Kevin Wolf and others. - Paolo]
> > 
> > Cc: Michael S. Tsirkin <mst@redhat.com>
> > Cc: Alex Bennée <alex.bennee@linaro.org>
> > Cc: Alistair Francis <alistair.francis@wdc.com>
> > Cc: BALATON Zoltan <balaton@eik.bme.hu>
> > Cc: Daniel P. Berrangé <berrange@redhat.com>
> > Cc: Fabiano Rosas <farosas@suse.de>
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Cc: Warner Losh <imp@bsdimp.com>
> > Cc: Philippe Mathieu-Daudé <philmd@linaro.org>
> > Link: https://lore.kernel.org/qemu-devel/20260524083329-mutt-send-email-mst@kernel.org/T/
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> >   docs/devel/code-provenance.rst |  71 +----------
> >   docs/devel/index-process.rst   |   1 +
> >   docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
> >   AGENTS.md                      |  42 +++++--
> >   scripts/checkpatch.pl          |   5 +-
> >   5 files changed, 252 insertions(+), 80 deletions(-)
> >   create mode 100644 docs/devel/llm-usage.rst
> 
> 
> > +.. _ai-used-for:
> > +
> > +Commit messages for AI-assisted changes
> > +'''''''''''''''''''''''''''''''''''''''
> > +
> > +In order to disclose your usage of AI/LLM tools, add an ``AI-used-for:``
> > +line before the :ref:`Signed-off-by <code-provenance>` line.  The trailer
> > +is both a reminder of your DCO obligations and a guide to reviewers.  The
> > +text is one or more of ``code``, ``tests``, ``docs``, ``research``, possibly
> > +followed by an explanation in parentheses:
> > +
> > +To be able to certify the provenance of AI/LLM-generated code that you submit
> > +to QEMU, you must follow the policies outlined in this document and in
> > +QEMU's ``AGENTS.md``.  **By using 'AI-used-for', a contributor both
> > +identifies areas of the patch that involved use of AI/LLM, and also
> > +attests that their usage of AI/LLMs was in compliance with the policies
> > +outlined in this document.**
> > +
> > +.. code-block:: none
> > +
> > +     AI-used-for: tests, docs
> > +     AI-used-for: code
> > +     AI-used-for: code (refactoring)
> > +     AI-used-for: code (prototype)
> > +     AI-used-for: research
> > +
> > +``AI-used-for`` should not be included for "background" usage such as
> > +autocomplete or obtaining a pre-review of the patch.
> > +
> > +Do not include your prompts or summarize the conversation in the commit
> > +message or cover letter.  Extract any information that is relevant to the
> > +reviewer and include it in commit messages, cover letters or code comments.
> > +
> > +QEMU does *not* use ``Assisted-by``, ``Co-authored-by`` or ``Generated-by``
> > +trailers to indicate AI usage.  In particular, do not specify the exact
> > +AI model or tool used to create the commit.
> > +
> > +Deterministic tooling (sed, coccinelle, formatters) is out of scope for
> > +the trailer, but should be mentioned in the commit message.
> 
> I noticed a discrepancy in a method docstring and a particular use case.
> Since the method is used distinctly in various configurations (KVM, TCG,
> RISCV, ARM) I asked a LLM "using the semcode tools only and deliberately
> ignoring the method documentation, look at all the call tree and how the
> passed arguments are used and explain what is expected of this method
> to a junior engineer" then once I understood out what was wrong I could
> update the docstring in the header. No code / comment generated by the
> LLM ends in the commit / repository. IIUC this use case is compatible
> with the new policy.

I would think that this is compatible even with the current policy:

  **Current QEMU project policy is to DECLINE any contributions which are
  believed to include or derive from AI generated content. This includes
  ChatGPT, Claude, Copilot, Llama and similar tools.**

  **This policy does not apply to other uses of AI, such as researching APIs
  or algorithms, static analysis, or debugging, provided their output is not
  included in contributions.**

You didn't include any AI generated content in your submission, and
"researching APIs" is quite literally what you did, so it's explicitly
out of scope for the policy.

> What trailer should I use?
> 
>   AI-used-for: research
>   AI-used-for: code (audit)
>   AI-used-for: code audit (semcode)

None, because your patch doesn't include AI generated content.

("AI-used-for: research" looks like it might be meant for such cases,
but I agree with Dan that we shouldn't have it because the project
honestly shouldn't care.)

Kevin