[PATCH 0/3] docs/code-provenance: clarify AI exception process

[PATCH 0/3] docs/code-provenance: clarify AI exception process

[Paolo Bonzini]

Some changes to QEMU's code provenance policy with respect to AI-generated
content.

First of all, clarify the intended scope: the policy is not about
content generators, it is about generated content (patch 1).

Second, establish the exception process as what it is meant to be:
a friendly/welcoming discussion where a contributor explains what they
would like to use AI for, and consensus is reached on why it is credible
for them to claim DCO compliance.

To this end, also clarify that AI exceptions are a description and not an
override of DCO compliance.

While the RFC had a motivating example of exception, leave it out as
these improvements are useful on their own.

Paolo

Supersedes: <20250922113219.32122-1-pbonzini@redhat.com>

Paolo Bonzini (3):
  docs/code-provenance: clarify scope very early
  docs/code-provenance: make the exception process more prominent
  docs/code-provenance: AI exceptions are in addition to DCO

 docs/devel/code-provenance.rst | 33 ++++++++++++++++++++++-----------
 1 file changed, 22 insertions(+), 11 deletions(-)

-- 
2.51.0

[PATCH 1/3] docs/code-provenance: clarify scope very early

[Paolo Bonzini]

The AI policy in QEMU is not about content generators, it is about generated
content.  Other uses are explicitly not covered.  Rename the policy and clarify
its scope in the TL;DR section, as a matter of convenience to the reader.

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 docs/devel/code-provenance.rst | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index b5aae2e2532..dba99a26f64 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -285,8 +285,8 @@ 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 content generators
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Use of AI-generated content
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 TL;DR:
 
@@ -294,6 +294,10 @@ TL;DR:
   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
@@ -322,10 +326,6 @@ 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.
-- 
2.51.0

[PATCH 2/3] docs/code-provenance: make the exception process more prominent

[Paolo Bonzini]

QEMU's AI generated content policy does not flesh out the exception
process yet.  Do it, while at the same time keeping things informal: ask
contributors to explain what they would like to use AI for, and let them
reach a consensus with the project on why it is credible to claim DCO
compliance in that specific scenario.

In other words, exceptions do not "solve the AI copyright problem".  They
take a position that a reasonable contributor could have, and assert that
we're comfortable with the argument.

Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 docs/devel/code-provenance.rst | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index dba99a26f64..103e0a97d76 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -326,8 +326,13 @@ The QEMU project thus requires that contributors refrain from using AI 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.
+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 the legal risks to the
+project.  After discussion, any exception will be listed below.
-- 
2.51.0

[PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Paolo Bonzini]

Using phrasing from https://openinfra.org/legal/ai-policy (with just
"commit" replaced by "submission", because we do not submit changes
as commits but rather emails), clarify that the contributor remains
responsible for its copyright or license status.

[This is not my preferred phrasing.  I would prefer something lighter
like "the "Signed-off-by" label in the contribution gives the author
responsibility".  But for the sake of not reinventing the wheel I am
keeping the exact words from the OpenInfra policy.]

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 docs/devel/code-provenance.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
index 103e0a97d76..41062f29639 100644
--- a/docs/devel/code-provenance.rst
+++ b/docs/devel/code-provenance.rst
@@ -341,3 +341,9 @@ 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 the legal risks to the
 project.  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 submissions 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.
-- 
2.51.0

Re: [PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Peter Maydell]

On Mon, 22 Sept 2025 at 16:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> Using phrasing from https://openinfra.org/legal/ai-policy (with just
> "commit" replaced by "submission", because we do not submit changes
> as commits but rather emails), clarify that the contributor remains
> responsible for its copyright or license status.
>
> [This is not my preferred phrasing.  I would prefer something lighter
> like "the "Signed-off-by" label in the contribution gives the author
> responsibility".  But for the sake of not reinventing the wheel I am
> keeping the exact words from the OpenInfra policy.]
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/devel/code-provenance.rst | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
> index 103e0a97d76..41062f29639 100644
> --- a/docs/devel/code-provenance.rst
> +++ b/docs/devel/code-provenance.rst
> @@ -341,3 +341,9 @@ 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 the legal risks to the
>  project.  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 submissions is a statement that the author takes

grammar nit: "submission".

> +responsibility for the entire contents of the patch, including any parts
> +that were generated or assisted by AI tools or other tools.

otherwise
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [PATCH 1/3] docs/code-provenance: clarify scope very early

[Peter Maydell]

On Mon, 22 Sept 2025 at 16:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> The AI policy in QEMU is not about content generators, it is about generated
> content.  Other uses are explicitly not covered.  Rename the policy and clarify
> its scope in the TL;DR section, as a matter of convenience to the reader.
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [PATCH 1/3] docs/code-provenance: clarify scope very early

[Alex Bennée]

Paolo Bonzini <pbonzini@redhat.com> writes:

