Linux is founded by all these big companies. Linus couldn't block AI pushes from them forever.
This is some ridiculous cope.
AI assistance when contributing to the Linux kernel
371–380 of 464 posts
Re: AI assistance when contributing to the Linux kernel
#372A phenomenon I can not explain is the fact that this simple clean statement of a fairly obvious approach to AI assistance somehow took this long and Linus to state so cleanly. Are there other popular repos with effectively this policy stated as neatly that I’ve missed?
We've had this for a while now: https://github.com/open-telemetry/community/blob/main/polici...
Re: AI assistance when contributing to the Linux kernel
#373Earlier quoted context omitted.
What is it that worries you about the change that is happening?
All kinds of worries are possible. (1) It turns out that all this AI generated stuff is full of bugs and we go back to traditional software development, creating a giant disinvestment and economic downturn. (2) sofware quality going way down. we cannot produce reliable programs anymore. (3) massive energy use makes it impossible to use sustainable energy sources and we wreck the environment every more than we are cur…
1 and 2 are really only an issue if you vibe code. There's no reason to expect properly reviewed AI assisted code to be any worse than human written code. In fact, in my experience, using LLMs to do a code review is a great asset - of used in addition to human review
Re: AI assistance when contributing to the Linux kernel
#374Earlier quoted context omitted.
What is it that worries you about the change that is happening?
People have measurably lower levels of ownership and understanding of AI generated code. The people using GenAI reap a major time and cognitive effort savings, but the task of verification is shifted to the maintainer. In essence, we get the output without the matching mental structures being developed in humans. This is great if you have nothing left to learn, its not that great if you are a newbie, or have low conf…
> The people using GenAI reap a major time and cognitive effort savings, but the task of verification is shifted to the maintainer.
The people using GenAI should be the ones doing the verification. The maintainer's job should not meaningfully change (other than the maintainer using AI to review on incoming code, of course).
Why does everyone who hears "AI code" automatically think "vibe-coded"?
Re: AI assistance when contributing to the Linux kernel
#375Earlier quoted context omitted.
You take responsibility. That means if the AI messes up, you get punished. No pushing blame onto the stupid computer. If you're not comfortable with that, don't use the AI.
There’s no reasonable way for you to use AI generated code and guarantee it doesn’t infringe. The whole use it but if it behaves as expected, it’s your fault is a ridiculous stance.
>There’s no reasonable way for you to use AI generated code and guarantee it doesn’t infringe.
I guess we’ll need to reevaluate what copy rights mean when derivatives grow on trees?
Re: AI assistance when contributing to the Linux kernel
#376Earlier quoted context omitted.
> liability could very likely also fall on the Linux foundation. It’s just the same as if I copy-paste proprietary code into the kernel and lie about it being GPL. Is the Linux foundation liable there?
Maybe. DCOs haven’t been tested. But you can at least say that the person who did this committed fraud and that you had no reasonable way to know they would do that. LLMs can and do regurgitate code without the user’s knowledge. That’s the problem, the user has no way to mitigate against it. You’re telling contributors “use this thing that has a random chance of creating infringing code”. You should have foreseen tha…
If someone sent you some code and said “it’s all good bro, you can put it in the kernel with your name on it”, would you?
If you don’t feel comfortable about where some code has come from, don’t sign your name.
The fact LLMs exist and can generate code doesn’t change how you would behave and sign your name to guarantee something.
Re: AI assistance when contributing to the Linux kernel
#377Earlier quoted context omitted.
> This does nothing to shield Linux from responsibility for infringing code. It’s no worse than non-AI assisted code. I could easily copy-paste proprietary code, sign my name that it’s not and that it complies with the GPL and submit it. At the end of the day, it just comes down to a lying human.
That’s the difference. In practice a human has to commit fraud to do this. But a human just using an LLM to generate code will do it accidentally. The difference is that regurgitation of training text is a documented failure mode of LLMs. And there’s no way for the human using it to be aware it’s happening.
You can not accidentally sign your name saying “this code is GPL compliant”
If you can’t be sure, don’t sign.
Re: AI assistance when contributing to the Linux kernel
#378Earlier quoted context omitted.
There's a stark difference between a table saw and an LLM that weakens this argument. A table saw isn't a probabilistic device.
But I, a woodworker, can immediately see if the piece of wood that came out of the table saw looks like it should. Also I, a programmer, can immediately see whether the "probabilistic device" generated code that looks like it should. Both just let me get to the same result faster with good enough quality for the situation. I can grab a tape measure or calipers and examine the piece of wood I cut on the table saw and…
Also I, a programmer, can immediately see whether the "probabilistic device" generated code that looks like it should.
I highly doubt that.
Empirical studies show that humans have very little effect on error rates when reviewing code. That effect disappears quickly the more code you read.
Most programmers are bad at detecting UB and memory ownership and lifetime errors.
A piece of wood comes off the table it’s cut or it’s not.
Code is far more complex.
Re: AI assistance when contributing to the Linux kernel
#379Earlier quoted context omitted.
What would be "discovered" exactly? You can't patent a basic CRUD application. There has to be an analogy to music or something here - except that code is even less copyrightable than melodies. Yes, there might be some specific algorithms that are patented, but the average programmer won't be implementing any of those from scratch, they'll use libraries anyway.
I’m not talking patents. Code is 100% copyrightable. Code being copyrightable is the entire basis for open source licenses.
s/patent/copyright/ in my comment then.
What part of a bog-standard HTTP API can be copyrighted? Parsing the POST request or processing it or shoving it to storage? I'm genuinely confused here and not just being an ass.
There are unique algorithms for things like media compression etc, I understand copyrighting those.
But for the vast majority of software, is there any realistic threat of hitting any copyrighted code that's so unique it has been copyrighted and can be determined as such? There are only so many ways you can do a specific common thing.
I kinda think of it like music, without ever hearing a specific song you might hit the same chord progressions by accident because in reality there are only so many combinations you can make with notes that sound good.
Re: AI assistance when contributing to the Linux kernel
#380Earlier quoted context omitted.
But I, a woodworker, can immediately see if the piece of wood that came out of the table saw looks like it should. Also I, a programmer, can immediately see whether the "probabilistic device" generated code that looks like it should. Both just let me get to the same result faster with good enough quality for the situation. I can grab a tape measure or calipers and examine the piece of wood I cut on the table saw and…
Also I, a programmer, can immediately see whether the "probabilistic device" generated code that looks like it should. I highly doubt that. Empirical studies show that humans have very little effect on error rates when reviewing code. That effect disappears quickly the more code you read. Most programmers are bad at detecting UB and memory ownership and lifetime errors. A piece of wood comes off the table it’s cut or…
> Most programmers are bad at detecting UB and memory ownership and lifetime errors.
And this is why we have languages and tooling that takes care of it.
There's only a handful of people who can one-shot perfect code in a language that doesn't guard against memory ownership or lifetime errors every time.
But even the crappiest programmer has to actually work against the tooling in a language like Rust to ownership issues. Add linters, formatters and unit tests on top of that and it becomes nigh-impossible.
Now put an LLM in the same position, it's also unable to create shitty code when the tooling prevents it from doing so.