Digital reproduction is digital reproduction no matter how many extra steps are added to the reproduction process. It's just an algorithm that sorts through a collection of stored data to find specific pieces of data which best fit the keywords supplied by the user, then regurgitates the results that are the best match based on correlation.

In spite of common meaning overlap and popular metaphors, the human brain is not a computer. Ask any neurologist.

whos paying for the linux kernel?

If you dont know, you arent prepared to engage in this convo.

Im not interested in discussing this topic with someone who even has to ask, lol.

That's splitting hairs on definitions, with no change in meaning. It's still not copying the data, and is far closer to a person learning than to a picture taken by a camera.

Only when the data in question is so obscure to the point that the original source is the only place in which the data exists; which is neither common, nor useful to regurgitate, in practice.

It's like if someone asked an artist to draw Trump, and then they did. It's not that they studied what he looks like, but they're familiar with that walking pusbag and there's only the one, so it's going to be a recognizable drawing.

I'm arguing that it's not a small difference since the cognitive burden is put on maintainers who are already overworked. Now they need to edit through AI PR manure to find decent requests. A lot of OSS projects have stopped taking public PRs for this reason. It shifts the cognitive burden from the programmer to make good code, onto the reviewer to read and understand AI slop contribution.

It's not worth it to review community PRs anymore

AI slop is DDOSing open source

Agentic code is worse to maintain and breaks more often, especially when refactoring.

https://en.wikipedia.org/wiki/Rhetorical_question

Yeah I think those workflows will adapt eventually, with more maintainers and some kind of more formal trust or reputation process to help sort things. It sucks but figuring out how to deal with it is really the only path forward. Otherwise all the cognitive load goes to arguing about AI.

I also think the worst offenders will get bored once the novelty wears off, and if the standards are kept high enough that getting a PR through still requires some amount of human work.

I'm not taking away your right to scrutinize it any way you want, I'm just offering a simpler explanation that you are free to disagree with. While I can disagree with his opinion, I don't believe it's anything but his actual opinion, as he has historically always held on to his technical opinions even when they burned bridges and were unpopular.

Training a neural network algorithm is not equivalent to human learning

That's a stretch, since we don't know exactly how human learning works. Yes we have more than just that one mechanism at work obviously, but that's not to say we're not using the same or similar method as part of our learning process.

original training data can be reproduced completely from models

So can a few savants, more if you take into account those with special training, etc. The ability to do so is obviously latent to our brain.

When they reproduce code which they have previously stored, even only in part, that is a derivative work.

I don't know about you, but I for one have not produced anything 'original' my entire coding career by that metric. I feel confident in saying the vast majority of programmers have not either.

Don't mistake me, I'm well aware LLMs are not intelligent. But I disagree with the idea that their method of learning and their actions is inherently different from what the average person does.

Arent the issues with ai in the linux kernel ethical, not about code quality?

It’s not linux’s job to be an ethical gatekeeper, within reason.

Let me ask you this; if you’re from a certain country, from a certain background or whatever, should you not be allowed to contribute the kernel? Or submit a bug report?

Devs of open source projects often find out others doing things they don’t like with their code. Or find major contributors have backgrounds they don’t like.

Happens all the time; drama ensues. But at the end of the day a permissively licensed project is out there, the work on it is done by whoever’s already contributed. And the Linux project, in particular, is not in the business of trying to personally judge every entity behind the code contributions.

I’d assert LLM agent usage is the same. Maintainers/reviewers don’t have to like LLMs, but it’s not really Linux’s job to judge who (or what) wrote the contribution; just if the code is good, or not.

I’d argue a different policy is a bad precedent. It opens the door to judging people, too.

And it’s also impractical. Contributors are going to use agents, so mind as well encourage them to attribute them rather than encouraging them to be unethical, and hiding it.

Now, should LLMs be maintainers? Hell no.

Should they blindly contribute code? Hell. No. Hence the policy requires a human to be responsible for it: https://docs.kernel.org/process/coding-assistants.html

Thank you for the opinion. If there's a trial, and if you're called as an expert witness, I'm sure they'll consider your opinion, and have a fun debate on whether a human brain being similar to a computer is relevant in any way.

In the meantime, the technology exists, is useful and the results are no more theft than creating piñatas from newspaper clippings is theft from the newspaper.

