OSS Can’t Detect AI Code. GCC Just Made That Its Policy.

On July 29, the GCC Steering Committee published its AI contribution policy after months of working group deliberation. The result: GCC will decline any “legally significant” LLM-generated contribution — meaning anything over roughly 15 lines of code. The threshold isn’t GCC’s invention; it comes from the GNU Project’s maintainer guidelines for copyright significance. That sourcing matters, because it tells you what problem GCC thinks it’s solving. They are solving a copyright problem. The problem worth solving is a quality problem.

Six months earlier, LLVM — the other major open-source compiler infrastructure, the one that compiles Rust, powers Clang, and underlies most of what Apple ships — adopted its own AI policy. LLVM’s approach is essentially the opposite: AI contributions are welcome, provided a human reads them before asking anyone else to, labels them, and takes full accountability. The framing the LLVM community used for what they were actually banning was “extractive contributions” — patches that shifted effort from the implementer to the reviewer without providing equivalent value. That framing is worth dwelling on. It names the actual cost. It asks a question reviewers can answer.

The Question GCC Asked

The 15-line number is not an engineering threshold. It is the line at which the FSF considers a change legally significant for copyright purposes — significant enough to require a copyright assignment or a Developer Certificate of Origin. At 14 lines, you don’t need one. At 16, you do. This is a legal accounting artifact, not a measure of whether code is correct, safe, or worth shipping.

GCC’s policy grounds itself in the copyright uncertainty around LLM output. If a language model generates code and that code lacks copyright protection — a question US copyright law has been wrestling with seriously since 2025, and has not yet settled — then including it in a GPL project creates a gap. The GPL depends on copyright to function: it grants the right to use, modify, and distribute, conditional on those same rights being passed downstream. Insert code that no copyright attaches to and the conditions can’t bind that portion. Legal scholars at Berkeley have begun articulating the paradox: if AI-generated code is truly uncopyrightable, including it in a GPL project doesn’t contaminate the copyright in the way GCC fears — it does something potentially more disruptive, inserting material that no license applies to into a project whose entire distribution logic depends on license compliance. GCC’s copyright concern is real. Their operationalization of it is a ban on provenance rather than a solution to quality.

The enforcement problem follows directly from that choice. GCC’s policy states that “merely editing or rewriting LLM-generated code doesn’t make it acceptable.” That is a meaningful rule in principle. In practice, there is no detection mechanism. Provenance, in July 2026, is already difficult to determine reliably. A frontier model fine-tuned on GCC’s own commit history — which is public, stretching back decades — would write patches matching the project’s ChangeLog conventions, comment style, and code idioms. A reviewer with no external context would not flag it. The policy that GCC announced on July 29 is enforced by contributor attestation — the same mechanism the Developer Certificate of Origin already provides, now with an additional clause. They have added a new attestation without adding a new verification mechanism for it.

Andrew Teylu, a contributor at Vector, expressed surprise in the mailing list thread the same day: he had expected GCC to be more accepting of generative AI assistance. He wasn’t advocating for change — just noting, publicly, that the restriction landed harder than he anticipated. He’s not alone in that read.

The Question LLVM Asked

LLVM’s policy came out of a specific problem. In late 2025, maintainers began seeing an uptick in what the community called “AI-driven nuisance contributions” — patches that had clearly been generated by a model, hadn’t been reviewed by the submitter, and were arriving in review queues as if they were ordinary pull requests. The maintainer cost was real: reading a patch, understanding it, identifying its flaws, explaining them. The submitter cost was near zero. That asymmetry is what LLVM named “extractive.”

The LLVM AI Tool Use Policy, published in January 2026, says: contributors must read and review all LLM-generated code before asking a maintainer to look at it. You are “always the author and fully accountable.” You must label the contribution with “Assisted-by:” in the commit message. You must be able to answer questions during review. The things LLVM actually bans are the specific behaviors where human judgment drops out entirely: automated agents acting in LLVM’s spaces without human approval, and AI assistance for “good first issue” bugs — which exist specifically to be learning experiences for new contributors, not efficiency shortcuts for existing ones. LLVM also retains the right to label non-compliant contributions as “extractive” and escalate persistent violations to moderation.

