Live data from Hacker News

AI assistance when contributing to the Linux kernel

github.com

121–130 of 464 posts

Re: AI assistance when contributing to the Linux kernel

#121
post #28

Earlier quoted context omitted.

And yet it puts a stop to the tsunami of slop and it's pretty much impossible to prove anything of value was lost.

but why? it's a human making the PR and you can shame/ban that human anyway.

I think AI bans are more common in projects where the maintainers are nice people that thoughtfully want to consider each PR and provide a reasoned response if rejected.

That’s only feasible when the people who open PRs are acting in good faith, and control both the quality and volume of PRs to something that the maintainers can realistically (and ought to) review in their 2-3 hours of weekly free time.

Linux is a bit different. Your code can be rejected, or not even looked at in the first place, if it’s not a high quality and desired contribution.

Also, it’s not just about PR quality, but also volume. It’s possible for contributions to be a net benefit in isolation. But most open source maintainers only have an hour or so a week to review PRs and need to prioritize aggressively. People who code with AI agents would benefit themselves to ask “does this PR align with the priorities and time availability of the maintainer?”

For instance, I’m sure we could point AI at many open source projects and tell it to optimize performance. And the agent would produce a bunch of high quality PRs that are a good idea in isolation. But what if performance optimization isn’t a good use of time for a given maintainer’s weekly code review quota?

Sure, maintainers can simply close the PR without a reason if they don’t have time.

But I fear we are taking advantage of nice people, who want to give a reasoned response to every contribution, but simply can’t keep up with the volume that agents can produce.

Re: AI assistance when contributing to the Linux kernel

#122

Earlier quoted context omitted.