It’s not linux’s job to be an ethical gatekeeper

Are people not allowed to complain when someone supports something that is unethical when they could easily not do that?

if you’re from a certain country, from a certain background or whatever, should you not be allowed to contribute the kernel? Or submit a bug report?

The people ruling the country are doing the unethical things, not the people that just happened to be born in the country, maybe fell victim to propaganda /
Is it not normal to not allow someone to contribute to a project if they are currently doing problematic things?

And the Linux project, in particular, is not in the business of trying to personally judge every entity behind the code contributions.

Judging a technology is not the same as judging a person. There arent an unreasonable amount of different technologies that people complain about to not be able to judge each one

Maintainers/reviewers don’t have to like LLMs, but it’s not really Linux’s job to judge who (or what) wrote the contribution

People can feel alienated from contributing to a project if they consider it unethical

And it’s also impractical. Contributors are going to use agents, so mind as well encourage them to attribute them rather than encouraging them to be unethical, and hiding it.

Stealing is illegal, but people still do it. Its impractical to catch every person that has ever stolen something so why bother trying at all?

Does any of what you just said sound reasonable or likely?

Edit: looking back through history we've had low-code tools cause a boom in software abundance before. AI is following the exact same trajectory as the late 90s. Devs being laid off left and right, slop code everywhere, and then suddenly, inevitably, experienced developers are worth their weight in gold again because the core issue isn't generating code, it's understanding and managing complexity in a code base which AI is shit at long term. It adds entropy with every single prompt. It seems like it can't help it... It just has to delete random lines, add redundant features, spam extra files, and do other stupid shit.

It's like a gifted but kind of stupid intern. If you just set it free on your project it sets it on fire within a year. The limiting factor has always been and always will be comprehending and synthesizing a code base.

Sorry, I don't follow the money.

so yeah you have a third option for folks you are unaware of since none of us pay to use the kernel?

It is actually not like a person learning at all. The only way you could believe this is if you have no grasp of the mathematics that are the basis of the multi-dimensional statistical analysis which is neural network training, and haven't bothered to do any reading on it.

There's a reason I referenced curve fitting.

Here is a better explanation than I could give, by someone who knows better than me:

Large Language Models explained briefly by 3Blue1Brown

maybe the license was cheaper? idk how getty images works.

That's a stretch, since we don't know exactly how human learning works.

It is not a stretch. We may not know exactly how human learning works, but we do know exactly how machine learning works, and we know that it is not like how human learning works. It is absolutely possible to differentiate things even without complete knowledge.

For instance, I am not a biologist. I do not have complete knowledge of the workings of a horse or a snake. However, I do know that a horse and a snake are different.

I don't know about you, but I for one have not produced anything 'original' my entire coding career by that metric. I feel confident in saying the vast majority of programmers have not either.

This is a bad argument. The output of a generative model is a copy-and-paste function from a library of ingested code samples with a fairly competent keyword search attached to it. Code writing bots are just script kiddie crutches.

If all you did was copy and paste from GNU GPL code, then your output would also be bound by the same license.

But I disagree with the idea that their method of learning and their actions is inherently different from what the average person does.

Then you don't understand even the basics of the mathematics that makes them actually work. It's a purely algorithmic process. It's an outgrowth of multidimensional analysis and optimization, that's all.

Here is a better explanation than I could give, by someone who knows better than me:

Large Language Models explained briefly by 3Blue1Brown

It actually is, but you want it to be literally the same. Given the options of what it can be compared to, learning is the most appropriate, which is exactly why it's named Machine Learning. The only reason you could believe otherwise is if you have no concept of language, and believe that it must be literally identical to a person learning in order to use the same verbiage.

It does not; which is the reason why it's called learning. It's the closest, and most accurate approximation, regardless of the mathematical operations on which it's based.

Yes and yes.

There's also arguments to be made that there is nothing unethical about the tools in general, only with specific LLM models due to the practices of their maintainers, and the closed status of specific models.

I like you, a lot. Thanks for existing, intelligent, rational and pragmatic stranger.

Based on what? Hopium? Open source maintainers are burning out and even extremely popular projects struggle to recruit new devs to help. What's supporting your argument here besides "lol idk they'll figure it out I guess"

