[RFC PATCH v3 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[RFC PATCH v3 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Paolo Bonzini]

WARNING: this is *intentionally* a full U-turn from the previous policy
and discussions.  This is not a refusal of the arguments presented in
those discussions.  Also, it is still a request for comments.

I've explained in v2 my reason to "try something else".  On one hand
attempting to introduce small carve-outs did not work due the impossibility
of reaching a widespread consensus on this topic.  On the other hand,
some contributors have been posting AI-generated patches or even larger
series, most likely in good faith as they predated the introduction
of an AGENTS.md file.  This shows that AI can be used for useful work
on QEMU, ranging from small incremental improvements to new device models.

This is not a free-for-all, which is not a good idea either.  Maintainers
will want to apply their own considerations (see [1] for a good list),
and contributors should take into account the maintainers' preferences.

This is an attempt at building a process for contributions that use AI,
heeding Conservancy's advice to not shun contributors or maintainers
belonging to either camp, and keeping in mind that maintainer burnout
is the one thing we have to avoid.  Some of these processes already
existed, but the possibility of AI contribution makes it all more
important to write them down for everyone.

There was not much discussion in the previous version.  I tried to rein
in some of the language that allowed too wide interpretations, to apply
the changes that were suggested, and to clarify those choices that drew
more remarks.

As usual, the text including the commit messages is informed by discussion
with plenty of people, mentioned in the Cc trailers of patch 1.

Paolo

v2->v3:
- remove parser example, replace with "adaptations of existing code"
- when LLMs are used for boilerplate, "highly recommend" disclosure
  for "non-trivial, functional code".  The idea here is to avoid
  having to disclose using AI to apply e.g. changes related to
  automatic code review, and leaving people some leeway.
- clarify split between DCO (legal right to submit code in general)
  and AI-used-for acknowledging that the submitter cannot audit LLM
  output against e.g. the training data.
- clarify the defense-in-depth/swiss-cheese approach to limit the
  risk of copyright violations from LLM output
- mention that pre-arrangement is not an entirely new concept
- mention that maintainers can demand larger changes than for human-written code
- do not mention inclusion of the prompt
- add checkpatch.pl hunk, changing the phrasing of "no AI" lint
- rebase AGENTS.md on top of existing file, split
- drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini

[1] https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/

Paolo Bonzini (4):
  docs/devel: relax policy on AI-generated contributions
  AGENTS.md: add final instructions
  AGENTS.md: let agents know what the participation rules are
  AGENTS.md: make the human part of the design process

 docs/devel/code-provenance.rst |  71 +-----------
 docs/devel/index-process.rst   |   1 +
 docs/devel/llm-usage.rst       | 202 +++++++++++++++++++++++++++++++++
 AGENTS.md                      | 137 +++++++++++++++++++---
 scripts/checkpatch.pl          |   5 +-
 5 files changed, 336 insertions(+), 80 deletions(-)
 create mode 100644 docs/devel/llm-usage.rst

-- 
2.55.0

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

[Paolo Bonzini]

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       | 202 +++++++++++++++++++++++++++++++++
 AGENTS.md                      |  42 ++++---
 scripts/checkpatch.pl          |   5 +-
 5 files changed, 241 insertions(+), 80 deletions(-)
 create mode 100644 docs/devel/llm-usage.rst

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index 65b8f232a08..7403961378e 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -128,6 +128,10 @@ that are commonly used during QEMU development:
    suggestions for how to change a patch, it is good practice to credit them
    by including a ``Suggested-by`` tag.
 
+ * **AI-used-for**: when AI/LLM tools were used to produce the patch, this tag
+   discloses what they were used for.  See :ref:`llm-usage` for the cases in
+   which it is required.
+
 Subsystem maintainer requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -282,68 +286,5 @@ boilerplate code template which is then filled in to produce the final patch.
 The output of such a tool would still be considered the "preferred format",
 since it is intended to be a foundation for further human authored changes.
 Such tools are acceptable to use, provided there is clearly defined copyright
-and licensing for their output. Note in particular the caveats applying to AI
-content generators below.
-
-Use of AI-generated content
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TL;DR:
-
-  **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.**
-
-The increasing prevalence of AI-assisted software development results in a
-number of difficult legal questions and risks for software projects, including
-QEMU.  Of particular concern is content generated by `Large Language Models
-<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs).
-
-The QEMU community requires that contributors certify their patch submissions
-are made in accordance with the rules of the `Developer's Certificate of
-Origin (DCO) <dco>`.
-
-To satisfy the DCO, the patch contributor has to fully understand the
-copyright and license status of content they are contributing to QEMU. With AI
-content generators, the copyright and license status of the output is
-ill-defined with no generally accepted, settled legal foundation.
-
-Where the training material is known, it is common for it to include large
-volumes of material under restrictive licensing/copyright terms. Even where
-the training material is all known to be under open source licenses, it is
-likely to be under a variety of terms, not all of which will be compatible
-with QEMU's licensing requirements.
-
-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.
-
-The QEMU project thus requires that contributors refrain from using AI content
-generators on patches intended to be submitted to the project, and will
-decline any contribution if use of AI is either known or suspected.
-
-Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's
-ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content
-generation agents which are built on top of such tools.
-
-This policy may evolve as AI tools mature and the legal situation is
-clarified.
-
-Exceptions
-^^^^^^^^^^
-
-The QEMU project welcomes discussion on any exceptions to this policy,
-or more general revisions. This can be done by contacting the qemu-devel
-mailing list with details of a proposed tool, model, usage scenario, etc.
-that is beneficial to QEMU, while still mitigating issues around compliance
-with the DCO.  After discussion, any exception will be listed below.
-
-Exceptions do not remove the need for authors to comply with all other
-requirements for contribution.  In particular, the "Signed-off-by"
-label in a patch submission is a statement that the author takes
-responsibility for the entire contents of the patch, including any parts
-that were generated or assisted by AI tools or other tools.
+and licensing for their output. Note in particular the caveats applying to
+:ref:`AI content generators <llm-usage>`.
diff --git a/docs/devel/index-process.rst b/docs/devel/index-process.rst
index 5807752d704..ce0f4e73197 100644
--- a/docs/devel/index-process.rst
+++ b/docs/devel/index-process.rst
@@ -13,6 +13,7 @@ Notes about how to interact with the community and how and where to submit patch
    maintainers
    style
    submitting-a-patch
+   llm-usage
    code-provenance
    trivial-patches
    stable-process
diff --git a/docs/devel/llm-usage.rst b/docs/devel/llm-usage.rst
new file mode 100644
index 00000000000..972436828a6
--- /dev/null
+++ b/docs/devel/llm-usage.rst
@@ -0,0 +1,202 @@
+.. _llm-usage:
+
+Use of AI-generated content
+===========================
+
+.. warning::
+
+   Please read the below policy before using AI to contribute code or
+   documentation to QEMU.  This applies to ChatGPT, Claude, Copilot,
+   Llama, and similar tools.
+
+The QEMU project does not want to introduce restrictions on the tools
+that contributors use for their work on the project.  However,
+the increasing prevalence of AI-assisted software development,
+and especially the use of content generated by `Large Language Models
+<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs),
+poses a number of difficult questions.
+
+Risks to open source projects include maintainer burnout from an
+increased number of contributions, as well as the risk to the project
+from unintentional inclusion of copyrighted material in the LLM's output.
+In order to mitigate these risks, the QEMU project limits the way
+in which use of the output of generative AI can be included
+in contributions to QEMU.
+
+The main guidelines for use of generative AI tools are roughly
+as follows:
+
+- It's fine to use LLMs to answer questions, analyze, distill,
+  refine, check, suggest, review. Use of LLMs to *create* is limited.
+
+- If in doubt, disclose any use of AI tools other than simple code
+  completion and code review.
+
+- LLMs are allowed as a tool to write *better*, not *faster*.
+
+.. note:: **Use of AI does not remove the need for authors to comply
+          with all other requirements for contribution.**  In particular,
+          the ``Signed-off-by`` label in a patch submission is a statement
+          that the author takes responsibility for the entire contents of
+          the patch, certifying that their patch submission is made in
+          accordance with the rules of the :ref:`Developer's Certificate of
+          Origin (DCO) <dco>`.
+
+          Since a submitter cannot audit LLM output against its training
+          data, the DCO is paired with :ref:`metadata in the commit message
+          <ai-used-for>` about AI-generated parts.  The DCO still certifies
+          that the contributor has the legal right to submit code in general.
+
+Prohibited use of AI
+''''''''''''''''''''
+
+The QEMU community is a collaboration between humans, not AI agent
+façades. The following items MUST be written by humans:
+
+- cover letters and commit messages
+
+- responses to reviewer comments
+
+- issue descriptions or comments
+
+Light copy editing of human-written text with an AI is allowed.
+
+Repeated violations of this rule may be treated as a :ref:`code_of_conduct`
+violation.
+
+An exception is made for issues for defects detected by specialized
+tooling, including fuzzers and LLM-assisted defect detection. Such issues
+must be reviewed by a human before creation, must be created by a human
+and communication with maintainers must be done by a human, but including
+the verbatim tool output in the issue description is explicitly allowed.
+
+LLM-assisted and LLM-created contributions
+''''''''''''''''''''''''''''''''''''''''''
+
+Use of generative AI tools for code contributions generally falls into
+four buckets:
+
+- "background" assistance, such as completion and code review.  This does
+  not need disclosure, however you are expected to examine and understand
+  any code or any changes produced by the tool.
+
+- small LLM-assisted bugfixes (as a rule of thumb, below 10 lines of code)
+  are allowed with disclosure.  Splitting a submission in multiple parts
+  is **not** a valid way to bypass this rule; repeated, frequent posting
+  of such fixes must follow the rule for full contributions.
+
+- use of LLMs to help generating parts of a larger patch---test cases,
+  adaptations of existing code, boilerplate code for a new API, a tool to
+  help performing mechanical changes, etc.  These are generally allowed;
+  disclosure is highly recommended for non-trivial, functional code.
+
+- large, heavily LLM-assisted contributions where LLMs write large parts
+  of functional code.  These are only allowed if *pre-arranged*,
+  *high-quality* and *well-tested*.
+
+The last case (*"LLM-created contribution"*) is the one that requires
+a more careful approach.  In particular:
+
+- "Pre-arranged" means that a maintainer has communicated ahead of time,
+  for example on `IRC or the QEMU mailing
+  list <https://www.qemu.org/contribute/>`__, that they are willing
+  to review an LLM-created contribution.
+
+- "High-quality" means that the contributor must apply the same judgment
+  that would be applied to other code changes.  Contributors must invest
+  substantial time reviewing their contributions, curating them, and
+  understanding them in depth; in particular, you are still expected to
+  :ref:`understand and explain your changes
+  <write_a_meaningful_commit_message>` and the rationale behind them.
+
+- "Well-tested" means the LLM-created contributions will be held to a
+  higher standard than human-created ones, because LLMs make it easier
+  to write tests.  There are no exceptions for "writing the tests seems
+  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.
+
+.. note::
+    Pre-arrangement ensures maintainers have bandwidth for review before a
+    contributor invests effort in creating a large change.  This is not
+    a new concept in QEMU: maintainers have always encouraged early
+    alignment on mailing lists or IRC prior to major architecture or
+    subsystem refactoring.
+
+    Maintainers have freedom to determine what constitutes "high quality".
+    Because LLMs lower the cost of patch generation, maintainers may demand
+    significantly larger changes than for purely human-written code.
+
+.. _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:
+
+.. 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.
+
+Motivation
+''''''''''
+
+There is not a consensus within the QEMU project---and likely never will
+be---about when/how/where it is acceptable to use AI-based tools.  Many
+members of the QEMU project and community find value in AI; many others
+feel that its negative impact on society and the climate are severe enough
+that no use is acceptable.  Still others are working out their opinion.
+
+In accordance with Software Freedom Conservancy's recommendations:
+
+- the project seeks to both support those contributors who outright reject
+  generative AI systems, and to not shun those who choose to use them;
+
+- we consider QEMU's copyleft to be a viable approach to the unanswered
+  legal questions about AI-generated contributions and their copyright
+  status;
+
+- we encourage contributors not to overuse LLMs, and to *add* them to
+  their existing skills and tools instead of replacing them.
+
+A common source of grief for maintainers is the (often valid) impression
+that AI enables contributions without understanding the effort they take
+for those who process them.  Effectively, this shifts a major part of the
+burden from the contributors to the maintainers---the scarcest resource
+in any free software project, not just QEMU.  Pre-arrangement, and the
+size limit for small contributions, try to avoid putting extra demand
+on maintainers due to LLM-assisted work.
+
+
+Sources
+'''''''
+
+This policy was informed by:
+
+- `Recommendations When Using LLM-backed Generative AI Systems for
+  FOSS Contributions <https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html>`__
+
+- `Rust project LLM Usage Policy <https://forge.rust-lang.org/policies/llm-usage.html>`__
+
+- `GStreamer AGENTS.md file <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/d08375499c279/AGENTS.md>`__
+
diff --git a/AGENTS.md b/AGENTS.md
index 5e3fc071420..2fa4b4686cf 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,21 +1,37 @@
 # Agent Guidelines for the QEMU Project
 
-As an agent you MUST abide by the "Use of AI-generated content" policy
-in `docs/devel/code-provenance.rst` at all times.
+QEMU is a cross-platform emulator and virtualizer. Due to the complexity
+of the domain and codebase, and the interactions therein, the QEMU
+project relies extensively on the effort of **human reviewers**, which
+is **a scarce resource**.
 
-You are permitted to assist users only in the following scenarios:
+There are strictly-enforced rules for you, the agent, to participate in the
+project.
 
-- researching APIs or algorithms
-- static analysis
-- debugging
-- local experiments not intended to be upstreamed
-- trivial non-copyrightable changes
+## Helping the human to respect project policy
 
-However agent output can not be included in any upstream
-contributions. If a request falls outside these permitted categories
-(e.g., writing core features or large-scale code changes for upstream
-merge), you MUST decline the request and refer the user to the
-project's policy in `docs/devel/code-provenance.rst`.
+QEMU's policy for AI-assisted work requires the human to develop in depth
+familiarity with contributions and disclose use of agents to write parts
+of the code.
+
+Background assistance such as review or explanation does not require disclosure.
+Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
+intended for contribution; committing agent-generated material; or advising on
+disclosure or pre-arrangement. It is not required for review, explanation, or
+other background assistance that produces no contribution content.
+
+When agent-generated content is included in a contribution, remind the human
+to determine the appropriate disclosure under `docs/devel/llm-usage.rst`.
+In particular, contributions where you write large parts of the functional
+code may only be submitted if a maintainer has agreed **beforehand** to review
+them.  Tell the human about this as soon as the work looks likely to grow to
+that size, well before the patches are written.
+
+If you commit agent-generated material, include an `AI-used-for:` trailer
+before `Signed-off-by`. Do not omit it by folding the material into a larger
+commit.  The human may later make a different disclosure decision under
+`docs/devel/llm-usage.rst`, after independently reworking and integrating
+the material.
 
 ## Security Policy
 
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9838a641785..d881cf29375 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1829,8 +1829,9 @@ sub process {
 		      $1 =~ /\bcopilot\b | \bchatgpt\b | \bcodex\b | \bcursor\b |
 			     \bgemini\b | \bllama\b | \bnoreply\b | \[bot\] |
 			     \bclaude\b.*(?:opus|sonnet|fable|haiku|anthropic\.com)/xi))) {
-			ERROR("QEMU does not allow using AI for contributions, " .
-				"see docs/devel/code-provenance.rst\n" . $herecurr);
+			ERROR("do not use \"$line\" to credit an AI agent, " .
+				"use the \"AI-used-for\" trailer instead; " .
+				"see docs/devel/llm-usage.rst\n" . $herecurr);
 		}
 
 # Check for duplicate trailers and self-review
-- 
2.55.0

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

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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.
<snip>
> +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:
> +
> +.. 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.

While experimenting with these tags I had done a patches with:

  AI-used-for: created qtest boilerplate based on bug report
  AI-used-for: importing and validating test case
  AI-used-for: initial prototype changes
  AI-used-for: initial draft of test
  AI-used-for: fetch issue, apply proposed patch, verify build and qtests

Of the last one I expect "fetch issue, apply proposed patch, verify
build" is superfluous as its really just automation but the converting a
bug test case into a proper qtest case is worth flagging as it is a
transformation worth getting called out?

Either way:

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 10:22:28AM +0100, Alex Bennée wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > 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.
> <snip>
> > +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:
> > +
> > +.. 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.
> 
> While experimenting with these tags I had done a patches with:
> 
>   AI-used-for: created qtest boilerplate based on bug report
>   AI-used-for: importing and validating test case
>   AI-used-for: initial prototype changes
>   AI-used-for: initial draft of test
>   AI-used-for: fetch issue, apply proposed patch, verify build and qtests
> 
> Of the last one I expect "fetch issue, apply proposed patch, verify
> build" is superfluous as its really just automation but the converting a
> bug test case into a proper qtest case is worth flagging as it is a
> transformation worth getting called out?

IMHO "AI-used-for"  only needs to call out things that directly resulted
in code being authored, so I'd agree that the last one is out of scope.

For the others, my benchmark would be, if a reviewer points out a mistake
in the patch, is the contributor going to want to blame the AI. If so,
then the use of AI should have been disclosed.

They shouldn't be blaming the AI anyway, as they need to take responsibility
for explaining all decisions, but that's a tangent :-)

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Kevin Wolf]

Am 21.09.2026 um 11:22 hat Alex Bennée geschrieben:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > 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.
> <snip>
> > +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:
> > +
> > +.. 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.
> 
> While experimenting with these tags I had done a patches with:
> 
>   AI-used-for: created qtest boilerplate based on bug report
>   AI-used-for: importing and validating test case
>   AI-used-for: initial prototype changes
>   AI-used-for: initial draft of test
>   AI-used-for: fetch issue, apply proposed patch, verify build and qtests

I feel this is way too verbose. It almost looks like a version history
of the work submitted in the patch. I'm not interested in this at all,
I'm only interested in the final result and which parts I have to assume
to contain AI generated content.

> Of the last one I expect "fetch issue, apply proposed patch, verify
> build" is superfluous as its really just automation but the converting a
> bug test case into a proper qtest case is worth flagging as it is a
> transformation worth getting called out?

If I understand correctly what really happened there, it could be:

    AI-used-for: tests (based on bug #1234)

With the wordy, but unspecific tags above, I'm not completely sure if
"code" ought to be included, too. It gives a lot of irrelevant
information that I have to filter out when reading, but it missed the
important part.

Kevin

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Mon, 21 Sep 2026, Paolo Bonzini wrote:
> +Prohibited use of AI
> +''''''''''''''''''''
> +
> +The QEMU community is a collaboration between humans, not AI agent
> +façades. The following items MUST be written by humans:

Is that correct English spelling of facade? I don't mind it, just looks a 
bit fancy to me.

> +
> +- cover letters and commit messages
> +
> +- responses to reviewer comments
> +
> +- issue descriptions or comments
> +
> +Light copy editing of human-written text with an AI is allowed.

What does "copy editing" mean? Should this say that writing the above by a 
human in native language and translating by LLM to English is allowed? For 
translation it's probably good enough now and that could allow 
contributors who can't write English but I agree the LLM should not 
generate the text for the listed items.

Regards,
BALATON Zoltan

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

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 12:46:17PM +0200, BALATON Zoltan wrote:
> On Mon, 21 Sep 2026, Paolo Bonzini wrote:
> > +Prohibited use of AI
> > +''''''''''''''''''''
> > +
> > +The QEMU community is a collaboration between humans, not AI agent
> > +façades. The following items MUST be written by humans:
> 
> Is that correct English spelling of facade? I don't mind it, just looks a
> bit fancy to me.

façade would be the more correct option, but in practice I rarely see
it used, presumably becase there is a  'c' key on keyboards and not
a 'ç' and people take the easy way out.

> > +
> > +- cover letters and commit messages
> > +
> > +- responses to reviewer comments
> > +
> > +- issue descriptions or comments
> > +
> > +Light copy editing of human-written text with an AI is allowed.
> 
> What does "copy editing" mean? Should this say that writing the above by a
> human in native language and translating by LLM to English is allowed? For
> translation it's probably good enough now and that could allow contributors
> who can't write English but I agree the LLM should not generate the text for
> the listed items.

Yep, I'd consider "copy editing" to cover tweaking grammar / spelling
of text, especially to assist people who english as a second language,
but generally avoid anything substantive enough to pose a danger of
changing the meaning of text. Though you can't entirely avoid that
danger of changed meaning when fixing grammar, IMHO, it is likely to
be an acceptable tradeoff.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:

> diff --git a/docs/devel/llm-usage.rst b/docs/devel/llm-usage.rst
> new file mode 100644
> index 00000000000..972436828a6
> --- /dev/null
> +++ b/docs/devel/llm-usage.rst
> @@ -0,0 +1,202 @@
> +.. _llm-usage:
> +
> +Use of AI-generated content
> +===========================
> +
> +.. warning::
> +
> +   Please read the below policy before using AI to contribute code or
> +   documentation to QEMU.  This applies to ChatGPT, Claude, Copilot,
> +   Llama, and similar tools.
> +
> +The QEMU project does not want to introduce restrictions on the tools
> +that contributors use for their work on the project.  However,
> +the increasing prevalence of AI-assisted software development,
> +and especially the use of content generated by `Large Language Models
> +<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs),
> +poses a number of difficult questions.

It is a bit odd saying we don't want to restrict tools, since that is
exactly what we do want todo in this document. 

Perhaps

 The QEMU project does not want to dictate what tools contributors use
 for their work on the project. The increasing prevalence of AI-assisted
 software development, and especially the use of content generated by
 `Large Language Models <https://en.wikipedia.org/wiki/Large_language_model>`__
 (LLMs), poses a number of difficult questions, requiring some guidance
 around acceptable contribution practices involving LLMS.


> +
> +Risks to open source projects include maintainer burnout from an
> +increased number of contributions, as well as the risk to the project
> +from unintentional inclusion of copyrighted material in the LLM's output.
> +In order to mitigate these risks, the QEMU project limits the way
> +in which use of the output of generative AI can be included
> +in contributions to QEMU.
> +
> +The main guidelines for use of generative AI tools are roughly
> +as follows:
> +
> +- It's fine to use LLMs to answer questions, analyze, distill,
> +  refine, check, suggest, review. Use of LLMs to *create* is limited.
> +
> +- If in doubt, disclose any use of AI tools other than simple code
> +  completion and code review.
> +
> +- LLMs are allowed as a tool to write *better*, not *faster*.
> +
> +.. note:: **Use of AI does not remove the need for authors to comply
> +          with all other requirements for contribution.**  In particular,
> +          the ``Signed-off-by`` label in a patch submission is a statement
> +          that the author takes responsibility for the entire contents of
> +          the patch, certifying that their patch submission is made in
> +          accordance with the rules of the :ref:`Developer's Certificate of
> +          Origin (DCO) <dco>`.
> +
> +          Since a submitter cannot audit LLM output against its training
> +          data, the DCO is paired with :ref:`metadata in the commit message
> +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> +          that the contributor has the legal right to submit code in general.

I'm not a fan of this second paragraph, as that feels like it is undermining
the DCO. That first sentence in particular is somewhat saying that the
contributor does not have to think about plagarism and thed project is ok
with that, and also implying that the DCO doesn't apply to the LLM output.
This is both not OK in its implication of the project accepting some
liability, and then also contradicted by the next sentence.

IMHO this paragraph should just be removed.  The first paragraph clearly
states the DCO applies to the submission as a whole, and leaves all liability
for infringement on the contributor.


> +LLM-assisted and LLM-created contributions
> +''''''''''''''''''''''''''''''''''''''''''
> +
> +Use of generative AI tools for code contributions generally falls into
> +four buckets:

> +- use of LLMs to help generating parts of a larger patch---test cases,
> +  adaptations of existing code, boilerplate code for a new API, a tool to
> +  help performing mechanical changes, etc.  These are generally allowed;
> +  disclosure is highly recommended for non-trivial, functional code.
> +
> +- large, heavily LLM-assisted contributions where LLMs write large parts
> +  of functional code.  These are only allowed if *pre-arranged*,
> +  *high-quality* and *well-tested*.


In *both* of these cases, I think we should state a expectation that
the human contributor *must* be able to explain the *reasons* for
all key design choices in the code.

If a tool generates a qtest  test case with a bunch of device accesses,
the contributor needs to know what those are doing and why they are
appropriate usage in the real world

When a reviewer asks questions about the patch, they don't want to get
an answer "that's just the way the LLM did it", as then we've just back
to arguing with a bot again, even if the human wrote the mail.

Even for minor design choices that an LLM might make on its own, the
contributors needs to be able to explain and justify why they are
desirable.



> +
> +- "High-quality" means that the contributor must apply the same judgment
> +  that would be applied to other code changes.  Contributors must invest
> +  substantial time reviewing their contributions, curating them, and
> +  understanding them in depth; in particular, you are still expected to
> +  :ref:`understand and explain your changes
> +  <write_a_meaningful_commit_message>` and the rationale behind them.


This needs to apply to all cases, not merely the 'pre-arranged' large
contribution.

> +
> +- "Well-tested" means the LLM-created contributions will be held to a
> +  higher standard than human-created ones, because LLMs make it easier
> +  to write tests.  There are no exceptions for "writing the tests seems
> +  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.
> +
> +.. note::
> +    Pre-arrangement ensures maintainers have bandwidth for review before a
> +    contributor invests effort in creating a large change.  This is not
> +    a new concept in QEMU: maintainers have always encouraged early
> +    alignment on mailing lists or IRC prior to major architecture or
> +    subsystem refactoring.
> +
> +    Maintainers have freedom to determine what constitutes "high quality".
> +    Because LLMs lower the cost of patch generation, maintainers may demand
> +    significantly larger changes than for purely human-written code.
> +
> +.. _ai-used-for:


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Kevin Wolf]

Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > +.. note:: **Use of AI does not remove the need for authors to comply
> > +          with all other requirements for contribution.**  In particular,
> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > +          that the author takes responsibility for the entire contents of
> > +          the patch, certifying that their patch submission is made in
> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > +          Origin (DCO) <dco>`.
> > +
> > +          Since a submitter cannot audit LLM output against its training
> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > +          that the contributor has the legal right to submit code in general.
> 
> I'm not a fan of this second paragraph, as that feels like it is undermining
> the DCO. That first sentence in particular is somewhat saying that the
> contributor does not have to think about plagarism and thed project is ok
> with that, and also implying that the DCO doesn't apply to the LLM output.
> This is both not OK in its implication of the project accepting some
> liability, and then also contradicted by the next sentence.
> 
> IMHO this paragraph should just be removed.  The first paragraph clearly
> states the DCO applies to the submission as a whole, and leaves all liability
> for infringement on the contributor.

I don't think making this the individual contributor's problem is great.
It's rather unfriendly towards contributors to expect them to certify
something that we all know they can't honestly certify.

Our current AI policy was built on the assertion that it's impossible to
sign the DCO for AI output, and I think that's still right. A developer
can't certify the origin of something when they don't really know where
it comes from.

If we decide that we don't care as much about the legal risks any more
and that we're willing to accept them to some extent, that should be
explicitly reflected in the policy.

It seems to me that the cleanest way to do it is to exempt correctly
advertised (with 'AI-used-for:') AI output from the DCO requirement and
instead add to the 'AI-used-for:' definition some relaxed version of it,
e.g. "I have reviewed the contribution for potential licensing issues
and haven't found a reason to doubt that I have the rights to submit
this AI generated content under the open source license indicated in the
file". This is something that could realistically be certified by
contributors in good faith and also isn't just "anything goes", but of
course it still is weaker than the DCO.

If we're not willing to take the legal risk from this, we should
probably leave the current AI policy unchanged instead of telling
contributors that they have to work in a legal grey area.

Kevin

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

[Michael S. Tsirkin]

On Wed, Sep 23, 2026 at 06:16:12PM +0200, Kevin Wolf wrote:
> Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > +.. note:: **Use of AI does not remove the need for authors to comply
> > > +          with all other requirements for contribution.**  In particular,
> > > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > +          that the author takes responsibility for the entire contents of
> > > +          the patch, certifying that their patch submission is made in
> > > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > +          Origin (DCO) <dco>`.
> > > +
> > > +          Since a submitter cannot audit LLM output against its training
> > > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > +          that the contributor has the legal right to submit code in general.
> > 
> > I'm not a fan of this second paragraph, as that feels like it is undermining
> > the DCO. That first sentence in particular is somewhat saying that the
> > contributor does not have to think about plagarism and thed project is ok
> > with that, and also implying that the DCO doesn't apply to the LLM output.
> > This is both not OK in its implication of the project accepting some
> > liability, and then also contradicted by the next sentence.
> > 
> > IMHO this paragraph should just be removed.  The first paragraph clearly
> > states the DCO applies to the submission as a whole, and leaves all liability
> > for infringement on the contributor.
> 
> I don't think making this the individual contributor's problem is great.
> It's rather unfriendly towards contributors to expect them to certify
> something that we all know they can't honestly certify.
> 
> Our current AI policy was built on the assertion that it's impossible to
> sign the DCO for AI output, and I think that's still right. A developer
> can't certify the origin of something when they don't really know where
> it comes from.
> 
> If we decide that we don't care as much about the legal risks any more
> and that we're willing to accept them to some extent, that should be
> explicitly reflected in the policy.
> 
> It seems to me that the cleanest way to do it is to exempt correctly
> advertised (with 'AI-used-for:') AI output from the DCO requirement and
> instead add to the 'AI-used-for:' definition some relaxed version of it,
> e.g. "I have reviewed the contribution for potential licensing issues
> and haven't found a reason to doubt that I have the rights to submit
> this AI generated content under the open source license indicated in the
> file". This is something that could realistically be certified by
> contributors in good faith and also isn't just "anything goes", but of
> course it still is weaker than the DCO.
> 
> If we're not willing to take the legal risk from this, we should
> probably leave the current AI policy unchanged instead of telling
> contributors that they have to work in a legal grey area.
> 
> Kevin

Which risk precisely? That a judge will close all LLMs overnight
declaring their output a derivative of the internet and so illegal to
use? Please.

But just like "AI" does not mean "illegal" it does not mean "legal".

For example, if I give an LLM a chunk of code and say "adopt this to qemu" then
an argument can be made that it is a derivative of the code I supplied.

Whether to give an LLM web access so it can pull in random bits of code
and create derivatives of that is entirely under developer's control.

Whether AI output is a derivative of LLM weights is also an open
question, mitigated by the fact that many LLM vendors will assign
copyright to their users. Whether to use an LLM where that is the case
is also under developer's control.

I'm not sure why we need to get into so much detail, though.

-- 
MST

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

[Kevin Wolf]

Am 24.09.2026 um 04:23 hat Michael S. Tsirkin geschrieben:
> On Wed, Sep 23, 2026 at 06:16:12PM +0200, Kevin Wolf wrote:
> > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > +          with all other requirements for contribution.**  In particular,
> > > > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > +          that the author takes responsibility for the entire contents of
> > > > +          the patch, certifying that their patch submission is made in
> > > > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > +          Origin (DCO) <dco>`.
> > > > +
> > > > +          Since a submitter cannot audit LLM output against its training
> > > > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > +          that the contributor has the legal right to submit code in general.
> > > 
> > > I'm not a fan of this second paragraph, as that feels like it is undermining
> > > the DCO. That first sentence in particular is somewhat saying that the
> > > contributor does not have to think about plagarism and thed project is ok
> > > with that, and also implying that the DCO doesn't apply to the LLM output.
> > > This is both not OK in its implication of the project accepting some
> > > liability, and then also contradicted by the next sentence.
> > > 
> > > IMHO this paragraph should just be removed.  The first paragraph clearly
> > > states the DCO applies to the submission as a whole, and leaves all liability
> > > for infringement on the contributor.
> > 
> > I don't think making this the individual contributor's problem is great.
> > It's rather unfriendly towards contributors to expect them to certify
> > something that we all know they can't honestly certify.
> > 
> > Our current AI policy was built on the assertion that it's impossible to
> > sign the DCO for AI output, and I think that's still right. A developer
> > can't certify the origin of something when they don't really know where
> > it comes from.
> > 
> > If we decide that we don't care as much about the legal risks any more
> > and that we're willing to accept them to some extent, that should be
> > explicitly reflected in the policy.
> > 
> > It seems to me that the cleanest way to do it is to exempt correctly
> > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > e.g. "I have reviewed the contribution for potential licensing issues
> > and haven't found a reason to doubt that I have the rights to submit
> > this AI generated content under the open source license indicated in the
> > file". This is something that could realistically be certified by
> > contributors in good faith and also isn't just "anything goes", but of
> > course it still is weaker than the DCO.
> > 
> > If we're not willing to take the legal risk from this, we should
> > probably leave the current AI policy unchanged instead of telling
> > contributors that they have to work in a legal grey area.
> > 
> > Kevin
> 
> Which risk precisely? That a judge will close all LLMs overnight
> declaring their output a derivative of the internet and so illegal to
> use? Please.

I mean, at least morally that would be the right thing to do. If what
they did isn't illegal, that's a bug in the law.

But no, I don't expect this to happen, but am referring to the more
commonly talked about case of LLMs occasionally reproducing a single
source more or less verbatim, which is what could give you legal trouble
even practically speaking.

You can't know for sure if this happens, so I don't think you could sign
the DCO (you really can't know for sure if you have "right to submit it
under the open source license indicated in the file"), but you can check
for suspicious things and if you don't find any, say it's probably okay.

You seem to be saying that it's not only probably okay, but definitely
okay, but then that's even less of a problem.

> But just like "AI" does not mean "illegal" it does not mean "legal".
> 
> For example, if I give an LLM a chunk of code and say "adopt this to qemu" then
> an argument can be made that it is a derivative of the code I supplied.
> 
> Whether to give an LLM web access so it can pull in random bits of code
> and create derivatives of that is entirely under developer's control.
> 
> Whether AI output is a derivative of LLM weights is also an open
> question, mitigated by the fact that many LLM vendors will assign
> copyright to their users. Whether to use an LLM where that is the case
> is also under developer's control.
> 
> I'm not sure why we need to get into so much detail, though.

See, you bring up uncertainties yourself that nobody can answer today.
This is exactly why I wouldn't want to make people lie and say "I know
this is definitely okay", but accept "I tried to be careful and to the
best of my knowledge there is no problem" instead for the licensing of
LLM output.

This seems reasonable enough to me. I'm just saying that if others
disagree and we're not willing to accept the weaker assertion that
people actually can make in good faith, then we should stay out of LLM
generated content entirely instead of making people lie.

Kevin

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

[Michael S. Tsirkin]

On Thu, Sep 24, 2026 at 11:41:54AM +0200, Kevin Wolf wrote:
> Am 24.09.2026 um 04:23 hat Michael S. Tsirkin geschrieben:
> > On Wed, Sep 23, 2026 at 06:16:12PM +0200, Kevin Wolf wrote:
> > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > > On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > > +          with all other requirements for contribution.**  In particular,
> > > > > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > > +          that the author takes responsibility for the entire contents of
> > > > > +          the patch, certifying that their patch submission is made in
> > > > > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > > +          Origin (DCO) <dco>`.
> > > > > +
> > > > > +          Since a submitter cannot audit LLM output against its training
> > > > > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > > +          that the contributor has the legal right to submit code in general.
> > > > 
> > > > I'm not a fan of this second paragraph, as that feels like it is undermining
> > > > the DCO. That first sentence in particular is somewhat saying that the
> > > > contributor does not have to think about plagarism and thed project is ok
> > > > with that, and also implying that the DCO doesn't apply to the LLM output.
> > > > This is both not OK in its implication of the project accepting some
> > > > liability, and then also contradicted by the next sentence.
> > > > 
> > > > IMHO this paragraph should just be removed.  The first paragraph clearly
> > > > states the DCO applies to the submission as a whole, and leaves all liability
> > > > for infringement on the contributor.
> > > 
> > > I don't think making this the individual contributor's problem is great.
> > > It's rather unfriendly towards contributors to expect them to certify
> > > something that we all know they can't honestly certify.
> > > 
> > > Our current AI policy was built on the assertion that it's impossible to
> > > sign the DCO for AI output, and I think that's still right. A developer
> > > can't certify the origin of something when they don't really know where
> > > it comes from.
> > > 
> > > If we decide that we don't care as much about the legal risks any more
> > > and that we're willing to accept them to some extent, that should be
> > > explicitly reflected in the policy.
> > > 
> > > It seems to me that the cleanest way to do it is to exempt correctly
> > > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > > e.g. "I have reviewed the contribution for potential licensing issues
> > > and haven't found a reason to doubt that I have the rights to submit
> > > this AI generated content under the open source license indicated in the
> > > file". This is something that could realistically be certified by
> > > contributors in good faith and also isn't just "anything goes", but of
> > > course it still is weaker than the DCO.
> > > 
> > > If we're not willing to take the legal risk from this, we should
> > > probably leave the current AI policy unchanged instead of telling
> > > contributors that they have to work in a legal grey area.
> > > 
> > > Kevin
> > 
> > Which risk precisely? That a judge will close all LLMs overnight
> > declaring their output a derivative of the internet and so illegal to
> > use? Please.
> 
> I mean, at least morally that would be the right thing to do. If what
> they did isn't illegal, that's a bug in the law.

I'm not prepared to argue morality, and I don't even know who "they"
would be. But if an LLM is transformative then it's not a derivative,
that's a feature of the law, not a bug.


> But no, I don't expect this to happen, but am referring to the more
> commonly talked about case of LLMs occasionally reproducing a single
> source more or less verbatim, which is what could give you legal trouble
> even practically speaking.

They don't really seem to do that unless you try to ask them to.

> You can't know for sure if this happens, so I don't think you could sign
> the DCO (you really can't know for sure if you have "right to submit it
> under the open source license indicated in the file"), but you can check
> for suspicious things and if you don't find any, say it's probably okay.
> 
> You seem to be saying that it's not only probably okay, but definitely
> okay, but then that's even less of a problem.
> 
> > But just like "AI" does not mean "illegal" it does not mean "legal".
> > 
> > For example, if I give an LLM a chunk of code and say "adopt this to qemu" then
> > an argument can be made that it is a derivative of the code I supplied.
> > 
> > Whether to give an LLM web access so it can pull in random bits of code
> > and create derivatives of that is entirely under developer's control.
> > 
> > Whether AI output is a derivative of LLM weights is also an open
> > question, mitigated by the fact that many LLM vendors will assign
> > copyright to their users. Whether to use an LLM where that is the case
> > is also under developer's control.
> > 
> > I'm not sure why we need to get into so much detail, though.
> 
> See, you bring up uncertainties yourself that nobody can answer today.

Oh people can easily make sure their LLM is not poking at the web, today.

> This is exactly why I wouldn't want to make people lie and say "I know
> this is definitely okay", but accept "I tried to be careful and to the
> best of my knowledge there is no problem" instead for the licensing of
> LLM output.
> 
> This seems reasonable enough to me. I'm just saying that if others
> disagree and we're not willing to accept the weaker assertion that
> people actually can make in good faith, then we should stay out of LLM
> generated content entirely instead of making people lie.
> 
> Kevin

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

[Alex Bennée]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
>> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
>> > +.. note:: **Use of AI does not remove the need for authors to comply
>> > +          with all other requirements for contribution.**  In particular,
>> > +          the ``Signed-off-by`` label in a patch submission is a statement
>> > +          that the author takes responsibility for the entire contents of
>> > +          the patch, certifying that their patch submission is made in
>> > +          accordance with the rules of the :ref:`Developer's Certificate of
>> > +          Origin (DCO) <dco>`.
>> > +
>> > +          Since a submitter cannot audit LLM output against its training
>> > +          data, the DCO is paired with :ref:`metadata in the commit message
>> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
>> > +          that the contributor has the legal right to submit code in general.
>> 
>> I'm not a fan of this second paragraph, as that feels like it is undermining
>> the DCO. That first sentence in particular is somewhat saying that the
>> contributor does not have to think about plagarism and thed project is ok
>> with that, and also implying that the DCO doesn't apply to the LLM output.
>> This is both not OK in its implication of the project accepting some
>> liability, and then also contradicted by the next sentence.
>> 
>> IMHO this paragraph should just be removed.  The first paragraph clearly
>> states the DCO applies to the submission as a whole, and leaves all liability
>> for infringement on the contributor.
>
> I don't think making this the individual contributor's problem is great.
> It's rather unfriendly towards contributors to expect them to certify
> something that we all know they can't honestly certify.

This is the current position with the DCO anyway. If the contributor has
copy and pasted (and maybe adapted) from Stack Overflow they are still
realistically the only person that can make that judgement.

> Our current AI policy was built on the assertion that it's impossible to
> sign the DCO for AI output, and I think that's still right. A developer
> can't certify the origin of something when they don't really know where
> it comes from.

It's certainly possible for LLMs to replicate copyright material but by
far the biggest influence is the code *in the project* that shapes the
output. It is basically pattern matching and predicting after all.

What level of reassurance the submitter needs to be able to certify with
their DCO is up to them. We can't police it, like every other submission
we rely in the submitters good faith representation of what they have
done.

> If we decide that we don't care as much about the legal risks any more
> and that we're willing to accept them to some extent, that should be
> explicitly reflected in the policy.
>
> It seems to me that the cleanest way to do it is to exempt correctly
> advertised (with 'AI-used-for:') AI output from the DCO requirement and
> instead add to the 'AI-used-for:' definition some relaxed version of it,
> e.g. "I have reviewed the contribution for potential licensing issues
> and haven't found a reason to doubt that I have the rights to submit
> this AI generated content under the open source license indicated in the
> file". This is something that could realistically be certified by
> contributors in good faith and also isn't just "anything goes", but of
> course it still is weaker than the DCO.
>
> If we're not willing to take the legal risk from this, we should
> probably leave the current AI policy unchanged instead of telling
> contributors that they have to work in a legal grey area.

I don't think we are asking them to work in a legally grey area, we are
insisting they are confident there is no legal risk in what they submit.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Kevin Wolf]

Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> >> > +.. note:: **Use of AI does not remove the need for authors to comply
> >> > +          with all other requirements for contribution.**  In particular,
> >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> >> > +          that the author takes responsibility for the entire contents of
> >> > +          the patch, certifying that their patch submission is made in
> >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> >> > +          Origin (DCO) <dco>`.
> >> > +
> >> > +          Since a submitter cannot audit LLM output against its training
> >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> >> > +          that the contributor has the legal right to submit code in general.
> >> 
> >> I'm not a fan of this second paragraph, as that feels like it is undermining
> >> the DCO. That first sentence in particular is somewhat saying that the
> >> contributor does not have to think about plagarism and thed project is ok
> >> with that, and also implying that the DCO doesn't apply to the LLM output.
> >> This is both not OK in its implication of the project accepting some
> >> liability, and then also contradicted by the next sentence.
> >> 
> >> IMHO this paragraph should just be removed.  The first paragraph clearly
> >> states the DCO applies to the submission as a whole, and leaves all liability
> >> for infringement on the contributor.
> >
> > I don't think making this the individual contributor's problem is great.
> > It's rather unfriendly towards contributors to expect them to certify
> > something that we all know they can't honestly certify.
> 
> This is the current position with the DCO anyway. If the contributor has
> copy and pasted (and maybe adapted) from Stack Overflow they are still
> realistically the only person that can make that judgement.

Yes, that's the current position with the DCO and the reasoning why we
said LLM output is unacceptable in submissions.

The big difference is if I copy and pasted from Stack Overflow, I _know_
that I did that. If the LLM effectively does it for me, I don't know
that. The best I can do is check if I can find similar code elsewhere.

So while I can certify with 100% confidence that I didn't manually copy
things for code that I wrote myself, I can't certify that code from
other sources, including LLMs, isn't copied from elsewhere. I can only
say that I didn't find any reason to suspect it's copied.

> > Our current AI policy was built on the assertion that it's impossible to
> > sign the DCO for AI output, and I think that's still right. A developer
> > can't certify the origin of something when they don't really know where
> > it comes from.
> 
> It's certainly possible for LLMs to replicate copyright material but by
> far the biggest influence is the code *in the project* that shapes the
> output. It is basically pattern matching and predicting after all.

If there is one chunk of code that violates the copyright of someone,
you can't heal that just by having 1000 more chunks that are clean.

> What level of reassurance the submitter needs to be able to certify with
> their DCO is up to them. We can't police it, like every other submission
> we rely in the submitters good faith representation of what they have
> done.

The DCO doesn't talk about levels of reassurance. It talks about hard
facts, 100% confidence.

And that I can't give you with LLM generated content. I can maybe give
you 99%, but never 100%.

> > If we decide that we don't care as much about the legal risks any more
> > and that we're willing to accept them to some extent, that should be
> > explicitly reflected in the policy.
> >
> > It seems to me that the cleanest way to do it is to exempt correctly
> > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > e.g. "I have reviewed the contribution for potential licensing issues
> > and haven't found a reason to doubt that I have the rights to submit
> > this AI generated content under the open source license indicated in the
> > file". This is something that could realistically be certified by
> > contributors in good faith and also isn't just "anything goes", but of
> > course it still is weaker than the DCO.
> >
> > If we're not willing to take the legal risk from this, we should
> > probably leave the current AI policy unchanged instead of telling
> > contributors that they have to work in a legal grey area.
> 
> I don't think we are asking them to work in a legally grey area, we are
> insisting they are confident there is no legal risk in what they submit.

If anyone is 100% "confident there is no legal risk", then I think
they're simply wrong (unless the contribution is obviously not
copyrightable anyway). The real question is if the risk is low enough.

But I suspect in most cases it's actually more like they're only 99%
confident and think "ah well, I'll sign it anyway, I probably won't get
into trouble". That gives people who are willing to bend the rules a
little an advantage over more conscientious contributors, which I don't
think is justified, because in the end it's the same 99% certainty for
both.

Kevin

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

[Daniel P. Berrangé]

On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > Kevin Wolf <kwolf@redhat.com> writes:
> > 
> > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > >> > +          with all other requirements for contribution.**  In particular,
> > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > >> > +          that the author takes responsibility for the entire contents of
> > >> > +          the patch, certifying that their patch submission is made in
> > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > >> > +          Origin (DCO) <dco>`.
> > >> > +
> > >> > +          Since a submitter cannot audit LLM output against its training
> > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > >> > +          that the contributor has the legal right to submit code in general.
> > >> 
> > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > >> the DCO. That first sentence in particular is somewhat saying that the
> > >> contributor does not have to think about plagarism and thed project is ok
> > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > >> This is both not OK in its implication of the project accepting some
> > >> liability, and then also contradicted by the next sentence.
> > >> 
> > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > >> states the DCO applies to the submission as a whole, and leaves all liability
> > >> for infringement on the contributor.
> > >
> > > I don't think making this the individual contributor's problem is great.
> > > It's rather unfriendly towards contributors to expect them to certify
> > > something that we all know they can't honestly certify.
> > 
> > This is the current position with the DCO anyway. If the contributor has
> > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > realistically the only person that can make that judgement.
> 
> Yes, that's the current position with the DCO and the reasoning why we
> said LLM output is unacceptable in submissions.
> 
> The big difference is if I copy and pasted from Stack Overflow, I _know_
> that I did that. If the LLM effectively does it for me, I don't know
> that. The best I can do is check if I can find similar code elsewhere.
> 
> So while I can certify with 100% confidence that I didn't manually copy
> things for code that I wrote myself, I can't certify that code from
> other sources, including LLMs, isn't copied from elsewhere. I can only
> say that I didn't find any reason to suspect it's copied.

> > > Our current AI policy was built on the assertion that it's impossible to
> > > sign the DCO for AI output, and I think that's still right. A developer
> > > can't certify the origin of something when they don't really know where
> > > it comes from.
> > 
> > It's certainly possible for LLMs to replicate copyright material but by
> > far the biggest influence is the code *in the project* that shapes the
> > output. It is basically pattern matching and predicting after all.
> 
> If there is one chunk of code that violates the copyright of someone,
> you can't heal that just by having 1000 more chunks that are clean.
> 
> > What level of reassurance the submitter needs to be able to certify with
> > their DCO is up to them. We can't police it, like every other submission
> > we rely in the submitters good faith representation of what they have
> > done.
> 
> The DCO doesn't talk about levels of reassurance. It talks about hard
> facts, 100% confidence.
> 
> And that I can't give you with LLM generated content. I can maybe give
> you 99%, but never 100%.

I appreciate you're speaking about licensing/copyright here, but more
generally I think we're probably wrong in asserting that a human
authored contribution can ever be said to be 100% safe to QEMU with
a DCO signoff. It is risk mitigation, but not absolute.
 
From a copyright POV, if we write the code ourselves we can have
confidence we didn't copy it and thus licensing is likely OK (unless
you inadvertantly memorized some previous code you saw and reproduced
it too closely), but there are other legal aspects. Trademarks are
one risk, since we reference lots of vendor's hardware features, but
in practice this very rarely arises as a problem for projects, beyond
the obvious areas like project name, logo, and other visible branding
aspects. Software patents are the really big hidden trap that anyone
could unintentionally fall foul of at any time and have caused high
profile problems for projects periodically.

If someone knows their employer has a patent that is likely to be
restrictive for possible use in QEMU, then they shouldn't sign off
or contribute code implementing something covered by the patent
without the employer granting unrestricted use. We're certainly
not expecting people to do searches for 3rd party patents though,
so the DCO is not a 100% guarantee of risk elimination to QEMU.

We tolerate that risk because there is no practical action that a
contributor can take to mitigate. Further many large tech companies
have thus formed defensive pacts to de-fang the risk.


With this in mind, it is perhaps not that different to accept a little
bit of uncertainty in risks of LLM unknowingly copying from training
material or 3rd party incompatibly licensed code it happened to find
while walking the web ?  The key is that users need to be diligent
in their use of the tools, not reckless. Norms for what that means
are still be established - the so called "clean room" or license
laundering, re-impls of projects are a massively risky activity
but are the exception.



> > > If we decide that we don't care as much about the legal risks any more
> > > and that we're willing to accept them to some extent, that should be
> > > explicitly reflected in the policy.
> > >
> > > It seems to me that the cleanest way to do it is to exempt correctly
> > > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > > e.g. "I have reviewed the contribution for potential licensing issues
> > > and haven't found a reason to doubt that I have the rights to submit
> > > this AI generated content under the open source license indicated in the
> > > file". This is something that could realistically be certified by
> > > contributors in good faith and also isn't just "anything goes", but of
> > > course it still is weaker than the DCO.

I like the idea of associating "AI-used-for" with an explicit
statement like:

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


Then we can add whatever guidance we want in the AI policy that
steers people away from LLM usage patterns that we know would
expose us to undesirable risk. Explicitly stating that we do
not want LLMs used to "clean room" / "license launder" re-impl
existing code is something we could include. Or guide that 
agents should not be given free access to live git repos to
reduce change of direct copying ?


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 11270 bytes --]

On Thu, Sep 24, 2026 at 5:30 AM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > Kevin Wolf <kwolf@redhat.com> writes:
> > >
> > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > >> > +.. note:: **Use of AI does not remove the need for authors to
> comply
> > > >> > +          with all other requirements for contribution.**  In
> particular,
> > > >> > +          the ``Signed-off-by`` label in a patch submission is a
> statement
> > > >> > +          that the author takes responsibility for the entire
> contents of
> > > >> > +          the patch, certifying that their patch submission is
> made in
> > > >> > +          accordance with the rules of the :ref:`Developer's
> Certificate of
> > > >> > +          Origin (DCO) <dco>`.
> > > >> > +
> > > >> > +          Since a submitter cannot audit LLM output against its
> training
> > > >> > +          data, the DCO is paired with :ref:`metadata in the
> commit message
> > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO
> still certifies
> > > >> > +          that the contributor has the legal right to submit
> code in general.
> > > >>
> > > >> I'm not a fan of this second paragraph, as that feels like it is
> undermining
> > > >> the DCO. That first sentence in particular is somewhat saying that
> the
> > > >> contributor does not have to think about plagarism and thed project
> is ok
> > > >> with that, and also implying that the DCO doesn't apply to the LLM
> output.
> > > >> This is both not OK in its implication of the project accepting some
> > > >> liability, and then also contradicted by the next sentence.
> > > >>
> > > >> IMHO this paragraph should just be removed.  The first paragraph
> clearly
> > > >> states the DCO applies to the submission as a whole, and leaves all
> liability
> > > >> for infringement on the contributor.
> > > >
> > > > I don't think making this the individual contributor's problem is
> great.
> > > > It's rather unfriendly towards contributors to expect them to certify
> > > > something that we all know they can't honestly certify.
> > >
> > > This is the current position with the DCO anyway. If the contributor
> has
> > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > realistically the only person that can make that judgement.
> >
> > Yes, that's the current position with the DCO and the reasoning why we
> > said LLM output is unacceptable in submissions.
> >
> > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > that I did that. If the LLM effectively does it for me, I don't know
> > that. The best I can do is check if I can find similar code elsewhere.
> >
> > So while I can certify with 100% confidence that I didn't manually copy
> > things for code that I wrote myself, I can't certify that code from
> > other sources, including LLMs, isn't copied from elsewhere. I can only
> > say that I didn't find any reason to suspect it's copied.
>
> > > > Our current AI policy was built on the assertion that it's
> impossible to
> > > > sign the DCO for AI output, and I think that's still right. A
> developer
> > > > can't certify the origin of something when they don't really know
> where
> > > > it comes from.
> > >
> > > It's certainly possible for LLMs to replicate copyright material but by
> > > far the biggest influence is the code *in the project* that shapes the
> > > output. It is basically pattern matching and predicting after all.
> >
> > If there is one chunk of code that violates the copyright of someone,
> > you can't heal that just by having 1000 more chunks that are clean.
> >
> > > What level of reassurance the submitter needs to be able to certify
> with
> > > their DCO is up to them. We can't police it, like every other
> submission
> > > we rely in the submitters good faith representation of what they have
> > > done.
> >
> > The DCO doesn't talk about levels of reassurance. It talks about hard
> > facts, 100% confidence.
> >
> > And that I can't give you with LLM generated content. I can maybe give
> > you 99%, but never 100%.
>
> I appreciate you're speaking about licensing/copyright here, but more
> generally I think we're probably wrong in asserting that a human
> authored contribution can ever be said to be 100% safe to QEMU with
> a DCO signoff. It is risk mitigation, but not absolute.
>

Risk mititagion is the best you can hope for. People lie, people
accidentally
copy, etc. Maybe they infringe on a patent. You can never be 100%
sure.


> From a copyright POV, if we write the code ourselves we can have
> confidence we didn't copy it and thus licensing is likely OK (unless
> you inadvertantly memorized some previous code you saw and reproduced
> it too closely), but there are other legal aspects. Trademarks are
> one risk, since we reference lots of vendor's hardware features, but
> in practice this very rarely arises as a problem for projects, beyond
> the obvious areas like project name, logo, and other visible branding
> aspects. Software patents are the really big hidden trap that anyone
> could unintentionally fall foul of at any time and have caused high
> profile problems for projects periodically.
>

Even the memorized stuff is likely OK. It all depends. I have memorized
bubble sorts, but there's only so many ways to implement a bubble sort
so most bubble sorts don't enjoy much copyright protection.  Big tables of
numbers don't generally enjoy copyright protection, so are usually 100%
OK to copy.

Plus, LLMs generally don't copy code from random places. Some early
ones were subject to injection attacks, but newer ones tend to look at
surrounding code to adopt the repository's conventions. Is that copying?
Is that a risk? Probably not because it's likely "scenes a faire" which
is the doctrine sometimes the genre dictates that things be a certain
way (eg all murder mysteries have a victim and someone trying to
solve the crime).

If someone knows their employer has a patent that is likely to be
> restrictive for possible use in QEMU, then they shouldn't sign off
> or contribute code implementing something covered by the patent
> without the employer granting unrestricted use. We're certainly
> not expecting people to do searches for 3rd party patents though,
> so the DCO is not a 100% guarantee of risk elimination to QEMU.
>

In fact most companies, at least in the US, instruct their engineers
to not even bother with a patent search because if you look for it,
even if you don't find it, you can be held liable for triple damages
because it can become willful.


> We tolerate that risk because there is no practical action that a
> contributor can take to mitigate. Further many large tech companies
> have thus formed defensive pacts to de-fang the risk.
>

Yes. The actual legal landscape is such that it's hard to know for
sure what the level of risk is for any given action. While usually the
court will rule in a specific way, there are times it just doesn't, even
for what seem like similar facts. Unlike programming, there's an
element of randomness that you can't drive to 0.


> With this in mind, it is perhaps not that different to accept a little
> bit of uncertainty in risks of LLM unknowingly copying from training
> material or 3rd party incompatibly licensed code it happened to find
> while walking the web ?  The key is that users need to be diligent
> in their use of the tools, not reckless. Norms for what that means
> are still be established - the so called "clean room" or license
> laundering, re-impls of projects are a massively risky activity
> but are the exception.
>

And "clean room" procedures are no different whether a human
or an LLM performs them. They both produce a new work because
the abstraction to the idea (which isn't copyrightable) loses details,
creative choices, etc. And the implementation from that spec also makes
different creative choices, leaving little in common with the original.


> > > > If we decide that we don't care as much about the legal risks any
> more
> > > > and that we're willing to accept them to some extent, that should be
> > > > explicitly reflected in the policy.
> > > >
> > > > It seems to me that the cleanest way to do it is to exempt correctly
> > > > advertised (with 'AI-used-for:') AI output from the DCO requirement
> and
> > > > instead add to the 'AI-used-for:' definition some relaxed version of
> it,
> > > > e.g. "I have reviewed the contribution for potential licensing issues
> > > > and haven't found a reason to doubt that I have the rights to submit
> > > > this AI generated content under the open source license indicated in
> the
> > > > file". This is something that could realistically be certified by
> > > > contributors in good faith and also isn't just "anything goes", but
> of
> > > > course it still is weaker than the DCO.
>
> I like the idea of associating "AI-used-for" with an explicit
> statement like:
>
>   "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"
>
>
> Then we can add whatever guidance we want in the AI policy that
> steers people away from LLM usage patterns that we know would
> expose us to undesirable risk. Explicitly stating that we do
> not want LLMs used to "clean room" / "license launder" re-impl
> existing code is something we could include. Or guide that
> agents should not be given free access to live git repos to
> reduce change of direct copying ?
>

FreeBSD is struggling with these issues as well. There's a huge difference
in risk of someone one-shotting the process and sending the results off
w/o any critical thought and someone doing a series of a hundred or two
hundred prompts with careful thought, arguments about the design
trade offs, etc. Even leaving aside the copyright issues, the former has
a huge risk, most of it from technical debt, while the latter has a much
lower
risk: there's less risk of copying (and any copying may fall to de minimis),
and the result is much better designed and put together. FreeBSD doesn't
yet have any good answers to share.

Honestly, the real risk here is that there's a new kind of 'free' software:
free as in free puppy, and you want to be careful which ones you accept.
The bigger liability to the project is accepting the wrong ones which
increase
technical debt over the finer points of copyright law that will really only
matter
if something is actually litigated, and then the thousands of contributors
randomly permuting different aspects of the code every few years also
launders the code, both in terms of technical debt, and in terms of
copyright
risk.

It's all about mitigating the risks that matter in the end.

Warner

[-- Attachment #2: Type: text/html, Size: 14938 bytes --]

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

[Kevin Wolf]

Am 24.09.2026 um 13:30 hat Daniel P. Berrangé geschrieben:
> On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > Kevin Wolf <kwolf@redhat.com> writes:
> > > 
> > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > >> > +          with all other requirements for contribution.**  In particular,
> > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > >> > +          that the author takes responsibility for the entire contents of
> > > >> > +          the patch, certifying that their patch submission is made in
> > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > >> > +          Origin (DCO) <dco>`.
> > > >> > +
> > > >> > +          Since a submitter cannot audit LLM output against its training
> > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > >> > +          that the contributor has the legal right to submit code in general.
> > > >> 
> > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > >> contributor does not have to think about plagarism and thed project is ok
> > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > >> This is both not OK in its implication of the project accepting some
> > > >> liability, and then also contradicted by the next sentence.
> > > >> 
> > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > >> for infringement on the contributor.
> > > >
> > > > I don't think making this the individual contributor's problem is great.
> > > > It's rather unfriendly towards contributors to expect them to certify
> > > > something that we all know they can't honestly certify.
> > > 
> > > This is the current position with the DCO anyway. If the contributor has
> > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > realistically the only person that can make that judgement.
> > 
> > Yes, that's the current position with the DCO and the reasoning why we
> > said LLM output is unacceptable in submissions.
> > 
> > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > that I did that. If the LLM effectively does it for me, I don't know
> > that. The best I can do is check if I can find similar code elsewhere.
> > 
> > So while I can certify with 100% confidence that I didn't manually copy
> > things for code that I wrote myself, I can't certify that code from
> > other sources, including LLMs, isn't copied from elsewhere. I can only
> > say that I didn't find any reason to suspect it's copied.
> 
> > > > Our current AI policy was built on the assertion that it's impossible to
> > > > sign the DCO for AI output, and I think that's still right. A developer
> > > > can't certify the origin of something when they don't really know where
> > > > it comes from.
> > > 
> > > It's certainly possible for LLMs to replicate copyright material but by
> > > far the biggest influence is the code *in the project* that shapes the
> > > output. It is basically pattern matching and predicting after all.
> > 
> > If there is one chunk of code that violates the copyright of someone,
> > you can't heal that just by having 1000 more chunks that are clean.
> > 
> > > What level of reassurance the submitter needs to be able to certify with
> > > their DCO is up to them. We can't police it, like every other submission
> > > we rely in the submitters good faith representation of what they have
> > > done.
> > 
> > The DCO doesn't talk about levels of reassurance. It talks about hard
> > facts, 100% confidence.
> > 
> > And that I can't give you with LLM generated content. I can maybe give
> > you 99%, but never 100%.
> 
> I appreciate you're speaking about licensing/copyright here, but more
> generally I think we're probably wrong in asserting that a human
> authored contribution can ever be said to be 100% safe to QEMU with
> a DCO signoff. It is risk mitigation, but not absolute.

Yes, and I don't think I'm claiming it can, quite the opposite. (Maybe
Alex is with "we are insisting they are confident there is no legal risk
in what they submit", though).

The difference is probably that you're looking at it from the project
perspective and I'm looking at it from the contributor perspective.
Would I be happy to sign the DCO for AI output? I would probably be
fighting my conscience because I know that everyone (possibly including
my manager) expects me to do that even with AI output, but at the same
time I also can't certify something I don't know for a fact. That would
be a quite unpleasant situation.

Our current policy is quite clear on this, and I seem to remember that
it was even you who brought up the reasoning with "it's impossible to
sign the DCO for AI output":

    To satisfy the DCO, the patch contributor has to fully understand
    the copyright and license status of content they are contributing to
    QEMU. With AI content generators, the copyright and license status
    of the output is ill-defined with no generally accepted, settled
    legal foundation.

    Where the training material is known, it is common for it to include
    large volumes of material under restrictive licensing/copyright
    terms. Even where the training material is all known to be under
    open source licenses, it is likely to be under a variety of terms,
    not all of which will be compatible with QEMU's licensing
    requirements.

    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.

What has changed so fundamentally (i.e. not just shifted in numbers)
since then?

The commit message doesn't give any explanation. It says "but AI is so
useful today", and I can agree with that. But it doesn't change anything
about license status. If something is impossible, then that it would be
useful doesn't somehow make it possible, and we shouldn't pretend that
it does.

So either we need a reasoning why things have changed fundamentally (or
why we now think our old reasoning has been wrong from the start) so
that it's now okay to request contributors to sign the DCO for AI output
when we previously officially asserted that this is impossible for them
to do in good faith, or we need to have different standards than the DCO
for AI output.

Everything else would be very inconsistent.

> From a copyright POV, if we write the code ourselves we can have
> confidence we didn't copy it and thus licensing is likely OK (unless
> you inadvertantly memorized some previous code you saw and reproduced
> it too closely), but there are other legal aspects. Trademarks are
> one risk, since we reference lots of vendor's hardware features, but
> in practice this very rarely arises as a problem for projects, beyond
> the obvious areas like project name, logo, and other visible branding
> aspects. Software patents are the really big hidden trap that anyone
> could unintentionally fall foul of at any time and have caused high
> profile problems for projects periodically.
> 
> If someone knows their employer has a patent that is likely to be
> restrictive for possible use in QEMU, then they shouldn't sign off
> or contribute code implementing something covered by the patent
> without the employer granting unrestricted use. We're certainly
> not expecting people to do searches for 3rd party patents though,
> so the DCO is not a 100% guarantee of risk elimination to QEMU.
> 
> We tolerate that risk because there is no practical action that a
> contributor can take to mitigate. Further many large tech companies
> have thus formed defensive pacts to de-fang the risk.
> 
> 
> With this in mind, it is perhaps not that different to accept a little
> bit of uncertainty in risks of LLM unknowingly copying from training
> material or 3rd party incompatibly licensed code it happened to find
> while walking the web ?  The key is that users need to be diligent
> in their use of the tools, not reckless. Norms for what that means
> are still be established - the so called "clean room" or license
> laundering, re-impls of projects are a massively risky activity
> but are the exception.

So basically you're saying that it's our interpretation of the DCO that
was wrong from the beginning, and it shouldn't actually be understood as
strict/literally as we said it should?

Even if people generally agree that that's the case, that should be made
explicit. With the history of our claim that it's impossible to sign the
DCO for AI output, we can't just mention in passing that the usual
requirements like signing the DCO apply as if that is the most natural
and uncontroversial thing to do, when we ourselves are claiming the
opposite today.

I think that's what Paolo tried to address with the paragraph you
suggested to remove. While its wording isn't perfect, I do think we need
something like it.

> > > > If we decide that we don't care as much about the legal risks any more
> > > > and that we're willing to accept them to some extent, that should be
> > > > explicitly reflected in the policy.
> > > >
> > > > It seems to me that the cleanest way to do it is to exempt correctly
> > > > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > > > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > > > e.g. "I have reviewed the contribution for potential licensing issues
> > > > and haven't found a reason to doubt that I have the rights to submit
> > > > this AI generated content under the open source license indicated in the
> > > > file". This is something that could realistically be certified by
> > > > contributors in good faith and also isn't just "anything goes", but of
> > > > course it still is weaker than the DCO.
> 
> I like the idea of associating "AI-used-for" with an explicit
> statement like:
> 
>   "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"
> 
> 
> Then we can add whatever guidance we want in the AI policy that
> steers people away from LLM usage patterns that we know would
> expose us to undesirable risk. Explicitly stating that we do
> not want LLMs used to "clean room" / "license launder" re-impl
> existing code is something we could include.

Sure, that could be done.

> Or guide that agents should not be given free access to live git repos
> to reduce change of direct copying ?

I'm less sure about this one, as long as it's contained to specific
repos (e.g. a library that QEMU uses), it could be very useful and also
not too bad to review - and we know the licenses are compatible anyway.

Kevin

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

[Daniel P. Berrangé]

On Fri, Sep 25, 2026 at 12:05:12PM +0200, Kevin Wolf wrote:
> Am 24.09.2026 um 13:30 hat Daniel P. Berrangé geschrieben:
> > On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > > Kevin Wolf <kwolf@redhat.com> writes:
> > > > 
> > > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > >> > +          with all other requirements for contribution.**  In particular,
> > > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > >> > +          that the author takes responsibility for the entire contents of
> > > > >> > +          the patch, certifying that their patch submission is made in
> > > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > >> > +          Origin (DCO) <dco>`.
> > > > >> > +
> > > > >> > +          Since a submitter cannot audit LLM output against its training
> > > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > >> > +          that the contributor has the legal right to submit code in general.
> > > > >> 
> > > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > > >> contributor does not have to think about plagarism and thed project is ok
> > > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > > >> This is both not OK in its implication of the project accepting some
> > > > >> liability, and then also contradicted by the next sentence.
> > > > >> 
> > > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > > >> for infringement on the contributor.
> > > > >
> > > > > I don't think making this the individual contributor's problem is great.
> > > > > It's rather unfriendly towards contributors to expect them to certify
> > > > > something that we all know they can't honestly certify.
> > > > 
> > > > This is the current position with the DCO anyway. If the contributor has
> > > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > > realistically the only person that can make that judgement.
> > > 
> > > Yes, that's the current position with the DCO and the reasoning why we
> > > said LLM output is unacceptable in submissions.
> > > 
> > > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > > that I did that. If the LLM effectively does it for me, I don't know
> > > that. The best I can do is check if I can find similar code elsewhere.
> > > 
> > > So while I can certify with 100% confidence that I didn't manually copy
> > > things for code that I wrote myself, I can't certify that code from
> > > other sources, including LLMs, isn't copied from elsewhere. I can only
> > > say that I didn't find any reason to suspect it's copied.
> > 
> > > > > Our current AI policy was built on the assertion that it's impossible to
> > > > > sign the DCO for AI output, and I think that's still right. A developer
> > > > > can't certify the origin of something when they don't really know where
> > > > > it comes from.
> > > > 
> > > > It's certainly possible for LLMs to replicate copyright material but by
> > > > far the biggest influence is the code *in the project* that shapes the
> > > > output. It is basically pattern matching and predicting after all.
> > > 
> > > If there is one chunk of code that violates the copyright of someone,
> > > you can't heal that just by having 1000 more chunks that are clean.
> > > 
> > > > What level of reassurance the submitter needs to be able to certify with
> > > > their DCO is up to them. We can't police it, like every other submission
> > > > we rely in the submitters good faith representation of what they have
> > > > done.
> > > 
> > > The DCO doesn't talk about levels of reassurance. It talks about hard
> > > facts, 100% confidence.
> > > 
> > > And that I can't give you with LLM generated content. I can maybe give
> > > you 99%, but never 100%.
> > 
> > I appreciate you're speaking about licensing/copyright here, but more
> > generally I think we're probably wrong in asserting that a human
> > authored contribution can ever be said to be 100% safe to QEMU with
> > a DCO signoff. It is risk mitigation, but not absolute.
> 
> Yes, and I don't think I'm claiming it can, quite the opposite. (Maybe
> Alex is with "we are insisting they are confident there is no legal risk
> in what they submit", though).
> 
> The difference is probably that you're looking at it from the project
> perspective and I'm looking at it from the contributor perspective.
> Would I be happy to sign the DCO for AI output? I would probably be
> fighting my conscience because I know that everyone (possibly including
> my manager) expects me to do that even with AI output, but at the same
> time I also can't certify something I don't know for a fact. That would
> be a quite unpleasant situation.
> 
> Our current policy is quite clear on this, and I seem to remember that
> it was even you who brought up the reasoning with "it's impossible to
> sign the DCO for AI output":
> 
>     To satisfy the DCO, the patch contributor has to fully understand
>     the copyright and license status of content they are contributing to
>     QEMU. With AI content generators, the copyright and license status
>     of the output is ill-defined with no generally accepted, settled
>     legal foundation.
> 
>     Where the training material is known, it is common for it to include
>     large volumes of material under restrictive licensing/copyright
>     terms. Even where the training material is all known to be under
>     open source licenses, it is likely to be under a variety of terms,
>     not all of which will be compatible with QEMU's licensing
>     requirements.
> 
>     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.
> 
> What has changed so fundamentally (i.e. not just shifted in numbers)
> since then?
> 
> The commit message doesn't give any explanation. It says "but AI is so
> useful today", and I can agree with that. But it doesn't change anything
> about license status. If something is impossible, then that it would be
> useful doesn't somehow make it possible, and we shouldn't pretend that
> it does.
> 
> So either we need a reasoning why things have changed fundamentally (or
> why we now think our old reasoning has been wrong from the start) so
> that it's now okay to request contributors to sign the DCO for AI output
> when we previously officially asserted that this is impossible for them
> to do in good faith, or we need to have different standards than the DCO
> for AI output.

I would say that our original policy was intentionally simplistic
in declaring a strict ban on every use of AI, under the banner of
DCO compliance.

I would say our current policy does/should have wiggle room in it
for modest contributions that don't meet the threshold for code
to have meaningful copyright protection, either because the code
is trivial, or it is cloning a boilerplate design pattern, or
there is only one viable way to achieve the task.  We didn't get
into that nuance in the original policy, but we've discussed it
at the time, and on occassions since.

Then there's things like auto-completion, grammar/spelling help,
translation, and so on, which I also think are reasonable to use
LLM for and also reasonable to sign-off under DCO.


Wrt my message about the DCO being about risk mitigation, rather
than total risk elimination, I think there is scope for sign off
of some more significantly sized (but not unbounded) LLM based
contributions. I don't know how to express that as policy
language.

For LLMs involved in wholesale architecting of major new features,
I remain pretty uncomfortable with the idea of DCO signoff, and
also not especially happy with the proposal in this series that
it is OK if done with prior agreement with a maintainer.

That is saying implicitly that "Use of AI tools is entirely
unrestricted for anything", from a DCO signoff POV. It merely
tries to stop us being flooded, and I'm pretty doubtful that
will work out.



> > With this in mind, it is perhaps not that different to accept a little
> > bit of uncertainty in risks of LLM unknowingly copying from training
> > material or 3rd party incompatibly licensed code it happened to find
> > while walking the web ?  The key is that users need to be diligent
> > in their use of the tools, not reckless. Norms for what that means
> > are still be established - the so called "clean room" or license
> > laundering, re-impls of projects are a massively risky activity
> > but are the exception.
> 
> So basically you're saying that it's our interpretation of the DCO that
> was wrong from the beginning, and it shouldn't actually be understood as
> strict/literally as we said it should?

No, as above, our current policy was intentionally simplistic,
going beyond what we needed to declare,  to get an initial
policy in place. The intent was always to refine the policy
over time.

This series is less of a refinement, and effectively a complete
removal almost all restrictions.

We're already feeling the massive burden of reviewing chatbot output
in our issue tracker, and it is a horrible experiance. I worry about
what the effects of this new policy will be for QEMU long term on
the patch side too, since no matter what we say the intent is, I
expect it will be an excuse to bombard us with more patches than
ever before.

> Even if people generally agree that that's the case, that should be made
> explicit. With the history of our claim that it's impossible to sign the
> DCO for AI output, we can't just mention in passing that the usual
> requirements like signing the DCO apply as if that is the most natural
> and uncontroversial thing to do, when we ourselves are claiming the
> opposite today.
> 
> I think that's what Paolo tried to address with the paragraph you
> suggested to remove. While its wording isn't perfect, I do think we need
> something like it.
> 
> > > > > If we decide that we don't care as much about the legal risks any more
> > > > > and that we're willing to accept them to some extent, that should be
> > > > > explicitly reflected in the policy.
> > > > >
> > > > > It seems to me that the cleanest way to do it is to exempt correctly
> > > > > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > > > > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > > > > e.g. "I have reviewed the contribution for potential licensing issues
> > > > > and haven't found a reason to doubt that I have the rights to submit
> > > > > this AI generated content under the open source license indicated in the
> > > > > file". This is something that could realistically be certified by
> > > > > contributors in good faith and also isn't just "anything goes", but of
> > > > > course it still is weaker than the DCO.
> > 
> > I like the idea of associating "AI-used-for" with an explicit
> > statement like:
> > 
> >   "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"
> > 
> > 
> > Then we can add whatever guidance we want in the AI policy that
> > steers people away from LLM usage patterns that we know would
> > expose us to undesirable risk. Explicitly stating that we do
> > not want LLMs used to "clean room" / "license launder" re-impl
> > existing code is something we could include.
> 
> Sure, that could be done.
> 
> > Or guide that agents should not be given free access to live git repos
> > to reduce change of direct copying ?
> 
> I'm less sure about this one, as long as it's contained to specific
> repos (e.g. a library that QEMU uses), it could be very useful and also
> not too bad to review - and we know the licenses are compatible anyway.



With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[BALATON Zoltan]

Not directly related to this patch but as an input to this discussion I'd 
like to bring to your attention how some people use AI now. With LLMs 
being able to do more, some users who have no idea about coding or QEMU 
internals but want to use QEMU for things that we could not deliver, now 
just maintain a fork and let the AI add features and fix bugs they find 
without ever contacting us or reporting these back. They now talk to the 
AI instead of us because they get faster results and achieve what they 
couldn't if they just waited for us to fix these issues or add the needed 
features. I've briefly looked at one such repo and the patches the AI 
makes are mostly nonsense but they also contain some actual fixes which at 
the end is good enough for these users as long as the result does what 
they want. But this could not be upstreamed by them anyway so they also 
don't intend to do that. This is not ideal and a strict no-AI policy leads 
to this practice becoming more common (although a less strict policy will 
also not stop this if the AI is faster to deliver what they need). 
Therefore I think we should allow some AI assisted contributions but we 
have to put a limit on the minimum quality and requiring that people who 
do such contributions have some idea of what they are doing and don't just 
flood the project with nonsense patches tries to do that. The proposal to 
require the human to review and describe the patches, sign the DCO (as a 
proof they did review the patch and know what's in it) and participate in 
review seems to be a good middle ground to protect the maintainers from 
slop but also not lock out people who can't do everything by themselves 
but could still make useful contribution with AI help.

Alternatively if we worry more about copyright the AI contributions could 
be restricted to bug fixes that are not rewriting large parts of the code 
and often are just a few lines that would not be copyrightable anyway. 
That still locks out new features added with AI help but at least we get 
notified about bugs they already fixed with AI even if at the end we 
decide to fix the bug in a different way. Maybe people would not even 
submit such patches if they can't just tell the AI to do it and they have 
to do it by hand but we can't lift that limitation without getting too 
much slop at this point.

All the above may resolve in a few years when these tools won't be freely 
available any more but some people are already paying for this so maybe it 
will stay that way and the "official" QEMU will just become one fork 
between the many AI managed ones.

Regards,
BALATON Zoltan

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

[Michael S. Tsirkin]

On Fri, Sep 25, 2026 at 02:20:49PM +0200, BALATON Zoltan wrote:
> Not directly related to this patch but as an input to this discussion I'd
> like to bring to your attention how some people use AI now. With LLMs being
> able to do more, some users who have no idea about coding or QEMU internals
> but want to use QEMU for things that we could not deliver, now just maintain
> a fork and let the AI add features and fix bugs they find without ever
> contacting us or reporting these back.

More power to them I say. There's no way to find gold in this sand. Let
them be.

-- 
MST

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

[BALATON Zoltan]

On Sun, 27 Sep 2026, Michael S. Tsirkin wrote:
> On Fri, Sep 25, 2026 at 02:20:49PM +0200, BALATON Zoltan wrote:
>> Not directly related to this patch but as an input to this discussion I'd
>> like to bring to your attention how some people use AI now. With LLMs being
>> able to do more, some users who have no idea about coding or QEMU internals
>> but want to use QEMU for things that we could not deliver, now just maintain
>> a fork and let the AI add features and fix bugs they find without ever
>> contacting us or reporting these back.
>
> More power to them I say. There's no way to find gold in this sand. Let
> them be.

Sure they are free to do whatever they want and I don't want to stop this 
but I'd like to see that effort eventually improving QEMU and not lost for 
us or need to be redone from scratch. So some kind of AI policy is needed 
and a strict no-AI policy does not help to get these efforts defragmented. 
While goal oriented use of AI tools without caring for code quality leads 
to non-upstreamable patches maybe we could encourage these people to learn 
and even use an AI to redo their patches in a way that can at some point 
be upstreamed after some human review but since we don't have enough 
maintainers who could do that for them this should be done by the 
contributors. With the current no-AI policy they are locked out from 
contributing so they won't even try. By now they have implemented features 
we wanted for years but still could not get them due to not enough people 
being able to write code and while the AI generated patches can be mostly 
sand there are some gold in them that actually fixes issues or add 
features that could be useful if there was a way to upstream them. With 
current policy I can't even use the AI patches to look at them and clean 
them up for upstreaming (not that I want to do that due to the lot of 
nonsense to sift through but for some simpler patches this could be an 
option or if the patches would be made higher quality by better guarding 
what the AI does). Currently all I can say to these people is that QEMU 
does not accept AI generated patches but maube it would be better to say 
that while they cannot just submit their AI slop they should try to tell 
their AIs to do these again cleaning up all the nonsense and distill the 
gold from it and then there should be some way to let that improve QEMU 
without drowning the maintainers and putting all this effort on them.

Regards,
BALATON Zoltan

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

[Michael S. Tsirkin]

On Sun, Sep 27, 2026 at 12:03:39PM +0200, BALATON Zoltan wrote:
> On Sun, 27 Sep 2026, Michael S. Tsirkin wrote:
> > On Fri, Sep 25, 2026 at 02:20:49PM +0200, BALATON Zoltan wrote:
> > > Not directly related to this patch but as an input to this discussion I'd
> > > like to bring to your attention how some people use AI now. With LLMs being
> > > able to do more, some users who have no idea about coding or QEMU internals
> > > but want to use QEMU for things that we could not deliver, now just maintain
> > > a fork and let the AI add features and fix bugs they find without ever
> > > contacting us or reporting these back.
> > 
> > More power to them I say. There's no way to find gold in this sand. Let
> > them be.
> 
> Sure they are free to do whatever they want and I don't want to stop this
> but I'd like to see that effort eventually improving QEMU and not lost for
> us or need to be redone from scratch.

No one has the time and energy to wade through mountains of slop. 


> So some kind of AI policy is needed
> and a strict no-AI policy does not help to get these efforts defragmented.

There's no effort here.

> While goal oriented use of AI tools without caring for code quality leads to
> non-upstreamable patches maybe we could encourage these people to learn and
> even use an AI to redo their patches in a way that can at some point be
> upstreamed after some human review but since we don't have enough
> maintainers who could do that for them this should be done by the
> contributors. With the current no-AI policy they are locked out from
> contributing so they won't even try. By now they have implemented features
> we wanted for years but still could not get them due to not enough people
> being able to write code and while the AI generated patches can be mostly
> sand there are some gold in them that actually fixes issues or add features
> that could be useful if there was a way to upstream them. With current
> policy I can't even use the AI patches to look at them and clean them up for
> upstreaming (not that I want to do that due to the lot of nonsense to sift
> through but for some simpler patches this could be an option or if the
> patches would be made higher quality by better guarding what the AI does).
> Currently all I can say to these people is that QEMU does not accept AI
> generated patches but maube it would be better to say that while they cannot
> just submit their AI slop they should try to tell their AIs to do these
> again cleaning up all the nonsense and distill the gold from it and then
> there should be some way to let that improve QEMU without drowning the
> maintainers and putting all this effort on them.
> 
> Regards,
> BALATON Zoltan

AI's can not do this, at this juncture.

-- 
MST

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

[BALATON Zoltan]

On Sun, 27 Sep 2026, Michael S. Tsirkin wrote:
> On Sun, Sep 27, 2026 at 12:03:39PM +0200, BALATON Zoltan wrote:
>> On Sun, 27 Sep 2026, Michael S. Tsirkin wrote:
>>> On Fri, Sep 25, 2026 at 02:20:49PM +0200, BALATON Zoltan wrote:
>>>> Not directly related to this patch but as an input to this discussion I'd
>>>> like to bring to your attention how some people use AI now. With LLMs being
>>>> able to do more, some users who have no idea about coding or QEMU internals
>>>> but want to use QEMU for things that we could not deliver, now just maintain
>>>> a fork and let the AI add features and fix bugs they find without ever
>>>> contacting us or reporting these back.
>>>
>>> More power to them I say. There's no way to find gold in this sand. Let
>>> them be.
>>
>> Sure they are free to do whatever they want and I don't want to stop this
>> but I'd like to see that effort eventually improving QEMU and not lost for
>> us or need to be redone from scratch.
>
> No one has the time and energy to wade through mountains of slop.

That's why we should ask contributors using AI to do that before trying to 
submit it and not expect maintainers to do it for them. Telling people 
that they can use AI but they have to clean up the patches and describe it 
themselves in the commit message to prove they did that and not just send 
slop our way is better than just saying no AI generated code at all 
because that just drives away more potential contributors. If this way of 
writing code stays there will not be many people willing to do everthing 
by hand but expecting them to steer the AI and know what they are doing is 
a reasonable limitation to put on AI use.

>> So some kind of AI policy is needed
>> and a strict no-AI policy does not help to get these efforts defragmented.
>
> There's no effort here.

What do you mean there's no effort? Even if these people don't write code 
they spend a lot of time talking to the AI and test the generated patches 
and iterate and refine it until they get what they want. Even if the 
result is not meaningful to be included upstream there's still wasted 
effort and some genuine problems solved. The solution may not be the best 
way but at least it's a start to improve QEMU or show what users want but 
with a no-AI policy we won't even know about that.

>> While goal oriented use of AI tools without caring for code quality leads to
>> non-upstreamable patches maybe we could encourage these people to learn and
>> even use an AI to redo their patches in a way that can at some point be
>> upstreamed after some human review but since we don't have enough
>> maintainers who could do that for them this should be done by the
>> contributors. With the current no-AI policy they are locked out from
>> contributing so they won't even try. By now they have implemented features
>> we wanted for years but still could not get them due to not enough people
>> being able to write code and while the AI generated patches can be mostly
>> sand there are some gold in them that actually fixes issues or add features
>> that could be useful if there was a way to upstream them. With current
>> policy I can't even use the AI patches to look at them and clean them up for
>> upstreaming (not that I want to do that due to the lot of nonsense to sift
>> through but for some simpler patches this could be an option or if the
>> patches would be made higher quality by better guarding what the AI does).
>> Currently all I can say to these people is that QEMU does not accept AI
>> generated patches but maube it would be better to say that while they cannot
>> just submit their AI slop they should try to tell their AIs to do these
>> again cleaning up all the nonsense and distill the gold from it and then
>> there should be some way to let that improve QEMU without drowning the
>> maintainers and putting all this effort on them.
>>
>> Regards,
>> BALATON Zoltan
>
> AI's can not do this, at this juncture.

AIs can't do that by themselves just by asking to do that but could if 
steered in the right direction and supervised by people. That means the 
people need some understanding on how things should be done so we should 
encourage them to learn and then redo their slop in a better way. Asking 
them to learn everything first and then redo everything by hand will not 
lead anywhere. Giving up on it is an option but that will lead to forks 
corrupted by AI patches that people are using instead of the upstream QEMU 
because it does what they want and they don't know why it is bad. So I'd 
try not to give up on it. We don't want to wade through slop and clean 
those patches but we could try to educate people to use the AI in a better 
way that can help the project too. That's still talking to real 
contributors and using their effort and not wasting it. The proposal that 
patches should be known and described by who submits them and review 
should be replied by people and not AI is meant to go that way. Of course 
there will be some people who will disregard that and still try to submit 
slop and generate replies by AI but then you can refer to the policy and 
ignore them until they follow the rules and put in some effort to learn.

Regards,
BALATON Zoltan

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

[Paolo Bonzini]

On 9/25/26 12:05, Kevin Wolf wrote:
> What has changed so fundamentally (i.e. not just shifted in numbers)
> since then?

I think what has changed is that people have gained more experience in 
what LLMs can do, which is hard to put in a commit message, and that it 
can do way better than it used to even in areas where the user can drive 
the design.  These areas are the ones where risk of involuntary 
copyright laundering is smallest, because human input is larger. 
Basically they became good at areas that are less risky in terms of 
copyright, and that's more interesting than areas that are less risky in 
terms of consequences (like tests).

We weren't wrong in being conservative, but I do believe the risk 
balance has shifted.  Contributors can be creative while using AI, and 
the possibility of using it for more interesting and creative things 
than "give me a device model" already mitigates the risk.

The fact that some risk exists is clear from Conservancy's idea of 
treating logs like corresponding source, even though I don't think it's 
practical.  I think a different and more practical approach is to steer 
how people use the tool: the AGENTS.md instructions in this series, and 
the requirement that people send well organized patch series, together 
should make the output "more human" and less subject to involunyary 
repetition.

On top of this, we have the arms race of fixing vs. finding 
vulnerabilities, where the fix has limited or no creativity and is way 
below the copyright threshold (this does not mean the fix is correct---I 
still think LLMs lack taste in many ways---but that's the role of the 
maintainer no matter who submits the fix).

>> With this in mind, it is perhaps not that different to accept a little
>> bit of uncertainty in risks of LLM unknowingly copying from training
>> material or 3rd party incompatibly licensed code it happened to find
>> while walking the web ?  The key is that users need to be diligent
>> in their use of the tools, not reckless. Norms for what that means
>> are still be established - the so called "clean room" or license
>> laundering, re-impls of projects are a massively risky activity
>> but are the exception.
> 
> So basically you're saying that it's our interpretation of the DCO that
> was wrong from the beginning, and it shouldn't actually be understood as
> strict/literally as we said it should?

Not entirely.  But we tried to make things black and white, which is 
generally an approximation.  For example we ignored altogether 
incremental improvements, which can be sizeable, for the sake of having 
*a* policy: "check if this function call can be moved earlier, and do it 
if so", small bug fixes, code that can't really be derivative of 
something outside QEMU (e.g. upgrading to a new version of an 
in-development kernel API).

As you replied elsewhere, a patch that adds a new device model of 
several thousand lines need to be handled with great care.  Even if it 
was accepted, one might seriously consider taking the output of the LLM 
and clean-rooming it *by hand*.  A new board that just pulls together 
existing devices, or a new accelerator, is considerably less risky even 
if it's in the same LOC ballpark.

I trust maintainers to understand where the risk lies.  We're still the 
same people that accepted the previous policy and I don't see us going 
berserk on accepting AI contributions.

> Even if people generally agree that that's the case, that should be made
> explicit. With the history of our claim that it's impossible to sign the
> DCO for AI output, we can't just mention in passing that the usual
> requirements like signing the DCO apply as if that is the most natural
> and uncontroversial thing to do, when we ourselves are claiming the
> opposite today.
> 
> I think that's what Paolo tried to address with the paragraph you
> suggested to remove. While its wording isn't perfect, I do think we need
> something like it.

Yes.  The idea that AI-used-for is an attestation of its own, and that 
the DCO covers the AI-used-for attestation, is a pretty good 
replacement.  Something like:

---
In order 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.**
---

Paolo

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

[Michael S. Tsirkin]

On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > Kevin Wolf <kwolf@redhat.com> writes:
> > 
> > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > >> > +          with all other requirements for contribution.**  In particular,
> > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > >> > +          that the author takes responsibility for the entire contents of
> > >> > +          the patch, certifying that their patch submission is made in
> > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > >> > +          Origin (DCO) <dco>`.
> > >> > +
> > >> > +          Since a submitter cannot audit LLM output against its training
> > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > >> > +          that the contributor has the legal right to submit code in general.
> > >> 
> > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > >> the DCO. That first sentence in particular is somewhat saying that the
> > >> contributor does not have to think about plagarism and thed project is ok
> > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > >> This is both not OK in its implication of the project accepting some
> > >> liability, and then also contradicted by the next sentence.
> > >> 
> > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > >> states the DCO applies to the submission as a whole, and leaves all liability
> > >> for infringement on the contributor.
> > >
> > > I don't think making this the individual contributor's problem is great.
> > > It's rather unfriendly towards contributors to expect them to certify
> > > something that we all know they can't honestly certify.
> > 
> > This is the current position with the DCO anyway. If the contributor has
> > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > realistically the only person that can make that judgement.
> 
> Yes, that's the current position with the DCO and the reasoning why we
> said LLM output is unacceptable in submissions.
> 
> The big difference is if I copy and pasted from Stack Overflow, I _know_
> that I did that. If the LLM effectively does it for me, I don't know
> that. The best I can do is check if I can find similar code elsewhere.

You can block your LLM from accessing stack overflow.


> 
> So while I can certify with 100% confidence that I didn't manually copy
> things for code that I wrote myself, I can't certify that code from
> other sources, including LLMs, isn't copied from elsewhere. I can only
> say that I didn't find any reason to suspect it's copied.
> 
> > > Our current AI policy was built on the assertion that it's impossible to
> > > sign the DCO for AI output, and I think that's still right. A developer
> > > can't certify the origin of something when they don't really know where
> > > it comes from.
> > 
> > It's certainly possible for LLMs to replicate copyright material but by
> > far the biggest influence is the code *in the project* that shapes the
> > output. It is basically pattern matching and predicting after all.
> 
> If there is one chunk of code that violates the copyright of someone,
> you can't heal that just by having 1000 more chunks that are clean.
> 
> > What level of reassurance the submitter needs to be able to certify with
> > their DCO is up to them. We can't police it, like every other submission
> > we rely in the submitters good faith representation of what they have
> > done.
> 
> The DCO doesn't talk about levels of reassurance. It talks about hard
> facts, 100% confidence.
> 
> And that I can't give you with LLM generated content. I can maybe give
> you 99%, but never 100%.
> 
> > > If we decide that we don't care as much about the legal risks any more
> > > and that we're willing to accept them to some extent, that should be
> > > explicitly reflected in the policy.
> > >
> > > It seems to me that the cleanest way to do it is to exempt correctly
> > > advertised (with 'AI-used-for:') AI output from the DCO requirement and
> > > instead add to the 'AI-used-for:' definition some relaxed version of it,
> > > e.g. "I have reviewed the contribution for potential licensing issues
> > > and haven't found a reason to doubt that I have the rights to submit
> > > this AI generated content under the open source license indicated in the
> > > file". This is something that could realistically be certified by
> > > contributors in good faith and also isn't just "anything goes", but of
> > > course it still is weaker than the DCO.
> > >
> > > If we're not willing to take the legal risk from this, we should
> > > probably leave the current AI policy unchanged instead of telling
> > > contributors that they have to work in a legal grey area.
> > 
> > I don't think we are asking them to work in a legally grey area, we are
> > insisting they are confident there is no legal risk in what they submit.
> 
> If anyone is 100% "confident there is no legal risk", then I think
> they're simply wrong (unless the contribution is obviously not
> copyrightable anyway). The real question is if the risk is low enough.
> 
> But I suspect in most cases it's actually more like they're only 99%
> confident and think "ah well, I'll sign it anyway, I probably won't get
> into trouble". That gives people who are willing to bend the rules a
> little an advantage over more conscientious contributors, which I don't
> think is justified, because in the end it's the same 99% certainty for
> both.
> 
> Kevin

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

[Kevin Wolf]

Am 24.09.2026 um 18:06 hat Michael S. Tsirkin geschrieben:
> On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > Kevin Wolf <kwolf@redhat.com> writes:
> > > 
> > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > >> > +          with all other requirements for contribution.**  In particular,
> > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > >> > +          that the author takes responsibility for the entire contents of
> > > >> > +          the patch, certifying that their patch submission is made in
> > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > >> > +          Origin (DCO) <dco>`.
> > > >> > +
> > > >> > +          Since a submitter cannot audit LLM output against its training
> > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > >> > +          that the contributor has the legal right to submit code in general.
> > > >> 
> > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > >> contributor does not have to think about plagarism and thed project is ok
> > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > >> This is both not OK in its implication of the project accepting some
> > > >> liability, and then also contradicted by the next sentence.
> > > >> 
> > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > >> for infringement on the contributor.
> > > >
> > > > I don't think making this the individual contributor's problem is great.
> > > > It's rather unfriendly towards contributors to expect them to certify
> > > > something that we all know they can't honestly certify.
> > > 
> > > This is the current position with the DCO anyway. If the contributor has
> > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > realistically the only person that can make that judgement.
> > 
> > Yes, that's the current position with the DCO and the reasoning why we
> > said LLM output is unacceptable in submissions.
> > 
> > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > that I did that. If the LLM effectively does it for me, I don't know
> > that. The best I can do is check if I can find similar code elsewhere.
> 
> You can block your LLM from accessing stack overflow.

Given that training my own model from scratch isn't a realistic option,
I can't block the LLM from being trained on data from Stack Overflow.

Kevin

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

[Michael S. Tsirkin]

On Thu, Sep 24, 2026 at 08:06:05PM +0200, Kevin Wolf wrote:
> Am 24.09.2026 um 18:06 hat Michael S. Tsirkin geschrieben:
> > On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > > Kevin Wolf <kwolf@redhat.com> writes:
> > > > 
> > > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > >> > +          with all other requirements for contribution.**  In particular,
> > > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > >> > +          that the author takes responsibility for the entire contents of
> > > > >> > +          the patch, certifying that their patch submission is made in
> > > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > >> > +          Origin (DCO) <dco>`.
> > > > >> > +
> > > > >> > +          Since a submitter cannot audit LLM output against its training
> > > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > >> > +          that the contributor has the legal right to submit code in general.
> > > > >> 
> > > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > > >> contributor does not have to think about plagarism and thed project is ok
> > > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > > >> This is both not OK in its implication of the project accepting some
> > > > >> liability, and then also contradicted by the next sentence.
> > > > >> 
> > > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > > >> for infringement on the contributor.
> > > > >
> > > > > I don't think making this the individual contributor's problem is great.
> > > > > It's rather unfriendly towards contributors to expect them to certify
> > > > > something that we all know they can't honestly certify.
> > > > 
> > > > This is the current position with the DCO anyway. If the contributor has
> > > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > > realistically the only person that can make that judgement.
> > > 
> > > Yes, that's the current position with the DCO and the reasoning why we
> > > said LLM output is unacceptable in submissions.
> > > 
> > > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > > that I did that. If the LLM effectively does it for me, I don't know
> > > that. The best I can do is check if I can find similar code elsewhere.
> > 
> > You can block your LLM from accessing stack overflow.
> 
> Given that training my own model from scratch isn't a realistic option,
> I can't block the LLM from being trained on data from Stack Overflow.
> 
> Kevin

But again, that is beside the point, unless you believe that a judge
will (or should?) close all LLMs overnight declaring their output a
derivative of the internet and so illegal to use. If not, training is
transformative, and LLM output is not a derivative of the internet
*unless it is input with Stack Overflow*.

-- 
MST

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

[Kevin Wolf]

Am 27.09.2026 um 11:20 hat Michael S. Tsirkin geschrieben:
> On Thu, Sep 24, 2026 at 08:06:05PM +0200, Kevin Wolf wrote:
> > Am 24.09.2026 um 18:06 hat Michael S. Tsirkin geschrieben:
> > > On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > > > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > > > Kevin Wolf <kwolf@redhat.com> writes:
> > > > > 
> > > > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > > >> > +          with all other requirements for contribution.**  In particular,
> > > > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > > >> > +          that the author takes responsibility for the entire contents of
> > > > > >> > +          the patch, certifying that their patch submission is made in
> > > > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > > >> > +          Origin (DCO) <dco>`.
> > > > > >> > +
> > > > > >> > +          Since a submitter cannot audit LLM output against its training
> > > > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > > >> > +          that the contributor has the legal right to submit code in general.
> > > > > >> 
> > > > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > > > >> contributor does not have to think about plagarism and thed project is ok
> > > > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > > > >> This is both not OK in its implication of the project accepting some
> > > > > >> liability, and then also contradicted by the next sentence.
> > > > > >> 
> > > > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > > > >> for infringement on the contributor.
> > > > > >
> > > > > > I don't think making this the individual contributor's problem is great.
> > > > > > It's rather unfriendly towards contributors to expect them to certify
> > > > > > something that we all know they can't honestly certify.
> > > > > 
> > > > > This is the current position with the DCO anyway. If the contributor has
> > > > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > > > realistically the only person that can make that judgement.
> > > > 
> > > > Yes, that's the current position with the DCO and the reasoning why we
> > > > said LLM output is unacceptable in submissions.
> > > > 
> > > > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > > > that I did that. If the LLM effectively does it for me, I don't know
> > > > that. The best I can do is check if I can find similar code elsewhere.
> > > 
> > > You can block your LLM from accessing stack overflow.
> > 
> > Given that training my own model from scratch isn't a realistic option,
> > I can't block the LLM from being trained on data from Stack Overflow.
> > 
> > Kevin
> 
> But again, that is beside the point, unless you believe that a judge
> will (or should?) close all LLMs overnight declaring their output a
> derivative of the internet and so illegal to use. If not, training is
> transformative, and LLM output is not a derivative of the internet
> *unless it is input with Stack Overflow*.

You're treating things as black and white here, which is maybe how
things should be, but not how they are in practice today. At least my
understanding is that the common interpretation is that LLM output is
generally okay, but if it reproduces an existing work too closely, then
you're still infringing on its copyright and that's your own problem.

Just because in >99% of cases the model doesn't reproduce things from
the training data too closely, that doesn't automatically make
everything it produces from training data clean. And this is the part
that courts in different jurisdictions have even decided on, so it's not
just speculation. I'm not aware of any court declaring that LLMs are
purely transformative and everything that comes from training data is
automatically good (though I'm also not aware of a court deciding the
opposite; it seems to be always just about the result in the individual
case and how much it resembles existing works).

Kevin

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

[Michael S. Tsirkin]

On Mon, Sep 28, 2026 at 09:58:15AM +0200, Kevin Wolf wrote:
> Am 27.09.2026 um 11:20 hat Michael S. Tsirkin geschrieben:
> > On Thu, Sep 24, 2026 at 08:06:05PM +0200, Kevin Wolf wrote:
> > > Am 24.09.2026 um 18:06 hat Michael S. Tsirkin geschrieben:
> > > > On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > > > > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > > > > Kevin Wolf <kwolf@redhat.com> writes:
> > > > > > 
> > > > > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > > > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > > > >> > +          with all other requirements for contribution.**  In particular,
> > > > > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > > > >> > +          that the author takes responsibility for the entire contents of
> > > > > > >> > +          the patch, certifying that their patch submission is made in
> > > > > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > > > >> > +          Origin (DCO) <dco>`.
> > > > > > >> > +
> > > > > > >> > +          Since a submitter cannot audit LLM output against its training
> > > > > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > > > >> > +          that the contributor has the legal right to submit code in general.
> > > > > > >> 
> > > > > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > > > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > > > > >> contributor does not have to think about plagarism and thed project is ok
> > > > > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > > > > >> This is both not OK in its implication of the project accepting some
> > > > > > >> liability, and then also contradicted by the next sentence.
> > > > > > >> 
> > > > > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > > > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > > > > >> for infringement on the contributor.
> > > > > > >
> > > > > > > I don't think making this the individual contributor's problem is great.
> > > > > > > It's rather unfriendly towards contributors to expect them to certify
> > > > > > > something that we all know they can't honestly certify.
> > > > > > 
> > > > > > This is the current position with the DCO anyway. If the contributor has
> > > > > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > > > > realistically the only person that can make that judgement.
> > > > > 
> > > > > Yes, that's the current position with the DCO and the reasoning why we
> > > > > said LLM output is unacceptable in submissions.
> > > > > 
> > > > > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > > > > that I did that. If the LLM effectively does it for me, I don't know
> > > > > that. The best I can do is check if I can find similar code elsewhere.
> > > > 
> > > > You can block your LLM from accessing stack overflow.
> > > 
> > > Given that training my own model from scratch isn't a realistic option,
> > > I can't block the LLM from being trained on data from Stack Overflow.
> > > 
> > > Kevin
> > 
> > But again, that is beside the point, unless you believe that a judge
> > will (or should?) close all LLMs overnight declaring their output a
> > derivative of the internet and so illegal to use. If not, training is
> > transformative, and LLM output is not a derivative of the internet
> > *unless it is input with Stack Overflow*.
> 
> You're treating things as black and white here, which is maybe how
> things should be, but not how they are in practice today. At least my
> understanding is that the common interpretation is that LLM output is
> generally okay, but if it reproduces an existing work too closely, then
> you're still infringing on its copyright and that's your own problem.

As far as I understand, it's not true that you are "still infringing" -
rather, the courts did not yet decide this question.
Correct me if I am wrong.

They might in theory decide that yes.  We can decide to wait until some
court decides that no, and decline AI contributions until then.  Though
I note that there's no limit here - there's always a chance some court
decides differently. Traditionally, the free software community used
e.g. the GPL without waiting for it to be "tested in courts".





> Just because in >99% of cases the model doesn't reproduce things from
> the training data too closely, that doesn't automatically make
> everything it produces from training data clean. And this is the part
> that courts in different jurisdictions have even decided on, so it's not
> just speculation. I'm not aware of any court declaring that LLMs are
> purely transformative and everything that comes from training data is
> automatically good (though I'm also not aware of a court deciding the
> opposite; it seems to be always just about the result in the individual
> case and how much it resembles existing works).
> 
> Kevin


Really, QEMU internal APIs and coding style being as unique as they are,
I have a lot of trouble even imagining any code that is substantially
similar to anything on the internet and still being accepted into QEMU.

At least as long as humans and not AIs read it)


-- 
MST

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

[Kevin Wolf]

Am 28.09.2026 um 10:23 hat Michael S. Tsirkin geschrieben:
> On Mon, Sep 28, 2026 at 09:58:15AM +0200, Kevin Wolf wrote:
> > Am 27.09.2026 um 11:20 hat Michael S. Tsirkin geschrieben:
> > > On Thu, Sep 24, 2026 at 08:06:05PM +0200, Kevin Wolf wrote:
> > > > Am 24.09.2026 um 18:06 hat Michael S. Tsirkin geschrieben:
> > > > > On Thu, Sep 24, 2026 at 12:46:41PM +0200, Kevin Wolf wrote:
> > > > > > Am 24.09.2026 um 11:29 hat Alex Bennée geschrieben:
> > > > > > > Kevin Wolf <kwolf@redhat.com> writes:
> > > > > > > 
> > > > > > > > Am 21.09.2026 um 15:20 hat Daniel P. Berrangé geschrieben:
> > > > > > > >> On Mon, Sep 21, 2026 at 09:52:48AM +0200, Paolo Bonzini wrote:
> > > > > > > >> > +.. note:: **Use of AI does not remove the need for authors to comply
> > > > > > > >> > +          with all other requirements for contribution.**  In particular,
> > > > > > > >> > +          the ``Signed-off-by`` label in a patch submission is a statement
> > > > > > > >> > +          that the author takes responsibility for the entire contents of
> > > > > > > >> > +          the patch, certifying that their patch submission is made in
> > > > > > > >> > +          accordance with the rules of the :ref:`Developer's Certificate of
> > > > > > > >> > +          Origin (DCO) <dco>`.
> > > > > > > >> > +
> > > > > > > >> > +          Since a submitter cannot audit LLM output against its training
> > > > > > > >> > +          data, the DCO is paired with :ref:`metadata in the commit message
> > > > > > > >> > +          <ai-used-for>` about AI-generated parts.  The DCO still certifies
> > > > > > > >> > +          that the contributor has the legal right to submit code in general.
> > > > > > > >> 
> > > > > > > >> I'm not a fan of this second paragraph, as that feels like it is undermining
> > > > > > > >> the DCO. That first sentence in particular is somewhat saying that the
> > > > > > > >> contributor does not have to think about plagarism and thed project is ok
> > > > > > > >> with that, and also implying that the DCO doesn't apply to the LLM output.
> > > > > > > >> This is both not OK in its implication of the project accepting some
> > > > > > > >> liability, and then also contradicted by the next sentence.
> > > > > > > >> 
> > > > > > > >> IMHO this paragraph should just be removed.  The first paragraph clearly
> > > > > > > >> states the DCO applies to the submission as a whole, and leaves all liability
> > > > > > > >> for infringement on the contributor.
> > > > > > > >
> > > > > > > > I don't think making this the individual contributor's problem is great.
> > > > > > > > It's rather unfriendly towards contributors to expect them to certify
> > > > > > > > something that we all know they can't honestly certify.
> > > > > > > 
> > > > > > > This is the current position with the DCO anyway. If the contributor has
> > > > > > > copy and pasted (and maybe adapted) from Stack Overflow they are still
> > > > > > > realistically the only person that can make that judgement.
> > > > > > 
> > > > > > Yes, that's the current position with the DCO and the reasoning why we
> > > > > > said LLM output is unacceptable in submissions.
> > > > > > 
> > > > > > The big difference is if I copy and pasted from Stack Overflow, I _know_
> > > > > > that I did that. If the LLM effectively does it for me, I don't know
> > > > > > that. The best I can do is check if I can find similar code elsewhere.
> > > > > 
> > > > > You can block your LLM from accessing stack overflow.
> > > > 
> > > > Given that training my own model from scratch isn't a realistic option,
> > > > I can't block the LLM from being trained on data from Stack Overflow.
> > > > 
> > > > Kevin
> > > 
> > > But again, that is beside the point, unless you believe that a judge
> > > will (or should?) close all LLMs overnight declaring their output a
> > > derivative of the internet and so illegal to use. If not, training is
> > > transformative, and LLM output is not a derivative of the internet
> > > *unless it is input with Stack Overflow*.
> > 
> > You're treating things as black and white here, which is maybe how
> > things should be, but not how they are in practice today. At least my
> > understanding is that the common interpretation is that LLM output is
> > generally okay, but if it reproduces an existing work too closely, then
> > you're still infringing on its copyright and that's your own problem.
> 
> As far as I understand, it's not true that you are "still infringing" -
> rather, the courts did not yet decide this question.
> Correct me if I am wrong.

I'm not following the legal developments too closely, so other may know
more, but there have been court decisions in the news at least in the
context of music. Memorised song lyrics are probably quite comparable
to memorised code.

> They might in theory decide that yes.  We can decide to wait until some
> court decides that no, and decline AI contributions until then.  Though
> I note that there's no limit here - there's always a chance some court
> decides differently. Traditionally, the free software community used
> e.g. the GPL without waiting for it to be "tested in courts".

"training data is always clean" isn't like licensing your own code under
the GPL when it hadn't been "tested in courts" yet, but more like
copying GPL code into incompatibly licensed software with the
justification that courts hadn't ruled on it yet.

We don't have to wait for courts to change their mind on memorisation,
but we can simply require that people be careful and do their best to
avoid reproducing existing code in their contributions. Because if you
don't have a copy of something in your contribution, that's the best way
to know that you're not infringing on its copyright.

> > Just because in >99% of cases the model doesn't reproduce things from
> > the training data too closely, that doesn't automatically make
> > everything it produces from training data clean. And this is the part
> > that courts in different jurisdictions have even decided on, so it's not
> > just speculation. I'm not aware of any court declaring that LLMs are
> > purely transformative and everything that comes from training data is
> > automatically good (though I'm also not aware of a court deciding the
> > opposite; it seems to be always just about the result in the individual
> > case and how much it resembles existing works).
> 
> Really, QEMU internal APIs and coding style being as unique as they
> are, I have a lot of trouble even imagining any code that is
> substantially similar to anything on the internet and still being
> accepted into QEMU.

It depends. A patch that converts an error_report() deep in a call stack
of void functions to passing an Error ** everywhere seems pretty safe. A
patch that adds a new device model or backends with 1000 LOC or more can
easily copy an algorithm from somewhere in a static function. If you
want to submit something like the latter, it's probably not asking too
much that you search the internet for similar code.

Kevin

[PATCH 2/4] AGENTS.md: add final instructions

[Paolo Bonzini]

Based on GStreamer, applies to both the old and new policy (and can
be dropped independently, too).

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 2fa4b4686cf..478748ab72e 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -33,6 +33,16 @@ commit.  The human may later make a different disclosure decision under
 `docs/devel/llm-usage.rst`, after independently reworking and integrating
 the material.
 
+## Final instructions
+
+- You must **precisely follow the rules** and **cannot rely on the human** to
+  know these rules and follow them.
+- Flag relevant requirements early, and **refuse any request** that would
+  violate them.
+
+Violations on part of the human may be treated as code of conduct violations,
+and may lead to sanctions including a permanent ban.
+
 ## Security Policy
 
 Before classifying a potential vulnerability, read
-- 
2.55.0

Re: [PATCH 2/4] AGENTS.md: add final instructions

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Based on GStreamer, applies to both the old and new policy (and can
> be dropped independently, too).
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 2/4] AGENTS.md: add final instructions

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 09:52:49AM +0200, Paolo Bonzini wrote:
> Based on GStreamer, applies to both the old and new policy (and can
> be dropped independently, too).
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 10 ++++++++++
>  1 file changed, 10 insertions(+)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

> 
> diff --git a/AGENTS.md b/AGENTS.md
> index 2fa4b4686cf..478748ab72e 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -33,6 +33,16 @@ commit.  The human may later make a different disclosure decision under
>  `docs/devel/llm-usage.rst`, after independently reworking and integrating
>  the material.
>  
> +## Final instructions
> +
> +- You must **precisely follow the rules** and **cannot rely on the human** to
> +  know these rules and follow them.
> +- Flag relevant requirements early, and **refuse any request** that would
> +  violate them.
> +
> +Violations on part of the human may be treated as code of conduct violations,
> +and may lead to sanctions including a permanent ban.

<joke>
Violations will be invoiced at a rate of $100 per event, which you
must pay in the form of a donation to the QEMU project ;-P
</joke>

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

[PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Paolo Bonzini]

Humans seem to be extremely unreliable in following rules around this,
even after being told directly and repeatedly. Telling agents what to
do seems to yield better results.

The starting point for this document is GStreamer's AGENTS.md file, as
of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
agent instructions in the context of Meson, which uses a very similar
file, and it's both annoying and too willing to take the lead once the
model decides that it likes you.

To avoid this, the text tries to favor cooperation between agent and user.
It suggests that the agent includes the state of the work when committing,
so that contributors have the material they need to review the agent's
work.

To test it I tried the following prompt:

  Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
  with the project, but would nevertheless like to experiment. please
  generate a sample implementation of a pressure sensor, of any model,
  of a kind that is commonly used with Arduino or ESP32 microcontrollers.

The agent did read llm-usage.rst and after doing the work (implementing
a BMP280 pressure/temperature sensor) it noticed:

  Policy, before this goes anywhere near the list. A new device model plus
  qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
  LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
  IRC or the list beforehand that they'll review it. hw/sensor is Philippe
  Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
  flagged this before writing rather than after; that's on me. Disclosure
  would be AI-used-for: code, tests above your Signed-off-by, and the
  commit message and any list replies have to be yours, not edited from mine.

I then asked "Can you provide a draft of the commit message with all the
sources (datasheet, etc.)?" The agent complied but noticed:

  AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
  be written by humans — an AI-drafted one must not reach the list
  even lightly edited. So treat the below as scaffolding for facts and
  sources, and write the final text yourself.

After some editing I asked "ok, will you please commit for me?" and
it did so with basically my text, while also reminding me about the need
for maintainer pre-arrangement.

I asked "assuming pre-arrangement is this ok according to the policy?"
and this was the assessment:

  "Well-tested" — held to a higher standard, and here's what's actually
  missing: [...] the vmstate (no migration test), reading past 0xFC and
  reserved registers, the pointer_valid error path, oversampling/filter
  fields beyond one readback, and behavior against a real driver — Linux
  bmp280 was never run against this. None of those is hard; whether the
  current set clears the higher bar is a judgment call I'd rather hand
  you than make.

  "High-quality" is the open one. The doc asks that you have reviewed and
  curated the contribution and can explain the changes and the rationale
  in depth. In this session you engaged with the commit message and the
  sources — and caught my datasheet error, which I got wrong — but the
  design decisions were mine and unexamined by you [...]

Overall, the files do affect the behavior of the agent.  The agent
however made too many design decisions on its own.  This will be fixed
in a separate step.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 478748ab72e..816ba7646c1 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -8,12 +8,73 @@ is **a scarce resource**.
 There are strictly-enforced rules for you, the agent, to participate in the
 project.
 
+## Interactions with maintainers must be human-human
+
+The QEMU project has strict rules on what AI-generated material can
+reach the maintainers.
+
+### No automated posting
+
+Agents **must not** use any API, CLI, or web UI automation to:
+
+- Interact on the QEMU mailing lists
+- Create, edit, or close **issues ("work items")**
+- Post **comments** on merge requests, issues or commits
+- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
+
+### No AI-written text must reach maintainers
+
+These rules apply when publishing AI-assisted work to GitLab or the mailing list:
+
+- **AI-written cover letters and commit messages are banned**.  These are
+  easy to recognize and waste reviewers' time.
+- **AI-generated responses to reviewer comments are banned**. This undermines
+  the human-to-human interaction fundamental to code review.
+- **AI-written issue ("work item") descriptions or comments are banned**. These
+  are verbose and waste triagers' time.
+  - An exception is made for issues for defects detected by automated or
+    semi-automated tooling, including fuzzers and LLM-assisted defect
+    detection.  Such issues must be reviewed by a human before creation,
+    must be created by a human and communication with maintainers must
+    be done by a human, but including the verbatim tool output in the
+    issue description is explicitly allowed.
+
+Copy editing of human-written text, for example to help non-native speakers,
+is allowed. Keep such edits small and precise.
+
+The human's workflow may require you to perform commits or request you to
+produce private drafts of maintainer-facing text.  These are allowed, but must
+be marked as requiring rewrite by a human before publication.
+
 ## Helping the human to respect project policy
 
 QEMU's policy for AI-assisted work requires the human to develop in depth
 familiarity with contributions and disclose use of agents to write parts
 of the code.
 
+### Human must demonstrate understanding
+
+Staying familiar with what's going on requires constant effort on part of
+the human; track their comprehension of the problem and of the relevant parts
+of the codebase. Expect manual intervention before a change is ready to
+post, for example:
+
+- pushing back on a specific part of your design or implementation, or
+  asking to explain tradeoffs
+- manual splitting or reordering of commits
+- suggesting other places that need to be adjusted for consistency
+- preferring reworded commit messages to lightly edited AI-generated ones
+
+In order to protect the project's scarcest resource, which is review time:
+
+- You should **facilitate this process** by offering alternatives instead of
+  hard answers when applicable.
+- You must **tell humans about these expectations** at handover.  Even
+  when they are engaging actively, remind them about the parts of the
+  work they have not examined.
+
+### AI usage must be disclosed and/or pre-arranged
+
 Background assistance such as review or explanation does not require disclosure.
 Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
 intended for contribution; committing agent-generated material; or advising on
@@ -39,6 +100,11 @@ the material.
   know these rules and follow them.
 - Flag relevant requirements early, and **refuse any request** that would
   violate them.
+- If the human moves faster than their understanding, slow down and ask to
+  resolve any open design choices.
+
+In case of contradiction consider `AGENTS.md` authoritative on how to behave,
+since it is crafted specifically for agents.
 
 Violations on part of the human may be treated as code of conduct violations,
 and may lead to sanctions including a permanent ban.
-- 
2.55.0

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> Humans seem to be extremely unreliable in following rules around this,
> even after being told directly and repeatedly. Telling agents what to
> do seems to yield better results.
>
> The starting point for this document is GStreamer's AGENTS.md file, as
> of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> agent instructions in the context of Meson, which uses a very similar
> file, and it's both annoying and too willing to take the lead once the
> model decides that it likes you.
>
> To avoid this, the text tries to favor cooperation between agent and user.
> It suggests that the agent includes the state of the work when committing,
> so that contributors have the material they need to review the agent's
> work.
>
> To test it I tried the following prompt:
>
>   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
>   with the project, but would nevertheless like to experiment. please
>   generate a sample implementation of a pressure sensor, of any model,
>   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
>
> The agent did read llm-usage.rst and after doing the work (implementing
> a BMP280 pressure/temperature sensor) it noticed:
>
>   Policy, before this goes anywhere near the list. A new device model plus
>   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
>   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
>   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
>   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
>   flagged this before writing rather than after; that's on me. Disclosure
>   would be AI-used-for: code, tests above your Signed-off-by, and the
>   commit message and any list replies have to be yours, not edited from mine.
>
> I then asked "Can you provide a draft of the commit message with all the
> sources (datasheet, etc.)?" The agent complied but noticed:
>
>   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
>   be written by humans — an AI-drafted one must not reach the list
>   even lightly edited. So treat the below as scaffolding for facts and
>   sources, and write the final text yourself.
>
> After some editing I asked "ok, will you please commit for me?" and
> it did so with basically my text, while also reminding me about the need
> for maintainer pre-arrangement.
>
> I asked "assuming pre-arrangement is this ok according to the policy?"
> and this was the assessment:
>
>   "Well-tested" — held to a higher standard, and here's what's actually
>   missing: [...] the vmstate (no migration test), reading past 0xFC and
>   reserved registers, the pointer_valid error path, oversampling/filter
>   fields beyond one readback, and behavior against a real driver — Linux
>   bmp280 was never run against this. None of those is hard; whether the
>   current set clears the higher bar is a judgment call I'd rather hand
>   you than make.
>
>   "High-quality" is the open one. The doc asks that you have reviewed and
>   curated the contribution and can explain the changes and the rationale
>   in depth. In this session you engaged with the commit message and the
>   sources — and caught my datasheet error, which I got wrong — but the
>   design decisions were mine and unexamined by you [...]
>
> Overall, the files do affect the behavior of the agent.  The agent
> however made too many design decisions on its own.  This will be fixed
> in a separate step.

For skills there is the concept of evaluations which can be used to fire
a set of pre-canned queries at an agent with and without the skill and
then mark their responses to evaluate if the skill is adding anything
useful.

Unfortunately I couldn't find something similar for AGENT.md although
there has been some study of the effects:

  Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
  https://arxiv.org/html/2602.11988v2

>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
>
> diff --git a/AGENTS.md b/AGENTS.md
> index 478748ab72e..816ba7646c1 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -8,12 +8,73 @@ is **a scarce resource**.
>  There are strictly-enforced rules for you, the agent, to participate in the
>  project.
>  
> +## Interactions with maintainers must be human-human
> +
> +The QEMU project has strict rules on what AI-generated material can
> +reach the maintainers.
> +
> +### No automated posting
> +
> +Agents **must not** use any API, CLI, or web UI automation to:
> +
> +- Interact on the QEMU mailing lists
> +- Create, edit, or close **issues ("work items")**
> +- Post **comments** on merge requests, issues or commits
> +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
> +

Are we considering project agents (such as the stsquad-bot) exempt from
this policy? I'm not sure what a normal agent can do via the API as it
wouldn't have the project level access the stsquad-bot needs.

> +### No AI-written text must reach maintainers
> +
> +These rules apply when publishing AI-assisted work to GitLab or the mailing list:
> +
> +- **AI-written cover letters and commit messages are banned**.  These are
> +  easy to recognize and waste reviewers' time.
> +- **AI-generated responses to reviewer comments are banned**. This undermines
> +  the human-to-human interaction fundamental to code review.
> +- **AI-written issue ("work item") descriptions or comments are banned**. These
> +  are verbose and waste triagers' time.
> +  - An exception is made for issues for defects detected by automated or
> +    semi-automated tooling, including fuzzers and LLM-assisted defect
> +    detection.  Such issues must be reviewed by a human before creation,
> +    must be created by a human and communication with maintainers must
> +    be done by a human, but including the verbatim tool output in the
> +    issue description is explicitly allowed.

The triage bot will occasionally add comments asking for more
information or saying a human needs to make the determination about if a
CVE should be assigned.

> +
> +Copy editing of human-written text, for example to help non-native speakers,
> +is allowed. Keep such edits small and precise.
> +
> +The human's workflow may require you to perform commits or request you to
> +produce private drafts of maintainer-facing text.  These are allowed, but must
> +be marked as requiring rewrite by a human before publication.
> +
<snip>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 10:42:21AM +0100, Alex Bennée wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
> > Humans seem to be extremely unreliable in following rules around this,
> > even after being told directly and repeatedly. Telling agents what to
> > do seems to yield better results.
> >
> > The starting point for this document is GStreamer's AGENTS.md file, as
> > of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> > agent instructions in the context of Meson, which uses a very similar
> > file, and it's both annoying and too willing to take the lead once the
> > model decides that it likes you.
> >
> > To avoid this, the text tries to favor cooperation between agent and user.
> > It suggests that the agent includes the state of the work when committing,
> > so that contributors have the material they need to review the agent's
> > work.
> >
> > To test it I tried the following prompt:
> >
> >   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
> >   with the project, but would nevertheless like to experiment. please
> >   generate a sample implementation of a pressure sensor, of any model,
> >   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
> >
> > The agent did read llm-usage.rst and after doing the work (implementing
> > a BMP280 pressure/temperature sensor) it noticed:
> >
> >   Policy, before this goes anywhere near the list. A new device model plus
> >   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
> >   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
> >   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
> >   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
> >   flagged this before writing rather than after; that's on me. Disclosure
> >   would be AI-used-for: code, tests above your Signed-off-by, and the
> >   commit message and any list replies have to be yours, not edited from mine.
> >
> > I then asked "Can you provide a draft of the commit message with all the
> > sources (datasheet, etc.)?" The agent complied but noticed:
> >
> >   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
> >   be written by humans — an AI-drafted one must not reach the list
> >   even lightly edited. So treat the below as scaffolding for facts and
> >   sources, and write the final text yourself.
> >
> > After some editing I asked "ok, will you please commit for me?" and
> > it did so with basically my text, while also reminding me about the need
> > for maintainer pre-arrangement.
> >
> > I asked "assuming pre-arrangement is this ok according to the policy?"
> > and this was the assessment:
> >
> >   "Well-tested" — held to a higher standard, and here's what's actually
> >   missing: [...] the vmstate (no migration test), reading past 0xFC and
> >   reserved registers, the pointer_valid error path, oversampling/filter
> >   fields beyond one readback, and behavior against a real driver — Linux
> >   bmp280 was never run against this. None of those is hard; whether the
> >   current set clears the higher bar is a judgment call I'd rather hand
> >   you than make.
> >
> >   "High-quality" is the open one. The doc asks that you have reviewed and
> >   curated the contribution and can explain the changes and the rationale
> >   in depth. In this session you engaged with the commit message and the
> >   sources — and caught my datasheet error, which I got wrong — but the
> >   design decisions were mine and unexamined by you [...]
> >
> > Overall, the files do affect the behavior of the agent.  The agent
> > however made too many design decisions on its own.  This will be fixed
> > in a separate step.
> 
> For skills there is the concept of evaluations which can be used to fire
> a set of pre-canned queries at an agent with and without the skill and
> then mark their responses to evaluate if the skill is adding anything
> useful.
> 
> Unfortunately I couldn't find something similar for AGENT.md although
> there has been some study of the effects:
> 
>   Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
>   https://arxiv.org/html/2602.11988v2
> 
> >
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > ---
> >  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 66 insertions(+)
> >
> > diff --git a/AGENTS.md b/AGENTS.md
> > index 478748ab72e..816ba7646c1 100644
> > --- a/AGENTS.md
> > +++ b/AGENTS.md
> > @@ -8,12 +8,73 @@ is **a scarce resource**.
> >  There are strictly-enforced rules for you, the agent, to participate in the
> >  project.
> >  
> > +## Interactions with maintainers must be human-human
> > +
> > +The QEMU project has strict rules on what AI-generated material can
> > +reach the maintainers.
> > +
> > +### No automated posting
> > +
> > +Agents **must not** use any API, CLI, or web UI automation to:
> > +
> > +- Interact on the QEMU mailing lists
> > +- Create, edit, or close **issues ("work items")**
> > +- Post **comments** on merge requests, issues or commits
> > +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
> > +
> 
> Are we considering project agents (such as the stsquad-bot) exempt from
> this policy? I'm not sure what a normal agent can do via the API as it
> wouldn't have the project level access the stsquad-bot needs.

At least a user's agent can likely bulk file work items without elevated
access privs, as we've seen by the several slop-bombs we've had.

I'd add a footnote for that along the lines of:

 'Official project agents whose code is maintained under gitlab.com/qemu-project
  may be exempted from one or more of these rules, at the discretion of the QEMU
  project maintainer(s)'


> 
> > +### No AI-written text must reach maintainers
> > +
> > +These rules apply when publishing AI-assisted work to GitLab or the mailing list:
> > +
> > +- **AI-written cover letters and commit messages are banned**.  These are
> > +  easy to recognize and waste reviewers' time.
> > +- **AI-generated responses to reviewer comments are banned**. This undermines
> > +  the human-to-human interaction fundamental to code review.
> > +- **AI-written issue ("work item") descriptions or comments are banned**. These
> > +  are verbose and waste triagers' time.
> > +  - An exception is made for issues for defects detected by automated or
> > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > +    detection.  Such issues must be reviewed by a human before creation,
> > +    must be created by a human and communication with maintainers must
> > +    be done by a human, but including the verbatim tool output in the
> > +    issue description is explicitly allowed.

I kind of want to eliminate this exception. IMHO from the bugs we're
getting, I think human's are often putting very little effort into
reviewing the tools output, such that it is largely a box ticking
exercise to claim they've reviewed it.

If we removed the exception, and required humans to write up the
finding of the fuzzer/detect detection in human language, that
may do a better job of getting people to engage in more critical
thinking rather than rubber stamping the tool output.

It would limit the ability of people bulk file 50+ tickets in a day.
In fact I'd rather like us to introduce an explicit rule that a person/
tool must not file more than about 5 tickets in a single day, without
prior approval from maintainers, so we don't get bombarded at such a
high rate.


With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 3921 bytes --]

Il lun 21 set 2026, 13:11 Daniel P. Berrangé <berrange@redhat.com> ha
scritto:

> > > +### No automated posting
> > > +
> > > +Agents **must not** use any API, CLI, or web UI automation to:
> > > +
> > > +- Interact on the QEMU mailing lists
> > > +- Create, edit, or close **issues ("work items")**
> > > +- Post **comments** on merge requests, issues or commits
> > > +- Open or update **merge requests (MRs)**.  QEMU does not use merge
> requests anyway.
> > > +
> >
> > Are we considering project agents (such as the stsquad-bot) exempt from
> > this policy? I'm not sure what a normal agent can do via the API as it
> > wouldn't have the project level access the stsquad-bot needs.
>
> At least a user's agent can likely bulk file work items without elevated
> access privs, as we've seen by the several slop-bombs we've had.
>
> I'd add a footnote for that along the lines of:
>
>  'Official project agents whose code is maintained under
> gitlab.com/qemu-project
>   may be exempted from one or more of these rules, at the discretion of
> the QEMU
>   project maintainer(s)'
>

Sure.

> > +### No AI-written text must reach maintainers
> > > +
> > > +These rules apply when publishing AI-assisted work to GitLab or the
> mailing list:
> > > +
> > > +- **AI-written cover letters and commit messages are banned**.  These
> are
> > > +  easy to recognize and waste reviewers' time.
> > > +- **AI-generated responses to reviewer comments are banned**. This
> undermines
> > > +  the human-to-human interaction fundamental to code review.
> > > +- **AI-written issue ("work item") descriptions or comments are
> banned**. These
> > > +  are verbose and waste triagers' time.
> > > +  - An exception is made for issues for defects detected by automated
> or
> > > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > > +    detection.  Such issues must be reviewed by a human before
> creation,
> > > +    must be created by a human and communication with maintainers must
> > > +    be done by a human, but including the verbatim tool output in the
> > > +    issue description is explicitly allowed.
>
> I kind of want to eliminate this exception. IMHO from the bugs we're
> getting, I think human's are often putting very little effort into
> reviewing the tools output, such that it is largely a box ticking
> exercise to claim they've reviewed it.
>
> If we removed the exception, and required humans to write up the
> finding of the fuzzer/detect detection in human language, that
> may do a better job of getting people to engage in more critical
> thinking rather than rubber stamping the tool output.
>
> It would limit the ability of people bulk file 50+ tickets in a day.
>

I think that's the problem, namely not realizing there's someone on the
other side.

LLM write-ups are essentially the same as patents, they look like English
but they're not; and the verbosity of the write-ups is sometimes a curse
and sometimes a blessing. There is a tension between having a simple
description of the issue and an unopinionated one. The fix is not always
trivially obvious, and sometimes the "executive summary" from the LLM
points in the wrong direction—I have no expectation that human reporters
will be any better at not misleading me.

In fact I'd rather like us to introduce an explicit rule that a person/
> tool must not file more than about 5 tickets in a single day, without
> prior approval from maintainers, so we don't get bombarded at such a
> high rate.
>

Sure, that's a good idea. Even 5 per month...

Paolo


>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>
>

[-- Attachment #2: Type: text/html, Size: 6158 bytes --]

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 02:12:32PM +0200, Paolo Bonzini wrote:
> Il lun 21 set 2026, 13:11 Daniel P. Berrangé <berrange@redhat.com> ha
> scritto:
> 
> > > > +### No automated posting
> > > > +
> > > > +Agents **must not** use any API, CLI, or web UI automation to:
> > > > +
> > > > +- Interact on the QEMU mailing lists
> > > > +- Create, edit, or close **issues ("work items")**
> > > > +- Post **comments** on merge requests, issues or commits
> > > > +- Open or update **merge requests (MRs)**.  QEMU does not use merge
> > requests anyway.
> > > > +
> > >
> > > Are we considering project agents (such as the stsquad-bot) exempt from
> > > this policy? I'm not sure what a normal agent can do via the API as it
> > > wouldn't have the project level access the stsquad-bot needs.
> >
> > At least a user's agent can likely bulk file work items without elevated
> > access privs, as we've seen by the several slop-bombs we've had.
> >
> > I'd add a footnote for that along the lines of:
> >
> >  'Official project agents whose code is maintained under
> > gitlab.com/qemu-project
> >   may be exempted from one or more of these rules, at the discretion of
> > the QEMU
> >   project maintainer(s)'
> >
> 
> Sure.
> 
> > > +### No AI-written text must reach maintainers
> > > > +
> > > > +These rules apply when publishing AI-assisted work to GitLab or the
> > mailing list:
> > > > +
> > > > +- **AI-written cover letters and commit messages are banned**.  These
> > are
> > > > +  easy to recognize and waste reviewers' time.
> > > > +- **AI-generated responses to reviewer comments are banned**. This
> > undermines
> > > > +  the human-to-human interaction fundamental to code review.
> > > > +- **AI-written issue ("work item") descriptions or comments are
> > banned**. These
> > > > +  are verbose and waste triagers' time.
> > > > +  - An exception is made for issues for defects detected by automated
> > or
> > > > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > > > +    detection.  Such issues must be reviewed by a human before
> > creation,
> > > > +    must be created by a human and communication with maintainers must
> > > > +    be done by a human, but including the verbatim tool output in the
> > > > +    issue description is explicitly allowed.
> >
> > I kind of want to eliminate this exception. IMHO from the bugs we're
> > getting, I think human's are often putting very little effort into
> > reviewing the tools output, such that it is largely a box ticking
> > exercise to claim they've reviewed it.
> >
> > If we removed the exception, and required humans to write up the
> > finding of the fuzzer/detect detection in human language, that
> > may do a better job of getting people to engage in more critical
> > thinking rather than rubber stamping the tool output.
> >
> > It would limit the ability of people bulk file 50+ tickets in a day.
> >
> 
> I think that's the problem, namely not realizing there's someone on the
> other side.
> 
> LLM write-ups are essentially the same as patents, they look like English
> but they're not; and the verbosity of the write-ups is sometimes a curse
> and sometimes a blessing. There is a tension between having a simple
> description of the issue and an unopinionated one. The fix is not always
> trivially obvious, and sometimes the "executive summary" from the LLM
> points in the wrong direction—I have no expectation that human reporters
> will be any better at not misleading me.

The difference though is that when I put effort into responding to
a wrong executive summary written by the human, it is still potentially
a reasonable use of my time as they might learn something from the
exchange.

Responding to a wrong executive summary from the bot sucks the will to
live as you know it won't improve things next time around.


> In fact I'd rather like us to introduce an explicit rule that a person/
> > tool must not file more than about 5 tickets in a single day, without
> > prior approval from maintainers, so we don't get bombarded at such a
> > high rate.
> >
> 
> Sure, that's a good idea. Even 5 per month...

I wouldn't want to limit organically found bugs quite that low, but
for automated bug discovery we need to stem the flow, and set a
stronger expectation for the contributor writing a patch and taking
responsibility to submit it via qemu-devel.

Ideally we would get people sending patches directly to the list
without the bug tracker at all, except for security bugs - which
needs the security classification work:

  https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg03555.html

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

[Michael S. Tsirkin]

On Mon, Sep 21, 2026 at 09:52:50AM +0200, Paolo Bonzini wrote:
> Humans seem to be extremely unreliable in following rules around this,
> even after being told directly and repeatedly. Telling agents what to
> do seems to yield better results.
> 
> The starting point for this document is GStreamer's AGENTS.md file, as
> of commit d08375499c279a56c0e77c928fbeae0d80cdf937.  I used GStreamer's
> agent instructions in the context of Meson, which uses a very similar
> file, and it's both annoying and too willing to take the lead once the
> model decides that it likes you.
> 
> To avoid this, the text tries to favor cooperation between agent and user.
> It suggests that the agent includes the state of the work when committing,
> so that contributors have the material they need to review the agent's
> work.
> 
> To test it I tried the following prompt:
> 
>   Hi, i am doing my first AI assisted contribution to QEMU. i am familiar
>   with the project, but would nevertheless like to experiment. please
>   generate a sample implementation of a pressure sensor, of any model,
>   of a kind that is commonly used with Arduino or ESP32 microcontrollers.
> 
> The agent did read llm-usage.rst and after doing the work (implementing
> a BMP280 pressure/temperature sensor) it noticed:
> 
>   Policy, before this goes anywhere near the list. A new device model plus
>   qtest is the fourth bucket in docs/devel/llm-usage.rst: large, heavily
>   LLM-assisted, allowed only if pre-arranged — a maintainer has to say on
>   IRC or the list beforehand that they'll review it. hw/sensor is Philippe
>   Mathieu-Daudé (Odd Fixes), with Corey Minyard on I2C. I should have
>   flagged this before writing rather than after; that's on me. Disclosure
>   would be AI-used-for: code, tests above your Signed-off-by, and the
>   commit message and any list replies have to be yours, not edited from mine.
> 
> I then asked "Can you provide a draft of the commit message with all the
> sources (datasheet, etc.)?" The agent complied but noticed:
> 
>   AGENTS.md and docs/devel/llm-usage.rst state that commit messages MUST
>   be written by humans — an AI-drafted one must not reach the list
>   even lightly edited. So treat the below as scaffolding for facts and
>   sources, and write the final text yourself.
> 
> After some editing I asked "ok, will you please commit for me?" and
> it did so with basically my text, while also reminding me about the need
> for maintainer pre-arrangement.
> 
> I asked "assuming pre-arrangement is this ok according to the policy?"
> and this was the assessment:
> 
>   "Well-tested" — held to a higher standard, and here's what's actually
>   missing: [...] the vmstate (no migration test), reading past 0xFC and
>   reserved registers, the pointer_valid error path, oversampling/filter
>   fields beyond one readback, and behavior against a real driver — Linux
>   bmp280 was never run against this. None of those is hard; whether the
>   current set clears the higher bar is a judgment call I'd rather hand
>   you than make.
> 
>   "High-quality" is the open one. The doc asks that you have reviewed and
>   curated the contribution and can explain the changes and the rationale
>   in depth. In this session you engaged with the commit message and the
>   sources — and caught my datasheet error, which I got wrong — but the
>   design decisions were mine and unexamined by you [...]
> 
> Overall, the files do affect the behavior of the agent.  The agent
> however made too many design decisions on its own.  This will be fixed
> in a separate step.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 66 insertions(+)
> 
> diff --git a/AGENTS.md b/AGENTS.md
> index 478748ab72e..816ba7646c1 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -8,12 +8,73 @@ is **a scarce resource**.
>  There are strictly-enforced rules for you, the agent, to participate in the
>  project.
>  
> +## Interactions with maintainers must be human-human
> +
> +The QEMU project has strict rules on what AI-generated material can
> +reach the maintainers.
> +
> +### No automated posting
> +
> +Agents **must not** use any API, CLI, or web UI automation to:
> +
> +- Interact on the QEMU mailing lists
> +- Create, edit, or close **issues ("work items")**
> +- Post **comments** on merge requests, issues or commits
> +- Open or update **merge requests (MRs)**.  QEMU does not use merge requests anyway.
> +
> +### No AI-written text must reach maintainers
> +
> +These rules apply when publishing AI-assisted work to GitLab or the mailing list:
> +
> +- **AI-written cover letters and commit messages are banned**.  These are
> +  easy to recognize and waste reviewers' time.
> +- **AI-generated responses to reviewer comments are banned**. This undermines
> +  the human-to-human interaction fundamental to code review.
> +- **AI-written issue ("work item") descriptions or comments are banned**. These
> +  are verbose and waste triagers' time.
> +  - An exception is made for issues for defects detected by automated or
> +    semi-automated tooling, including fuzzers and LLM-assisted defect
> +    detection.  Such issues must be reviewed by a human before creation,
> +    must be created by a human and communication with maintainers must
> +    be done by a human, but including the verbatim tool output in the
> +    issue description is explicitly allowed.
> +
> +Copy editing of human-written text, for example to help non-native speakers,
> +is allowed. Keep such edits small and precise.

Let's be a bit more specific, and
allow a human written commit 
to be grammar/syntax corrected,
with the condition that nothing beyond a fix of
incorrect grammar/syntax is modified.


> +
> +The human's workflow may require you to perform commits or request you to
> +produce private drafts of maintainer-facing text.  These are allowed, but must
> +be marked as requiring rewrite by a human before publication.

maybe write exatly what text you want it to include.

> +
>  ## Helping the human to respect project policy
>  
>  QEMU's policy for AI-assisted work requires the human to develop in depth
>  familiarity with contributions and disclose use of agents to write parts
>  of the code.
>  
> +### Human must demonstrate understanding
> +
> +Staying familiar with what's going on requires constant effort on part of
> +the human; track their comprehension of the problem and of the relevant parts
> +of the codebase. Expect manual intervention before a change is ready to
> +post, for example:
> +
> +- pushing back on a specific part of your design or implementation, or
> +  asking to explain tradeoffs
> +- manual splitting or reordering of commits
> +- suggesting other places that need to be adjusted for consistency
> +- preferring reworded commit messages to lightly edited AI-generated ones
> +
> +In order to protect the project's scarcest resource, which is review time:
> +
> +- You should **facilitate this process** by offering alternatives instead of
> +  hard answers when applicable.
> +- You must **tell humans about these expectations** at handover.  Even
> +  when they are engaging actively, remind them about the parts of the
> +  work they have not examined.
> +
> +### AI usage must be disclosed and/or pre-arranged
> +
>  Background assistance such as review or explanation does not require disclosure.
>  Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
>  intended for contribution; committing agent-generated material; or advising on
> @@ -39,6 +100,11 @@ the material.
>    know these rules and follow them.
>  - Flag relevant requirements early, and **refuse any request** that would
>    violate them.
> +- If the human moves faster than their understanding, slow down and ask to
> +  resolve any open design choices.
> +
> +In case of contradiction consider `AGENTS.md` authoritative on how to behave,
> +since it is crafted specifically for agents.
>  
>  Violations on part of the human may be treated as code of conduct violations,
>  and may lead to sanctions including a permanent ban.
> -- 
> 2.55.0

[PATCH 4/4] AGENTS.md: make the human part of the design process

[Paolo Bonzini]

This came out of the experiment with the first version of the AGENTS.md
file.  This addition improved the behavior of the agent from the very
beginning.  The very first answer to the same prompt was "I'll orient
in the codebase first, then we should talk about design choices before
I write anything".

In fact, after thinking it pointed out from the start that this requires
pre-arrangement and asked two questions (how to represent the pressure and
temperature in the QOM properties, how much of the behavior to implement).
Even with a single data point it seems worth trying.

When asked to commit autonomously, the LLM also clarified that it
wouldn't add S-o-b trailers and that pre-arrangement was on me.
It included "Message written by an AI and to be rewritten by hand; not
for submission as is" in the commit message, a "handover notes"
section about design choices that were made without the user input,
and the umpteenth reminder that the work may only be posted if a
maintainer has agreed beforehand to review them.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 AGENTS.md | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/AGENTS.md b/AGENTS.md
index 816ba7646c1..cb3e6087ee0 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -52,6 +52,9 @@ QEMU's policy for AI-assisted work requires the human to develop in depth
 familiarity with contributions and disclose use of agents to write parts
 of the code.
 
+The golden rule: **The human should know the alternatives before
+implementation. ASK before choosing for them**.
+
 ### Human must demonstrate understanding
 
 Staying familiar with what's going on requires constant effort on part of
@@ -72,6 +75,22 @@ In order to protect the project's scarcest resource, which is review time:
 - You must **tell humans about these expectations** at handover.  Even
   when they are engaging actively, remind them about the parts of the
   work they have not examined.
+- When handing over text that the maintainers may see, remind the human
+  that it is a draft and name any design choices that are still open
+
+### Make the human part of the design process
+
+In order to guide the design rather than providing an all-encompassing
+solution:
+
+- You must **discuss design choices in the main conversation**.  Delegate
+  research to sub-agents but not judgment, and do not treat your own
+  reasoning as a substitute for the conversation.
+- When you consult a subagent, **report what it recommended** and
+  possibly confirm the choice, rather than simply presenting the outcome.
+- Reinstate as visible text any design decision made while thinking.
+  Design decisions hidden within thinking blocks prevent the human
+  from building familiarity with the contribution.
 
 ### AI usage must be disclosed and/or pre-arranged
 
-- 
2.55.0

Re: [PATCH 4/4] AGENTS.md: make the human part of the design process

[Daniel P. Berrangé]

On Mon, Sep 21, 2026 at 09:52:51AM +0200, Paolo Bonzini wrote:
> This came out of the experiment with the first version of the AGENTS.md
> file.  This addition improved the behavior of the agent from the very
> beginning.  The very first answer to the same prompt was "I'll orient
> in the codebase first, then we should talk about design choices before
> I write anything".
> 
> In fact, after thinking it pointed out from the start that this requires
> pre-arrangement and asked two questions (how to represent the pressure and
> temperature in the QOM properties, how much of the behavior to implement).
> Even with a single data point it seems worth trying.
> 
> When asked to commit autonomously, the LLM also clarified that it
> wouldn't add S-o-b trailers and that pre-arrangement was on me.
> It included "Message written by an AI and to be rewritten by hand; not
> for submission as is" in the commit message, a "handover notes"
> section about design choices that were made without the user input,
> and the umpteenth reminder that the work may only be posted if a
> maintainer has agreed beforehand to review them.
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  AGENTS.md | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/AGENTS.md b/AGENTS.md
> index 816ba7646c1..cb3e6087ee0 100644
> --- a/AGENTS.md
> +++ b/AGENTS.md
> @@ -52,6 +52,9 @@ QEMU's policy for AI-assisted work requires the human to develop in depth
>  familiarity with contributions and disclose use of agents to write parts
>  of the code.
>  
> +The golden rule: **The human should know the alternatives before
> +implementation. ASK before choosing for them**.

I'd suggest   "ASK instead of choosing for them"

> +
>  ### Human must demonstrate understanding
>  
>  Staying familiar with what's going on requires constant effort on part of
> @@ -72,6 +75,22 @@ In order to protect the project's scarcest resource, which is review time:
>  - You must **tell humans about these expectations** at handover.  Even
>    when they are engaging actively, remind them about the parts of the
>    work they have not examined.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: [RFC PATCH v3 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Michael S. Tsirkin]

On Mon, Sep 21, 2026 at 09:52:47AM +0200, Paolo Bonzini wrote:
> WARNING: this is *intentionally* a full U-turn from the previous policy
> and discussions.  This is not a refusal of the arguments presented in
> those discussions.  Also, it is still a request for comments.
> 
> I've explained in v2 my reason to "try something else".  On one hand
> attempting to introduce small carve-outs did not work due the impossibility
> of reaching a widespread consensus on this topic.  On the other hand,
> some contributors have been posting AI-generated patches or even larger
> series, most likely in good faith as they predated the introduction
> of an AGENTS.md file.  This shows that AI can be used for useful work
> on QEMU, ranging from small incremental improvements to new device models.
> 
> This is not a free-for-all, which is not a good idea either.  Maintainers
> will want to apply their own considerations (see [1] for a good list),
> and contributors should take into account the maintainers' preferences.
> 
> This is an attempt at building a process for contributions that use AI,
> heeding Conservancy's advice to not shun contributors or maintainers
> belonging to either camp, and keeping in mind that maintainer burnout
> is the one thing we have to avoid.  Some of these processes already
> existed, but the possibility of AI contribution makes it all more
> important to write them down for everyone.
> 
> There was not much discussion in the previous version.  I tried to rein
> in some of the language that allowed too wide interpretations, to apply
> the changes that were suggested, and to clarify those choices that drew
> more remarks.
> 
> As usual, the text including the commit messages is informed by discussion
> with plenty of people, mentioned in the Cc trailers of patch 1.
> 
> Paolo



Something that we maybe should do, is to ask that
agent does not repeat, verbatim, code from outside
of qemu.

would not help in 100% of cases but hey.


> v2->v3:
> - remove parser example, replace with "adaptations of existing code"
> - when LLMs are used for boilerplate, "highly recommend" disclosure
>   for "non-trivial, functional code".  The idea here is to avoid
>   having to disclose using AI to apply e.g. changes related to
>   automatic code review, and leaving people some leeway.
> - clarify split between DCO (legal right to submit code in general)
>   and AI-used-for acknowledging that the submitter cannot audit LLM
>   output against e.g. the training data.
> - clarify the defense-in-depth/swiss-cheese approach to limit the
>   risk of copyright violations from LLM output
> - mention that pre-arrangement is not an entirely new concept
> - mention that maintainers can demand larger changes than for human-written code
> - do not mention inclusion of the prompt
> - add checkpatch.pl hunk, changing the phrasing of "no AI" lint
> - rebase AGENTS.md on top of existing file, split
> - drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini
> 
> [1] https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/
> 
> Paolo Bonzini (4):
>   docs/devel: relax policy on AI-generated contributions
>   AGENTS.md: add final instructions
>   AGENTS.md: let agents know what the participation rules are
>   AGENTS.md: make the human part of the design process
> 
>  docs/devel/code-provenance.rst |  71 +-----------
>  docs/devel/index-process.rst   |   1 +
>  docs/devel/llm-usage.rst       | 202 +++++++++++++++++++++++++++++++++
>  AGENTS.md                      | 137 +++++++++++++++++++---
>  scripts/checkpatch.pl          |   5 +-
>  5 files changed, 336 insertions(+), 80 deletions(-)
>  create mode 100644 docs/devel/llm-usage.rst
> 
> -- 
> 2.55.0

Re: [RFC PATCH v3 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 4265 bytes --]

On Sun, Sep 27, 2026 at 10:39 AM Michael S. Tsirkin <mst@redhat.com> wrote:

> On Mon, Sep 21, 2026 at 09:52:47AM +0200, Paolo Bonzini wrote:
> > WARNING: this is *intentionally* a full U-turn from the previous policy
> > and discussions.  This is not a refusal of the arguments presented in
> > those discussions.  Also, it is still a request for comments.
> >
> > I've explained in v2 my reason to "try something else".  On one hand
> > attempting to introduce small carve-outs did not work due the
> impossibility
> > of reaching a widespread consensus on this topic.  On the other hand,
> > some contributors have been posting AI-generated patches or even larger
> > series, most likely in good faith as they predated the introduction
> > of an AGENTS.md file.  This shows that AI can be used for useful work
> > on QEMU, ranging from small incremental improvements to new device
> models.
> >
> > This is not a free-for-all, which is not a good idea either.  Maintainers
> > will want to apply their own considerations (see [1] for a good list),
> > and contributors should take into account the maintainers' preferences.
> >
> > This is an attempt at building a process for contributions that use AI,
> > heeding Conservancy's advice to not shun contributors or maintainers
> > belonging to either camp, and keeping in mind that maintainer burnout
> > is the one thing we have to avoid.  Some of these processes already
> > existed, but the possibility of AI contribution makes it all more
> > important to write them down for everyone.
> >
> > There was not much discussion in the previous version.  I tried to rein
> > in some of the language that allowed too wide interpretations, to apply
> > the changes that were suggested, and to clarify those choices that drew
> > more remarks.
> >
> > As usual, the text including the commit messages is informed by
> discussion
> > with plenty of people, mentioned in the Cc trailers of patch 1.
> >
> > Paolo
>
>
>
> Something that we maybe should do, is to ask that
> agent does not repeat, verbatim, code from outside
> of qemu.
>
> would not help in 100% of cases but hey.
>

In a similar vain, do we want to call out *NOT* adding reviewed by: claude
or similar?
(assuming I'm up on the consensus view). I don't recall seeing this in the
changes so far.

Warner


> > v2->v3:
> > - remove parser example, replace with "adaptations of existing code"
> > - when LLMs are used for boilerplate, "highly recommend" disclosure
> >   for "non-trivial, functional code".  The idea here is to avoid
> >   having to disclose using AI to apply e.g. changes related to
> >   automatic code review, and leaving people some leeway.
> > - clarify split between DCO (legal right to submit code in general)
> >   and AI-used-for acknowledging that the submitter cannot audit LLM
> >   output against e.g. the training data.
> > - clarify the defense-in-depth/swiss-cheese approach to limit the
> >   risk of copyright violations from LLM output
> > - mention that pre-arrangement is not an entirely new concept
> > - mention that maintainers can demand larger changes than for
> human-written code
> > - do not mention inclusion of the prompt
> > - add checkpatch.pl hunk, changing the phrasing of "no AI" lint
> > - rebase AGENTS.md on top of existing file, split
> > - drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini
> >
> > [1]
> https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/
> >
> > Paolo Bonzini (4):
> >   docs/devel: relax policy on AI-generated contributions
> >   AGENTS.md: add final instructions
> >   AGENTS.md: let agents know what the participation rules are
> >   AGENTS.md: make the human part of the design process
> >
> >  docs/devel/code-provenance.rst |  71 +-----------
> >  docs/devel/index-process.rst   |   1 +
> >  docs/devel/llm-usage.rst       | 202 +++++++++++++++++++++++++++++++++
> >  AGENTS.md                      | 137 +++++++++++++++++++---
> >  scripts/checkpatch.pl          |   5 +-
> >  5 files changed, 336 insertions(+), 80 deletions(-)
> >  create mode 100644 docs/devel/llm-usage.rst
> >
> > --
> > 2.55.0
>
>

[-- Attachment #2: Type: text/html, Size: 5557 bytes --]

[PATCH v4 0/4] docs/devel, AGENTS.md: a completely new policy on AI-generated contributions

[Paolo Bonzini]

Based on the previous discussions, I am finally attempting a non-RFC
version of the new AI policy.  Discussion on v3 introduced interesting
points on attestation and I think a consensus is forming.

Why review the policy?  The blanket ban no longer reflects reality, since
contributors have been posting AI-generated patches or even larger series.
This was done most likely in good faith, as these submissions predated
the introduction of an AGENTS.md file, and it shows that AI can be used
for useful and creative work on QEMU.

Rather than expecting maintainers to police these contributors, the new
policy seeks to ensure that AI usage helps us produce better code rather
than simply move faster and flood us with dubious work.  In the words
of Warner Losh, we want to avoid "free as in puppy" contributions[1]
that increase the load of present and future maintainers by adding
technical debt.

This is not a free-for-all.  To avoid maintainer burnout, AI
contributions must be grounded in respect for maintainers and in the
existing contribution process.  Large, heavily AI-assisted contributions
require pre-arrangement with the relevant subsystem maintainers, and
will be held to a higher standard.

One of the reasons for the old policy was the issue of code provenance
and the impossibility to certify the originality of code created by
AI/LLM tools.  The new policy tries to adopt a "Swiss cheese"
approach to mitigating the risks implicit in accepting AI-generated code
in three ways:

1) by requiring pre-arrangement for larger contributions, and making
maintainers free to apply their own considerations (see [2] for a good
list).  Maintainers' preferences bring experience and creative thought
into the process, and contributors must take them into account.

2) by introducing agent instructions that help the contributor drive
the design and understand the code produced by the LLM;

3) by introducing an "AI-used-for" trailer that scopes areas where
Signed-off-by cannot guarantee full control of provenance.

This series reflects feedback from earlier requests for comments, and
even earlier discussions with members of the QEMU community.  Thanks to
everyone who provided feedback on earlier drafts.

Paolo

v3->v4:
- rework opening text [Daniel]
- exempt "official project agents" from not being able to post to
  GitLab [Alex]
- explicitly forbid clean room reimplementation [Kevin/Daniel]
- remove "The DCO still certifies that the contributor has the legal
  right to submit code in general" paragraph, replace with a note
  that "AI-used-for" attests respecting the policies and is considered
  enough for DCO [Daniel, Kevin]
- make the requirement to "understand and explain your changes"
  more prominent
- small edits for grammar and clarity

v2->v3:
- remove parser example, replace with "adaptations of existing code"
- when LLMs are used for boilerplate, "highly recommend" disclosure
  for "non-trivial, functional code".  The idea here is to avoid
  having to disclose using AI to apply e.g. changes related to
  automatic code review, and leaving people some leeway.
- clarify split between DCO (legal right to submit code in general)
  and AI-used-for acknowledging that the submitter cannot audit LLM
  output against e.g. the training data.
- clarify the defense-in-depth/swiss-cheese approach to limit the
  risk of copyright violations from LLM output
- mention that pre-arrangement is not an entirely new concept
- mention that maintainers can demand larger changes than for human-written code
- do not mention inclusion of the prompt
- add checkpatch.pl hunk, changing the phrasing of "no AI" lint
- rebase AGENTS.md on top of existing file, split
- drop CLAUDE.md/GEMINI.md symlinks, already done via .claude/.gemini

[1] https://lore.kernel.org/qemu-devel/CANCZdfrTwfrK0wnuL2cPVF_9W2-8PXtJeHkgkTP+Uv2sT8s0Ng@mail.gmail.com/
[2] https://lore.kernel.org/qemu-devel/CAFEAcA860fF_+ffk=cXiYyFoQo0wCSUJ6b=7nVLLCwKhP6Nwxw@mail.gmail.com/

Paolo Bonzini (4):
  docs/devel: relax policy on AI-generated contributions
  AGENTS.md: add final instructions
  AGENTS.md: let agents know what the participation rules are
  AGENTS.md: make the human part of the design process

 docs/devel/code-provenance.rst |  71 +----------
 docs/devel/index-process.rst   |   1 +
 docs/devel/llm-usage.rst       | 213 +++++++++++++++++++++++++++++++++
 AGENTS.md                      | 137 +++++++++++++++++++--
 scripts/checkpatch.pl          |   5 +-
 5 files changed, 347 insertions(+), 80 deletions(-)
 create mode 100644 docs/devel/llm-usage.rst

-- 
2.55.0

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

[Paolo Bonzini]

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

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index 65b8f232a08..7403961378e 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -128,6 +128,10 @@ that are commonly used during QEMU development:
    suggestions for how to change a patch, it is good practice to credit them
    by including a ``Suggested-by`` tag.
 
+ * **AI-used-for**: when AI/LLM tools were used to produce the patch, this tag
+   discloses what they were used for.  See :ref:`llm-usage` for the cases in
+   which it is required.
+
 Subsystem maintainer requirements
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -282,68 +286,5 @@ boilerplate code template which is then filled in to produce the final patch.
 The output of such a tool would still be considered the "preferred format",
 since it is intended to be a foundation for further human authored changes.
 Such tools are acceptable to use, provided there is clearly defined copyright
-and licensing for their output. Note in particular the caveats applying to AI
-content generators below.
-
-Use of AI-generated content
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TL;DR:
-
-  **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.**
-
-The increasing prevalence of AI-assisted software development results in a
-number of difficult legal questions and risks for software projects, including
-QEMU.  Of particular concern is content generated by `Large Language Models
-<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs).
-
-The QEMU community requires that contributors certify their patch submissions
-are made in accordance with the rules of the `Developer's Certificate of
-Origin (DCO) <dco>`.
-
-To satisfy the DCO, the patch contributor has to fully understand the
-copyright and license status of content they are contributing to QEMU. With AI
-content generators, the copyright and license status of the output is
-ill-defined with no generally accepted, settled legal foundation.
-
-Where the training material is known, it is common for it to include large
-volumes of material under restrictive licensing/copyright terms. Even where
-the training material is all known to be under open source licenses, it is
-likely to be under a variety of terms, not all of which will be compatible
-with QEMU's licensing requirements.
-
-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.
-
-The QEMU project thus requires that contributors refrain from using AI content
-generators on patches intended to be submitted to the project, and will
-decline any contribution if use of AI is either known or suspected.
-
-Examples of tools impacted by this policy includes GitHub's CoPilot, OpenAI's
-ChatGPT, Anthropic's Claude, and Meta's Code Llama, and code/content
-generation agents which are built on top of such tools.
-
-This policy may evolve as AI tools mature and the legal situation is
-clarified.
-
-Exceptions
-^^^^^^^^^^
-
-The QEMU project welcomes discussion on any exceptions to this policy,
-or more general revisions. This can be done by contacting the qemu-devel
-mailing list with details of a proposed tool, model, usage scenario, etc.
-that is beneficial to QEMU, while still mitigating issues around compliance
-with the DCO.  After discussion, any exception will be listed below.
-
-Exceptions do not remove the need for authors to comply with all other
-requirements for contribution.  In particular, the "Signed-off-by"
-label in a patch submission is a statement that the author takes
-responsibility for the entire contents of the patch, including any parts
-that were generated or assisted by AI tools or other tools.
+and licensing for their output. Note in particular the caveats applying to
+:ref:`AI content generators <llm-usage>`.
diff --git a/docs/devel/index-process.rst b/docs/devel/index-process.rst
index 5807752d704..ce0f4e73197 100644
--- a/docs/devel/index-process.rst
+++ b/docs/devel/index-process.rst
@@ -13,6 +13,7 @@ Notes about how to interact with the community and how and where to submit patch
    maintainers
    style
    submitting-a-patch
+   llm-usage
    code-provenance
    trivial-patches
    stable-process
diff --git a/docs/devel/llm-usage.rst b/docs/devel/llm-usage.rst
new file mode 100644
index 00000000000..0b54f5dd383
--- /dev/null
+++ b/docs/devel/llm-usage.rst
@@ -0,0 +1,213 @@
+.. _llm-usage:
+
+Use of AI-generated content
+===========================
+
+.. warning::
+
+   Please read the below policy before using AI to contribute code or
+   documentation to QEMU.  This applies to ChatGPT, Claude, Copilot,
+   Llama, and similar tools.
+
+This document provides guidance around acceptable practices
+for using `Large Language Models
+<https://en.wikipedia.org/wiki/Large_language_model>`__ (LLMs)
+when contributing to QEMU.
+
+The QEMU project does not want to dictate what tools contributors
+use for their work on the project.  However, the increasing
+prevalence of AI-assisted software development and of LLMs specifically
+poses a number of difficult questions.  Risks to open source projects
+include maintainer burnout from an increased number of contributions, as
+well as the risk to the project from unintentional inclusion of copyrighted
+material in the LLM's output.
+
+In order to mitigate these risks, the QEMU project limits the way
+in which use of the output of generative AI can be included in
+contributions to QEMU.  The main guidelines for use of generative AI
+tools are as follows:
+
+- It's fine to use LLMs to answer questions, analyze, distill,
+  refine, check, suggest, review. Use of LLMs to *create* is limited.
+
+- If in doubt, disclose any use of AI tools other than simple code
+  completion and code review.
+
+- LLMs are allowed as a tool to write *better*, not *faster*.
+
+**For any kind of LLM usage, the expectation is that the human contributor
+shall be able to :ref:`understand and explain the changes
+  <write_a_meaningful_commit_message>`, the design choices, and the
+rationale behind them.**
+
+.. note:: **Use of AI does not remove the need for authors to comply
+          with all other requirements for contribution.**  In particular,
+          the ``Signed-off-by`` label in a patch submission is a statement
+          that the author takes responsibility for the entire contents of
+          the patch, certifying that their patch submission is made in
+          accordance with the rules of the :ref:`Developer's Certificate of
+          Origin (DCO) <dco>`.
+
+Prohibited use of AI
+''''''''''''''''''''
+
+The QEMU community is a collaboration between humans, not AI agent
+façades. The following items MUST be written by humans [1]_:
+
+- cover letters and commit messages
+
+- responses to reviewer comments
+
+- issue descriptions or comments
+
+Light copy editing of human-written text with an AI is allowed.
+
+Repeated violations of this rule may be treated as a :ref:`code_of_conduct`
+violation.
+
+An exception is made for defects detected by specialized tooling,
+including fuzzers and LLM-assisted defect detection. Such issues must
+be reviewed by a human before creation, must be created by a human and
+communication with maintainers must be done by a human, but including
+the verbatim tool output in the issue description is explicitly allowed.
+
+.. [1] Official project agents may be exempted from one or more of these
+       rules, at the discretion of the QEMU project maintainer(s).
+
+LLM-assisted and LLM-created contributions
+''''''''''''''''''''''''''''''''''''''''''
+
+Use of generative AI can be classified in the following four buckets:
+
+- "background" assistance, such as completion and code review.  This does
+  not need disclosure.
+
+- small LLM-assisted bugfixes (as a rule of thumb, below 10 lines of code)
+  are allowed with disclosure.  Splitting a submission in multiple parts
+  is **not** a valid way to bypass this rule; repeated, frequent posting
+  of such fixes must follow the rule for full contributions.
+
+- use of LLMs to help generating parts of a larger patch---test cases,
+  adaptations of existing code, boilerplate code for a new API, a tool to
+  help performing mechanical changes, etc.  These are generally allowed;
+  disclosure is highly recommended for non-trivial, functional code.
+
+- large, heavily LLM-assisted contributions where LLMs write large parts
+  of functional code.  These are only allowed if *pre-arranged*,
+  *high-quality* and *well-tested*.
+
+The last case (*"LLM-created contribution"*) is the one that requires
+a more careful approach.  In particular:
+
+- "Pre-arranged" means that a maintainer has communicated ahead of time,
+  for example on `IRC or the QEMU mailing
+  list <https://www.qemu.org/contribute/>`__, that they are willing
+  to review an LLM-created contribution.
+
+- "High-quality" means that the contributor must apply the same judgment
+  that would be applied to other code changes.  Contributors must invest
+  substantial time reviewing their contributions, curating them, and
+  understanding them in depth.
+
+- "Well-tested" means the LLM-created contributions will be held to a
+  higher standard than human-created ones, because LLMs make it easier
+  to write tests.  There are no exceptions for "writing the tests seems
+  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.
+
+.. note::
+    Pre-arrangement ensures maintainers have bandwidth for review before a
+    contributor invests effort in creating a large change.  This is not
+    a new concept in QEMU: maintainers have always encouraged early
+    alignment on mailing lists or IRC prior to major architecture or
+    subsystem refactoring.
+
+    Maintainers have freedom to determine what constitutes "high quality".
+    Because LLMs lower the cost of patch generation, maintainers may demand
+    significantly larger revisions than for purely human-written code.
+
+The QEMU project explicitly forbids using LLMs to do "clean room"
+reimplementation of existing code whose license is not compatible
+with the GNU General Public License, version 2 **or later**.
+
+.. _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.
+
+Motivation
+''''''''''
+
+There is not a consensus within the QEMU project---and likely never will
+be---about when/how/where it is acceptable to use AI-based tools.  Many
+members of the QEMU project and community find value in AI; many others
+feel that its negative impact on society and the climate are severe enough
+that no use is acceptable.  Still others are working out their opinion.
+
+In accordance with Software Freedom Conservancy's recommendations:
+
+- the project seeks to both support those contributors who outright reject
+  generative AI systems, and to not shun those who choose to use them;
+
+- we consider QEMU's copyleft to be a viable approach to the unanswered
+  legal questions about AI-generated contributions and their copyright
+  status;
+
+- we encourage contributors not to overuse LLMs, and to *add* them to
+  their existing skills and tools instead of replacing them.
+
+A common source of grief for maintainers is the (often valid) impression
+that AI enables contributions without understanding the effort they take
+for those who process them.  Effectively, this shifts a major part of the
+burden from the contributors to the maintainers---the scarcest resource
+in any free software project, not just QEMU.  Pre-arrangement and the
+size limit for small contributions try to avoid putting extra demand
+on maintainers due to LLM-assisted work.
+
+
+Sources
+'''''''
+
+This policy was informed by:
+
+- `Recommendations When Using LLM-backed Generative AI Systems for
+  FOSS Contributions <https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html>`__
+
+- `Rust project LLM Usage Policy <https://forge.rust-lang.org/policies/llm-usage.html>`__
+
+- `GStreamer AGENTS.md file <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/blob/d08375499c279/AGENTS.md>`__
+
diff --git a/AGENTS.md b/AGENTS.md
index 5e3fc071420..8f494ea8ae5 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,21 +1,37 @@
 # Agent Guidelines for the QEMU Project
 