> The AI policy in QEMU is not about content generators, it is about generated
> content.  Other uses are explicitly not covered.  Rename the policy and clarify
> its scope in the TL;DR section, as a matter of convenience to the reader.
>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

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

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 2/3] docs/code-provenance: make the exception process more prominent

[Stefan Hajnoczi]

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

On Mon, Sep 22, 2025 at 05:48:41PM +0200, Paolo Bonzini wrote:
> QEMU's AI generated content policy does not flesh out the exception
> process yet.  Do it, while at the same time keeping things informal: ask
> contributors to explain what they would like to use AI for, and let them
> reach a consensus with the project on why it is credible to claim DCO
> compliance in that specific scenario.
> 
> In other words, exceptions do not "solve the AI copyright problem".  They
> take a position that a reasonable contributor could have, and assert that
> we're comfortable with the argument.
> 
> Suggested-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/devel/code-provenance.rst | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
> index dba99a26f64..103e0a97d76 100644
> --- a/docs/devel/code-provenance.rst
> +++ b/docs/devel/code-provenance.rst
> @@ -326,8 +326,13 @@ The QEMU project thus requires that contributors refrain from using AI 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.
> +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 the legal risks to the
> +project.  After discussion, any exception will be listed below.

"Legal risks to the project" is all-encompassing and vague. People may
not know how to start addressing the topic and might therefore not
attempt to request an exception.

I suggest replacing "legal risks to the project" with something more
concrete like "issues around license and copyright status required to
satisfy the Developer Certificate of Origin (DCO) requirements".

> -- 
> 2.51.0
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/3] docs/code-provenance: clarify scope very early

[Stefan Hajnoczi]

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

On Mon, Sep 22, 2025 at 05:48:40PM +0200, Paolo Bonzini wrote:
> The AI policy in QEMU is not about content generators, it is about generated
> content.  Other uses are explicitly not covered.  Rename the policy and clarify
> its scope in the TL;DR section, as a matter of convenience to the reader.
> 
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/devel/code-provenance.rst | 11 ++++++-----
>  1 file changed, 6 insertions(+), 5 deletions(-)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Stefan Hajnoczi]

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

On Mon, Sep 22, 2025 at 05:48:42PM +0200, Paolo Bonzini wrote:
> Using phrasing from https://openinfra.org/legal/ai-policy (with just
> "commit" replaced by "submission", because we do not submit changes
> as commits but rather emails), clarify that the contributor remains
> responsible for its copyright or license status.
> 
> [This is not my preferred phrasing.  I would prefer something lighter
> like "the "Signed-off-by" label in the contribution gives the author
> responsibility".  But for the sake of not reinventing the wheel I am
> keeping the exact words from the OpenInfra policy.]
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/devel/code-provenance.rst | 6 ++++++
>  1 file changed, 6 insertions(+)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/3] docs/code-provenance: make the exception process more prominent

[Paolo Bonzini]

On 9/23/25 19:58, Stefan Hajnoczi wrote:
>> +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 the legal risks to the
>> +project.  After discussion, any exception will be listed below.
> 
> "Legal risks to the project" is all-encompassing and vague. People may
> not know how to start addressing the topic and might therefore not
> attempt to request an exception.
> 
> I suggest replacing "legal risks to the project" with something more
> concrete like "issues around license and copyright status required to
> satisfy the Developer Certificate of Origin (DCO) requirements".

It's already a long sentence.  Would "while still mitigating issues around
compliance with the DCO" be enough?

Paolo

Re: [PATCH 2/3] docs/code-provenance: make the exception process more prominent

[Stefan Hajnoczi]

On Tue, Sep 23, 2025 at 3:20 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 9/23/25 19:58, Stefan Hajnoczi wrote:
> >> +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 the legal risks to the
> >> +project.  After discussion, any exception will be listed below.
> >
> > "Legal risks to the project" is all-encompassing and vague. People may
> > not know how to start addressing the topic and might therefore not
> > attempt to request an exception.
> >
> > I suggest replacing "legal risks to the project" with something more
> > concrete like "issues around license and copyright status required to
> > satisfy the Developer Certificate of Origin (DCO) requirements".
>
> It's already a long sentence.  Would "while still mitigating issues around
> compliance with the DCO" be enough?

Yes.

Thanks,
Stefan

Re: [PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Kevin Wolf]

Am 22.09.2025 um 17:48 hat Paolo Bonzini geschrieben:
> Using phrasing from https://openinfra.org/legal/ai-policy (with just
> "commit" replaced by "submission", because we do not submit changes
> as commits but rather emails), clarify that the contributor remains
> responsible for its copyright or license status.

I feel here the commit message is clearer than...

> [This is not my preferred phrasing.  I would prefer something lighter
> like "the "Signed-off-by" label in the contribution gives the author
> responsibility".  But for the sake of not reinventing the wheel I am
> keeping the exact words from the OpenInfra policy.]
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  docs/devel/code-provenance.rst | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/docs/devel/code-provenance.rst b/docs/devel/code-provenance.rst
> index 103e0a97d76..41062f29639 100644
> --- a/docs/devel/code-provenance.rst
> +++ b/docs/devel/code-provenance.rst
> @@ -341,3 +341,9 @@ 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 the legal risks to the
>  project.  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 submissions 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.