There's a ton of load bearing stuff that's going to break once maybe 100 people have enough and stop thanklessly maintaining things. In fact it's even worse than being thanklessly expected to fix shit since people are outright hostile towards you for maintaining your own passion project that nobody else wants to help with. And now you have people pushing AI slop PRs they shat out of Claude in 15 seconds, and you're expected to comb through it and suggest changes?

And don't even get me started on AI's ability to code. It can work well for small constrained tasks like scripting or unit testing. It breaks down entirely when you aks it to maintain a complex code base for years. It just can't help but duplicate code, delete features, spam files, and it has no ability to architect a project.

Based on the fact that it is now reality, and there is no alternative. Adapt or die.

Even if, moronically, Linus had followed the popular trend of banning AI tools - the only thing that would change is disclosure. The reality is, the tools will be used either way, and banning just means they won't report the tools used.

Whether AI tools are used or not, a person is still attaching their identity to the submission. Regardless of the tools they did, or did not use, they are stamping the end result. The only feasible solution in the long term is to scrutinize those submitting PR, rather than attempting to police the tools they used to create them.

To demonstrate the core issue, from now on I'll argue with you using chatgpt. You'll need to read this wall of AI slop, and all I need to do is copy paste your comment into my current chat and hit "generate"

I think there are actually several different dimensions to this discussion, and I don't think it's quite as straightforward as you're presenting it. It's important to recognize that technological transitions have historically been disruptive before new equilibria emerge, and while the current situation certainly creates challenges for maintainers, I don't think that necessarily implies a long-term negative trajectory for the open-source ecosystem as a whole.
From a systems perspective, what we're really observing is a temporary mismatch between contribution velocity and review capacity. Historically, software engineering has repeatedly experienced periods where productivity increased faster than existing workflows could absorb those gains. While AI-generated pull requests undoubtedly increase the volume of contributions, that doesn't automatically mean the ecosystem is fundamentally unsustainable. Instead, it suggests that governance models, review methodologies, contributor onboarding, and trust mechanisms will likely evolve over time.
Another point worth considering is that AI-assisted development should not necessarily be evaluated solely in terms of code quality. There are also accessibility benefits, educational benefits, and opportunities for new contributors who otherwise might never have engaged with open source. While some of these contributions may indeed be lower quality, the broader increase in participation could, over a sufficiently long time horizon, create a larger pool of experienced contributors than currently exists. This is, admittedly, speculative, but it is also consistent with historical patterns observed during previous shifts in software tooling.
Additionally, I think it's useful to separate concerns regarding code generation from concerns regarding software architecture. Current language models certainly have limitations with maintaining long-lived systems, preserving architectural consistency, and minimizing technical debt. However, these limitations should not necessarily be interpreted as permanent characteristics rather than temporary engineering constraints. Future iterations may demonstrate substantially improved long-context reasoning, architectural awareness, and repository-scale understanding.
Finally, I would caution against assuming that current social dynamics necessarily represent the eventual steady state. Communities have historically developed moderation strategies, reputation systems, automated quality gates, and contribution standards in response to changing incentives. While the present situation may be frustrating, it seems plausible that open-source governance will adapt in ways that reduce reviewer burden while maintaining quality.
Ultimately, I think the long-term outcome remains uncertain. There are certainly valid concerns about maintainer burnout, review overload, and declining signal-to-noise ratios. At the same time, there are also reasons to believe that new institutional norms, improved tooling, and changing contributor behavior could partially or substantially mitigate those issues over time. As such, I don't think it is possible to confidently conclude either that open source is doomed or that everything will automatically work itself out. The reality is likely to be considerably more nuanced than either extreme.

I think it's important to distinguish between descriptive and normative claims here. Nobody is disputing that AI exists, or that people will continue to use AI. That observation, while factually correct, doesn't meaningfully address the underlying concerns regarding review burden, maintainer workload, long-term software sustainability, or governance challenges. The existence of a technology does not, in and of itself, imply that existing institutions have already adapted to it, nor does it imply that adaptation is trivial, inevitable, or costless.

Similarly, I think there's a tendency to frame this as a binary choice between "adapt" and "die," when in reality the situation is substantially more nuanced than that. Adaptation itself is not a single event but rather an ongoing process involving changes to community norms, tooling, contributor expectations, trust mechanisms, and review workflows. The fact that this process is occurring says relatively little about whether it is succeeding, who bears the associated costs, or whether those costs are being distributed equitably across maintainers and contributors.

