Split View: GCC의 AI 정책과 오픈소스의 선택 — 15줄이라는 경계선은 무엇을 지키려는 것인가

GCC's AI Policy and Open Source's Choice — What Is the 15-Line Boundary Actually Protecting

• Introduction — July 29, and a Line Drawn at 15 Lines
• What the Policy Actually Requires — and What It Doesn't Prohibit
• Why 15 Lines, of All Things — Copyright Assignment, the DCO, and a Two-Pronged Risk
• Where Other Projects Have Drawn Their Line
• What Actually Changes for a Contributor
• Both Sides of This Debate
• Conclusion — This Policy Is About Provenance, Not Code Quality
• References

Introduction — July 29, and a Line Drawn at 15 Lines

On July 29, 2026, David Edelsohn posted an AI policy announcement to the GCC mailing list. It states that the steering committee adopted, as-is, the recommendations of the AI Policy Working Group led by Jonathan Wakely. The working group included Carlos O'Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp, and Arthur Cohen.

The policy text lives at gcc.gnu.org/ai-policy.html, and cut to one sentence, it reads: legally significant contributions containing or derived from LLM-generated content will not be accepted. And the threshold for "legally significant" follows the GNU Maintainers guide, at roughly 15 lines.

The headlines mostly ran with "GCC bans AI code," but read the policy text itself and the picture is far more granular. Quite a lot isn't banned, something new is being required, and there's one exception — which happens to be test cases. This post looks at what the policy actually requires, the legal structure behind it, where other major projects have drawn their own lines, and what actually changes from a contributor's standpoint. I won't render a verdict on which side is right — both sets of arguments have real substance, and knowing exactly where they actually diverge is more useful than picking a winner.

What the Policy Actually Requires — and What It Doesn't Prohibit

Broken into items, the policy comes down to four things.

What's prohibited. Legally significant contributions that contain, or are derived from, content an LLM produced. It matters that the word "derived" is used broadly here — code a human touched up after a model wrote it still counts as derived.

What's allowed. Contributions that aren't legally significant — roughly, under 15 lines — can be accepted even if an LLM generated them, as long as they're clearly marked as such and meet the usual other requirements.

The exception. Maintainers may accept legally significant test cases even if an LLM generated all or part of them. The intent behind this exception is clear — a test case is an artifact a compiler itself can grade, so the human review burden is low, and from a copyright standpoint the scope for expression is usually narrow anyway. The same logic we saw earlier in large-scale migration cases that used a test suite as a machine judge applies here too.

A new obligation. Work that got help from AI must carry an Assisted-by: trailer in the commit message. And a human still has to understand the change, be able to answer questions about it, and approve its inclusion. Only a human can sign a DCO.

There's a point that's frequently misunderstood, and it's worth pinning down clearly. The policy does not restrict an individual's use of an LLM in itself. Using one for accessibility tools, research, analysis, finding and reporting bugs, or reviewing patches is explicitly allowed. There's exactly one condition — that the output doesn't get submitted to the project as-is. In other words, what this policy is trying to control isn't a developer's workflow — it's the provenance of the bytes that land in the repository.

Finally, the policy itself is provisional. The text states that it expects to change based on the community's or the broader GNU project's position, and that it will be reviewed no later than early 2027. And there's one line about tone attached — regardless of one's own position on LLMs, treat contributors with respect, and steer toward compliance rather than rejection. The fact that a sentence like this made it into a policy document tells you how sharp this debate got inside the community.

Why 15 Lines, of All Things — Copyright Assignment, the DCO, and a Two-Pronged Risk

The number 15 isn't something newly invented — it's the copyright-attribution threshold the GNU project has used for a long time. The working practice is that below that line, it's hard to call something creative expression protectable by copyright. The fact that the AI policy simply reused this existing line tells you something about the policy's nature — this isn't a quality policy. It's a copyright policy.

