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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jun 25, 2025 at 04:49:17PM -0400, Michael S. Tsirkin wrote:
> On Wed, Jun 25, 2025 at 04:47:06PM -0400, Stefan Hajnoczi wrote:
> > 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.
> 
> Right. Let's put that in the doc?

In terms of mitigating risk I think it is better to avoid saying that
explicitly, and be seen to actively encourage acceptance of AI generated
code. The boundary between copyrightable and non-copyrightable code is
always pretty fuzzy and a matter of differing opinions.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|