Re: [PATCH v5 3/3] docs: define policy forbidding use of AI code generators

[Stefan Hajnoczi <stefanha@gmail.com>]

On Wed, Jun 25, 2025 at 4:39 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Am 25.06.2025 um 21:16 hat Michael S. Tsirkin geschrieben:
> > 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.
> >
> >
> > Can we soften this to only apply to expressive code?
> >
> > I feel a lot of cleanups would be enabled by this.
>
> Hasn't refactoring been a (deterministically) solved problem long before
> LLMs became capable to do the same with a good enough probability?

It's easier to describe a desired refactoring to an LLM in natural
language than to figure out the regexes, semantic patches, etc needed
for traditional refactoring tools.

Also, LLMs can perform higher level refactorings that might not be
supported by traditional tools. Things like "split this interface into
callbacks that take a Foo * argument and implement the callbacks for
both a.c and b.c".

I think what Daniel mentioned is a good guide: if it's something that
you think it copyrightable, then avoid it.

Stefan