GCC steering committee announces AI policy
Mirrored from Hacker News — AI on Front Page for archival readability. Support the source by reading on the original site.
The GCC steering committee has announced that it has accepted an AI contributions policy recommended by the GCC AI policy working group.
The policy, in part, states that the project will decline any
"legally significant contributions which include LLM-generated
content or are derived from LLM-generated content
". It uses the definition
of "legally significant" from the GNU Project maintainer guidelines,
which holds that the threshold is "around 15 lines of code and/or
text
" to qualify as significant for copyright purposes. GCC
maintainers may, however, choose to accept legally significant test
cases that are generated by an LLM.
The policy does not forbid use of LLMs for research, analysis, bug discovery and reporting, patch review, etc. as long as the output is not included in contributions. The committee says that it expects the policy will evolve and will be revisited periodically.
Rules
Posted Jul 29, 2026 22:56 UTC (Wed) by pizza (subscriber, #46) [Link] (12 responses)
Of _course "industry sees nothing wrong with it" -- They will gladly fire every single worker that they think they can replace with a machine. Especially when said machine is still priced well below cost. Make no mistake, this is their ultimate goal.
Why is anyone not surprised that some folks are not enthusiastically building their own gallows?
"The true purpose of AI is to allow wealth to access skill without allowing skill to access wealth."
Rules
Posted Jul 29, 2026 23:31 UTC (Wed) by bluca (subscriber, #118303) [Link] (11 responses)
Rules
Posted Jul 29, 2026 23:38 UTC (Wed) by alx.manpages (subscriber, #145117) [Link] (10 responses)
If *you*, and possibly a reduced number of people, would willingly break the rules, that's up to you. But please don't insult everybody else.
There are people that don't want to do anything with AI.
And there are people that they wish they could, but respect the maintainers of the project, and thus avoid using it for the project.
Rules
Posted Jul 30, 2026 0:38 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (9 responses)
Fact is, the way people work, no-AI policies will produce covert AI use. You may not like it, but it's true, because it's human nature. It will continue to be human nature even if you accuse people who notice why people are bad of being bad themselves. "Reality is what's still there when you close your eyes".
Since we're exchange Spanish wisdom, I'd encourage you to read what Cervantes had to say about noble self-deception.
Rules
Posted Jul 30, 2026 1:32 UTC (Thu) by pizza (subscriber, #46) [Link]
This isn't about the choices/actions of "everyone else", it's about the choices and actions *you* make for yourself. To a lesser extent, it's about sorts of folks you choose to voluntarily associate with.
Sure, some folks lie, cheat and steal. Does that mean we all should enthusiastically emulate them?
Rules
Posted Jul 30, 2026 2:06 UTC (Thu) by dskoll (subscriber, #1630) [Link] (7 responses)
no-AI policies will produce covert AI use
I seriously doubt that. I think it's much more likely that people who want to use AI just won't contribute to projects with no-AI policies.
And as I wrote elsewhere... if someone does use AI covertly, it's extremely likely they'll be found out, blocked from the project, and that their reputation will suffer. This is the enforcement mechanism, just like a speeding ticket doesn't prevent speeding before the fact, but it tends to deter it after the fact.
Rules
Posted Jul 30, 2026 4:32 UTC (Thu) by quotemstr (subscriber, #45331) [Link] (2 responses)
> extremely likely they'll be found out,
Why do you believe these things to be true? Is it that you can tell something is AI slop by looking at it? What about non-slop AI outputs? You see the detection bias here, do you not?
Rules
Posted Jul 30, 2026 9:47 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]
> > extremely likely they'll be found out,
> Why do you believe these things to be true? Is it that you can tell something is AI slop by looking at it?
Yes, I've been able to tell when contributors came with AI-derived contributions quite consistently.
Since the policy had been there for a short time, and they weren't regular contributors, I assumed good faith and told them about it, and they admitted it, so it was all good. Some of them decided to not contribute to the project; others rewrote the patches from scratch, without AI slop.
For non-trivial contributions, it's easy to tell when a non-regular contributor has used AI. It tends to make fundamental mistakes 2 lines away from having the same thing done perfectly, just too frequently. There's almost always (at least) a line of code that screams "AI".
For trivial contributions, it's less easy to tell, but it doesn't matter that much.
> What about non-slop AI outputs? You see the detection bias here, do you not?
I don't believe "non-slop AI outputs" exist at all. I haven't seen it. Whenever that exists, I'll think what to do about it.
But in any case, liars are likely to be one-time contributors. Regular contributors have a reputation, and the risk of losing it if it is found that AI was used, should be motivation enough to not use it at all. Even if the contributor is careful to check all the output to make sure it's not slop, it might make a mistake eventually, and uncover the fact that it's using AI. That would be terrible for the contributor.
One-time contributors who don't yet have a reputation to care about might be more prone to lying, but in general, maintainers are more skeptic of such contributions, precisely because there's no established trust.
Rules
Posted Jul 30, 2026 14:28 UTC (Thu) by dskoll (subscriber, #1630) [Link]
No, they may not be found out on the basis of the code they write. But if they're asked questions about the code and they show they don't understand it, or it somehow slips out they've used AI, they'll be found out.
In my experience, people who deliberately break rules are not the sharpest knives in the drawer, and they eventually slip up and get found out.
Rules
Posted Jul 30, 2026 12:49 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (3 responses)
Probably that you haven't received enough ai-generated security reports then, otherwise you'd see that for a lot of such reporters, reputation is totally out of the equation, they're using randomly generated names as senders, and they don't care. There's a growing part of the population who has a very different perception of the one some of the older ones among us had. They're used to just create throw-away accounts everywhere, they don't even reuse them between two visits. They just live the instant and take the shortest path to get something done. If they need to create a discord account to report a bug, no worries, they click somewhere and a new e-mail address and account are created for this purpose, they report the bug and disappear. They've done their duty and that suffices.
They will absolutely not care about being blocked, reputation nor whatever. They will not even read the rules that say "no AI contributions". They'll just adapt existing code to their needs using AI because that's how they work, then they will submit the patch hoping that someone takes it to relieve them from having to maintain it. If it's accepted, fine. If not, they won't care either. Anyway the week after they'll already be on something else.
IMHO the real issue with AI contributions is the responsibility: who will respond to future bug reports? Such rules could be helpful in keeping such ephemeral contributors away, but it might hurt serious ones working in good faith.
Rules
Posted Jul 30, 2026 13:00 UTC (Thu) by pizza (subscriber, #46) [Link]
Trying to suss out the 0.1% of "good faith" in a sea of slop is not worth the effort.
"Serious ones working in good faith" are only slightly more common than unicorns and honest politicians.
Rules
Posted Jul 30, 2026 13:14 UTC (Thu) by alx.manpages (subscriber, #145117) [Link]
If that user really cares about the bug they found (most likely, because it affects them), they'll do something about it. Otherwise, if it's not interesting for them, then the maintainers would do well just ignoring the slop.
In any case, it's often easy to see that they used AI. Unless it's a trivial one-liner, in which it isn't as important (and GCC allows, it, FWIW).
Dealing with a contributor such as those you described is something that is not interesting for a project like GCC. Contributors should be prepared to maintain their code, if bugs are found in it. I think this might act as a good filter against such contributions, as a side effect.
Rules
Posted Jul 31, 2026 0:13 UTC (Fri) by sionescu (subscriber, #59410) [Link]
Rules
Posted Jul 29, 2026 22:57 UTC (Wed) by dskoll (subscriber, #1630) [Link] (21 responses)
If someone lies about contributions to a free software project, they will most likely eventually be found out and then blocked from further contributions.
AI is here to stay, sure. But so is Microsoft Windows. I don't use Microsoft Windows and I don't use AI. I don't accept patches to my hobby projects to port them to Windows, and I don't accept AI-generated contributions either.
What do people pushing expect to accomplish?
I can't speak for the GCC developers, but what I expect to accomplish is to prevent AI-generated contributions from making their way into my projects. I have my own reasons for this, which you are free to disagree with... but the project owner gets to make the rules.
Rules
Posted Jul 30, 2026 13:27 UTC (Thu) by bluca (subscriber, #118303) [Link] (20 responses)
That's a naive and outdated view of how these tools work. With models at the level of Opus 4.8 or GPT 5.5 and newer in the hand of a competent programmer the result is simply indistinguishable. So much so that in systemd we simply scrapped the requirement to annotate commits with "Co-developed-by" a month ago or so, as it became completely pointless (while giving the usual shits-for-brains handy targets to abuse and harass).
There are only good PRs or bad PRs, and the tools used to write them are now completely orthogonal to that. A bad PR is a bad PR, regardless of whether it is artisanal, organic, free-range and grass-fed or not. And nobody can tell the difference in good PRs. That's why these kind of rules are silly and pointless.
Enough
Posted Jul 30, 2026 13:54 UTC (Thu) by jzb (editor, #7867) [Link] (2 responses)
Enough
Posted Jul 30, 2026 14:01 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)
Enough
Posted Jul 30, 2026 14:04 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
I presume that using "naive" and "outdated" to describe the idea that AI outputs are necessarily low quality is fine, because these views are, in fact, naive and outdated. systemd has the right policy.
Rules
Posted Jul 30, 2026 14:30 UTC (Thu) by dskoll (subscriber, #1630) [Link] (16 responses)
That's a naive and outdated view of how these tools work
I never said they'd be found out because it would be obvious from the code. But in a social environment, it's hard to maintain a lie for a long time. They'd be found out (for example) if they're questioned about the code and show they don't really understand it, or they somehow let slip they used AI, or whatever. They are likely to be discovered by non-technical means.
Rules
Posted Jul 30, 2026 14:39 UTC (Thu) by bluca (subscriber, #118303) [Link] (12 responses)
Why wouldn't a competent programmer understand the code they are submitting, just because it was written with the help of an LLM, in general?
Also it certainly happened to me, and I bet to most people working on complex projects too, to not fully understand the code I manually wrote, because of many layers of abstractions, or unknown interactions, or whatever.
> they somehow let slip they used AI
Well, sure, if they tell you, then it's easy ;-)
Rules
Posted Jul 30, 2026 14:50 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)
The presumption of the submitter being "a competent programmer" relies on facts not in evidence.
Rules
Posted Jul 30, 2026 15:17 UTC (Thu) by bluca (subscriber, #118303) [Link] (3 responses)
Rules
Posted Jul 30, 2026 15:50 UTC (Thu) by Klaasjan (subscriber, #4951) [Link] (2 responses)
Rules
Posted Jul 30, 2026 16:01 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)
Rules
Posted Jul 31, 2026 2:20 UTC (Fri) by cypherpunks2 (guest, #152408) [Link]
Rules
Posted Jul 30, 2026 15:15 UTC (Thu) by dskoll (subscriber, #1630) [Link] (6 responses)
Why wouldn't a competent programmer understand the code they are submitting, just because it was written with the help of an LLM, in general?
Because they didn't write it? If someone asks "Why did you do it this way; can you explain the reasoning behind the approach?" I suspect it would be harder to answer if you didn't actually write the code.
But anyway, I am pretty confident a rule violation would eventually find out because rule-breakers are notoriously bad at hiding the fact that they have broken rules.
Also it certainly happened to me, and I bet to most people working on complex projects too, to not fully understand the code I manually wrote
Oh sure. That happens to me a lot. But only with code I wrote a long time ago and haven't looked at for a while. It's never happened to me that I've written code and then not understood it a couple of days later.
Rules
Posted Jul 30, 2026 15:23 UTC (Thu) by bluca (subscriber, #118303) [Link] (3 responses)
You "suspect" it or you "know" it? Have you actually done any of this? My experience is completely difference for example, so I'm not sure how you can make such confident generalisations
> It's never happened to me that I've written code and then not understood it a couple of days later.
Really? You never found out that some internal API you use has, nested several layers deep, a side effect that you didn't notice? I am pretty sure things like these have happened to most people working on non-trivial projects at least a few times. Otherwise how would bugs get introduced?
Rules
Posted Jul 30, 2026 15:30 UTC (Thu) by dskoll (subscriber, #1630) [Link] (2 responses)
I suspect. I have run a bunch of software projects, including owning a software company for 19 years, but this was pre-AI. And I could almost always tell when someone was doing something shady (in terms of any violation of company rules, not specifically software development.) People have tells.
But anyway. A project is free to set its own rules. If you don't agree with them, don't contribute to the project. If you break the rules anyway, then you're acting a bit sociopathically and we can't 100% protect ourselves from sociopaths. All we can do is our best, and the fact that we can't protect ourselves 100% from rule-breakers doesn't mean we shouldn't set rules.
Really? You never found out that some internal API you use has, nested several layers deep, a side effect that you didn't notice?
That's normal bug-hunting. It's not "not understanding the code". I've never been in a position where I've written code and then been unable to explain why I wrote it a certain way or why I picked the algorithms and data structures that I did.
Rules
Posted Jul 30, 2026 15:57 UTC (Thu) by bluca (subscriber, #118303) [Link] (1 responses)
So given you don't have such first-hand experience, don't you feel a bit weird telling people who do have it, how their experience actually is?
> That's normal bug-hunting. It's not "not understanding the code".
I disagree, I would definitely qualify that as "understanding the code". Which in a way, confirms that it does happen that you don't understand your code either, but you simply don't qualify it as "understanding", which is an easy way out I guess?
Rules
Posted Jul 30, 2026 16:18 UTC (Thu) by daroc (editor, #160859) [Link]
Understanding code
Posted Jul 30, 2026 16:19 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (1 responses)
> Oh sure. That happens to me a lot. But only with code I wrote a long time ago and haven't looked at for a while. It's never happened to me that I've written code and then not understood it a couple of days later.
I'd say you're lucky; it does happen to me. Regularly. When you work on different projects and different areas in a project, some of your days are driven by bug handling, which force you to jump around between totally different topics. A few days ago I jumped from a case of missing or duplicate EOB block in a GZIP output stream, to a read-past-end in an HTTP cookie parser, then to a duplicate entry bug in a binary tree descent algo, and a bunch of other ones, all that the same day. It usually takes me several hours to days to enter certain topics at full speed. I put lots of comments to explain why it works like this, write lengthy commit messages, but we're all humans and when you revisit this 2 days later after a coworker says "your patch broke for me here" and you've done 10 different topics since you wrote it, I can assure you that sometimes you already just don't remember the details anymore. And sadly, you discover that your comments were insufficient so it hurts again to have to dive into it again. Sometimes it happens to me to mix up multiple issues handled at the same time.
I found that AI bug reports are causing me the exact same pain, and they take me a huge amount of time to appropriate, because I just want to be responsible of the resulting fixes exactly for the reason above (i.e. revisiting the patch in a few days/weeks/months must not hurt as much). So it can sometimes take me almost as much time to review, understand and adapt an AI-produced fix as it would have to do it by myself. However it allows to better group the topics and switch less between topics (i.e. perform small series on the same topic). That is already an appreciable saving sometimes.
Understanding code
Posted Jul 30, 2026 16:32 UTC (Thu) by dskoll (subscriber, #1630) [Link]
I guess I am lucky in that I've tended to work on one project at a time rather than flitting amongst different ones. I can definitely see how that would place a much higher cognitive load on you.
Rules
Posted Jul 30, 2026 17:54 UTC (Thu) by aigarius (guest, #7329) [Link] (2 responses)
In fact this one of the wonderful uses for AI - point it at any codebase and ask questions. I'we seen them point to very complex multi-threaded interactions across message queues and how exactly the code I wrote a year ago was designed to work. Something I have since forgotten, but now remember that it was indeed written like this *exactly* because of that interaction (without it ever been mentioned in comments or covered by tests).
Rules
Posted Jul 30, 2026 18:48 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)
You're right; I have no experience working with recent AI models because, as a matter of personal ethics, I do not knowingly use AI at all.
I suspect that use of an AI model will reveal itself in back-and-forth questioning, though. But maybe I'm wrong.
Even so, the GCC project has the right to set its rules, and I would hope that people would respect them rather than knowingly violate them and then lie about it.
Rules
Posted Jul 30, 2026 19:15 UTC (Thu) by khim (subscriber, #9252) [Link]
They reveal themselves very easily because they don't have a world model. If you ask model once — you get plausibly sounding answers, but if you ask it two or more times then it start inventing different answers.
One of the most notoriously hard thing for the models to do is resist pressure: tell it that you think something is not needed or can be changed to something different — and it would incorporate your asks without thinking if that's good or sane thing to do.
And, again, goal is not to catch one-time use of AI (one individual patch can always be redone) but to catch systematic use of AI on at least one example. Then you ban such user forever and problem is solved.
Compiler crashes on LLM Code?
Posted Jul 30, 2026 7:12 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)
Compiler crashes on LLM Code?
Posted Jul 30, 2026 8:39 UTC (Thu) by hvd (guest, #128680) [Link]
> The policy does not forbid use of LLMs for research, analysis, bug discovery and reporting, patch review, etc. as long as the output is not included in contributions.
This would be an example of using an LLM for bug discovery.
Presumably ...
Posted Jul 30, 2026 14:55 UTC (Thu) by lmb (subscriber, #39048) [Link] (3 responses)
Are LLM outputs copyrightable? Are they the preferred form? Hmmm. I'd not openly accept legally significant LLM contributions at this point either.
This seems a fairly sensible policy.
I'd have expected something much harsher given all the, uh, ethics or lack thereof in the supplychain and the impact on Free or even just Open Source software. Rarely has the FSF been this reasonable.
Presumably ...
Posted Jul 30, 2026 15:19 UTC (Thu) by bluca (subscriber, #118303) [Link] (2 responses)
Yes, there is no indication that suggests otherwise in the context of contributing code to an existing project
> Are they the preferred form?
Yes, code is what matters
Presumably ...
Posted Jul 30, 2026 20:49 UTC (Thu) by neilbrown (subscriber, #359) [Link] (1 responses)
C code? Assembler code? Object code? Yacc code? Prompt code? Design notes?
Where do you draw the line? Where do I?
Presumably ...
Posted Jul 30, 2026 21:09 UTC (Thu) by mb (subscriber, #50428) [Link]
This is completely different from AI generated code, though. There's no obfuscation happening. There's no compiler-like down-conversion happening. Quite contrary. The generated code typically contains more information than the prompt that generated it.
The source code (which may include prompts and AI instructions in md files!) is the primary and preferred form for modification, no matter if you modify it by hand or by tool (AI).
legally significant
Posted Jul 30, 2026 16:51 UTC (Thu) by GNUtoo (guest, #61279) [Link]
Just for information, the "legally significant" section has been written at a time before LLMs existed, and it is meant to enforce copyleft as the goal is to understand when it's worth to assign copyright to the FSF or not. This interpretation is documented in the gnu-prog-discuss mailing list which is unfortunately only for GNU maintainers.
With LLMs, the generated code/data could come from free software projects under incompatible licenses so we have 0 guarantee that the result is legal if it is under 15 lines. According to what I understood from conservancy, having leaked code is also possible but less likely as these usually get taken down so they are less likely to end up in training data.
Guix was also working on a policy about LLMs, and during the first proposition, this has pushed Guix to not rely on the "legally signficant" as a basis for determining weather or not to accept a contribution made with LLMs.
Instead it used another test which I copied verbatim below:
2. **Contribution acceptance.** Changes produced by genAI or deriving
from genAI output that can be viewed as “creative”, and [could thus
fall under
copyright](https://en.wikipedia.org/wiki/Threshold_of_originality),
MUST be rejected to avoid any risk of copyright infringement.
Conversely, when reviewers consider a genAI-produced change
“non-creative”, and thus do not fall under copyright, the change MAY be
accepted. Examples of non-creative changes include mechanical
conversions of package metadata from other repositories similar to
those made by `guix import`, mechanical changes similar to those
made by `guix refresh` or `guix style`, and changes that merely
follow suggestions made by `guix lint`.
The text of the proposal (which didn't pass) is available in the commit a0aca85d5079d740f953794f63722d76611aece9 of https://codeberg.org/guix/guix-consensus-documents/
This proposal has then led GNU to consider adding something like this in the LLM policy it is working on and which would have been compatible with the first policy proposed in Guix. And I also got the information that this looked legally sound (I'm not a lawyer so I asked people who had access to one).
Also note that until the GNU policy is in place, there is a moratorium by GNU on the inclusion of code/data generated by LLMs, but GNU projects tend to not respect that, though here and in the case of binutils as well, it can also led to underestimate legal risks (there are always legal risks, the question is rather how much we are willing to take).
Denis.
Why all the fuss?
Posted Jul 31, 2026 1:04 UTC (Fri) by Ichthyostega (subscriber, #177297) [Link]
It is really surprising why some people get so agitated regarding the use of AI. It seems to me, that the perception of "AI" in itself touches onto hidden and subconscious religious tropes.
That being said, the point in question here is perfectly clear, once you apply rational reasoning:
You can contribute to an Open Source project under the terms of a License. Such a license is based on some legal mechanism to work and achieve its effect.
The purpose of the GPL (without wanting to judge that here) is to ensure that everyone downstream has some fundamental rights. And this purpose is achieved by a chain of contributions, that are each based on copyright.
If you use an AI tool to learn, reason, challenge your own arguments, and even review your code, this is fine, as long as you created the code. As long as it was you, as a person, using your insight, your knowledge, and, ultimately your judgement. This is something you can claim a copyright for.
However, if someone just vibecodes a load of stuff they don’t understand and feeds that as a contribution into a GPLed project, the fundamental mechanism breaks down that allowed them in the first place even to contribute.
Please note that this is not a matter of "yes" or "no", but rather a matter of "we can't know for sure": we can not know if there even was a act of creation by a person, and furthermore we can not know who the author was. Thus it simply does not clear the bar of a contribution that would be allowed by the license.
Legal code is different than source code. It is based on an attitude, and on a conscious, responsible action by a person. And those matters stand until / unless challenged. If someone challenges the contributed code and shows that it is structurally equivalent to some other code that is covered by some third-party copyright, then the outcome boils down to who can present the better argument and convince a court.
AI generated contributions and copyright
Posted Jul 31, 2026 2:37 UTC (Fri) by rswail (subscriber, #130113) [Link] (1 responses)
Given that the GPL is entirely dependent on copyright to be enforceable, the fact that AI contributions are not copyrightable is something that is going to bite someone big very soon.
The US copyright office has released a public report about the fact that copyright requires a human author.
They compare the different cases of the equivalent of "prompt engineering", of a client that provides an architect guidance on what they want, but the architect holds the copyright in the actual drawings and structure, even if they use CAD tools.
Totally AI generated code as a result of a prompt is not going to be able to be defended under copyright IPRs.
So GCC are literally ensuring that there is a human in the loop to ensure that the GPL will stay enforceable.
AI generated contributions and copyright
Posted Jul 31, 2026 2:48 UTC (Fri) by dskoll (subscriber, #1630) [Link]
The situation in the USA is actually pretty messy.
From Page 27 of that document:
Similarly, the inclusion of elements of AI-generated content in a larger human-authored work does not affect the copyrightability of the larger human-authored work as a whole.For example, a film that includes AI-generated special effects or background artwork is copyrightable, even if the AI effects and artwork separately are not.
But given that the situation is so messy, and the rules vary from place to place and might change over time, I think the GCC steering committee is being prudent.
More from Hacker News — AI on Front Page
Discussion (0)
Sign in to join the discussion. Free account, 30 seconds — email code or GitHub.
Sign in →No comments yet. Sign in and be the first to say something.