Regarding disclosure, I broadly agree that attempting to prohibit AI tooling outright is unlikely to be effective over the long term. However, that observation does not eliminate the practical challenges introduced by dramatically increasing the marginal cost asymmetry between producing code and reviewing it. Even if disclosure disappeared entirely tomorrow, maintainers would still need to invest substantial cognitive effort into understanding, validating, testing, and integrating incoming changes. In other words, removing disclosure changes the visibility of AI usage but does not meaningfully reduce the review burden itself.

Likewise, while I agree that individuals ultimately attach their identities to pull requests, identity alone should not necessarily be interpreted as a proxy for trustworthiness or software quality. Trust is not merely an intrinsic property of an individual contributor but rather an emergent property built over repeated interactions, demonstrated competence, consistency, responsiveness to review, architectural understanding, and alignment with project goals. Consequently, shifting emphasis toward contributor reputation may indeed form part of a broader governance strategy, but it should not be viewed as a comprehensive solution to the broader ecosystem-wide challenges associated with increasing contribution volume.

I also think it's worth recognizing that contributor reputation systems themselves introduce additional complexities. Reputation requires accumulation, maintenance, interpretation, and governance. New contributors necessarily begin without reputation. Existing contributors can experience changes in quality over time. Organizations can rotate personnel while preserving identities. Accounts can change ownership. Even sophisticated trust models therefore require ongoing human oversight rather than eliminating the need for reviewer judgment altogether.

Ultimately, I think this discussion benefits from avoiding false dichotomies. The issue has never been whether AI exists, whether contributors will continue using AI, or whether maintainers should attempt to inspect people's prompt histories. Rather, the central question is how finite pools of human attention are allocated in an environment where the cost of generating plausible-looking contributions has fallen dramatically while the cost of validating correctness, preserving architectural integrity, and preventing long-term maintenance debt remains comparatively unchanged. That seems to me to be the more interesting systems question, and one that likely cannot be answered solely through increased reliance on identity-based trust mechanisms.

.

At which point, I'd reply: eliminate the verbosity. Be succinct, or I'm closing this PR and line of communication.

I'd say they're in the same tier. It will take time to determine which is worse.

I appreciate the feedback regarding verbosity, and I think that concern is both understandable and illustrative of the broader discussion we're having. However, I would suggest that your response actually reinforces the systemic dynamics that I'm attempting to highlight. Specifically, while you are entirely correct that an individual response can simply be closed or ignored if it fails to meet project standards, that observation does not necessarily scale in environments where the overall volume of incoming communication increases by one or two orders of magnitude.

To elaborate, the issue isn't that any individual AI-generated pull request, issue report, or discussion comment is impossible to dismiss. On the contrary, as you've demonstrated, a maintainer can absolutely review a single submission, determine that it lacks sufficient value, and reject it accordingly. The challenge emerges not at the level of individual interactions but at the aggregate systems level, where review capacity becomes the scarce resource rather than code generation capacity.

For example, if one contributor submits an unnecessarily verbose pull request, the cost of evaluating that submission may be relatively modest. If ten contributors do the same, the cost increases proportionally. If one hundred contributors begin submitting plausible-looking but low-value AI-assisted changes every week, each of which requires even a few minutes of human evaluation before being confidently rejected, the cumulative impact becomes substantially more significant. This isn't because any individual submission is uniquely problematic but because the total review burden scales with submission volume while maintainer attention does not.

From a queueing theory perspective, this creates an interesting imbalance. Human review throughput remains relatively fixed, whereas AI-assisted content generation dramatically increases the arrival rate of new work. Once the arrival rate consistently exceeds the processing rate, backlog accumulates regardless of how efficient reviewers become at rejecting individual items. Consequently, "just reject it" is a locally optimal strategy that may nevertheless fail to address the global characteristics of the system.

Furthermore, I think it's useful to distinguish between identifying low-quality contributions and doing so at scale. The cognitive effort required to conclude "this is not worth merging" is still non-zero. Every submission requires context switching, repository loading, architectural reasoning, verification that nothing subtle has been overlooked, and ultimately a decision. While each of these activities may appear trivial in isolation, their cumulative effect across hundreds or thousands of submissions represents a meaningful opportunity cost for maintainers who might otherwise be spending that same time reviewing genuinely valuable work or implementing new features.