-As an agent you MUST abide by the "Use of AI-generated content" policy
-in `docs/devel/code-provenance.rst` at all times.
+QEMU is a cross-platform emulator and virtualizer. Due to the complexity
+of the domain and codebase, and the interactions therein, the QEMU
+project relies extensively on the effort of **human reviewers**, which
+is **a scarce resource**.
 
-You are permitted to assist users only in the following scenarios:
+There are strictly-enforced rules for you, the agent, to participate in the
+project.
 
-- researching APIs or algorithms
-- static analysis
-- debugging
-- local experiments not intended to be upstreamed
-- trivial non-copyrightable changes
+## Helping the human to respect project policy
 
-However agent output can not be included in any upstream
-contributions. If a request falls outside these permitted categories
-(e.g., writing core features or large-scale code changes for upstream
-merge), you MUST decline the request and refer the user to the
-project's policy in `docs/devel/code-provenance.rst`.
+QEMU's policy for AI-assisted work requires the human to develop in-depth
+familiarity with contributions and disclose use of agents to write parts
+of the code.
+
+Background assistance such as review or explanation does not require disclosure.
+Read `docs/devel/llm-usage.rst` before generating code, tests, or documentation
+intended for contribution; committing agent-generated material; or advising on
+disclosure or pre-arrangement. It is not required for review, explanation, or
+other background assistance that produces no contribution content.
+
+When agent-generated content is included in a contribution, remind the human
+to determine the appropriate disclosure under `docs/devel/llm-usage.rst`.
+In particular, contributions where you write large parts of the functional
+code may only be submitted if a maintainer has agreed **beforehand** to review
+them.  Tell the human about this as soon as the work looks likely to grow to
+that size, well before the patches are written.
+
+If you commit agent-generated material, include an `AI-used-for:` trailer
+before `Signed-off-by`. Do not omit it by folding the material into a larger
+commit.  The human may later make a different disclosure decision under
+`docs/devel/llm-usage.rst`, after independently reworking and integrating
+the material.
 
 ## Security Policy
 
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9838a641785..d881cf29375 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1829,8 +1829,9 @@ sub process {
 		      $1 =~ /\bcopilot\b | \bchatgpt\b | \bcodex\b | \bcursor\b |
 			     \bgemini\b | \bllama\b | \bnoreply\b | \[bot\] |
 			     \bclaude\b.*(?:opus|sonnet|fable|haiku|anthropic\.com)/xi))) {
-			ERROR("QEMU does not allow using AI for contributions, " .
-				"see docs/devel/code-provenance.rst\n" . $herecurr);
+			ERROR("do not use \"$line\" to credit an AI agent, " .
+				"use the \"AI-used-for\" trailer instead; " .
+				"see docs/devel/llm-usage.rst\n" . $herecurr);
 		}
 
 # Check for duplicate trailers and self-review
