So take Torvalds' advice and walk away, friend. The immediate subject here is Sashiko, an AI system that reviews patches submitted to the kernel. It does not write patches, merge patches, or waive the kernel's standards. You have silently replaced that subject with an imaginary “slopped Linux kernel,” then left reality behind. Sashiko's own documentation describes a multistage review system whose final product is an ordinary LKML review message, not code smuggled into the tree.
I wouldn't say pragmatic, no.
“No” is not an argument. Torvalds evaluated a tool, found that it produces useful results, acknowledged its failure modes, and concluded that the answer is to manage those failure modes rather than prohibit the tool. That is almost a dictionary illustration of pragmatism. You may dislike his conclusion. You do not get to redefine the word merely because it reached a destination you dislike.
He's tried it, found it works, and now won't listen to the people pointing out the numerous problems with it.
Torvalds explicitly mentions maintainer workload, bad output, imperfect results, economic uncertainty, and the embarrassment of having tools uncover bugs humans missed. His stated objective is to make these tools help maintainers rather than burden them. So your evidence that he “won't listen” is a post in which he explicitly lists the problems and discusses what should be done about them? You are impeaching him with evidence that contradicts your own assertion.
The slopped Linux kernel may well be a violation of the copyrights of several unknowns in Europe, for example.
“Slopped” assumes the conclusion before you have identified a single defective patch. “May well” supplies insinuation without assuming the inconvenience of evidence. “Several unknowns in Europe” supplies neither a copyrighted work, an allegedly infringing kernel passage, a claimant, a contributor, nor even a coherent theory connecting Sashiko's review comments to infringement.
Sashiko is reviewing human-submitted code. You have switched from “an LLM commented on this patch” to “the kernel contains copied LLM output.” Even where AI-assisted code is submitted, kernel policy does not confer some mystical robot exemption. A human must review it, ensure license compliance, sign the Developer Certificate of Origin, and accept responsibility for the contribution. Maintainers can apply extra scrutiny or reject it outright. The DCO is not a magic anti-lawsuit talisman, but it demolishes your pretense that Torvalds has ordered the gates opened and dismissed provenance as somebody else's problem. Bring us an actual patch and an actual infringement allegation. Until then, “unknown Europeans may object” is pure insinuation.
If you're not planning to build a Linux-based product in Europe, not a big issue I guess.
You have not established a European violation, so you cannot derive business advice from one. Geographical hand-waving does not transmute “perhaps some unknown person owns something somewhere” into evidence. The word “Europe” is not an incantation that relieves you of identifying what was copied.
One sentence ago, the law was apparently so subtle that everyone else was irresponsibly overlooking international complexity. Now the copyright status of an unspecified patch, containing unspecified material from an unspecified source, has been conclusively resolved for the entire United States in one sweeping sentence. That is jurisdictional Mad Libs, not a coherent argument.
But it's amazing how many people think US copyright law is the only type of copyright law.
Who said that? Torvalds did not. The Sashiko devs did not. The GP did not.You manufactured a provincially ignorant opponent because refuting that strawman is easier than demonstrating infringement in the Linux kernel. Announcing that foreign laws exist is not a substitute for applying one of them to an identifiable set of facts.
And that's before we get to changing the entire nature of Linux so it's no longer a project understood by human beings.
An AI reviewer does not make the reviewed C code incomprehensible. It produces comments about a diff. A human still submits the patch and accepts responsibility for it; humans still review it, humans still test it, and humans still decide whether it enters the tree. Kernel guidance is explicit: submitters are expected to understand and defend everything they submit. If they cannot, maintainers are entitled to reject the series without detailed review.
As for your prophecy that Linux will cease to be understood by human beings, Hitchens’s razor applies: what can be asserted without evidence can be dismissed without evidence. Consider it etched in silicon.
A compiler does not make C unknowable. The kernel already uses Coccinelle semantic patches to detect problematic patterns and generate complex, tree-wide changes. Nobody claims the resulting code has ceased to be understandable by humans merely because software helped produce the patch. And the kernel does not become occult because one of its reviewers is silicon. “Humans might stop understanding Linux” is a legitimate risk to watch for. It is not evidence that this has happened, and certainly not evidence that an automated reviewer caused it.
This is Bitkeeper all over again.
BitKeeper was proprietary source-control infrastructure used to manage kernel history. Sashiko is an optional review tool that comments on proposed patches. BitKeeper occupied the repository-management layer. Sashiko supplies another opinion during review. BitKeeper's continued availability depended upon a commercial vendor's license. Sashiko's code is Apache-licensed and supports multiple LLM providers. If one provider disappears, Sashiko can be pointed at another; the kernel development infrastructure remains exactly where it was.
The only overlap between these two different tools is that “Torvalds approved a tool.”
That was the last time Torvalds made a "pragmatic" decision, effectively locking out a large number of kernel devs from kernel development, until he was forced to build Git to replace it.
That assertion is so reality-warping it has a Schwarzschild radius. Kernel contributors were not required to use BitKeeper. Contemporary kernel documentation explicitly stated that no developer was required to use BitKeeper to contribute. And the official Git history says Git followed the breakdown of the vendor relationship and revocation of BitKeeper's free-of-charge status, not some mass expulsion of non-BitKeeper developers. I was there; I watched it happen in real-time. The arrangement ended when BitKeeper's free-of-charge availability was withdrawn after the relationship with its vendor broke down. Torvalds and the community then created Git using lessons learned from BitKeeper. The official Git history describes exactly that sequence, completely contradicting your revisionism. Furthermore, calling this “the last time Torvalds made a pragmatic decision” requires us to believe that the top-level maintainer of the kernel has made no pragmatic technical decisions since 2005. That claim collapses under its own theatrical weight.
If anything, BitKeeper demonstrates the opposite of your intended lesson: Torvalds adopted a tool because it improved development, tolerated ideological criticism while it remained technically useful, and replaced it when the dependency became untenable. The result was Git. That is not an indictment of pragmatism. That is pragmatism successfully handling both adoption and failure.
Ultimately, you have not demonstrated slop, infringement, developer lockout, or the disappearance of human comprehension. You have substituted an epithet for a quality analysis, hypothetical claimants for an infringement case, a slippery slope for evidence, and BitKeeper for a relevant analogy.
Torvalds did not say that AI output gets a pass. He said AI is a tool, and that contributions will continue to stand or fall on technical merit. That is the whole point you are trying to obscure. If the code meets the kernel's standards, it is not “slop.” If it does not, reject the patch. That is the standard we use for human work, compiler-generated work, transformation tools, static-analysis fixes, and every other contribution.
Demanding that one disliked tool be judged by tribal affiliation instead of its output is not a tenable position. Your whole post is an attempt to import your anti-AI ideology into the review process, despite Torvalds's explicit rejection of ideological vetoes over technical merit.