From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, stefanha@redhat.com,
alex.bennee@linaro.org
Subject: Re: [PATCH] docs/code-provenance: add an exception for non-creative AI changes
Date: Mon, 29 Sep 2025 19:36:05 +0100 [thread overview]
Message-ID: <aNrRlUUFm64pQMyn@redhat.com> (raw)
In-Reply-To: <CAFEAcA_6nf6zAK9=VZE9kCXUvYcZhxAgPUN=0gxtun7ip6b7ig@mail.gmail.com>
On Fri, Sep 26, 2025 at 03:38:49PM +0100, Peter Maydell wrote:
>
> I'm not enthusiastic. The current policy is essentially
> "the legal risks are unclear and the project isn't willing
> to accept them".
Broadly speaking the legal risks are unclear. The challenge from Paolo
though is there are some usage scenarios where the legal risks are
negligible, even in today's murky situation wrt training material
license laundering
> That's a straightforward rule to follow
> that doesn't require either the contributor or the reviewer
> or the project to make a possibly difficult judgement call on
> what counts as not in fact risky. As soon as we start adding
> exceptions then either we the project are making those
> judgement calls, or else we're pushing them on contributors
> or reviewers. I prefer the simple "'no' until the legal
> picture becomes less murky" rule we have currently.
The simplicity of the current rule is very appealing, but at the same time
I find it hard to justify why we should reject usage in some of these
scenarios.
So we have a choice of deciding we're going to accept the collatoral
damage of rejecting what are almost certainly low risk contributions,
or tolerate a little more complexity in our policy via exceptions.
I'm willing to entertain the idea of exceptions, as long as we don't
make it too onerous for our maintainers to evaluate patches with a
reasonable consistency across our different maintainers.
Something should be able to pass an obvious & simple "sniff test" to
be able to qualify under an exception. If we find ourselves having
to debate & ponder applicability, then the exception would be unworkable.
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 :|
next prev parent reply other threads:[~2025-09-29 18:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-25 7:56 [PATCH] docs/code-provenance: add an exception for non-creative AI changes Paolo Bonzini
2025-09-26 14:38 ` Peter Maydell
2025-09-26 19:26 ` Paolo Bonzini
2025-09-29 9:51 ` Daniel P. Berrangé
2025-09-29 11:52 ` Peter Maydell
2025-09-29 18:36 ` Daniel P. Berrangé [this message]
2025-09-29 18:28 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aNrRlUUFm64pQMyn@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).