GCC's AI Code Problem Isn't About Quality — It's About Who Owns the Copyright

Every major open source project has had to answer the same question this year: do we accept AI-generated code? The Linux kernel published guidelines. Zig said no. Godot effectively closed the door. Now it’s GCC’s turn — and the GNU toolchain is asking a fundamentally different question than everyone else.

Worth saying upfront: this isn’t a viral fight. Scan the last month of Reddit and you’ll find almost nothing on it. That silence is the interesting part. What GCC touched isn’t the kind of thing that burns through social media in an afternoon. It’s the kind of thing you need to read legal documents to understand.

Everyone else asked about quality. GCC asked about ownership.

Line up the AI-code policies published so far and the reasoning rhymes.

Zig’s Andrew Kelley rejected AI-generated contributions primarily over review burden. If a contributor can’t explain their own code, the reviewer inherits that work. Godot’s announcement landed in the same register: a flood of unvetted PRs eating maintainer time. The Linux kernel went softer — use whatever tools you want, but the moment you add a Signed-off-by, the code is yours to answer for.

All three are asking the same thing: who is accountable for this patch? It’s a question about quality and about the cost of review.

GCC asks something else entirely. Who holds the copyright to this code in the first place? That’s a step earlier in the chain, and considerably nastier.

The FSF copyright assignment wrinkle

To understand why GCC is different, you have to understand how GCC works.

GCC is a GNU project, and historically it has required contributors to assign copyright to the Free Software Foundation for anything past a trivial size. It now runs a DCO (Developer Certificate of Origin) track alongside that, but the underlying structure holds: GCC explicitly manages who owns what.

Why bother? Because concentrating copyright in one entity means there’s a clear party with standing when someone violates the GPL. Rights scattered across hundreds of individual contributors make enforcement a nightmare. Same logic applies to relicensing decisions — moving to GPLv3 was only clean because the FSF held the pieces.

And here’s where it breaks. Copyright assignment rests on a quiet assumption: that there is a copyright to assign. Ask whether LLM-generated code has one, and nobody can answer with confidence right now.

You can’t sign away something that doesn’t exist

The US Copyright Office has held that purely AI-generated output, with no human creative contribution, isn’t copyrightable. Human involvement shifts the analysis — but where exactly the line sits is anyone’s guess.

Map that onto GCC and you get this.

A contributor uses Copilot to write a function and submits it. They sign a document assigning copyright in that code to the FSF. If the code never had a copyright, the signature transferred nothing — it’s a blank instrument. But if the contributor iterated hard on the prompt and substantially reworked the output, copyright may well exist. So which is it?

The maintainer cannot tell. There is no mechanism to see how a given patch was produced. Which leaves self-reporting by the contributor — thin cover for something meant to function as legal protection.

The training-data problem sits on top of that. If an LLM trained on GPL code emits something substantially similar to its source, that output may effectively be an unattributed derivative work. Mix code with murky license provenance into GPL-distributed GCC, and the next time the FSF wants to enforce the GPL, it’s arguing from unstable ground. The entire reason for consolidating copyright starts working against itself.

Why nobody’s shouting about this

I think the Reddit silence has a straightforward explanation.

“Ban AI code” versus “allow AI code” is a debate anyone can join. “Does a copyright assignment agreement remain valid when applied to machine-generated output” requires you to know both copyright law and the governance history of the GNU project. The barrier to entry is much higher.

GCC is also just this kind of project. Discussions ripen over months on mailing lists and barely leak onto social platforms. Quiet doesn’t mean nothing’s happening. If anything, the quiet is a signal of how heavy the question is.

Compilers sit at the bottom of the stack

One more thing worth naming: GCC isn’t merely a large open source project.

The Linux kernel builds with GCC. So does glibc. So do most distro packages. A problem in GCC propagates into everything stacked on top of it. Compilers sit at the bottom of the trust chain, and when the bottom moves, everything above it moves too.

Ken Thompson’s 1984 Turing Award lecture made the point permanently: plant a backdoor in a compiler and no amount of staring at source code will find it. The current situation is a different animal, but the conclusion transfers — what goes into a compiler deserves a higher bar than what goes into an app. This is a codebase where one subtle optimization bug quietly reaches thousands of packages.

GCC handling legally-ambiguous code more carefully than other projects isn’t excess caution. It’s a function of where GCC sits.

What’s actually unresolved

So here’s the split.

Zig and Godot asked: do we have time to review this? Practical, immediate, answerable this quarter. GCC asked: can we own this? That one may need a court ruling or new legislation before it has an answer.

And it isn’t GCC’s problem alone. Every project with a CLA carries the same structure — Apache Foundation projects, and most corporate-backed open source. GCC just hit the wall first.

For anyone contributing right now, the practical posture is roughly this. Check the project’s CLA and AI policy before you open a PR. If you used AI tooling, disclose it rather than hiding it. And be able to explain every line you submit.

Who owns code an AI wrote? That question is going to sit unresolved at the center of open source for years. GCC is simply the first project to pick it up and take it seriously.