GCC steering committee announces AI policy
The GCC steering committee has announcedthat 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 definitionof "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.
---
to post comments
Rules
Posted Jul 29, 2026 22:18 UTC (Wed) by quotemstr (subscriber, #45331) \[Link\] (47 responses)
Unenforceable rules that punish honesty breed dishonesty and contempt for rules in general. Denying it is denying human nature, and the gods tend to punish the hubris of denying nature.
AI is here to stay. New programmers are brought up on it. Most of the industry sees nothing wrong with it. Do anti-LLM types expect to be vindicated in an orgy of copyright lawsuits that resets the industry back to 2022? What do people pushing expect to accomplish?
Rules
Posted Jul 29, 2026 22:56 UTC (Wed) by pizza (subscriber, #46) \[Link\] (15 responses)
\> Most of the industry sees nothing wrong with it.
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\] (14 responses)
Making up silly rules that nobody will follow won't do anything to stop capitalism behaving as it always had for the past 200 odd years. We do know what actually works: join a trade union and unionize the workplace.
Rules
Posted Jul 29, 2026 23:38 UTC (Wed) by alx.manpages (subscriber, #145117) \[Link\] (13 responses)
\nobody\? Are you accusing \everybody\ of being dishonest in this regard? We have a saying in Spanish: "cree el ladron que todos son de su condicion".
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\] (12 responses)
It's human nature. Are there saints out there? Sure, but you'd be foolish to act as if everyone were one. If you want to achieve your goals, you must model the world accurately so you can take actions that advance your goals. If you act according to an inaccurate model, your actions will not advance your goals and will likely make a fool of yourself.
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\]
\> It's human nature. Are there saints out there? Sure, but you'd be foolish to act as if everyone were one.
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\] (10 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\] (4 responses)
\> much more likely
\> 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\] (2 responses)
\> > much more likely
\> > 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 31, 2026 10:26 UTC (Fri) by adirat (subscriber, #86623) \[Link\] (1 responses)
\> 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.
Most people will stop contributing, regardless of AI use, because this is turning into a witch hunt.
Rules
Posted Jul 31, 2026 11:08 UTC (Fri) by pizza (subscriber, #46) \[Link\]
\> Most people will stop contributing, regardless of AI use, because this is turning into a witch hunt.
Please. "Most people" will never bother/care to contribute in the first place.
The goal here is not "ease of contribution above all else". If that's what you care about, then feel free to put your money where your mouth is and (1) allow full commit access to everyone+everything, and (2) daily drive the resultant slop.
If that's not acceptable/good enough/whatever, leading to additional rules (=\~ "some measure of quality") before accepting a random "contribution", congratulations, you prioritize something other than "ease of contribution". So why the objections to the rules that others come up with?
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\] (4 responses)
\> 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.
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\]
\> 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.
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 it's a serious problem, someone else will eventually rediscover it, and take it seriously.
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\] (1 responses)
I'm afraid we might have to resort to reputation-based filtering where all submissions from accounts (or email identities) younger than 5 years will be automatically rejected. That will have serious repercussions on training youngsters and will probably create a black market for identities, but on the short term it will reduce slop.
Rules
Posted Jul 31, 2026 7:53 UTC (Fri) by taladar (subscriber, #68407) \[Link\]
Requiring a 5 year account age is one way to kill the project but there are probably simpler ways if that is the goal.
Rules
Posted Jul 29, 2026 22:57 UTC (Wed) by dskoll (subscriber, #1630) \[Link\] (25 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\] (24 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.
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)
We've asked time and again for you to be civil in your comments. There is no need for such language, nor does it contribute to the conversation in a polite, respectful, or informative way. You can make your points without it, please do so in the future.
Enough
Posted Jul 30, 2026 14:01 UTC (Thu) by bluca (subscriber, #118303) \[Link\] (1 responses)
Uh? What language are you talking about exactly?
Enough
Posted Jul 30, 2026 14:04 UTC (Thu) by quotemstr (subscriber, #45331) \[Link\]
"Shit-for-brains" presumably, which seems to be an odd moderator objection because it's not singling out anyone in the thread.
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\] (20 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\] (16 responses)
\> if they're questioned about the code and show they don't really understand it
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\] (8 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?
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\] (7 responses)
Yeah of course, anybody who uses a tool you don't personally approve of is obviously not competent, how silly of me to forget such basic universal truths
Rules
Posted Jul 30, 2026 15:50 UTC (Thu) by Klaasjan (subscriber, #4951) \[Link\] (2 responses)
Dear Luca, sarcasm is not the preferred mode of discussion here at lwn, and the editors have repeatedly called you out on your communication style. I am pretty sure your well-informed opinions and messages would come across better if these were phrased in a more respectful way. Just a well-meant suggestion.
Rules
Posted Jul 30, 2026 16:01 UTC (Thu) by bluca (subscriber, #118303) \[Link\] (1 responses)
Did you miss the bit in the message I replied to where it openly called me, and many many others, "incompetent"? Do you think that's ok?
Rules
Posted Jul 31, 2026 2:20 UTC (Fri) by cypherpunks2 (guest, #152408) \[Link\]
I didn't read it as calling you incompetent. I read that as him implying that a person is not necessarily competent just because they seem to understand their LLM-generated code.
Rules
Posted Jul 31, 2026 11:38 UTC (Fri) by pizza (subscriber, #46) \[Link\] (3 responses)
\> Yeah of course, anybody who uses a tool you don't personally approve of is obviously not competent, how silly of me to forget such basic universal truths
Unfortunately, your "basic universal truth" doesn't match harsh reality.
In my experience (which, frankly, is all that matters when it comes to stuff that \I\ maintain or contribute to), the ratio of "incompetent using LLMs to produce utter rubbish" \[1\] to "competent using LLMs to produce something that can be reworked into something usable" is currently about two orders of magnitude. (This was much higher a month ago, btw)
When it comes to my actual $dayjob \[1\], the ratio is still effectively \infinite\.
Or to put it more directly -- In pracice, "Use of LLMs" almost perfectly correlates with "incompetent". \[3\]
\[1\] ...and then pushing back/compounding the slop in response to feedback\[2\] \[2\] ...in the rare instances where they don't just ghost us completely \[3\] Remember that \you\ chose that word+definition, not me.
Rules
Posted Jul 31, 2026 13:33 UTC (Fri) by mb (subscriber, #50428) \[Link\] (2 responses)
\>In pracice, "Use of LLMs" almost perfectly correlates with "incompetent"
How do you know whether a competent person contributing good changes used LLMs or not?
<https://en.wikipedia.org/wiki/Survivorship%5Fbias>
Rules
Posted Jul 31, 2026 15:46 UTC (Fri) by pizza (subscriber, #46) \[Link\] (1 responses)
\> How do you know whether a competent person contributing good changes used LLMs or not?
...Because (a) they said so, and (b) the nature of the mistakes made along the way.
Meanwhile, rejected another LLM slop patch this morning. It completely hallucinated hardware registers that don't exist, on top of re-introducing bugs fixed about 2 years ago.
Rules
Posted Jul 31, 2026 15:51 UTC (Fri) by mb (subscriber, #50428) \[Link\]
Ok. But do you realize (c) exists? Experts using LLMs and you do not notice.
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)
\> 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.
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)
\> I suspect.
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\]
Luca, I don't think this conversation is going to go anywhere productive from this point (across all the current threads, not just this one). You have already made your perspective clear, and I believe everyone here understands it even if they continue to disagree. Please leave things here.
Understanding code
Posted Jul 30, 2026 16:19 UTC (Thu) by wtarreau (subscriber, #51152) \[Link\] (1 responses)
\> > 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.
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)
It appears that you have not had the experience of working with recent AI models. They will gladly explain, they in great detail exactly how and why any changes were written.
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\]
\> I suspect that use of an AI model will reveal itself in back-and-forth questioning, though. But maybe I'm wrong.
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.
Rules
Posted Jul 31, 2026 5:57 UTC (Fri) by witheld (guest, #96686) \[Link\] (3 responses)
These kinds of communities are built on reputation, reputation you spend time and energy building. Intertwined with the personal relationships you make.
If you choose to make significant AI contributions in these projects you will live a lie you will have to audit every screenshot you take every line of text you copy. Your behavior may appear inconsistent. You may find yourself making confidants of other intrepid rule breakers, and they may betray you.
These kinds of honor based rules have always existed and lying has always been possible; but living a lie is unsustainable your lies are eventually exposed and you are shunned, exiled. You’re hurt and the people you lied to are hurt.
So if you feel like doing that if you want to live a lie, then live a lie. Just try to learn from it when things go wrong.
Rules
Posted Jul 31, 2026 6:12 UTC (Fri) by mb (subscriber, #50428) \[Link\]
It's the same as lying to you that I use Emacs if I actually use Vim instead. Not a big deal.
If I generate some code and then thoroughly audit, edit, check it, I really don't see where the problem would be with that. All the quality and trust arguments immediately vanish. And the copyright one is not even one, as has been explained elsewhere.
I fully understand that we don't want to have slop in projects such as gcc. But ban rules are neither required to prevent that nor do they actually prevent generated code from being merged. Just review the submissions, as is required anyway. Slop is obvious.
Rules
Posted Jul 31, 2026 8:25 UTC (Fri) by taladar (subscriber, #68407) \[Link\] (1 responses)
These projects have an inflated sense of self-importance. If they are going to make things difficult for contributors those contributors will just move to alternative projects, especially with the projects that are stuck on some old implementation language that was in decline anyway.
Rules
Posted Jul 31, 2026 12:04 UTC (Fri) by dskoll (subscriber, #1630) \[Link\]
GCC was in decline? That is news to me...
Rules
Posted Jul 31, 2026 8:04 UTC (Fri) by erwaelde (subscriber, #34976) \[Link\]
\> Most of the industry sees nothing wrong with it.
Well, I personally consider the amount of infrastructure and energy these beasts consume as "insane". And that has nothing to do with any llm generated text or source code.
Compiler crashes on LLM Code?
Posted Jul 30, 2026 7:12 UTC (Thu) by taladar (subscriber, #68407) \[Link\] (1 responses)
So if contributions derived from LLM content are forbidden does that mean if an LLM writes some code and that crashes the compiler and then I hand-develop a fix for that compiler crash that contribution isn't welcome in GCC?
Compiler crashes on LLM Code?
Posted Jul 30, 2026 8:39 UTC (Thu) by hvd (guest, #128680) \[Link\]
No, the article says that is fine.
\> 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)
Presumably the FSF wants to retain copyright of the gcc codebase and keep it under the (L)GPL respectively, so I'm not sure what else they could have said.
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)
\> Are LLM outputs copyrightable?
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)
\> Yes, code is what matters
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\]
The "preferred form to modify" idea pretty much exists so that somebody could not plausibly claim that obfuscated C code for example would be the preferred form to distribute and as such hide the \actual\ source code.
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\]
Hi,
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\, 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\] (9 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.
AI generated contributions and copyright
Posted Jul 31, 2026 4:36 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) \[Link\]
\> Totally AI generated code as a result of a prompt is not going to be able to be defended under copyright IPRs.
If some parts of the code are not copyrightable, this doesn't change that the whole GCC is still copyrightable. Moreover, \compilations\ (in the original sense) are also copyrightable if there was even a bit of artistic input. In case of GCC, the acts of human reviewers deciding which patches to accept, is likely to be enough to trigger the copyright.
So even the GCC of Theseus should be fine.
AI generated contributions and copyright
Posted Jul 31, 2026 9:07 UTC (Fri) by bluca (subscriber, #118303) \[Link\] (6 responses)
\> The US copyright office has released a public report about the fact that copyright requires a human author.
No, they did not. They correctly refused registering copyright when the human who controlled the AI image generator voluntarily and explicitly relinquished all his rights.
This does not apply to normal software development obviously, as authors simply don't do that, and especially to the GCC case, as authors are \required\ to do the exact opposite instead and assign all their copyrights to the FSF in order to have their changes merged, which makes it even more obvious than usual that particular case does not apply.
This idea that "LLM output cannot be copyrighted" is just wishful thinking and has no bearing with the real world.
https://sfconservancy.org/blog/2026/mar/04/scotus-deny-ce...
AI generated contributions and copyright
Posted Jul 31, 2026 10:47 UTC (Fri) by hvd (guest, #128680) \[Link\] (5 responses)
\> > The US copyright office has released a public report about the fact that copyright requires a human author.
\> No, they did not.
Yes, they did. The report can be read at <https://www.copyright.gov/ai/> and deals with more complicated cases than the one you are linking to where any human authorship was disclaimed.
AI generated contributions and copyright
Posted Jul 31, 2026 11:50 UTC (Fri) by bluca (subscriber, #118303) \[Link\] (4 responses)
No, they did not. That also reinforces the same points from the court case, that are summarized in the linked blog post, that as long as a human is in the loop and directs the tools, then copyright protection still applies. Copilot/codex/claude are all ASSISTING tools, they do not act by themselves in a vacuum out of their own volition, they produce output based on local context, which include both the series of prompts from the user, local written instructions and directions for bots written by humans, and the existing codebase.
AI generated contributions and copyright
Posted Jul 31, 2026 12:07 UTC (Fri) by hvd (guest, #128680) \[Link\] (3 responses)
It'd be fine to argue that people are misinterpreting what that report says, if you have reasons for doing so, but just straight up continuing to deny it exists even when provided with a link to that report that literally talks about "the human authorship requirement" (wording is from that very report) is worrying, that makes it seem like we live in entirely different realities.
AI generated contributions and copyright
Posted Jul 31, 2026 12:36 UTC (Fri) by bluca (subscriber, #118303) \[Link\]
\> makes it seem like we live in entirely different realities
that must evidently be true, given you just replied to something that I clearly did not write
AI generated contributions and copyright
Posted Jul 31, 2026 12:49 UTC (Fri) by kleptog (subscriber, #1183) \[Link\] (1 responses)
From the conclusion of the report:
- Based on the fundamental principles of copyright, the current state of fast-evolving technology, and the information received in response to the NOI, the Copyright Office concludes that existing legal doctrines are adequate and appropriate to resolve questions of copyrightability. Copyright law has long adapted to new technology and can enable case-by-case determinations as to whether AI-generated outputs reflect sufficient human contribution to warrant copyright protection. As described above, in many circumstances these outputs will be copyrightable in whole or in part \- where AI is used as a tool, and where a human has been able to determine the expressive elements they contain. Prompts alone, however, at this stage are unlikely to satisfy those requirements. The Office continues to monitor technological and legal developments to evaluate any need for a different approach.
- The copyright office refused to register copyright for an AI, saying that only humans can register a copyright
- The copyright office also says that outputs of AI can be copyrightable in many situations.
ISTM you two are talking past each other about two completely different points.
I don't doubt there are people submitting code written by AIs with minimal human supervision. I doubt they are any good and having a policy to restrict that is fine. But these policies throw the baby out with the bath-water by refusing to accept any code where even a single bit was produced by AI, which is just ridiculous.
BTW, loving the Markdown editor.
AI generated contributions and copyright
Posted Jul 31, 2026 12:53 UTC (Fri) by hvd (guest, #128680) \[Link\]
\> ISTM you two are talking past each other about two completely different points.
No, I focused very narrowly only on a specific point that bluca made.
\> > The US copyright office has released a public report about the fact that copyright requires a human author.
\> No, they did not.
with a link to that public report by the US copyright office about the fact that copyright requires a human author.