Knowing the background clarifies why GCC in particular is so conservative. Per the GCC contribution guide, the FSF still prefers copyright assignment for large contributions, and accepts, as an alternative, the DCO approach of attaching a Signed-off-by: tag to a commit. Copyright assignment exists for exactly one reason — to consolidate standing as a plaintiff in one place so a GPL violation can actually be enforced in court. Copyleft is a contract layered on top of copyright, so if copyright itself is shaky, the GPL wobbles right along with it.

This is where LLM output creates a problem that splits two ways. Either way it goes, it's bad news for a copyleft project.

Branch one — if there's no copyright. If pure machine output with no human authorship isn't recognized as copyrightable, the basis for attaching GPL conditions to that code weakens. That means the leverage to demand source disclosure from a redistributor disappears. (It's widely known background that the US Copyright Office has required human authorship, but I haven't verified the primary source directly in this post.)

Branch two — if there is copyright. Then the question becomes whose copyright it is. There's currently no way to rule out the possibility that it's derived from GPL or proprietary code that was in the training data, and a contributor becomes unable to honestly make the declaration the DCO requires — "I have the right to contribute this code." This is exactly the first reason Gentoo gives in its policy text — that using such material doesn't just risk infringing copyright, it can also weaken Gentoo's own copyleft protections.

To sum up, GCC's line isn't a judgment that "AI code is bad" — it's a judgment that "code with broken provenance can't go into a GPL repository." Which is why it's 15 lines, why test cases are the exception, and why personal use is unrestricted.

Where Other Projects Have Drawn Their Line

Facing the same problem, major projects have arrived at different answers. Here's what's confirmed.

The contrast between the Linux kernel and GCC illustrates this landscape best. The kernel's official documentation allows AI-assisted contributions but requires disclosure in the format Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2], while pinning down that only a human can attach Signed-off-by. In other words, the kernel solves the problem by anchoring accountability to a person, while GCC solves it by restricting what's allowed in at the source. The kernel's consensus rests on three principles Sasha Levin pushed through at the 2025 Maintainers Summit — human accountability is non-negotiable, purely machine-generated submissions without human review aren't welcome, and tool use must be disclosed.

Debian is still in progress. Five proposals are on the table for a general resolution whose discussion period opened on July 24, 2026, spanning a wide spectrum — from Matthias Geiger's outright ban, to Lucas Nussbaum's conditional-approval proposal, Ian Jackson's recommendation for restraint, Pierre-Elliott Bécue's approval-with-guidelines proposal, and Marc Haber's neutral option. One interesting design choice is that the scope is limited to Debian's own work and doesn't extend to upstream — a distribution that has to package the Linux kernel can hardly regulate the kernel's own AI policy.

I could not confirm anything about Qt. I found no explicit clause on AI-generated code in Qt's contribution guidelines as of this writing. I left it out of the table above for lack of grounds to place it alongside the other projects.

Looking at the overall landscape in numbers, GCC's side is the minority. Per a study by Andre Hora and Romain Robbes that surveyed GitHub's top 1,000 starred repositories, of the 118 with an AI policy, 78 percent allowed AI-assisted contributions (51 percent explicitly welcomed it, 27 percent discouraged but allowed it), and 22 percent explicitly required restraint. 51 percent required disclosure, and 74 percent mandated human involvement.

What Actually Changes for a Contributor

Translated into practice, the policy document comes down to this.

If you're sending a patch to GCC, for code or documentation of 15 lines or more, you can't write it by touching up model output. This isn't a matter of "just make it undetectable" — it's a matter of the honesty of your DCO signature. Conversely, there's nothing wrong with using a model to understand code, to find bugs, or to review someone else's patch. Test cases can be accepted at a maintainer's discretion, so it's worth asking ahead of time.

# GCC: if a human-written patch got assistance from an AI tool
Signed-off-by: Your Name <your@email>
Assisted-by: <tool and model name>

# Linux kernel: the format is specified explicitly
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Signed-off-by: Your Name <your@email>