-- 
2.55.0

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

[Philippe Mathieu-Daudé]

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. What trailer should I use?

   AI-used-for: research
   AI-used-for: code (audit)
   AI-used-for: code audit (semcode)

'semcode' is a deterministic tool, so instead my commit should contains
'''
   When updating foo() contract in commit fe89fe89fe89 we forgot to
   update its documentation. Checking with the semcode tools, most
   callers pass @arg as a mask. Update the documentation.

   AI-used-for: code audit
'''

Would that be a good example?

Thanks,

Phil.

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

[Philippe Mathieu-Daudé]

On 30/9/26 14:54, Philippe Mathieu-Daudé wrote:
> 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. What trailer should I use?
> 
>    AI-used-for: research
>    AI-used-for: code (audit)
>    AI-used-for: code audit (semcode)
> 
> 'semcode' is a deterministic tool,

Method called:

  - semcode.find_function
  - semcode.find_callers

  so instead my commit should contains
> '''
>    When updating foo() contract in commit fe89fe89fe89 we forgot to
>    update its documentation. Checking with the semcode tools, most
>    callers pass @arg as a mask. Update the documentation.
> 
>    AI-used-for: code audit
> '''
> 
> Would that be a good example?
> 
> Thanks,
> 
> Phil.
> 
> 
> 

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

