What was decided
GCC is the compiler suite that turns source code written in C, C++ and other languages into something a machine can run. That project has now drawn an official line around AI-generated code.
The steering committee accepted the working group's proposal
On July 29, 2026, an announcement to the GCC mailing list confirmed that the GCC Steering Committee had accepted the policy recommended by the GCC AI Policy Working Group. The announcement came from David Edelsohn.
The working group was led by Jonathan Wakely, with Carlos O'Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp and Arthur Cohen named as members. The policy is expected to continue evolving, and will be revisited periodically.
The GCC Steering Committee has accepted the recommended policy of the GCC AI Policy Working Group. The policy is described in the following document preview / pull request in Forge, which will be committed to the GCC website: / We expect the policy to continue to evolve and will revisit it periodically. We wish to thank Jonathan Wakely for his leadership of the working group and the members of the working group: Carlos O'Donell, Sudakshina Das, Jason Merrill, Joel Sherrill, Sam James, Robin Dapp, and Arthur Cohen. — from the announcement of the committee's acceptance and the working group's membership
The line is drawn at "legally significant"
The policy turns on a single sentence. For the time being, GCC declines any legally significant contribution that includes, or is derived from, LLM-generated content.
Conversely, where a contribution is not legally significant, maintainers are free to accept LLM-generated work. Two conditions attach: it must meet the usual prerequisites for any contribution, and the contribution must be clearly marked as AI-generated.
So structurally this is not a blanket ban on AI-generated code. It is a design where acceptance stops once the contribution grows large enough to carry copyright weight.
For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content. The GCC maintainers are free to accept legally insignificant contributions generated by an LLM as long as they meet the usual prerequisites for any contribution and the contribution is clearly marked. — from the statement of what is declined and the conditions under which contributions may be accepted
Test cases are the one exception
One carve-out is written in. Contributions to test cases may be accepted by maintainers even at legally significant scale, whether generated in whole or in part by an LLM.
A second exclusion is spelled out as well: code that does not primarily belong to the GCC project—code imported from other projects for convenience or to satisfy prerequisites, with libsanitizer given as the example—falls outside the policy.
As an exception, the GCC maintainers are free to accept legally significant contributions to test cases, generated in whole or in part by an LLM. / This policy does not apply to code which does not primarily belong to the GCC project, but is imported from other projects for convenience or to satisfy prerequisites (e.g. libsanitizer). — from the test-case exception and the exclusion for imported code
Where "15 lines" came from
"AI-generated code of 15 lines or more is rejected" is the summary you will see most often. The direction is right, but the number originates in a different document.
The policy text never says 15 lines
Read the GCC AI policy end to end and there is no reference to a line count anywhere. The only criterion written down for what may or may not be accepted is the phrase "legally significant."
In other words, the line count is not a standard GCC invented. GCC carried over an existing GNU copyright standard and layered one condition on top of it: if it came from an LLM, it is not accepted. Miss that, and you end up believing GCC created a bespoke 15-line rule.
For the time being, the GNU Compiler Collection (GCC) policy is to decline any legally significant contributions which include LLM-generated content or are derived from LLM-generated content. — evidence that the criterion is expressed as "legally significant" rather than as a line count
GNU's copyright threshold is where the number lives
The source is GNU's guidance for maintainers of GNU software. It states that if a person contributes more than around 15 lines of code and/or text that is legally significant for copyright purposes, copyright papers are needed for that contribution. It goes on: a change of just a few lines—fewer than 15 or so—is not legally significant for copyright.
A worked example follows. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places.
If a person contributes more than around 15 lines of code and/or text that is legally significant for copyright purposes, we need copyright papers for that contribution, as described above. A change of just a few lines (less than 15 or so) is not legally significant for copyright. A regular series of repeated changes, such as renaming a symbol, is not legally significant even if the symbol has to be renamed in many places. — from the definition of the 15-line threshold and the treatment of repeated mechanical changes
Small changes still add up
There is an easily missed proviso in that same guidance: a series of minor changes by the same person can add up to a significant contribution.
What counts is the person's total contribution, and it is irrelevant which parts of it were contributed when. The guidance even prescribes the procedure: when recording a small patch, first search for previous changes by the same person and check whether past plus present now amounts to something legally significant.
Applied to GCC's policy, this means you cannot read it as "keep every patch under 15 lines and you can keep feeding in AI-generated code." Stack up enough small LLM-generated patches from one person and the total eventually crosses into legally significant territory.
Working out where your own cumulative changes stand is a matter of reading diffs. When you want to know how many lines a patch actually moves, a diff view is the fastest way there.
…Keep in mind, however, that a series of minor changes by the same person can add up to a significant contribution. What counts is the total contribution of the person; it is irrelevant which parts of it were contributed when. — from the statement that a series of small changes by one person can accumulate into a significant contribution
The process, and what falls outside it
The policy carries requirements beyond line counts. In day-to-day practice these are the ones that bite.
Assisted-by is for machines; Signed-off-by is for humans
Under transparency and accountability, the commit message for any contribution containing LLM-generated content must include an "Assisted-by:" tag.
Responsibility is then placed squarely on the human side. Every contribution must be submitted by a human who understands the changes and is prepared to answer questions about them. The decision to include a contribution in the project must also be made by a human.
Only a human may provide the Signed-off-by: tag certifying the Developer Certificate of Origin (DCO). And a final line states plainly that an LLM may not commit code to the project repository.
The commit message for any contribution of LLM-generated content must include an “Assisted-by:” tag. / All contributions must be submitted by a human who understands the changes and is prepared to answer questions about them. The decision to include the contribution in the project must also be made by a human. Only a human may provide the “Signed-off-by:” tag certifying the Developer Certificate of Origin (DCO). An LLM may not commit code to the project repository. — from the commit tag requirements and the responsibilities assigned to humans
Research, review support and debugging are out of scope
The exclusions are drawn broadly. Personal use comes first: screen readers, text-to-speech, direct translation, spelling and grammar assistance—tools that let contributors work with their own computing devices—are outside the policy, provided the contributor verifies the output.
Then there is use in development work itself. Research, analysis, bug discovery and reporting, patch review, and debugging are excluded as long as the output is not included in contributions to the project.
Two provisos ride along. On bug reports: output should not be sent verbatim without due consideration. On patch review: AI supports human review rather than replacing it. And if the output does end up in a contribution, the policy applies after all.
This policy does not apply to a contributor's other uses of AI including the use of these tools to enable them to work with their own computing devices e.g. screen readers, text-to-speech, direct translations, spelling or grammar assistance, where the contributor verifies the output of the tool. / This policy does not apply to a contributor's use of AI for the purposes of research, analysis, bug discovery and reporting (output should not be sent verbatim without due consideration), patch review (supporting human review, not replacing it) and debugging, so long as the output is not included in the contributions to the project. If the output is included in the contributions to the project then this policy would apply. — from the exclusions for personal use and for research, review support and debugging
A review by early 2027
None of this is fixed. The policy is expected to evolve with the community or as the overall GNU Project position is updated, and will be reviewed at the latest at the start of 2027. The document itself is published under CC0 1.0 Universal—a waiver of copyright that lets anyone use it freely—which makes it easy for other projects to build on.
The "Community First" section at the top is distinctive too. It acknowledges that there are strongly held and widely varying opinions regarding LLMs, and that everyone should be presumed to be contributing in good faith. Contributors who have not yet followed the policy are still welcome, and the project's job is to guide them.
This policy is expected to evolve with the community or as the overall GNU Project position is updated. At the latest the policy will be reviewed at the start of 2027. / …There are strongly held and widely varying opinions regarding large language models (LLMs) and everyone should be presumed to be contributing in good faith. We welcome all contributors to the community even if they have not yet followed our policies; we should guide such contributors on how to do so. — from the review timeline and the project's stance toward its contributors
In closing: copyright drew the line, not line count
Remembering this policy as "AI-generated code up to 15 lines" misses the point. What GCC imported is a copyright test, not a code-quality test. The policy says nothing whatsoever about whether LLM output is any good.
The policy text does not explain its reasoning, but placing the two documents side by side makes the shape visible. GNU has long required copyright papers for legally significant contributions. For code generated by an LLM, who is in a position to provide those papers? What is really at issue, as far as one can read it, is who can vouch for the rights in that code. That test cases are exempt makes sense on the same reading—little copyright weight attaches there.
In the same window, Google published a working example of AI built into Chrome's vulnerability fixing, where the final call on every fix stays with a human. The more real DeepSeek's coding-focused model and development with a local LLM on your own machine become, the more you need to settle who holds the rights and the responsibility before the code lands. GCC has published one answer to that question.
