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 <[email protected]> Cc: Alex Bennée <[email protected]> Cc: Alistair Francis <[email protected]> Cc: BALATON Zoltan <[email protected]> Cc: Daniel P. Berrangé <[email protected]> Cc: Fabiano Rosas <[email protected]> Cc: Kevin Wolf <[email protected]> Cc: Peter Maydell <[email protected]> Cc: Warner Losh <[email protected]> Cc: Philippe Mathieu-Daudé <[email protected]> Link: https://lore.kernel.org/qemu-devel/[email protected]/T/ Signed-off-by: Paolo Bonzini <[email protected]> --- 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.