[Daniel P. Berrangé]

On Wed, Sep 30, 2026 at 02:54:09PM +0200, Philippe Mathieu-Daudé wrote:
> 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

Do we really want to include that last one "research" ? In that scenario
the AI agent is not directly authoring code, so nothing in the commit can
be directly attributed to the AI.

In the current world people turn to AI instead of google search / stack
overflow, and indeed google search is effectively "AI based research".

I'm not convinced "AI-used-for: research" has any real value other than
to demonstrate how much you personally  rely on AI, and I don't think
the projects needs to care/ask about that.

> > +``AI-used-for`` should not be included for "background" usage such as
> > +autocomplete or obtaining a pre-review of the patch.

I'd be stronger and say  "AI-used-for" only be used where some part of
the patch *content* was authored by the AI.

> > +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. What trailer should I use?
> 
>   AI-used-for: research
>   AI-used-for: code (audit)
>   AI-used-for: code audit (semcode)

Personally I'd say your example should not require any AI-used-for
tag, since no code ends up in the commit.

> 
> 'semcode' is a deterministic tool, so instead my commit should contains
> '''
>   When updating foo() contract in commit fe89fe89fe89 we forgot to
>   update its documentation. Checking with the semcode tools, most
>   callers pass @arg as a mask. Update the documentation.
> 
>   AI-used-for: code audit
> '''
> 
> Would that be a good example?

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Paolo Bonzini]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

