From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
"Markus Armbruster" <armbru@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>
Subject: Re: [RFC PATCH 4/4] docs/code-provenance: make the exception process feasible
Date: Mon, 22 Sep 2025 14:04:22 +0100 [thread overview]
Message-ID: <aNFJVrusgEUaLuDW@redhat.com> (raw)
In-Reply-To: <CAFEAcA9Vr2rxeJ0P7Yohqt2+NWQ8CmmpKsB016CoKv8RchkDDQ@mail.gmail.com>
On Mon, Sep 22, 2025 at 12:46:51PM +0100, Peter Maydell wrote:
> On Mon, 22 Sept 2025 at 12:32, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > I do not think that anyone knows how to demonstrate "clarity of the
> > copyright status in relation to training".
>
> Yes; to me this is the whole driving force behind the policy.
>
> > On the other hand, AI tools can be used as a natural language refactoring
> > engine for simple tasks such as modifying all callers of a given function
> > or even less simple ones such as adding Python type annotations.
> > These tasks have a very low risk of introducing training material in
> > the code base, and can provide noticeable time savings because they are
> > easily tested and reviewed; for the lack of a better term, I will call
> > these "tasks with limited or non-existing creative content".
>
> Does anybody know how to demonstrate "limited or non-existing
> creative content", which I assume is a standin here for
> "not copyrightable" ?
That was something we aimed to intentionally avoid specifying in the
policy. It is very hard to define it in a way that will be clearly
understood by all contributors.
Furthermore by defining it explicitly QEMU also weakens its legal
position should any issues arise, because it has pre-emptively
documented its acceptance of certain scenearios. This has the effect
of directing risk away from contributors and back onto the project.
We want to be very clear that the burden / requirement for determining
legal / license compliance of contributions rests on the contributor,
not the project, whether AI is involve or not.
In terms of historical practice, when contributors have come to us
with legal questions about whether they can contribute something or
the legality of cerati nchange, as a general rule we will avoid
giving any clear legal guidance from the project's POV.
Especially with any corporate contributor the rule is to refer that
person back to their own organization's legal department. This makes
it clear where the responsibility is and avoids the QEMU project
pre-emptively setting out its legal interpretation.
TL;DR: I don't think we should attempt to define whether the boundary
is between copyrightable and non-copyrightable code changes.
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-22 13:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 11:32 [RFC PATCH 0/4] docs/code-provenance: make AI policy clearer and more practical Paolo Bonzini
2025-09-22 11:32 ` [RFC PATCH 1/4] docs/code-provenance: clarify scope very early Paolo Bonzini
2025-09-22 11:34 ` Daniel P. Berrangé
2025-09-22 12:52 ` Alex Bennée
2025-09-22 11:32 ` [RFC PATCH 2/4] docs/code-provenance: make the exception process more prominent Paolo Bonzini
2025-09-22 13:24 ` Daniel P. Berrangé
2025-09-22 13:56 ` Paolo Bonzini
2025-09-22 14:51 ` Daniel P. Berrangé
2025-09-22 11:32 ` [RFC PATCH 3/4] docs/code-provenance: clarify the scope of AI exceptions Paolo Bonzini
2025-09-22 13:02 ` Alex Bennée
2025-09-22 13:38 ` Daniel P. Berrangé
2025-09-22 11:32 ` [RFC PATCH 4/4] docs/code-provenance: make the exception process feasible Paolo Bonzini
2025-09-22 11:46 ` Peter Maydell
2025-09-22 12:06 ` Paolo Bonzini
2025-09-22 13:04 ` Daniel P. Berrangé [this message]
2025-09-22 13:26 ` Peter Maydell
2025-09-22 14:03 ` Daniel P. Berrangé
2025-09-22 15:10 ` Paolo Bonzini
2025-09-22 16:36 ` Daniel P. Berrangé
2025-09-22 16:55 ` Paolo Bonzini
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=aNFJVrusgEUaLuDW@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.