qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@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>,
	"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [PATCH v2 0/3] docs: define policy forbidding use of "AI" / LLM code generators
Date: Thu, 16 May 2024 18:34:13 +0100	[thread overview]
Message-ID: <CAFEAcA_ZhSvaZtwooZXfM2=acypm=uCvVFroPOy5E2BbKtGRKA@mail.gmail.com> (raw)
In-Reply-To: <20240516131141-mutt-send-email-mst@kernel.org>

On Thu, 16 May 2024 at 18:20, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, May 16, 2024 at 05:22:27PM +0100, Daniel P. Berrangé wrote:
> > AFAICT at its current state of (im)maturity the question of licensing
> > of AI code generator output does not have a broadly accepted / settled
> > legal position. This is an inherant bias/self-interest from the vendors
> > promoting their usage, who tend to minimize/dismiss the legal questions.
> > >From my POV, this puts such tools in a position of elevated legal risk.
> >
> > Given the fuzziness over the legal position of generated code from
> > such tools, I don't consider it credible (today) for a contributor
> > to assert compliance with the DCO terms (b) or (c) (which is a stated
> > pre-requisite for QEMU accepting patches) when a patch includes (or is
> > derived from) AI generated code.
> >
> > By implication, I think that QEMU must (for now) explicitly decline
> > to (knowingly) accept AI generated code.
> >
> > Perhaps a few years down the line the legal uncertainty will have
> > reduced and we can re-evaluate this policy.

> At this junction, the code generated by these tools is of such
> quality that I really won't expect it to pass even cursory code
> review.

I disagree, I think that in at least some cases they can
produce code that would pass our quality bar, especially with
human supervision and editing after the fact. If the problem
was merely "LLMs tend to produce lousy output" then we wouldn't
need to write anything new -- we already have a process for
dealing with bad patches, which is to say we do code review and
suggest changes or simply reject the patches. What we *don't* have
any process to handle is the legal uncertainties that Dan outlines
above.

-- PMM


  reply	other threads:[~2024-05-16 17:35 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-16 16:22 [PATCH v2 0/3] docs: define policy forbidding use of "AI" / LLM code generators Daniel P. Berrangé
2024-05-16 16:22 ` [PATCH v2 1/3] docs: introduce dedicated page about code provenance / sign-off Daniel P. Berrangé
2024-05-16 17:29   ` Peter Maydell
2024-05-16 17:34     ` Michael S. Tsirkin
2024-05-16 17:43       ` Peter Maydell
2024-05-17  5:05         ` Thomas Huth
2024-05-17 10:03           ` Daniel P. Berrangé
2024-05-16 17:33   ` Michael S. Tsirkin
2024-05-17 11:09     ` Daniel P. Berrangé
2024-05-17 18:08   ` Alex Bennée
2024-05-16 16:22 ` [PATCH v2 2/3] docs: define policy limiting the inclusion of generated files Daniel P. Berrangé
2024-05-16 17:04   ` Michael S. Tsirkin
2024-05-17 10:51     ` Daniel P. Berrangé
2024-05-17 18:23   ` Alex Bennée
2024-05-28 15:41   ` Kevin Wolf
2024-05-16 16:22 ` [PATCH v2 3/3] docs: define policy forbidding use of AI code generators Daniel P. Berrangé
2024-05-16 17:11   ` Michael S. Tsirkin
2024-05-17 10:57     ` Daniel P. Berrangé
2024-05-16 17:20 ` [PATCH v2 0/3] docs: define policy forbidding use of "AI" / LLM " Michael S. Tsirkin
2024-05-16 17:34   ` Peter Maydell [this message]
2024-05-16 17:36     ` Michael S. Tsirkin
2024-05-21 14:27 ` Stefan Hajnoczi
2024-05-28 15:41 ` Kevin Wolf

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='CAFEAcA_ZhSvaZtwooZXfM2=acypm=uCvVFroPOy5E2BbKtGRKA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --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=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --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).