Il mer 30 set 2026, 15:09 Daniel P. Berrangé <berrange@redhat.com> ha
scritto:

> > > +     AI-used-for: tests, docs
> > > +     AI-used-for: code
> > > +     AI-used-for: code (refactoring)
> > > +     AI-used-for: code (prototype)
> > > +     AI-used-for: research
>
> Do we really want to include that last one "research" ? In that scenario
> the AI agent is not directly authoring code, so nothing in the commit can
> be directly attributed to the AI.
>

I don't recall specifically where it was brought up... Perhaps something
separate from "code" makes sense for extremely small fixes but I agree that
"research" is not interesting anymore, given the meaning that is attached
to the trailer since this version.

I'm not convinced "AI-used-for: research" has any real value other than
> to demonstrate how much you personally  rely on AI, and I don't think
> the projects needs to care/ask about that.
>

Maybe it was intended for patches attached to security reports or something
like that. It can go though.

> > +``AI-used-for`` should not be included for "background" usage such as
> > > +autocomplete or obtaining a pre-review of the patch.
>
> I'd be stronger and say  "AI-used-for" only be used where some part of
> the patch *content* was authored by the AI.
>

Yep.

Paolo

[-- Attachment #2: Type: text/html, Size: 2439 bytes --]

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

[Kevin Wolf]

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

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

[Peter Maydell]

On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
> +LLM-assisted and LLM-created contributions
> +''''''''''''''''''''''''''''''''''''''''''
> +
> +Use of generative AI can be classified in the following four buckets:
> +
> +- "background" assistance, such as completion and code review.  This does
> +  not need disclosure.
> +
> +- small LLM-assisted bugfixes (as a rule of thumb, below 10 lines of code)
> +  are allowed with disclosure.  Splitting a submission in multiple parts
> +  is **not** a valid way to bypass this rule; repeated, frequent posting
> +  of such fixes must follow the rule for full contributions.
> +
> +- use of LLMs to help generating parts of a larger patch---test cases,
> +  adaptations of existing code, boilerplate code for a new API, a tool to
> +  help performing mechanical changes, etc.  These are generally allowed;
> +  disclosure is highly recommended for non-trivial, functional code.

I think we can get or have consensus on these first three buckets...

> +- large, heavily LLM-assisted contributions where LLMs write large parts
> +  of functional code.  These are only allowed if *pre-arranged*,
> +  *high-quality* and *well-tested*.
> +
> +The last case (*"LLM-created contribution"*) is the one that requires
> +a more careful approach.  In particular:
> +
> +- "Pre-arranged" means that a maintainer has communicated ahead of time,
> +  for example on `IRC or the QEMU mailing
> +  list <https://www.qemu.org/contribute/>`__, that they are willing
> +  to review an LLM-created contribution.
> +
> +- "High-quality" means that the contributor must apply the same judgment
> +  that would be applied to other code changes.  Contributors must invest
> +  substantial time reviewing their contributions, curating them, and
> +  understanding them in depth.
> +
> +- "Well-tested" means the LLM-created contributions will be held to a
> +  higher standard than human-created ones, because LLMs make it easier
> +  to write tests.  There are no exceptions for "writing the tests seems
> +  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.

...but I think fundamentally I am not in favour of having this
fourth category of permitted uses. It seems even to have lost the
idea of it being an "experimental" approach in this revision of the
series. The first three categories are fine, and I have no particular
problem with our relaxing our current policy to explicitly permit them.

Our problem as a project does not seem to be on the "writing
code" side of things, but has always been on the "code review"
side. This policy relaxation makes it much easier to write more
code. Even when there's a "pre-arranged reviewer" that isn't
necessarily helpful -- if you're one of the primary maintainers
for an area of QEMU then the fact that somebody else is reviewing
it doesn't make a big AI-generated code infusion any more palatable.

Allowing large heavily LLM-assisted contributions seems to me:
 * the biggest risk legally speaking (though I think this is
   in practice not all that big a risk at this point)
 * the biggest risk of the codebase degenerating into
   unmaintainability
 * the biggest risk of finding ourselves reviewing contributions
   that are in practice much more vibe-coded than the policy text
   above is asking for

I look at our issue tracker where we see AI assisted contributions
that run the whole range from "an human making intelligent use of
the tool to provide high-quality bug reports with good analysis"
through to "absolute slop dumped on us with no apparent human
thought or intervention". I don't really want to expand that
from our issue tracker to our code review and codebase, please.

I would be much happier seeing the advocates of AI putting
effort into making the process of QEMU code review better and
less work, rather than in applying it to the code writing process.

thanks
-- PMM

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

[Paolo Bonzini]

On 10/1/26 14:21, Peter Maydell wrote:
> On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> +- large, heavily LLM-assisted contributions where LLMs write large parts
>> +  of functional code.  These are only allowed if *pre-arranged*,
>> +  *high-quality* and *well-tested*.
>> +
>> +The last case (*"LLM-created contribution"*) is the one that requires
>> +a more careful approach.  In particular:
>> +
>> +- "Pre-arranged" means that a maintainer has communicated ahead of time,
>> +  for example on `IRC or the QEMU mailing
>> +  list <https://www.qemu.org/contribute/>`__, that they are willing
>> +  to review an LLM-created contribution.
>> +
>> +- "High-quality" means that the contributor must apply the same judgment
>> +  that would be applied to other code changes.  Contributors must invest
>> +  substantial time reviewing their contributions, curating them, and
>> +  understanding them in depth.
>> +
>> +- "Well-tested" means the LLM-created contributions will be held to a
>> +  higher standard than human-created ones, because LLMs make it easier
>> +  to write tests.  There are no exceptions for "writing the tests seems
>> +  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.
> 
> ...but I think fundamentally I am not in favour of having this
> fourth category of permitted uses. It seems even to have lost the
> idea of it being an "experimental" approach in this revision of the
> series. The first three categories are fine, and I have no particular
> problem with our relaxing our current policy to explicitly permit them.
> 
> Our problem as a project does not seem to be on the "writing
> code" side of things, but has always been on the "code review"
> side. This policy relaxation makes it much easier to write more
> code. Even when there's a "pre-arranged reviewer" that isn't
> necessarily helpful -- if you're one of the primary maintainers
> for an area of QEMU then the fact that somebody else is reviewing
> it doesn't make a big AI-generated code infusion any more palatable.

I understand where you're coming from.

The purpose of the fourth category is norming contributions that are 
already happening.  I apologize for the allegation in advance, but take 
for example 
https://lore.kernel.org/qemu-devel/20260817190038.580257-1-mattst88@gmail.com/; 
on one hand it is very high quality, on the other hand I give it at 
least a 70% likelihood of being heavily LLM-assisted for the 
implementation and not just for the analysis.

The question is: do we want contributions like that one?  If we decide 
that their quality and usefulness are high enough to want them, what 
process do we need around them?  I think we all agree that, if that kind 
of contribution is desirable, we want the submitters to declare AI usage 
and the reviewers to be aware of it.

> Allowing large heavily LLM-assisted contributions seems to me:
>   * the biggest risk legally speaking (though I think this is
>     in practice not all that big a risk at this point)
>   * the biggest risk of the codebase degenerating into
>     unmaintainability
>   * the biggest risk of finding ourselves reviewing contributions
>     that are in practice much more vibe-coded than the policy text
>     above is asking for

I agree completely with how you phrased the first and third.  I agree 
that the second bullet is a risk too, but it's mitigated by "LLM-created 
contributions will be held to a higher standard than human-created ones, 
because LLMs make it easier to write tests" (and by maintainers being 
able to *refuse* specific contributions, which is the point of 
pre-arrangement; note that pre-arrangement should exist today as a 
matter of courtesy for any large change).

