qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
	qemu-devel@nongnu.org, "Thomas Huth" <thuth@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Mark Cave-Ayland" <mark.cave-ayland@ilande.co.uk>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Alexander Graf" <agraf@csgraf.de>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [PATCH v5 3/3] docs: define policy forbidding use of AI code generators
Date: Wed, 25 Jun 2025 16:01:55 -0400	[thread overview]
Message-ID: <20250625155910-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <aFxRUFIfuDdRYA2m@redhat.com>

On Wed, Jun 25, 2025 at 08:46:54PM +0100, Daniel P. Berrangé wrote:
> On Wed, Jun 25, 2025 at 03:16:52PM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jun 16, 2025 at 11:22:41AM +0200, Markus Armbruster wrote:
> > > From: Daniel P. Berrangé <berrange@redhat.com>
> > > 
> > > There has been an explosion of interest in so called AI code
> > > generators. Thus far though, this is has not been matched by a broadly
> > > accepted legal interpretation of the licensing implications for code
> > > generator outputs. While the vendors may claim there is no problem and
> > > a free choice of license is possible, they have an inherent conflict
> > > of interest in promoting this interpretation. More broadly there is,
> > > as yet, no broad consensus on the licensing implications of code
> > > generators trained on inputs under a wide variety of licenses
> > > 
> > > The DCO requires contributors to assert they have the right to
> > > contribute under the designated project license. Given the lack of
> > > consensus on the licensing of AI code generator output, it is not
> > > considered credible to assert compliance with the DCO clause (b) or (c)
> > > where a patch includes such generated code.
> > > 
> > > This patch thus defines a policy that the QEMU project will currently
> > > not accept contributions where use of AI code generators is either
> > > known, or suspected.
> > > 
> > > These are early days of AI-assisted software development. The legal
> > > questions will be resolved eventually. The tools will mature, and we
> > > can expect some to become safely usable in free software projects.
> > > The policy we set now must be for today, and be open to revision. It's
> > > best to start strict and safe, then relax.
> > > 
> > > Meanwhile requests for exceptions can also be considered on a case by
> > > case basis.
> > > 
> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > > Reviewed-by: Kevin Wolf <kwolf@redhat.com>
> > > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > > Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
> > > Signed-off-by: Markus Armbruster <armbru@redhat.com>
> > 
> > Sorry about only reacting now, was AFK.
> > 
> > So one usecase that to me seems entirely valid, is refactoring.
> > 
> > For example, change a function prototype, or a structure,
> > and have an LLM update all callers.
> > 
> > The only part of the patch that is expressive is the
> > actual change, the rest is a technicality and has IMHO nothing to do with
> > copyright. LLMs can just do it with no hassle.
> 
> Well the policy is defined in terms of requirements to comply with
> the DCO, and that implicitly indicates that the code in question
> is eligible for copyright protection to begin with.
> 
> IOW, if a change is such that it is not considered eligible for
> copyright protection, then you can take the view that it is trivially
> DCO compliant, whether you wrote the code, an arbitrary 3rd party
> wrote the code, or whether an AI wrote the code. 

Exactly. I agree! However the patch states:

+The QEMU project thus requires that contributors refrain from using AI content
+generators on patches intended to be submitted to the project, and will
+decline any contribution if use of AI is either known or suspected.

and makes no exception for non copyrighteable parts of the patch.

Or do I misunderstand?


> > Can we soften this to only apply to expressive code?
> > 
> > I feel a lot of cleanups would be enabled by this.
> 
> Trying to detail every possible scenario is impractical and would
> make the document too onerous for people to read, remember & apply.
> It is better to leave it up to the contributor to decide whether a
> change is non-copyrightable, than to try to draw that line crudely
> in text. Even for refactoring that line will be fuzzy and contextual,
> so not a scenario where we should say any use of AI for reactoring
> is OK, as that will lull contributors into having a false sense of
> acceptibility, rather than being aware of need to question it. 

Agree again! What worries me is that the patch as posted here does
not make contributors question anything. It just flatly forbids using "AI
content generators".

-- 
MST



  reply	other threads:[~2025-06-25 20:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-16  9:22 [PATCH v5 0/3] docs: define policy forbidding use of "AI" / LLM code generators Markus Armbruster
2025-06-16  9:22 ` [PATCH v5 1/3] docs: introduce dedicated page about code provenance / sign-off Markus Armbruster
2025-06-16  9:22 ` [PATCH v5 2/3] docs: define policy limiting the inclusion of generated files Markus Armbruster
2025-06-16  9:22 ` [PATCH v5 3/3] docs: define policy forbidding use of AI code generators Markus Armbruster
2025-06-25 19:16   ` Michael S. Tsirkin
2025-06-25 19:46     ` Daniel P. Berrangé
2025-06-25 20:01       ` Michael S. Tsirkin [this message]
2025-06-26 10:41         ` Markus Armbruster
2025-06-25 20:38     ` Kevin Wolf
2025-06-25 20:45       ` Michael S. Tsirkin
2025-06-25 20:47       ` Stefan Hajnoczi
2025-06-25 20:49         ` Michael S. Tsirkin
2025-06-26  8:18           ` Daniel P. Berrangé
2025-06-26  8:38             ` Michael S. Tsirkin
2025-06-26  6:34   ` Michael S. Tsirkin
2025-06-26  7:56     ` Daniel P. Berrangé
2025-06-23 19:30 ` [PATCH v5 0/3] docs: define policy forbidding use of "AI" / LLM " Stefan Hajnoczi
2025-06-23 22:25   ` Alex Bennée
2025-06-24  5:02     ` Markus Armbruster
2025-06-24 10:41       ` Stefan Hajnoczi
2025-06-24 17:33 ` Stefan Hajnoczi

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=20250625155910-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=agraf@csgraf.de \
    --cc=alex.bennee@linaro.org \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@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).