Right now it's very easy not to infringe on copyrighted code if you write the code yourself. In the vast majority of cases if you infringed it's because you did something wrong that you could have prevented (in the case where you didn't do anything wrong, inducement creation is an affirmative defense against copyright infringement). That is not the case when using AI generated code. There is no way to use it without…

> Right now it's very easy not to infringe on copyrighted code if you write the code yourself. Humans routinely produce code similar to or identical to existing copyrighted code without direct copying.

They don’t produce enough similar code to infringe frequently. And if they did independent creation is an affirmative defense to copyright infringement that likely doesn’t apply to LLMs since they have the demonstrated capability to produce code directly from their training set.

Re: AI assistance when contributing to the Linux kernel

#123
post #97

Earlier quoted context omitted.

In a court case the responsibility party very well could be the Linux foundation because this is a foreseeable consequence of allowing AI contributions. There’s no reasonable way for a human to make such a guarantee while using AI generated code.

Because contributions to Linux are meticulously attributed to, and remain property of, their authors, those authors bear ultimate responsibility. If Fred Foobar sends patches to the kernel that, as it turns out, contain copyrighted code, then provided upstream maintainers did reasonable due diligence the court will go after Fred Foobar for damages, and quite likely demand that the kernel organization no longer distri…

Anyone distributing infringing material can be liable, and it’s unlikely that this technicality will actually would shield anyone.

Anyone who thinks they have a strong infringement case isn’t going to stop at the guy who authored the code, they’re going to go after anyone with deep pockets with a good chance of winning.

Re: AI assistance when contributing to the Linux kernel

#124

Earlier quoted context omitted.

> Right now it's very easy not to infringe on copyrighted code if you write the code yourself. Humans routinely produce code similar to or identical to existing copyrighted code without direct copying.

They don’t produce enough similar code to infringe frequently. And if they did independent creation is an affirmative defense to copyright infringement that likely doesn’t apply to LLMs since they have the demonstrated capability to produce code directly from their training set.

You have shifted from "very easy not to infringe" to "don't infringe frequently", which concedes the original point that humans can and do produce infringing code without intent.

On independent creation: you are conflating the tool with the user. The defense applies to whether the developer had access to the copyrighted work, not whether their tools did. A developer using an LLM did not access the training set directly, they used a synthesis tool. By your logic, any developer who has read GPL code on GitHub should lose independent creation defense because they have "demonstrated capability to produce code directly from" their memory.

LLM memorization/regurgitation is a documented failure mode, not normal operation (nor typical case). Training set contamination happens, but it is rare and considered a bug. Humans also occasionally reproduce code from memory: we do not deny them independent creation defense wholesale because of that capability!

In any case, the legal question is not settled, but the argument that LLM-assisted code categorically cannot qualify for independent creation defense creates a double standard that human-written code does not face.

Re: AI assistance when contributing to the Linux kernel

#125

Earlier quoted context omitted.

That’s just it though it’s not just your head. The liability could very likely also fall on the Linux foundation. You can’t say “you can do this thing that we know will cause problems that you have no way to mitigate, but if it does we’re not liable”. The infringement was a foreseeable consequence of the policy.

The only lawsuits so far have been over training on open source software. You're inventing a liability problem that essentially does not exist.

OpenAI and Anthropic added an indemnity clause to their enterprise contracts specifically to cover this scenario because companies wouldn’t adopt otherwise.

Re: AI assistance when contributing to the Linux kernel

#126

Earlier quoted context omitted.

That’s just it though it’s not just your head. The liability could very likely also fall on the Linux foundation. You can’t say “you can do this thing that we know will cause problems that you have no way to mitigate, but if it does we’re not liable”. The infringement was a foreseeable consequence of the policy.

This policy effectively punts on the question of what tools were used to create the contribution, and states that regardless of how the code was made, only humans may be considered authors. From the foundation's point of view, humans are just as capable of submitting infringing code as AI is. If your argument is sound, then how can Linux accept contributors at all? EDIT: To answer my own question: Instead of a signed…

Anyone distributing copyrighted material can be liable that DCO isn’t going to stop anyone.

If that worked any corporation that wanted to use code they legally couldn’t could just use a fork from someone who assumed responsibility and worst case they’d have to stop using it if someone found out.

Re: AI assistance when contributing to the Linux kernel

#127

Earlier quoted context omitted.

Yeah, but that's not a useful thing to do because not everybody thinks about that or considers it a problem. If somebody's careless and contributes copyrighted code, that's a problem for linux too, not only the author. For comparison, you wouldn't say, "you're free to use a pair of dice to decide what material to build the bridge out of, as long as you take responsibility if it falls down", because then of course som…

It was already necessary to solve the problem of humans contributing infringing code. It was solved by having contributors assume liability with a DCO. The policy being discussed today asserts that, because AI may not be held legally liable for its contributions, AI may not sign a DCO. A human signature is required. This puts the situation back to what it was with human contributors. What you are proposing goes beyon…

It’s not solved. It hasn’t been tested in court to my knowledge and in my opinion is unlikely to hold up to serious challenge. You can be held liable for just distributing copyrighted code even if the whole “the Linux foundation doesn’t own anything” holds up.

Re: AI assistance when contributing to the Linux kernel

#128
post #118

Earlier quoted context omitted.

That is a nonsensical analogy on multiple levels, and doesn't even support your own argument.

Nice rebuttal.

Why would I put much effort into responding to a post like yours, which makes no sense and just shows that you don't understand what you're talking about?

Re: AI assistance when contributing to the Linux kernel

#129
post #90
post #40

Earlier quoted context omitted.

That's not going to shield the Linux organization.

A DCO bearing a claim of original authorship (or assertion of other permitted use) isn't going to shield them entirely, but it can mitigate liability and damages.

Can it though? As far as I know this hasn’t been tested.

Re: AI assistance when contributing to the Linux kernel

#130
post #21

Earlier quoted context omitted.

Not insane at all. Just a very useful shortcut. Not everyone wants to move fast and break shit.

I still think it's insane, why would you care about the "origin" of the code as long as there is a human accountable (that you can ban anyway)?

Because they aren’t accountable - after it is merged only I am. And why would I want to go back and forth with an LLM through PR comments when I could just talk to the agent myself in real time? Anytime I want to work through a pile of slop I can ask for one, but I don’t work that way. I work with the agent to create plans first and refine them, and the author of a PR who couldn’t do that adds nothing.
Post reply on HN