From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
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 13:36:28 -0400 [thread overview]
Message-ID: <20240516133541-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAFEAcA_ZhSvaZtwooZXfM2=acypm=uCvVFroPOy5E2BbKtGRKA@mail.gmail.com>
On Thu, May 16, 2024 at 06:34:13PM +0100, Peter Maydell wrote:
> 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
Maybe I'm bad at prompting ;)
--
MST
next prev parent reply other threads:[~2024-05-16 17:37 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
2024-05-16 17:36 ` Michael S. Tsirkin [this message]
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=20240516133541-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).