There is nothing far fetched about this. GNU is an ideological organization and their ideology is "free software." Free software exists because of the copyright system. Now imagine if someone can just fork your GPL licensed software and distribute it under an incompatible license, and when you go to court, the judge tells you to punch sand because your codebase is all AI generated and therefore not copyrighted.
I am not saying this is not what will happen — the actual law seems to be still up in the air. But if it does happen it will be an existential threat to the GNU and the whole free software ecosystem.
> the judge tells you to punch sand because your codebase is all AI generated and therefore not copyrighted.
1. There is no indication that is at all likely except for purely vibe-coded projects. It seems highly unlikely and in some countries (e.g. the UK) the law clearly says otherwise.
2. There have been quite a few rulings in countries where it is unclear, and they all set some level of human input that will make AI generated code covered by copyright. Look at the cases that have been in HN stories about cases in the US, Germany and Japan, for example.
2. It would have to be all AI generated, and you would need to replace all the human written parts. Not a practical problem for a large, old project.
If this is their real reasoning they are jumping at shadows. However, this might be like where, the copyright (which is the explanation given in the ToS) is not the real reason (which was explained in the subsequent blog post).
It is interesting that proprietary software businesses, who have an even stronger interest in ensuring their software is covered by copyright in all countries seem to be quite happy to use LLM generated code. Microsoft and many others boast about how much of their code is now LLM generated.
Without code copyright we are inherently free to modify, improve and share code we have access to. FSF used copyleft as a legal hack to maintain that right in an environment where corporations where using copyright to deny that right.
I don’t think taking copyright off the table harms the practice of sharing code. They will still try to use trade secrets to restrict code sharing and contracts, but using GNU software won’t be stopped. It will reduce the ability to sue people not sharing their modifications but that was always outside the mainstream, and places like AWS, Apple, and Google find ways around it anyways since it doesn’t cover hosted services or non-linked code.
The core stream of openly developed and exponentially improving software does not need copyright to win if it cannot be sued for copyright violation.
Now I suppose some OpenAI lawyer is trying to find a way to sue humans for copyright infringement while keeping them safe from lawsuits, so we can worry about that attack.
I don't think the concerns are far fetched at all. Look at how image models spit out copyrighted stuff all the time. Midjourney has a bizarre EULA clause that if you use it to generate images that violate copyright and _they_ get sued, they can hold you liable downstream. Which is wild to me -- just don't train on things you don't own and this is not a problem!
In images it's much more _obvious_, but I think code is very likely to have similar problems. Like, websites that an LLM spits out are often very very similar. It wouldn't be shocking to me if some of the code in the training set was trained off GPL code, and there are small GPL violations all over the place.
Anthropic and co basically have the opposite policy (for paid users): if you get sued for copyright infringement, they will indemnify you. That means they're confident it's not an issue.
By the way, do you have a source on Midjourney spitting out copyrighted stuff all the time? Does it happen at random or when users intentionally steer the prompt in that direction? I suspect it's the latter but I admit I'm not really familiar with this tool.
These companies have already shown they're extremely reckless with copyright (Anthropic was penalized 1.5B for books, for example). I don't think they've earned that trust of "they looked at it so it must be ok"
The risk might be small -- but is it a risk they need to take at all? We're talking about a very mature project here that more or less needs to move at the speed of standards bodies, which is basically glacial. Being the first to implement C++ 29 probably isn't that big of a deal. People do not upgrade their compilers daily, shit, most projects stay on the same version for years, so optimizing for velocity seems like a bad idea here.
For that very reason they would also add very little LLM code over the next few years (until we get more court rulings) even if they allowed it. A little LLM code would not be usable without the rest of their code which remains covered by copyright.
Its much the same as someone creating a fork of GPL code in which they make additions that they put in the public domain. All the original code and the fork as a whole would remain GPL.
You want to prevent the transition from a GPL codebase with some public domain code to a public domain codebase with some GPL code. One way to do so is to outright ban contributions leveraging tools that are able to generate public domain code at superhuman speeds.
As you pointed out yourself, there's always the option to create a fork that does allow AI contributions, which may eventually force a re-assessment of the policy if the gap in utility grows too large.
> You want to prevent the transition from a GPL codebase with some public domain code to a public domain codebase with some GPL code.
That would take a very long time if contributions are reviewed etc. By then any legal ambiguities would be clear.
> a public domain codebase with some GPL code
which would still be a GPL codebase
> One way to do so is to outright ban contributions leveraging tools that are able to generate public domain code at superhuman speeds.
Can they generate code that would pass the quality standards, and pass the processes, of a project like this at superhuman speed? There is a separate requirement that contributors must be able to understand code and answer questions about it so a human would have to review code before even trying to contribute it.
> As you pointed out yourself, there's always the option to create a fork that does allow AI contributions, which may eventually force a re-assessment of the policy if the gap in utility grows too large.
1. if you are right that LLMs will do well enough to create a huge gap, then that is inevitable.
2. if you are wrong about that then it is unnecessary to try to stop it.
Uhm, removing code once it's in there and load bearing REALLY hard, and breaks a lot of things. You can't just be like "well, I'll just remove the parts with copyright issues". Plus, all those parts with copyright issues you'd basically have to rewrite by hand, which would take much longer than with an LLM. It would be an absolute disaster.
At the same time, they would be somewhat forced to concede those use cases if they wanted to stick to the copyright story. Maybe you're right but I remain skeptical.
Yes but if the concern is being forced to remove code in the case of copyright violation it is trivial to remove code that is a test case as opposed to a feature of the compiler
The stance may be reasonable, but the reasoning is not clear to me and the limit does sesm to suggest copyright concerns that are, as you say, far fetched.
I think definitely a combination; there are those who believe that LLMs are the entire future, and those who are ashamed of themselves for using it. Both lead to rage at people who don't approve totally.
I am making an argument based on the fundamental nature of the tool, which is to make stochastic, unvetted decisions our behalf — categorically different from everything else in our toolbox. The technical and social repercussions to this are potentially vast: no other tool comes close. So it is actually Linus who is making an unconvincing appeal to emotion (and authority) by pretending that LLMs resemble hammers.
I said at face value because there was no reason given in either the policy nor the article submitted here.
It would be interesting to know why they decided for a general prohibition, rather than going with the default "a human must be responsible for the contribution" kind of policy.
Perhaps they have received a flood of undesirable AI generated contributions, and actual contributors do not use AI significantly.
Off the cuff, I would be surprised if the GNU project embraced AI, so I'm confused that people think so strongly otherwise.