...the actually committed text. We should probably mention "copyright or
license status" explicitly here in some way instead of just a more
generic "responsibility for the entire contents" without referring to
copyright.

Maybe something like "...responsibility for the entire contents of the
patch and in particular its copyright or license status, ..."

Kevin

Re: [PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Paolo Bonzini]

On 9/29/25 09:54, Kevin Wolf wrote:
> Am 22.09.2025 um 17:48 hat Paolo Bonzini geschrieben:
>> Using phrasing from https://openinfra.org/legal/ai-policy (with just
>> "commit" replaced by "submission", because we do not submit changes
>> as commits but rather emails), clarify that the contributor remains
>> responsible for its copyright or license status.
> 
> I feel here the commit message is clearer than...
>
>> +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 submissions 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.
> 
> ...the actually committed text. We should probably mention "copyright or
> license status" explicitly here in some way instead of just a more
> generic "responsibility for the entire contents" without referring to
> copyright.

It's mentioned earlier, since the responsibility is not limited to 
exceptions: "To satisfy the DCO, the patch contributor has to fully 
understand the copyright and license status of content they are 
contributing to QEMU".  I find this sentence to be already a bit heavy, 
and would prefer not to make it longer.

Paolo

> Maybe something like "...responsibility for the entire contents of the
> patch and in particular its copyright or license status, ..."

Re: [PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Kevin Wolf]

Am 29.09.2025 um 11:19 hat Paolo Bonzini geschrieben:
> On 9/29/25 09:54, Kevin Wolf wrote:
> > Am 22.09.2025 um 17:48 hat Paolo Bonzini geschrieben:
> > > Using phrasing from https://openinfra.org/legal/ai-policy (with just
> > > "commit" replaced by "submission", because we do not submit changes
> > > as commits but rather emails), clarify that the contributor remains
> > > responsible for its copyright or license status.
> > 
> > I feel here the commit message is clearer than...
> > 
> > > +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 submissions 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.
> > 
> > ...the actually committed text. We should probably mention "copyright or
> > license status" explicitly here in some way instead of just a more
> > generic "responsibility for the entire contents" without referring to
> > copyright.
> 
> It's mentioned earlier, since the responsibility is not limited to
> exceptions: "To satisfy the DCO, the patch contributor has to fully
> understand the copyright and license status of content they are contributing
> to QEMU".  I find this sentence to be already a bit heavy, and would prefer
> not to make it longer.

Isn't the whole paragraph meant to say that exceptions don't make any of
earlier mentioned requirements go away? So I don't think it would be
redundant in this context, even though of course it would repeat the
requirement just to tell more specifically what it's referring to.

If you don't want to say "copyright or license status" here, referring
to "DCO requirements" would have the same effect (because we do have
the explanation you quoted).

Kevin

Re: [PATCH 3/3] docs/code-provenance: AI exceptions are in addition to DCO

[Paolo Bonzini]

On 9/29/25 11:35, Kevin Wolf wrote:
>> It's mentioned earlier, since the responsibility is not limited to
>> exceptions: "To satisfy the DCO, the patch contributor has to fully
>> understand the copyright and license status of content they are contributing
>> to QEMU".  I find this sentence to be already a bit heavy, and would prefer
>> not to make it longer.
> 
> Isn't the whole paragraph meant to say that exceptions don't make any of
> earlier mentioned requirements go away? So I don't think it would be
> redundant in this context, even though of course it would repeat the
> requirement just to tell more specifically what it's referring to.

Even though this section is specifically about generated content
exceptions, requirements are not limited to the DCO.  Of the other
practices in the file, "where an automated manipulation is performed
on code, however, this should be declared in the commit message" is
an important one in this context.  The fourth and more controversial
patch in the RFC included text about providing the prompt and, while
it is premature to have it now, I can imagine this paragraph becoming
a bullet list:

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

- it is highly encouraged to provide background information such as the
   prompts that were used, and to not mix AI- and human-written code in the
   same commit, as much as possible.
---

Also, for lack of a better place, this sentence about requirements could
even extend to those spelled out by submitting-a-patch.rst.  For example,
"use the QEMU coding style", "split up long patches", "don't include
irrelevant changes", "write a meaningful commit message" all serve as
indicators that contributors have properly reviewed and understood any
generated output.

I like the idea that the concerns are split between the exception process
(assessing risk in general) and regular review (assessing code quality of
specific contributions).

Either way, I agree that there is room for clarifying the policy even further.

Thanks,

Paolo

> If you don't want to say "copyright or license status" here, referring
> to "DCO requirements" would have the same effect (because we do have
> the explanation you quoted).
> 
> Kevin
> 
> 
>