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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Sep 22, 2025 at 03:56:51PM +0200, Paolo Bonzini wrote:
> 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).

Agreed, when I say an exception a tool, I would find it highly
unlikely we would do so for such a highly generic tool as
Claude/ChatGPT. That would effectively be removing all policy
limitations.

Rather I was thinking about the possibility that certain very
specialized tools might appear.

The usage scenarios exception seems the much more likely one
in the near future.

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

When a maintainer gives an Acked-by or Signed-off-by tag they
are stating the contribution complies with our policies and
that includes this AI policy.

If a maintainer isn't comfortable with the AI exception
applicability they should not give Acked-by/Signed-off-by,
and/or ask another maintainer to give their own NNN-by tag
as a second opinion.

> What I do *not* want is Generated-by or Assisted-by.

Yes, I don't want to see us advertizing commercial products in
git history

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

Employees likely don't have any way to check that either. They'll
just be blindly trusting what little information their employer
provides, if any. We don't want to put our contributions into an
impossible situation wrt determining compliance. It needs to be
practical for them to make a judgement call.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|