If you contribute to multiple projects, account for the fact that the trailer differs by project. Assisted-by: is effectively converging into a de facto standard, but its format and meaning aren't unified yet. In the kernel, this trailer isn't a normative approval — it's closer to a forensic device for later tracing per-model bug clusters. The same tag serves a different purpose depending on the project.

One gray area remains. Where does an IDE's autocomplete fall? A single-line completion doesn't cross the 15-line threshold, but how do you count a result built from dozens of accepted completions over one session? No project's policy gives a clean answer to this. In practice, the only self-check that actually works is "can I explain this code from scratch, can I answer a reviewer's questions about it." As it happens, that's exactly what GCC's policy explicitly requires too.

Both Sides of This Debate

Without landing on a verdict, here's where the actual divide lies.

The case for restriction. Copyleft stands on copyright, and code with unclear provenance erodes that foundation. Once irreversible contamination enters a codebase built up over 30-plus years, there's no way to filter it out later. And the review burden is real — the cost of catching a plausible-but-wrong patch falls on the maintainer, and curl putting the phrase "contributions that can't justify the review time" into its policy is evidence of that burden. Of the three reasons Gentoo gives (copyright, quality, ethics), the first two are hard to argue with from a project-operations standpoint.

The case for permission. First, unenforceability. There's no reliable way to determine whether submitted code was made with AI, so a ban only filters out honest contributors while letting dishonest ones straight through. Second, ambiguity of definition. Read "derived" broadly, and the line blurs between a Stack Overflow answer found by search and API usage a model told you about. Third, accessibility — the fact that GCC's policy explicitly allows accessibility tools shows this objection was actually raised. Fourth, upstream is already using it. Debian scoping itself to its own work is a design that acknowledges this reality.

There's also a point the two camps actually agree on. That a human is accountable. That tool use is disclosed. That machine submissions without human review aren't accepted. The kernel's three principles and GCC's requirements are, in effect, the same thing at this point. The difference isn't the principle — it's where the threshold sits. The kernel puts it at the human signature; GCC puts it at the code's provenance.

As I see it, the real variable behind this difference is a project's legal structure. A project that maintains an enforcement mechanism like FSF copyright assignment, and a project that runs purely on the DCO, carry the same risk differently. So it's more useful to ask which structure your own project falls under than to ask who's right.

Conclusion — This Policy Is About Provenance, Not Code Quality

Cut to three lines:

• GCC's line is 15 lines, and the basis for it isn't the quality of AI code — it's that enforcing the GPL requires unbroken provenance. Which is why test cases are exempt, personal use is unrestricted, and a commit trailer is now required.
• The landscape is split. The kernel and curl allow it on condition of disclosure; GCC, Gentoo, NetBSD, and QEMU restrict it; Debian is voting on five proposals. Among the top 1,000 repositories, permission is the majority position.
• What the two camps agree on is human accountability, tool disclosure, and rejecting unreviewed submissions. What splits them is where the threshold sits, and that position is set by a project's legal structure.

The most practical thing a contributor can do right now isn't memorizing policy documents. It's staying in a state where you can explain the patch you're sending, start to finish. Whatever a project's policy says, in the end, it's just phrasing that one thing differently.

References

• GCC AI Policy Announcement — original mailing list post (2026-07-29)
• GCC AI policy — policy text
• GCC Contributing — copyright assignment and DCO requirements
• LWN — GCC steering committee announces AI policy
• Phoronix — GCC To Decline Any Significant Contributions Made Via AI/LLMs
• Linux Kernel — AI Coding Assistants documentation
• Debian — General Resolution: LLM usage in Debian (in progress)
• Gentoo Council — AI policy (2024-04-14)
• melissawm/open-source-ai-contribution-policies — a collection of per-project policies
• Hora & Robbes — AI Policy, Disclosure, and Human in the Loop (arXiv, 2026-07-13)