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

[Paolo Bonzini <pbonzini@redhat.com>]

On 9/22/25 16:03, Daniel P. Berrangé wrote:
> Whether we have our AI policy or not, contributors are still required
> to abide by the terms of the DCO, which requires them to understand
> the legal situation of any contribution.
> 
> Our policy is effectively saying that most use of AI is such that we
> don't think it is possible for contributions to claim DCO compliance.
> 
> If we think there are situations where it might be credible for a
> contributor to claim DCO compliance, we can try to find a way to
> describe that situation, without having to explicitly state our
> legal interpretation of the "copyrightable vs non-copyrightable"
> boundary.

Right.  I am sure that a lawyer would find some overlap between my 
definition of "where the creativity lies" and the law's definition of 
"copyrightability", but that's not where I am coming from and I am not 
even pretending to be dispensing legal advice.

The point is more that the tool shouldn't have any bearing on DCO 
compliance if the same contributor can reasonably make the same change 
with different tools or with just an editor.  And we have dozens of 
mechanical changes contributed every year, written either by hand or 
with a wide variety of tools.

I have no QEMU example at hand, but let's look at a commit like 
https://github.com/bonzini/meson/commit/09765594d.  Something like this 
could be plausibly created with AI.  What I care about is:

* to what degree can I automate what I could do by hand.  An AI tool 
moves the break-even point more towards automation.  I would not bring 
up Coccinelle for a 10 line change, in fact I looked by hand at every 
occurrence of ".cfg" and relied on mypy to check if I missed something. 
Maybe an experienced AI user would have reached to AI as the first step?[1]

* keeping people honest.  Between the two cases of "they don't tell and 
I don't realize it is AI-generated" and "they split the commit clearly 
into AI-generated and human-generated parts", an exception makes the 
latter more likely to happen.

> That said there is  still a questionmark over complexity. Getting
> to the end point may be a trival & mundane exercise in some cases,
> while requiring considerable intellectual thought in other cases.
> The latter is perhaps especially true if wanting simple, easily
> bisected series of small steps rather than a big bang conversion.

We encourage anyway people to isolate the mundane parts, therefore they 
could use AI for them if they see fit.  Independent of whether the 
contributor has worked on QEMU before, the more complex parts are also 
signed-off on (and we'd much more likely spot signs of AI usage when 
reviewing them) and that makes me more willing to trust their good faith.

Paolo

[1] I tried "I want to track the PackageConfiguration object per machine 
in mesonbuild/cargo/interpreter.py.  Make PackageState.cfg a PerMachine 
object. Initialize PackageState.cfg when the PackageState is created. 
The old pkg.cfg becomes pkg.cfg[MachineChoice.HOST]" and it did pretty 
much the same changes in a bit more than 2 minutes.  Including the time 
to write the prompt it's almost certainly more than it took me to do it 
by hand, but this time I was doing something else in the meanwhile. :)