For that reason, I don't think the existence of a rejection mechanism meaningfully addresses the broader concern being discussed. Rather, it demonstrates that the cost of filtering remains attached to human reviewers even as the marginal cost of generating candidate contributions approaches zero.

In other words, I agree that you can close this thread.

Now imagine doing that another 699 times today...

Alright, you've demonstrated the difficulty posed by reality; let's hear your proposed solution?

Yes we have more than just that one mechanism at work obviously, but that's not to say we're not using the same or similar method as part of our learning process.

You seem to have entirely ignored the gist of my first point. We may be using a more well rounded method which utilises the same technique LLMs use as a part of our overall learning ability.

If all you did was copy and paste from GNU GPL code, then your output would also be bound by the same license.

We're back to the same argument that's been around since the start of the current AI boom, about whether or not people produce art and everything else the same way. At this point it's very obviously a philosophical argument in general, and from your other comments in this post you've offered nothing but semantics as to how they're different. We're going to have to agree to disagree there.

Then you don't understand even the basics of the mathematics that makes them actually work.

I understand how LLMs work. We DON'T understand how humans work, and unless you've got a human theory of mind in your back pocket, insisting that they're inherently different instead of possibly being part of our mental toolkit is premature.

Straight up banning ai won't solve this issue either. People will just commit code either way and simply won't tell you they used ai.

We've had low code tools before that caused similar issues. Nothing like AI though... I do agree with the other commenter here that a reputation system is probably the path forwar. Something like a minimum number of PRs accepted on gold standard projects or something? People will game that too though and post slop regardless... It's a fine line between making proof so onerous that nobody contributes, or so easy to get people just spin up new accounts to contribute and don't care if they get banned from projects.

Realistically AI is still heavily subsidized by circular financing and IOUs. The real cost of AI is still orders of magnitude more expensive (if you want to truly break even) so this might end up being a self solving problem once the AI bubble pops and it now costs $15 to shit out a slop PR

Well it's what maintainers are already doing. Closing community contributions or burning out. A reputation system can be gamed unless the requirements for contributing are so restrictive it kills contributions anyways since most people don't have the time and energy to get 100 PRs reviewed and accepted in a gold-standard group of projects to prove they won't suggest slop.

Honestly I think the solution is the true price of tokens being charged to end users. If it costs you $15 instead of $0.10 to generate a slop PR now you actually give a shit about how it works. I think we're heading there soon... Anthropic already hiked their prices 9-27X, and it looks like they need at least 2 more of those hikes in a row to begin to break even.

I think the eventual mature path for AI is as a coding assistant instead of autopilot. An expensive tool you use like an intern for making unit tests or finding a persistent bug in your code.

Eh...I don't know that that's a viable solution.

Take me, for example - I get $19 of tokens per month through one of my employers. That used to be more than enough to do nearly everything I wanted every month. Now, that's one minor feature per month. So I don't bother even using them. Instead, I use the GPU on my leisure/gaming laptop, and it processes all my LLM requests locally. So I have unlimited tokens.

I think the actual solution is patience. As the tools improved in quality, so too do the quality of the PR. Soon, I believe, they will be better quality than they have been ever before. If maintainers can just hold out that long ... 🤞

I don't know about that. The constraint seems to be context since AI struggles to hold all of the pieces for a project mentally while making changes like an experienced maintainer can. I find AI is a lot like using a credit card. It seems like free money at first until you start paying back the tech debt of a junior programmer who had no idea how to architect a project. You end up making your own legacy code base, except you were the one who made it... And because your context has long since been wiped clean from using your AI it can't remember why it did what it did.

"Only Claude and God knew what this did when Claude made this code. Now that it's context has expired, only God knows."

Copying is not theft.

better than Torvalds

Have you forgotten about Bitkeeper?

Copying GNU GPL code without licensing your derivative code as GNU GPL and publishing it where it's publicly accessible, and then using your derivative code to generate profit for a corporation, is definitely theft. Just because it's open source doesn't mean you can just do whatever you want with it, the original programmer still has rights over the code they wrote.

It literally isn't.