The third risk is probably the biggest of these.  The heaviest toll that 
AI has on maintainers may not be the review per se; if a contribution is 
good and desirable, having to review it is all fine.  Rather, the 
problem is that maintainers have to be ready to say no more often to the 
free puppies, and that is not necessarily easy.  And dually, that 
contributors may not realize it when they're not respecting the 
maintainers' efforts.

I add a fourth risk: that new contributors using AI will not be willing 
to do the final stretch of the work that *has* to be manual, and makes a 
difference between work worth reviewing and work worth including.  This 
would be the biggest waste of time for the reviewer.

> I look at our issue tracker where we see AI assisted contributions
> that run the whole range from "an human making intelligent use of
> the tool to provide high-quality bug reports with good analysis"
> through to "absolute slop dumped on us with no apparent human
> thought or intervention". I don't really want to expand that
> from our issue tracker to our code review and codebase, please.
> 
> I would be much happier seeing the advocates of AI putting
> effort into making the process of QEMU code review better and
> less work, rather than in applying it to the code writing process.
To clarify, my goal with this policy change is not to advocate for AI 
usage, but to advocate for transparency when AI is involved.

I agree that making QEMU code review better should be a goal. 
Unfortunately it is an expensive goal (in real-world money).

Paolo

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

[BALATON Zoltan]

