All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, "Alex Bennée" <alex.bennee@linaro.org>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"BALATON Zoltan" <balaton@eik.bme.hu>,
	"Fabiano Rosas" <farosas@suse.de>,
	"Kevin Wolf" <kwolf@redhat.com>, "Warner Losh" <imp@bsdimp.com>,
	"Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Paolo Bonzini" <bonzini@gnu.org>
Subject: Re: [PATCH v2] docs/devel: relax policy on AI-generated contributions
Date: Fri, 7 Aug 2026 15:41:45 +0100	[thread overview]
Message-ID: <anXuqbBXERqn4lPu@redhat.com> (raw)
In-Reply-To: <CAFEAcA-VB7kNn6MM4cF7Pz356KgkyKRaK0xMC2PTXYYCVVfLyg@mail.gmail.com>

On Fri, Aug 07, 2026 at 01:39:32PM +0100, Peter Maydell wrote:
> On Sun, 2 Aug 2026 at 20:51, Michael S. Tsirkin <mst@redhat.com> wrote:
> > So GCC has now decided that 15 lines or so is ok, if a maintainer
> > decides so, and that one
> > should only count significantly different changes, what they call,
> > following the gnu maintainer guidelines "legally significant contributions":
> >
> >         A change of just a few lines (less than 15 or so) is not legally
> >         significant for copyright. A regular series of repeated changes, such as
> >         renaming a symbol, is not legally significant even if the symbol has to
> >         be renamed in many places.
> 
> That is more that the GNU project already had a level they defined
> as legally significant, because they wanted it to determine whether
> they needed copyright assignment or not. So it's natural for GCC to
> use it also in their AI policy.

None the less that is an interesting benchmark.

A key challenge we've always had in these discussions is how
to draw a line on what "legally signicant" means in practice.

The fact that the GNU project has used the "15 lines" rule
for copyright assignment is quite a useful benchmark to take
in to account precisely because they've used that for years
(presumably decades?). To me the longevity gives it weight
because it isn't something made up recently to suit the needs
of those pushing use AI/LLM tools, and has had long term
practical application in many real world OSS projects.


> > GCC also makes an exception for tests and I guess we could make
> > an exception for internal developer docs?
>
> I don't think we should have AI generated docs, including
> developer docs, as I noted somewhere up thread. That's not for
> any particular copyright reasons, it's because we need actual
> humans to be understanding and writing the documentation,
> because it can't be easily cross-checked by tests.

IME, it is by writing docs for a feature, that you come to learn about
the flaws / gaps in the thing that is implemented, which feeds back to
improve the code.  Generating docs you're just going get text that
reflects the state of the code without the learning & improvement
experiance.

I don't think we should have an exception for tests either. If we
have code in the tests directory that is generalized to become
part of the broader codebase, we shouldn't have to think about the
history of whether the tests code was AI generated.

The boundary between docs and code is also not entirely clear cut
and intermingled in areas like command line help, QAPI inline
docs, API doc comments,and so on.

IMHO all content in the repository should be treated the equivalently
and held to a common standard. IOW, *if* we decide it is reasonable to
allow limited AI/LLM usage in some manner, prefer to do that universally
rather than trying to be very selective across sub-directories/files.

Simplicity & clarity of rules makes it more likely that people will
actually be able to follow them.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



  reply	other threads:[~2026-08-07 14:43 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-29  9:46 [PATCH v2] docs/devel: relax policy on AI-generated contributions Paolo Bonzini
2026-05-29 11:52 ` Alex Bennée
2026-05-29 13:06   ` Paolo Bonzini
2026-05-29 13:10     ` Michael S. Tsirkin
2026-05-29 11:59 ` BALATON Zoltan
2026-05-29 15:34 ` Peter Maydell
2026-05-29 15:46   ` Michael S. Tsirkin
2026-05-29 15:55     ` Peter Maydell
2026-05-29 16:17     ` Paolo Bonzini
2026-05-29 17:47       ` Michael S. Tsirkin
2026-06-02  7:38   ` Michael S. Tsirkin
2026-06-02  8:09     ` Paolo Bonzini
2026-06-02 15:53 ` Stefan Hajnoczi
2026-06-03 11:35   ` Paolo Bonzini
2026-06-03 14:55     ` Stefan Hajnoczi
2026-06-03 14:59 ` Daniel P. Berrangé
2026-06-03 15:06   ` Michael S. Tsirkin
2026-06-03 15:35   ` Paolo Bonzini
2026-06-03 17:54     ` Daniel P. Berrangé
2026-06-04 10:37       ` Paolo Bonzini
2026-06-05  9:17         ` Daniel P. Berrangé
2026-06-05  9:25           ` Michael S. Tsirkin
2026-06-05  9:39             ` Daniel P. Berrangé
2026-06-05  9:48               ` Michael S. Tsirkin
2026-06-05 10:23                 ` Daniel P. Berrangé
2026-06-05 10:28                   ` Michael S. Tsirkin
2026-06-05 10:34                     ` Daniel P. Berrangé
2026-06-05 11:26                   ` Paolo Bonzini
2026-06-05 12:39                   ` BALATON Zoltan
2026-06-05 13:00                     ` Daniel P. Berrangé
2026-06-03 18:14     ` Alex Bennée
2026-06-03 18:20       ` Daniel P. Berrangé
2026-06-04 10:04         ` Alex Bennée
2026-06-04  6:08       ` Michael S. Tsirkin
2026-06-05 10:12     ` Kevin Wolf
2026-06-05 10:23       ` Michael S. Tsirkin
2026-06-16 17:06 ` Christian Borntraeger
2026-06-16 17:30   ` Michael S. Tsirkin
2026-06-16 17:44   ` Daniel P. Berrangé
2026-06-17  6:28     ` Alex Bennée
2026-06-17  8:38   ` Kevin Wolf
2026-06-17  8:49     ` Daniel P. Berrangé
2026-06-17 14:44       ` Kevin Wolf
2026-06-17 15:49         ` Peter Maydell
2026-06-23 19:26 ` Michael S. Tsirkin
2026-08-02 19:51 ` Michael S. Tsirkin
2026-08-07 12:39   ` Peter Maydell
2026-08-07 14:41     ` Daniel P. Berrangé [this message]
2026-08-07 14:53       ` Markus Armbruster
2026-08-07 18:42       ` GCC, Conservancy and Rust AI documents (was Re: [PATCH v2] docs/devel: relax policy on AI-generated contributions) Paolo Bonzini
2026-08-10 10:18         ` Peter Maydell

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=anXuqbBXERqn4lPu@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=alistair.francis@wdc.com \
    --cc=balaton@eik.bme.hu \
    --cc=bonzini@gnu.org \
    --cc=farosas@suse.de \
    --cc=imp@bsdimp.com \
    --cc=kwolf@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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.