Re: GCC AI Policy Announcement

On Mon, Aug 3, 2026 at 8:20=E2=80=AFPM Thomas Koenig <[email protected]=
> wrote:
>
> Am 02.08.26 um 22:21 schrieb Sam James via Gcc:
> > Thomas Koenig via Gcc <[email protected]> writes:
> >
> >> Am 01.08.26 um 21:00 schrieb Sam James:
> >>>> What happens if a patch contains a non-trival amount of code that
> >>>> cannot be copyrighted because it was assisted by AI?
> >>> The open questions around this are why the GNU project issued
> >>> provisional guidance to reject significant contributions developed wi=
th
> >>> an LLM.
> >>> If it is copyrightable, then who owns the copyright? If it's based
> >>> on
> >>> the training data, then the contributor may not have the rights to
> >>> share such a patch, and it cannot be legally redistributed under the =
GPL
> >>> (or any licence).
> >> [...]
> >>
> >> To put it bluntly: The current policy is based on a risk assessment
> >> that nobody shares
> >
> > Here's a few that come to mind:
> >
> > * https://openjdk.org/legal/ai
> > * https://www.netbsd.org/developers/commit-guidelines.html
> > * the GNU project overall
> > * https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai=
-generated-content
>
> OK.
>
> As a first step for a gcc-specific risk assessment, let us look at what
> risks there are regarding LLM output.
>
> 1. Copyright issues
>
> 1 a)
>
> LLM output which does not carry copyright might "water down" the
> copyleft of the existing codebase.
>
> See https://www.gnu.org/licenses/license-list.en.html which allows
> inclusion of public domain software. If anything, this would then
> be a matter of quantity, not quality.

DCO is already a step in that direction (from the enforcing side).

> 1 b)
>
> LLM output which reproduces existing code used for training,
> which falls under somebody else's copyright.
>
> This should not pose a problem, at least if it is working
> within gcc and its support libraries - in order to work at all,
> such code would have to realistically come from a gcc fork itself,
> which would then be under the GPL.

That was my line of thinking as well.  In the end it boils down to
the definition of derived work.  Also note that in the end any
plaintiff would have to prove infringement.  We possibly make
that easier by labelling commits.  It's also always possible to
revert a change.

> 1 c)
>
> Code which was suitably modified / prompted by a human so
> that copyright is obtained.
>
> No problem, then the code can be assigned to the gcc project
> the normal way.
>
>
> 2. Project management issues (aka dealing with lots of AI slop)
>
> 2 a)
>
> LLMs are known to generate bad code, which fulfills the specs
> but nothing else, and to make bad architectural decisions. This
> could lead to all sorts of bad things, including hard to find
> bugs.
>
> 2 b)
>
> A flood of AI-generated patches could overwhelm maintainers,
> who would have to do much more than currently because
> quantity would very probably increase, while quality would
> likely go down.
>
> A serious problem, and one which would require care. A possible
> approach could be to require a regular contributor as a "sponsor"
> for an AI-generated patch.
>
> 3. Becoming irrelevant because of low development speed
>
> If gcc puts an effective block on LLM-generated code, and other
> projects such as LLVM manage to accelerate their development
> using LLMs, gcc could become marginalized by simply becoming,
> relative to the other projects, a worse compiler.  This is
> especially true of such subprojects such as gfortran, which is
> struggling with lack of developer capacity as is.
>
> So, what are the risks? The legal ones, to me, appear to be
> nebulous and far off. gcc becoming marginalized against
> the "competition", however, I would classify as a very high risk,
> at least if we wait for "decades" until the legal questions
> are settled.

I think both 2 and 3 are process issues;  For 3, even without letting
LLM code GCC you can increase productivity with appropriate tools,
be it to write testcases (which seems to be explicitly allowed), write
detailed develpment plans, and possibly even do refactoring tasks
(the policy isn't clear about this - but AI refactoring shouldn't be handle=
d
differently from say, using cocinelle).

Richard.

> Best regards
>
>         Thomas
>
>
>