Re: GCC AI Policy Announcement

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 with
>>> 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.

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.

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.

Best regards

	Thomas