Live data from Hacker News

AI assistance when contributing to the Linux kernel

github.com

181–190 of 464 posts

Re: AI assistance when contributing to the Linux kernel

#181

This feels like the OSS community is giving up. LLMs are lossily-compressed models of code and other text (often mass-scraped despite explicit non-consent) which has licenses almost always requiring attribution and very often other conditions. Just a few weeks ago a SOTA model was shown to reproduce non-trivial amounts of licensed code[0]. The idea of intelligence being emergent from compression is nothing new[1]. Th…

[deleted]

Re: AI assistance when contributing to the Linux kernel

#182
post #60

Earlier quoted context omitted.

In this case, the "fall guy" is the person who actually introduced the code in question into the codebase. They wouldn't be some patsy that is around just to take blame, but the actual responsible party for the issue.

Imagine your a factory owner and you need a chemical delivered from across the country, but the chemical is dangerous and if the tanker truck drives faster than 50 miles per hour it has a 0.001% chance per mile of exploding. You hire an independent contractor and tell him that he can drive 60 miles per hour if he wants to but if it explodes he accepts responsibility. He does and it explodes killing 10 people. If the…

Cool analogy! Which has nothing to do with the topic in hand.

Re: AI assistance when contributing to the Linux kernel

#183

The policy makes sense as a liability shield, but it doesn't address the actual problem, which is review bandwidth. A human signs off on AI-generated code they don't fully understand, the patch looks fine, it gets merged. Six months later someone finds a subtle bug in an edge case no reviewer would've caught because the code was "too clean."

> they don't fully understand, the patch looks fine

I don't get this part. Why is the reviewer signing off on it? AI code should be fully documented (probably more so than a human could) and require new tests. Code review gates should not change

Re: AI assistance when contributing to the Linux kernel

#184
post #5

Basically the rules are that you can use AI, but you take full responsibility for your commits and code must satisfy the license. That's... refreshingly normal? Surely something most people acting in good faith can get behind.

It cannot be understated how religiously opposed many in the Linux community are to even a single AI assisted commit landing in the kernel no matter how well reviewed.

Plenty see Torvalds as a traitor for this policy and will never contribute again if any clearly labeled AI generated code is actually allowed to merge.

Re: AI assistance when contributing to the Linux kernel

#185

Earlier quoted context omitted.

AIs are not human and therefore their output is a human authored contribution and only human authored things are covered by copyright. The work might hypothetically infringe on other people's copyright. But such an infringement does not happen until a human decides to create and distribute a work that somehow integrates that generated code or text. The solution documented here seems very pragmatic. You as a contribut…

That you can't copyright the AI's output (in the US, at least), doesn't imply it doesn't contain copyrighted material. If you generate an image of a Disney character, Disney still owns the copyright to that character.

You can copyright AI output assuming there is a "reasonable" degree of human involvement. https://www.cnet.com/tech/services-and-software/this-company...

Re: AI assistance when contributing to the Linux kernel

#186
post #5

Basically the rules are that you can use AI, but you take full responsibility for your commits and code must satisfy the license. That's... refreshingly normal? Surely something most people acting in good faith can get behind.

But why should AI then be attributed if it is merely a tool that is used?

AI tools can do the entire job from finding the problem, implementing and testing it.

It's different from the regular single purpose static tools.

Re: AI assistance when contributing to the Linux kernel

#187
Interesting that coccinelle, sparse, smatch & clang-tidy are included, at least as examples. Those aren't AI coding tools in the normal sense, just regular, deterministic static analysis / code generation tools. But fine, I guess.

We've been using Co-Developed-By: for our AI annotations.

Re: AI assistance when contributing to the Linux kernel

#188
post #5

Basically the rules are that you can use AI, but you take full responsibility for your commits and code must satisfy the license. That's... refreshingly normal? Surely something most people acting in good faith can get behind.

But then if AI output is not under GNU General Public License, how can it become so just because a Linux-developer adds it to the code-base?

There is already lots and lots of non-GPL code in the kernel, under dozens of licenses, see https://raw.githubusercontent.com/Open-Source-Compliance/pac...

As long as everything is GPLv2-compatible it‘s okay.

Re: AI assistance when contributing to the Linux kernel

#189

Earlier quoted context omitted.

No, a court did not declare that. The case involved a person trying to register a work with only the AI system listed as author. The Supreme Court decided that you can't do that, you need to list a human being as author to register a work with the Copyright Office. This stems from existing precedent where someone tried to register a photograph with the monkey photographer listed as author. I don't believe the idea th…

I’m curious to see if subscription vs free ends up mattering here. If it is a work for hire, generally it doesn’t matter how the work was produced, the end result is mine, because I contracted and instructed (prompted?) someone to do it for me. So will the copyright office decide it cares if I paid for the AI tool explicitly?

That would depend on whether those who sold you the software-output, had copyright to it.

Re: AI assistance when contributing to the Linux kernel

#190

> Signed-Off ... > The human submitter is responsible for: > Reviewing all AI-generated code > Ensuring compliance with licensing requirements > Adding their own Signed-off-by tag to certify the DCO > Taking full responsibility for the contribution > Attribution: ... Contributions should include an Assisted-by tag in the following format: Responsibility assigned to where it should lie. Expected no less from Torvalds,…

Signed-off-by is already a custom/formality that is surely cargo-culted by many first-time/infrequent contributors. It has an air of "the plans were on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'" There's no way to assert that every contributor has read a random document declaring what that line means in kernel parlance. I recent…

The way you describe it, the developers all did the right thing. You contributed something to the patch, and even if it wasn't in your preferred final form (and it's basically never going to be for a kernel contribution of any significance), you were correctly credited.

If you didn't want to be credited you should have said.

Signed-off-by probably has some legal weight. When you add that to code you are making a clear statement about the origins of the code and that you have legal authority to contribute it - for example, that you asked your company for permission if needed. As far as I know none of this has been tested in court, but it seems reasonable to assume it might be one day.

Post reply on HN