Corporate Linux

> The fact that working on Linux code will now require corporate backing to pay for the AI will also aid in taking Linux away from the free software community

This isn't remotely true, it is fictional ragebait

  Or you could, you know, use any decent IDE, or a deterministic refactoring utility, or even a quick Perl script.

At the risk of having everybody go full on flame war. I'm going to take a bit of an opposite position. Code written with AI assistance does not require AI to change that code. This article seems to be concentrating on who to blame, for an error in code, rather than concentrating on how in the heck we're going to fix those errors. Saying that if the code was written by/or with the help of, AI, you're now going to have to have corporate sponsorship to fix any subsequent error. Is like saying we can't fix our product anymore because Fred left the company and Fred wrote the original code. Since the mid-90s, much of the development in Linux was done by people with corporate sponsorship. Sometimes third parties, quite often they worked for a distribution. That was a corporation.

> By ensuring nobody can tell which parts of a work are AI-generated, it becomes impossible to claim copyright protection on it in the US

Not true. As long as any of the code is human written the copyright can be enforced. You would have to have a kernel that is entirely AI written.

As far as I can see they are only dropping the need to add a note to commits which is only part of what you need to follow the Copyright Office procedure. What you really want is things like the prompt history. it also seems the information will be recorded in a "cover letter". If these are kept it seems fine.

The fact that the AI companies like to push the "assisted by" tag might be a clue that dropping it is not some corporate plot.

> The fact that working on Linux code will now require corporate backing to pay for the AI will also aid in taking Linux away from the free software community.

1) are corporations not part of the community? 2) can individuals not afford access to LLMs?

> Torvalds said that the time has come to make it harder for new people to contribute code to the kernel.

because they have too many low quality contributions from first time contributors.

Also the LWN article says:

> Pinchart asked Torvalds to confirm that he is not trying to push out developers who do not use LLMs; Torvalds agreed that he is not. Pinchart added that it is important to communicate that message to the community. Torvalds added that he does not want to scare off people who want to write code; his message is that you have to either put in the effort to learn, or put a lot of money into an LLM to participate.

This article is alarmist ragebait.

It would be interesting to read Torvalds' response to this article as it paints a very one-sided picture. If we presume the article is at least in the right direction, from what I know about some devs, I presume he sees Linux as "his" baby that he just happens to be sharing with the world. If you like it, great. If you don't, idc. This seems to fit his character of harsh criticism of bad code. On the bright side, it has always meant that Linux has had a critical eye examining it, ensuring that it works. On the flip side, some feelings are hurt. But that's ok. You can't always appease people's feelings if you want something done right.

In a way, Torvalds is more true to liberty than Stallman: Do what you want with the code. Stallman is more "Let's all share freely." They form contrasting camps to the FOSS community, which is one of the many reasons the community can't just all agree.

Linus is clear in his communication: the license, community, corporations, AI and even Linus himself are there to make Linux better for its users, not the other way around. And as a BDFL, Linus makes the decisions, don't like it, you are free to go. Until now, it has been a huge success, so I am on his side, because I like Linux very much and Linus takes great care of it.

The thing about copyright is complete bullshit. Let's assume AI work is indeed not copyrightable, ok, neither is public domain. And when Disney made "Snow White", the folk tale that is based on is public domain, so, by that logic, Disney's "Snow White" copyright shouldn't be enforceable. Well, try it and see how Disney's lawyers react.

And then there is the part where he tries to demonstrate that AI self reviews (not vibe coding, not flooding maintainers with useless reports) are useless by giving alternative. Yes, the alternatives are good, but it mean that your shouldn't use AI in addition to all that. Throwing every tool you have at your code base is a good thing, a LLM is one of these tools, and it is an effective one as it can catch issues others don't, and also doesn't catch what other tools catch, that's why it is good to use both.

I personally have found many bugs in my code using a LLM. Absolutely no vibe coding involved, not even a single copy-paste from a chatbot, no AI completion, just oldschool code. I had the static analyzers on it, the sanitizers, and the program was quite robust. And still the LLM found bugs, real bugs, enough of them to make me feel a bit ashamed. False positives too, but I still have a brain, I can manage.