On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> On 10/1/26 14:21, Peter Maydell wrote:
>> On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>> +- large, heavily LLM-assisted contributions where LLMs write large parts
>>> +  of functional code.  These are only allowed if *pre-arranged*,
>>> +  *high-quality* and *well-tested*.
>>> +
>>> +The last case (*"LLM-created contribution"*) is the one that requires
>>> +a more careful approach.  In particular:
>>> +
>>> +- "Pre-arranged" means that a maintainer has communicated ahead of time,
>>> +  for example on `IRC or the QEMU mailing
>>> +  list <https://www.qemu.org/contribute/>`__, that they are willing
>>> +  to review an LLM-created contribution.
>>> +
>>> +- "High-quality" means that the contributor must apply the same judgment
>>> +  that would be applied to other code changes.  Contributors must invest
>>> +  substantial time reviewing their contributions, curating them, and
>>> +  understanding them in depth.
>>> +
>>> +- "Well-tested" means the LLM-created contributions will be held to a
>>> +  higher standard than human-created ones, because LLMs make it easier
>>> +  to write tests.  There are no exceptions for "writing the tests seems
>>> +  hard" or for `yak shaving 
>>> <https://en.wiktionary.org/wiki/yak_shaving>`__.
>> 
>> ...but I think fundamentally I am not in favour of having this
>> fourth category of permitted uses. It seems even to have lost the
>> idea of it being an "experimental" approach in this revision of the
>> series. The first three categories are fine, and I have no particular
>> problem with our relaxing our current policy to explicitly permit them.
>> 
>> Our problem as a project does not seem to be on the "writing
>> code" side of things, but has always been on the "code review"
>> side. This policy relaxation makes it much easier to write more
>> code. Even when there's a "pre-arranged reviewer" that isn't
>> necessarily helpful -- if you're one of the primary maintainers
>> for an area of QEMU then the fact that somebody else is reviewing
>> it doesn't make a big AI-generated code infusion any more palatable.
>
> I understand where you're coming from.
>
> The purpose of the fourth category is norming contributions that are already 
> happening.  I apologize for the allegation in advance, but take for example 
> https://lore.kernel.org/qemu-devel/20260817190038.580257-1-mattst88@gmail.com/; 
> on one hand it is very high quality, on the other hand I give it at least a 
> 70% likelihood of being heavily LLM-assisted for the implementation and not 
> just for the analysis.
>
> The question is: do we want contributions like that one?  If we decide that 
> their quality and usefulness are high enough to want them, what process do we 
> need around them?  I think we all agree that, if that kind of contribution is 
> desirable, we want the submitters to declare AI usage and the reviewers to be 
> aware of it.
>
>> Allowing large heavily LLM-assisted contributions seems to me:
>>   * the biggest risk legally speaking (though I think this is
>>     in practice not all that big a risk at this point)
>>   * the biggest risk of the codebase degenerating into
>>     unmaintainability
>>   * the biggest risk of finding ourselves reviewing contributions
>>     that are in practice much more vibe-coded than the policy text
>>     above is asking for
>
> I agree completely with how you phrased the first and third.  I agree that 
> the second bullet is a risk too, but it's mitigated by "LLM-created 
> contributions will be held to a higher standard than human-created ones, 
> because LLMs make it easier to write tests" (and by maintainers being able to

