Re: GCC AI Policy Announcement

On Tue, 4 Aug 2026, Richard Biener via Gcc wrote:

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

I'm going to argue against this point, but it doesn't mean I concede
the others; my opposition to use of so-called AI is broader than this.

(to be clear, the point is "would have to realistically come from a gcc
fork itself")

On a technical level, how is the claim true at all, especially for
runtime libraries, like libstdc++? They generally host and import new code
that has nothing to do with the compiler proper. I don't see how the
claim would hold for std::regex or std::format, for instance.

It's not true for gcc proper either, as it occasionally adds code that is
novel and unrelated to the rest of the compiler (to name two such instances
I contributed: gcc/sort.cc and search_line_ssse3 in libcpp).

On a policy level, since when is code being under the GPL is a sufficient
condition for adding it to GCC? The necessary condition that I know goes
either via copyright assignment, or under DCO's certification chain.

And on a social level, is that actually the stance GCC wants to take?
That when the actual author of a piece of code that was imported via 
an LLM asks about their code appearing uncredited, the response will be
"it's our derived work now" and "prove it or go away"?

This is not what I hope the community stands for.
Alexander