This is also an honor system. There is no AI detector enforcing the “Assisted-by:” trailer. But the question LLVM is asking — did a human take responsibility for this code? — is one maintainers can act on. A contributor who signs off on a bad patch can be held accountable. The feedback loop is intact. What GCC is asking — is any AI involved anywhere in this code’s lineage? — becomes unanswerable without technology that doesn’t exist and won’t exist as the models improve. LLVM’s framework survives model improvement. GCC’s doesn’t.

The Landscape Both Are Part Of

Codeberg voted on July 22 to ban repos where AI wrote most of the code. The vote was 358-144 — roughly 71 percent in favor — at their annual assembly, with about half the membership participating. The policy text explicitly covers human-reviewed AI output: reviewing the code doesn’t make it acceptable. Then Codeberg’s own documentation acknowledges the gap: no percentage threshold defines “mostly,” no detection methodology exists, and enforcement is complaint-driven, handled by volunteers already stretched across a large repository host. They passed the ban knowing this. The value of the norm was judged to exceed the limits of the enforcement.

Across the wider OSS ecosystem, more than 400 projects now have documented AI contribution policies. Roughly 80 are restrictive; about 40 are permissive with disclosure requirements. The permissive group includes CPython, Django, the Linux Kernel, NumPy, Kubernetes, and Apache Airflow — the infrastructure that runs most of what’s actually deployed on the internet. The restrictive group includes Alacritty, Zig, GNOME, Krita, Forgejo, and now GCC. These are significant projects. They are not the ones most servers depend on every hour of every day. The field is splitting, and the permissive side holds a disproportionate share of the world’s deployed infrastructure.

The split reflects a genuine value difference, not just a policy difference. Projects that lean restrictive tend to have strong craft identities — GCC contributors care deeply about what it means for a human to have written the compiler that compiles the world’s C. Projects that lean permissive tend to treat contributions instrumentally: does this code make the software better? If yes, the origin matters less than the quality. Both positions are coherent. Only one of them is enforceable.

What the 2027 Review Will Find

GCC’s policy explicitly commits to a review at the start of 2027. The working group, led by Jonathan Wakely, will convene again roughly six months from now. The question worth asking is what changes between now and then.

The models get better. Fine-tuning on GCC’s commit history is not a research project — it is a weekend effort for anyone with a modest GPU cluster and access to GCC’s decades of public commits. The resulting model writes patches in the GCC idiom: proper ChangeLog entries, GNU Coding Standards compliance, comment style matching the surrounding file. A maintainer reviewing such a patch without external context would not flag it as AI-generated. By Q1 2027, “I can tell this is AI-written” will be meaningfully less reliable than it is today.

At that point, GCC has two honest choices. They can decide that attestation is the mechanism — that contributors signing off on code is sufficient accountability, which is functionally the LLVM model. Or they can decide that human authorship is a matter of project identity that they will defend even as a non-enforceable declaration, and state that plainly. “We are a human-authored project as a matter of value, not because we can technically verify it” is a coherent position. It is a different argument from the copyright and provenance framing the current policy uses. The current policy implies that the ban is operative. By Q1 2027, it will be a statement of intent enforced by community norms and honor — exactly the DCO system they already have, with an extra clause.

The Phoronix coverage noted that the policy provides no specific rationale for why now. The timing probably reflects a threshold moment: AI coding agents have gotten good enough that the project started receiving patches that were high quality enough to pass review, written in part by AI, and the community decided that was worth drawing a line against before it became the default. That instinct is defensible. The line they drew — 15 lines, copyright grounds, provenance attestation — is the one that will be hardest to hold.

GCC’s working group did the project a genuine service by forcing this conversation before the question became inescapable. LLVM had the same conversation six months earlier, coming from the same concern — code quality degrading from unconsidered submissions — and landed on a framework built around accountability rather than detection. Quality is the thing a compiler project can measure: tests pass or they don’t, code review surfaces issues or it doesn’t, bugs either ship or they don’t. Provenance is the thing that becomes undetectable within the window GCC set for its own policy review. They chose the wrong axis. The code GCC ships in 2027 will be the same quality either way. The difference is which framework survives contact with a frontier model that has read every commit GCC ever made.

AI-generated editorial illustration · TemperatureZero · July 30, 2026