It looks like Linus is having the same experience and recommends it to everyone. I can get behind that. In the end you get better code. Can't afford it and you are not enough of a genus to get it right without it, the Linux user doesn't care, so Linus doesn't care either, your patch will be rejected for not meeting the quality standards, which are higher now that a new tool is available.

> This is another attitude I’ve noticed in AI enthusiasts: the AI never fails, the AI is never the problem, it’s always the human who failed the AI by not asking it properly.

I assume you have never used any tool ever? It is common knowledge by now that AI is not a one shot wonder in a lot of cases (weirdly so every argument seems use that as a precursor).

You are saying the equivalent of: Failed to compile source code - oh shit the compiler is wrong not my source code

If you expect a "stochastic parrot" to be a one shot wonder, surprise you get what you looked for.

Here's a simple thought exercise: You have a macro for generating a for loop that in X% of cases is correct, what is the X that is needed until it is practically useful.

The answer is not actually that straightforward, because typing it is far more cognitively complex that actually reading and verifying that it is a for loop.

Or another one that is far more relatable, what is the probability of accurate autocomplete that is needed for be useful? This is much easier to answer, as long as it is >0% it is useful for the small hits it provides, because checking is easy.

What does this mean? As long you have a better autocomplete using AI compared to the static analysis autocomplete you are already "better off". Again the simplest example, and at current stage this has long passed.

If you can't shape a tool to your workflow sorry but that's on you. You don't have to use the tool and that's perfectly fine as well. But that doesn't mean people have to hire you if there is someone who can use it and "performs better" (whatever this means).

There's this trend in the last couple of years of very successful software engineers heartily endorsing AI usage - I can think of Matz, dhh, Linus, uncle Bob. Probably a lot of other people I don't follow too closely.

I can't pinpoint a common motivation for all of them, other than the obvious (the tools are great and are the future, if you think otherwise you're a loser (paraphrasing dhh) etc).

I think at least at some level, these people are at a point of their careers where they have "been there, done that" (coding) and are happy to go do something else.

All of them have in common not having written code in a long time, instead reviewing patches from others, so the AI thing isn't really too different from what they've been doing for a long time.

Here's Linus' diatribe if you haven't seen it - https://lkml.org/lkml/2026/10/13/3242

> The obvious benefit is that when the kernel gets noticeably worse and terrible defects are found

At some point, you are going to have to accept that AI can out code you. And if you really are in the 99th percentile of coders, AI will be able to out code you in 3 months.

It's easier to live in reality.

You either die a hero or live long enough to become the villain. Fork it, run it, make it better. That's the gift of GPL. Just because you can't spin it up on EC2 (yet) doesn't make it a worse kernel. Lots of hosting providers accept custom images.

It has been for a maybe 10 years. I take the recent announcements as "proof" the Linux Foundation does not care about hiding that fact. It is too bad, some distros are trying to avoid following corporate mandates, but I think their days are numbered. The Debian/AI vote proves that.

Another indication is the on-going rewrite of GNU UN*X utilities to a different License. Corporations hate the GPL. With clang, rust/uutil and now pgp rewritten in another license, distros are well on their way to being non-GPL. I have popcorn out waiting to see how Companies will move the kernel from the GPL2 to something else.

It was nice while it lasted.

[dead]

That's why FreeBSD/OpenBSD/NetBSD are superior.

Linus has been a corporate tool ever since he was forced to take a "retreat" for getting "counseling" for better behavior.

Powerful, aging maintainers who welcome the AI crutch and accelerate the demise of open source is something I would not have predicted, but here we are.

In mathematics similar events are taking place and some tenured professors sell out the next generation.

Once upon a time, Linus had a bit about Good Taste in code[1], but it's hard to see that thinking at play delegating code to a machine.

I'm not really shocked to see this happening, even though I remain disappointed. Not the sheer use factor, tools are tools in my humble opinion, but the disregard for the lowly hackers who established the foundations and culture that led here. That is going to die, as the exclusionary pressures build.

Unfortunate, I guess next maybe I'll wait for the Year of the Plan9 Desktop.

[1] https://felipec.github.io/good-taste/parts/1.html