Re: [PATCH v5 3/3] docs: define policy forbidding use of AI code generators

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

On Mon, Jun 16, 2025 at 11:22:41AM +0200, Markus Armbruster wrote:
> From: Daniel P. Berrangé <berrange@redhat.com>
> 
> There has been an explosion of interest in so called AI code
> generators. Thus far though, this is has not been matched by a broadly
> accepted legal interpretation of the licensing implications for code
> generator outputs. While the vendors may claim there is no problem and
> a free choice of license is possible, they have an inherent conflict
> of interest in promoting this interpretation. More broadly there is,
> as yet, no broad consensus on the licensing implications of code
> generators trained on inputs under a wide variety of licenses
> 
> The DCO requires contributors to assert they have the right to
> contribute under the designated project license. Given the lack of
> consensus on the licensing of AI code generator output, it is not
> considered credible to assert compliance with the DCO clause (b) or (c)
> where a patch includes such generated code.
> 
> This patch thus defines a policy that the QEMU project will currently
> not accept contributions where use of AI code generators is either
> known, or suspected.
> 
> These are early days of AI-assisted software development. The legal
> questions will be resolved eventually. The tools will mature, and we
> can expect some to become safely usable in free software projects.
> The policy we set now must be for today, and be open to revision. It's
> best to start strict and safe, then relax.
> 
> Meanwhile requests for exceptions can also be considered on a case by
> case basis.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> Reviewed-by: Kevin Wolf <kwolf@redhat.com>
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>

Sorry about only reacting now, was AFK.

So one usecase that to me seems entirely valid, is refactoring.

For example, change a function prototype, or a structure,
and have an LLM update all callers.

The only part of the patch that is expressive is the
actual change, the rest is a technicality and has IMHO nothing to do with
copyright. LLMs can just do it with no hassle.


Can we soften this to only apply to expressive code?

I feel a lot of cleanups would be enabled by this.


> ---
>  docs/devel/code-provenance.rst | 55 +++++++++++++++++++++++++++++++++-
>  1 file changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
> index c25afed98d..b5aae2e253 100644
> --- a/docs/devel/code-provenance.rst
> +++ b/docs/devel/code-provenance.rst
> @@ -282,4 +282,57 @@ 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.
> +and licensing for their output. Note in particular the caveats applying to AI
> +content generators below.
> +
> +Use of AI content generators
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +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.**
> +
> +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.
> +
> +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 to be
> +included in contributions.
> +
> +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
> +clarifed. In the meanwhile, requests for exceptions to this policy will be
> +evaluated by the QEMU project on a case by case basis. To be granted an
> +exception, a contributor will need to demonstrate clarity of the license and
> +copyright status for the tool's output in relation to its training model and
> +code, to the satisfaction of the project maintainers.
> -- 
> 2.49.0