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

[Paolo Bonzini <pbonzini@redhat.com>]

On 9/22/25 15:24, Daniel P. Berrangé wrote:
> FWIW, I considered that the "exception process" would end up
> being something like...
> 
>   * someone wants to use a particular tool for something they
>     believe is compelling
>   * they complain on qemu-devel that our policy blocks their
>     valid use
>   * we debate it

I guess we're here, except for hiding the complaint behind a patch. :)

>   * if agreed, we add a note to this code-proveance.rst doc to
>     allow it
> 
> 
> I would imagine that exceptions might fall into two buckets
> 
>   * Descriptions of techniques/scenarios for using tools
>     that limit the licensing risk
>   * Details of specific tools (or more likely models) that
>     are judged to have limited licensing risk
>
> it is hard to predict the future though, so this might be
> too simplistic. Time will tell when someone starts the
> debate...

Yeah, I'm afraid it is; allowing specific tools might not be feasible, 
as the scope of "allow Claude Code" or "allow cut and paste for ChatGPT 
chats" is obviously way too large.  Allowing some usage scenarios seems 
more feasible (as done in patch 4).

>> What is missing: do we want a formal way to identify commits for which an
>> exception to the AI policy was granted?  The common way to do so seems to
>> be "Generated-by" or "Assisted-by" but I don't want to turn commit message
>> into an ad space.  I would lean more towards something like
>>
>>    AI-exception-granted-by: Mary Maintainer <mary.maintainer@mycorp.test>
> 
> IMHO the code-provenance.rst doc is what grants the exception, not
> any individual person, nor any individual commit.
> 
> Whether we want to reference that a given commit is relying on an
> exception or not is hard to say at this point as we don't know what
> any exception would be like.
> 
> Ideally the applicability of an exception could be self-evident
> from the commit. Realiyt might be more fuzzy. So if self-evident,
> then it likely warrants a sentence two of english text in the
> commit to justify its applicability.
> IOW, a tag like AI-exception-granted-by doesn't feel like it is
> particularly useful.

I meant it as more of an audit trail, especially for the case where a 
new submaintainer would prefer to ask someone else, or for the case of a 
maintainer contributing AI-generated code.  If we can keep it simple and 
avoid this, that's fine (it's not even in the policy, only in the commit 
message).

What I do *not* want is Generated-by or Assisted-by.  The exact model or 
tool should matter in deciding whether a contribution fits the 
exception.  Companies tell their employees "you can use this model 
because we have an indemnification contract in place", but I don't think 
we should care about what contracts they have---we have no way to check 
if it's true or if the indemnification extends to QEMU, for example.

>>     **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.**
>> +  ChatGPT, Claude, Copilot, Llama and similar tools.  Exceptions may be
>> +  requested on a case-by-case basis.**
> 
> I'm not sure what you mean by 'case-by-case basis' ? I certainly don't
> think we should entertain debating use of AI in individual patch series,
> as that'll be a never ending burden on reviewer/maintainer resources.
> 
> Exceptions should be things that can be applied somewhat generically to
> tools, or models or usage scenarios IMHO.

I meant that at some point a human will have to agree that it fits the 
exception, but yeah it is not the right place to say that.

> I would suggest only this last paragraph be changed
> 
> 
>    This policy may evolve as AI tools mature and the legal situation is
>    clarifed.
> 
>    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 exceptions that can be relied upon in contributions
>    will be listed below. The listing of an exception does not remove the
>    need for contributors to comply with all other pre-existing contribution
>    requirements, including DCO signoff.

This sounds good (I'd like to keep the requirement that maintainers ask 
for a second opinion when contributing AI-generated code, but that can 
be weaved into your proposal).  Another benefit is that this phrasing is 
independent of the existence of any exceptions.

I'll split the first three patches into its own non-RFC series, and we 
can keep discussing the "refactoring scenario" in this thread.

Paolo