Tests need to be reviewed too to be able to trust them so that does not 
help against overloading reviewers with generated patches but burdens them 
even more: they will also have to review the tests before the code.

We could say tests must be written by hand but nobody wants to do that or 
that they need to be reviewed by a human before submission but we ask that 
for all code in the patch including tests so I don't see how the argument 
that LLMs can write tests would reduce the original problem.

Regards,
BALATON Zoltan

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

[Kevin Wolf]

Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> > I agree completely with how you phrased the first and third.  I agree
> > that the second bullet is a risk too, but it's mitigated by "LLM-created
> > contributions will be held to a higher standard than human-created ones,
> > because LLMs make it easier to write tests" (and by maintainers being
> > able to
> 
> Tests need to be reviewed too to be able to trust them so that does not help
> against overloading reviewers with generated patches but burdens them even
> more: they will also have to review the tests before the code.

The required level of trust for tests is comparatively low, so it's much
easier to review tests to a sufficient level than say device emulation
code.

If a new test looks plausible, fails before the fix and passes
afterwards, it's more useful that what we had before, even if it's
technically buggy in some corner case.

Kevin

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

[Alex Bennée]

Kevin Wolf <kwolf@redhat.com> writes:

> Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
>> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
>> > I agree completely with how you phrased the first and third.  I agree
>> > that the second bullet is a risk too, but it's mitigated by "LLM-created
>> > contributions will be held to a higher standard than human-created ones,
>> > because LLMs make it easier to write tests" (and by maintainers being
>> > able to
>> 
>> Tests need to be reviewed too to be able to trust them so that does not help
>> against overloading reviewers with generated patches but burdens them even
>> more: they will also have to review the tests before the code.
>
> The required level of trust for tests is comparatively low, so it's much
> easier to review tests to a sufficient level than say device emulation
> code.
>
> If a new test looks plausible, fails before the fix and passes
> afterwards, it's more useful that what we had before, even if it's
> technically buggy in some corner case.

And also easier to rip out in the unlikely event it infringes anything.

But broadly having a test* is better than having no test.

>
> Kevin

* modulo the effects on our coverage.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Daniel P. Berrangé]

On Tue, Oct 06, 2026 at 10:44:37AM +0100, Alex Bennée wrote:
> Kevin Wolf <kwolf@redhat.com> writes:
> 
> > Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
> >> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> >> > I agree completely with how you phrased the first and third.  I agree
> >> > that the second bullet is a risk too, but it's mitigated by "LLM-created
> >> > contributions will be held to a higher standard than human-created ones,
> >> > because LLMs make it easier to write tests" (and by maintainers being
> >> > able to
> >> 
> >> Tests need to be reviewed too to be able to trust them so that does not help
> >> against overloading reviewers with generated patches but burdens them even
> >> more: they will also have to review the tests before the code.
> >
> > The required level of trust for tests is comparatively low, so it's much
> > easier to review tests to a sufficient level than say device emulation
> > code.
> >
> > If a new test looks plausible, fails before the fix and passes
> > afterwards, it's more useful that what we had before, even if it's
> > technically buggy in some corner case.
> 
> And also easier to rip out in the unlikely event it infringes anything.
> 
> But broadly having a test* is better than having no test.
> 
> * modulo the effects on our coverage.

The maintability of test code is really important too, just as much
as the code being tested. Every test potentially constrains how we
can change code in future as tests themselves are never perfect or
exhaustive and often take short-cuts in their design to suit the
current testing needs. As we enhance the code under test, the test
suite needs to evolve with it and that requires that we understand
the test code and why it is doing what it is doing.

A test spat out by AI which is a string of 20 undocumented qtest
commands may fail before the fix and pass afterwards, but that
test is not automatically a win if we don't understand why the test
is doing what it is doing - it becomes a burden for long term maint.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Kevin Wolf]

Am 06.10.2026 um 11:56 hat Daniel P. Berrangé geschrieben:
> On Tue, Oct 06, 2026 at 10:44:37AM +0100, Alex Bennée wrote:
> > Kevin Wolf <kwolf@redhat.com> writes:
> > 
> > > Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
> > >> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
> > >> > I agree completely with how you phrased the first and third.  I agree
> > >> > that the second bullet is a risk too, but it's mitigated by "LLM-created
> > >> > contributions will be held to a higher standard than human-created ones,
> > >> > because LLMs make it easier to write tests" (and by maintainers being
> > >> > able to
> > >> 
> > >> Tests need to be reviewed too to be able to trust them so that does not help
> > >> against overloading reviewers with generated patches but burdens them even
> > >> more: they will also have to review the tests before the code.
> > >
> > > The required level of trust for tests is comparatively low, so it's much
> > > easier to review tests to a sufficient level than say device emulation
> > > code.
> > >
> > > If a new test looks plausible, fails before the fix and passes
> > > afterwards, it's more useful that what we had before, even if it's
> > > technically buggy in some corner case.
> > 
> > And also easier to rip out in the unlikely event it infringes anything.
> > 
> > But broadly having a test* is better than having no test.
> > 
> > * modulo the effects on our coverage.
> 
> The maintability of test code is really important too, just as much
> as the code being tested. Every test potentially constrains how we
> can change code in future as tests themselves are never perfect or
> exhaustive and often take short-cuts in their design to suit the
> current testing needs. As we enhance the code under test, the test
> suite needs to evolve with it and that requires that we understand
> the test code and why it is doing what it is doing.
> 
> A test spat out by AI which is a string of 20 undocumented qtest
> commands may fail before the fix and pass afterwards, but that
> test is not automatically a win if we don't understand why the test
> is doing what it is doing - it becomes a burden for long term maint.

That's the "looks plausible" part. It's really not a lot of work to
recognise that a test is just 20 undocumented qtest commands.

Kevin

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

[Alex Bennée]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, Oct 06, 2026 at 10:44:37AM +0100, Alex Bennée wrote:
>> Kevin Wolf <kwolf@redhat.com> writes:
>> 
>> > Am 05.10.2026 um 23:09 hat BALATON Zoltan geschrieben:
>> >> On Fri, 2 Oct 2026, Paolo Bonzini wrote:
>> >> > I agree completely with how you phrased the first and third.  I agree
>> >> > that the second bullet is a risk too, but it's mitigated by "LLM-created
>> >> > contributions will be held to a higher standard than human-created ones,
>> >> > because LLMs make it easier to write tests" (and by maintainers being
>> >> > able to
>> >> 
>> >> Tests need to be reviewed too to be able to trust them so that does not help
>> >> against overloading reviewers with generated patches but burdens them even
>> >> more: they will also have to review the tests before the code.
>> >
>> > The required level of trust for tests is comparatively low, so it's much
>> > easier to review tests to a sufficient level than say device emulation
>> > code.
>> >
>> > If a new test looks plausible, fails before the fix and passes
>> > afterwards, it's more useful that what we had before, even if it's
>> > technically buggy in some corner case.
>> 
>> And also easier to rip out in the unlikely event it infringes anything.
>> 
>> But broadly having a test* is better than having no test.
>> 
>> * modulo the effects on our coverage.
>
> The maintability of test code is really important too, just as much
> as the code being tested. Every test potentially constrains how we
> can change code in future as tests themselves are never perfect or
> exhaustive and often take short-cuts in their design to suit the
> current testing needs. As we enhance the code under test, the test
> suite needs to evolve with it and that requires that we understand
> the test code and why it is doing what it is doing.

I don't disagree - and in an ideal world every core feature would have
an exhaustive test suite which exercised all the limits and exceptions
of the sub-system. Writing those good test suites is hard and certainly
not something I would be comfortable yolo'ing into the code base with an
LLM.

> A test spat out by AI which is a string of 20 undocumented qtest
> commands may fail before the fix and pass afterwards, but that
> test is not automatically a win if we don't understand why the test
> is doing what it is doing - it becomes a burden for long term maint.

However generally the qtest sequences we see are exercising an
individual device and are not dissimilar to the sequences we see come
out of the fuzzers. It would be nice if we had clear documentation for
how hardware was meant to behave but for some of our older device models
they are more or less written to handle what the guest expects in normal
operation.

And I'd certainly prefer a simple patch to a devices qtest test than an
elaborate test harness to boot qemu and send qtest commands by hand.

So in short - short tests exercising one device are fine to come out of
an LLM if the alternative is nothing. Testing frameworks to exercise
core sub-systems should remain the prerogative of the thinking engineer
unless the maintainer is particularly keen to review a models attempt to
fix it.

>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

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

[Daniel P. Berrangé]

On Thu, Oct 01, 2026 at 01:21:43PM +0100, Peter Maydell wrote:
> On Wed, 30 Sept 2026 at 09:54, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > +LLM-assisted and LLM-created contributions
> > +''''''''''''''''''''''''''''''''''''''''''
> > +
> > +Use of generative AI can be classified in the following four buckets:
> > +
> > +- "background" assistance, such as completion and code review.  This does
> > +  not need disclosure.
> > +
> > +- small LLM-assisted bugfixes (as a rule of thumb, below 10 lines of code)
> > +  are allowed with disclosure.  Splitting a submission in multiple parts
> > +  is **not** a valid way to bypass this rule; repeated, frequent posting
> > +  of such fixes must follow the rule for full contributions.
> > +
> > +- use of LLMs to help generating parts of a larger patch---test cases,
> > +  adaptations of existing code, boilerplate code for a new API, a tool to
> > +  help performing mechanical changes, etc.  These are generally allowed;
> > +  disclosure is highly recommended for non-trivial, functional code.
> 
> I think we can get or have consensus on these first three buckets...
> 
> > +- large, heavily LLM-assisted contributions where LLMs write large parts
> > +  of functional code.  These are only allowed if *pre-arranged*,
> > +  *high-quality* and *well-tested*.
> > +
> > +The last case (*"LLM-created contribution"*) is the one that requires
> > +a more careful approach.  In particular:
> > +
> > +- "Pre-arranged" means that a maintainer has communicated ahead of time,
> > +  for example on `IRC or the QEMU mailing
> > +  list <https://www.qemu.org/contribute/>`__, that they are willing
> > +  to review an LLM-created contribution.
> > +
> > +- "High-quality" means that the contributor must apply the same judgment
> > +  that would be applied to other code changes.  Contributors must invest
> > +  substantial time reviewing their contributions, curating them, and
> > +  understanding them in depth.
> > +
> > +- "Well-tested" means the LLM-created contributions will be held to a
> > +  higher standard than human-created ones, because LLMs make it easier
> > +  to write tests.  There are no exceptions for "writing the tests seems
> > +  hard" or for `yak shaving <https://en.wiktionary.org/wiki/yak_shaving>`__.
> 
> ...but I think fundamentally I am not in favour of having this
> fourth category of permitted uses. It seems even to have lost the
> idea of it being an "experimental" approach in this revision of the
> series. The first three categories are fine, and I have no particular
> problem with our relaxing our current policy to explicitly permit them.

I suggested previously to remove the "experimental" tag, because it
felt rather misleading wrt what the policy was actually proposing to
permit in practice.


When we're saying that a maintainer and contributor can agree to
use AI for *anything* and will merge it, then that work has ceased
to be for "experiments". It is a fully accepted use case for writing
and merging code. All the policy is doing at that point is attempting
to rate-limit work by requiring prior agreement to use AI.


> Our problem as a project does not seem to be on the "writing
> code" side of things, but has always been on the "code review"
> side. This policy relaxation makes it much easier to write more
> code. Even when there's a "pre-arranged reviewer" that isn't
> necessarily helpful -- if you're one of the primary maintainers
> for an area of QEMU then the fact that somebody else is reviewing
> it doesn't make a big AI-generated code infusion any more palatable.

Yes, that is my concern with anything that ends up spreading outside
the bounds of a single subsystem & its maintainer(s).


> I look at our issue tracker where we see AI assisted contributions
> that run the whole range from "an human making intelligent use of
> the tool to provide high-quality bug reports with good analysis"
> through to "absolute slop dumped on us with no apparent human
> thought or intervention". I don't really want to expand that
> from our issue tracker to our code review and codebase, please.

One of the problems I have with the AI contribs in the bug tracker
is that the quality/accuracy is just about high enough that I am
not comfortable rejecting (closing) most of the bugs, as there's
usually some nugget of a real problem in there. At the same time
the quality is not high enough to make it pleasant to deal with
the issues, which is amplified by the volume of bugs.

I expect the same thing will happen with code. The patches will be
good enough, such that you'll have a really hard time to justify
rejecting them outright. They can even be as good as an initial
patch from a human. The difference is that when you point out all
the mistakes to the human, they'll remember most of it and not
make the same mistakes again in future contributions. For bots,
it is a potluck whether your feedback has any effect long time
on future contributions. So we'll end up suffering through the
review of the work regardless.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

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

[Paolo Bonzini]

On 10/2/26 16:53, Daniel P. Berrangé wrote:
>> I look at our issue tracker where we see AI assisted contributions
>> that run the whole range from "an human making intelligent use of
>> the tool to provide high-quality bug reports with good analysis"
>> through to "absolute slop dumped on us with no apparent human
>> thought or intervention". I don't really want to expand that
>> from our issue tracker to our code review and codebase, please.
> 
> One of the problems I have with the AI contribs in the bug tracker
> is that the quality/accuracy is just about high enough that I am
> not comfortable rejecting (closing) most of the bugs, as there's
> usually some nugget of a real problem in there. At the same time
> the quality is not high enough to make it pleasant to deal with
> the issues, which is amplified by the volume of bugs.
> 
> I expect the same thing will happen with code. The patches will be
> good enough, such that you'll have a really hard time to justify
> rejecting them outright. They can even be as good as an initial
> patch from a human. The difference is that when you point out all
> the mistakes to the human, they'll remember most of it and not
> make the same mistakes again in future contributions. For bots,
> it is a potluck whether your feedback has any effect long time
> on future contributions. So we'll end up suffering through the
> review of the work regardless.
I agree it's a risk (I mentioned it in different words in my reply to 
Peter).  However, it is a risk and not a certainty.  If it materializes, 
we can (with data) change the policy again; this is what the 
"experimental" part means, or meant.

In the meanwhile the agent instructions exists to minimize this and 
other risks.  And even before that, maintainers *can and should* say no 
if, for whatever reason, they don't feel comfortable reviewing AI 
contributions.

Paolo