From: "Daniel P. Berrangé" <berrange@redhat.com>
To: qemu-devel@nongnu.org
Cc: "Thomas Huth" <thuth@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"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>,
"Daniel P. Berrangé" <berrange@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>,
"Markus Armbruster" <armbru@redhat.com>
Subject: [PATCH v2 0/3] docs: define policy forbidding use of "AI" / LLM code generators
Date: Thu, 16 May 2024 17:22:27 +0100 [thread overview]
Message-ID: <20240516162230.937047-1-berrange@redhat.com> (raw)
This patch kicks the hornet's nest of AI / LLM code generators.
With the increasing interest in code generators in recent times,
it is inevitable that QEMU contributions will include AI generated
code. Thus far we have remained silent on the matter. Given that
everyone knows these tools exist, our current position has to be
considered tacit acceptance of the use of AI generated code in QEMU.
The question for the project is whether that is a good position for
QEMU to take or not ?
IANAL, but I like to think I'm reasonably proficient at understanding
open source licensing. I am not inherantly against the use of AI tools,
rather I am anti-risk. I also want to see OSS licenses respected and
complied with.
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.
Discuss...
Changes in v2:
* Fix a huge number of typos in docs
* Clarify that maintainers should still add R-b where relevant, even
if they are already adding their own S-oB.
* Clarify situation when contributor re-starts previously abandoned
work from another contributor.
* Add info about Suggested-by tag
* Add new docs section dealing with the broad topic of "generated
files" (whether code generators or compilers)
* Simplify the section related to prohibition of AI generated files
and give further examples of tools considered covered
* Remove repeated references to "LLM" as a specific technology, just
use the broad "AI" term, except for one use of LLM as an example.
* Add note that the policy may evolve if the legal clarity improves
* Add note that exceptions can be requested on case-by-case basis
if contributor thinks they can demonstrate a credible copyright
and licensing status
Daniel P. Berrangé (3):
docs: introduce dedicated page about code provenance / sign-off
docs: define policy limiting the inclusion of generated files
docs: define policy forbidding use of AI code generators
docs/devel/code-provenance.rst | 315 ++++++++++++++++++++++++++++++
docs/devel/index-process.rst | 1 +
docs/devel/submitting-a-patch.rst | 19 +-
3 files changed, 318 insertions(+), 17 deletions(-)
create mode 100644 docs/devel/code-provenance.rst
--
2.43.0
next reply other threads:[~2024-05-16 16:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 16:22 Daniel P. Berrangé [this message]
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
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=20240516162230.937047-1-berrange@redhat.com \
--to=berrange@redhat.com \
--cc=agraf@csgraf.de \
--cc=alex.bennee@linaro.org \
--cc=armbru@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=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).