From: Paolo Bonzini <[email protected]> Until now QEMU's code provenance policy declined any contribution believed to include or derive from AI-generated content. A blanket ban was easy to maintain while LLM output was rarely usable on its own, but as the tools improved an absolute prohibition has become harder to justify.
The concern that motivated the policy is unchanged, and it is worth stating precisely: the DCO is about whether the submitter has the legal right to contribute the code, not about "creative expression". The copyright and license status of LLM output remains unsettled, so that question is still open. What has shifted is the balance of risk: - projects accepting AI-assisted content have not run into serious legal trouble so far, which suggests the probability of the risk materializing is not high; - other organizations, such as Red Hat[1], have assessed the risk as acceptable -- though a community of individual developers does not have the legal backing of a company, and even an unfounded dispute would be a long-lasting distraction from work on QEMU. Revise the policy to permit AI assistance where the ramifications of copyright violations are at least easy to revert and unlikely to spread: tests, documentation, mechanical changes, and small bug fixes. Core code that other things depend on, and that cannot simply be thrown away once a problem is noticed long after the fact, stays off-limits without prior agreement from a maintainer. Related to this, and already visible in the incredible uptick in security requirements, is the question of maintainer burnout and the shift in effort from the author to the reviewer of the code. AI lowers the cost of producing a patch but does nothing to lower the cost of understanding and reviewing one; if anything it raises it, since a reviewer can no longer assume that the submitter has reasoned through every line. The limits above work just as much to keep the volume of review work sustainable. Furthermore, introduce "AI-used-for:" as a trailer to record where AI was used, and include other suggestions that help reviewers judge the result. The standard is slightly different from the more usual "Assisted-by", which doubles as a check that the author has read the policy. In any case, use of AI does not relax any other contribution requirement: authors still comply with the DCO and take responsibility for the whole patch via Signed-off-by. [Commit message largely based on https://lore.kernel.org/qemu-devel/[email protected]/, by Kevin Wolf. - Paolo] [1] https://www.redhat.com/en/blog/ai-assisted-development-and-open-source-navigating-legal-issues Cc: Alistair Francis <[email protected]> Cc: Daniel P. Berrangé <[email protected]> Cc: Kevin Wolf <[email protected]> Cc: Michael S. Tsirkin <[email protected]> Cc: Peter Maydell <[email protected]> Cc: Warner Losh <[email protected]> Link: https://lore.kernel.org/qemu-devel/[email protected]/T/ Signed-off-by: Paolo Bonzini <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Message-ID: <[email protected]> Signed-off-by: Alex Bennée <[email protected]> --- v2 - add warning emphasis to policy - add Documentation to list of acceptable uses - make clear maintainers have discretion to accept/reject large AI changes - make it clear a human should write the commit message - rephrase "presence" to "usage" - make helpful/unhelpful prompts clearer --- docs/devel/code-provenance.rst | 172 +++++++++++++++++++++------------ 1 file changed, 111 insertions(+), 61 deletions(-) diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst index 65b8f232a08..3085c2e99dc 100644 --- a/docs/devel/code-provenance.rst +++ b/docs/devel/code-provenance.rst @@ -1,7 +1,7 @@ .. _code-provenance: -Code provenance -=============== +Code provenance and AI usage +============================ Certifying patch submissions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -288,62 +288,112 @@ 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. +.. 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 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 currently allows +using AI/LLM tools to produce patches in a limited set of scenarios: + +**Mechanical changes** + If you can use a deterministic tool or a script, it is preferred + that you use it and not replace it with AI. If you don't know how + to do the change deterministically, you can ask the AI for help. + +**Small bug fixes** + These should be limited to 20 lines of code or less, not including + tests. You are still expected to understand and explain your changes + and the rationale behind them. + +**Tests** + Note that you must still confirm that each test actually exercises + the intended behavior including, for regression tests, that it + fails without the code under test and passes for the right reason. + +**Documentation** + Updates to documentation can be driven by an AI tool. However it is + essential the result is carefully reviewed before submission. LLMs + can write nicely worded and plausible prose that is still incorrect. + +These boundaries do not apply to other uses of AI, such as researching +APIs or algorithms, static analysis, or debugging, provided the model's +output is not included in contributions. + +If you wish to send large amounts of AI-generated changes, or any other +contribution not in the above categories, please get in touch with the +maintainer beforehand. It is at the discretion of the relevant +maintainers if they would review and accept such contributions. + +**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 `Developer's Certificate of Origin (DCO) <dco>`. + +Commit messages for AI-assisted changes +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +AI tools **should not be used to write commit messages**. The act of +summarising and explaining the reasoning for the changes is an +important demonstration of the human authors understanding of the +commit. + +When AI/LLM tools produce or substantively shape your patch, add an +``AI-used-for:`` trailer along with the sign-offs and other metadata +at the bottom of the commit message. The text of the trailer could be +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 + +The trailer is intended as a clarification of your DCO obligations as +well as to guide reviewers. It is not intended for minimal usage such +as autocomplete or asking for a pre-review of the patch, and it does +not remove your responsibility to understand the changes that you are +submitting. + +There is no requirement to include your prompts or summarize the +conversation in the commit message or cover letter, but you may do so +if you think it helps a reviewer judge the result. For example: + +**Helpful prompts** + These describe concrete constraints or instructions, making it easy for a + reviewer to see how the tool's output was guided: + + * "move field ``foo`` from ``struct aa`` to ``struct bb``. If a + function already has a local variable or parameter of type ``struct + bb``, use it instead of accessing ``aa.bb``" + + * "add an implementation of the trait for ``Mutex<T: MyTrait>``; for + the implementation, take the lock around the calls and forward to ``T``" + +**Unhelpful prompts** + These are too generic to provide meaningful context: + + * "write user-facing documentation for the new tool" + + * "write testcases for the new functions" + +QEMU does *not* use ``Assisted-by`` or ``Generated-by`` trailers. In +particular, it is not necessary to 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. -- 2.47.3
