I think what it means is "we will judge you based on the code you submit, we don't care if it comes from an AI". Also probably "we will judge you if you obviously don't understand the code you submit".

At least that's how I do it. When someone offers a patch to an open source project, I don't really care if that person has a PhD, or if that person does this in their free time, or if that patch is actually the result of a whole team working together. I judge the patch based on the value it brings to me as a maintainer.

Obviously the code has to be good, but also the interaction with whoever offers the patch has to be smooth: if I have a question, if I need them to confirm/change/test/elaborate on something, I need that to work.

If I feel like I would be faster doing the work myself AND this author is not putting effort into it (e.g. they just copy-paste an AI), I will not review that work. Possibly I will distrust that author. If too many contributions end up wasting my time, I will start limiting the contributions to people I know/trust, etc.

In terms of maintenance, I don't see a difference between getting a contribution from a stranger or from a stranger using an AI.

In terms of philosophy, that's obviously different: One may not want to accept contributions from people using AI because they think that AI is bad for society, for instance. And I would totally understand that. But if the stance (and it seems to be Linus' stance) is that a patch is only judged based on its technical merit, then I don't see why AI-in-the-loop would be an issue.

> In terms of maintenance, I don't see a difference between getting a contribution from a stranger or from a stranger using an AI.

Perhaps not in terms of maintenance. In terms of provenance there is a significant difference between "I wrote this." and "I found this."

I meant as a maintainer. As a maintainer, I receive patches from contributors, I decide if I merge them or not (and under which conditions), and then I take ownership of the merged patch (as in, if it breaks I am responsible for getting it fixed).

Which means that "as a maintainer", I don't write anything. I merge code that falls from the sky. Whether it was an AI cloud or a manual-coding cloud, I don't know: from where I stand, it falls from the sky.

> there is a significant difference between "I wrote this." and "I found this."

Of course. When I write code ("I wrote this"), then it does not fall from the sky: I wrote it. I know, it's me :-). But in the open source world, being a maintainer means that you deal with code that falls from the sky. Unless you decide to close your project to contributions and only accept people you trust.

> In terms of provenance there is a significant difference between "I wrote this." and "I found this."

That's very well put. I'm stealing your wording.

This was my take on it as well. Which in many ways makes a lot of sense and is pragmatic.

The thing which I think is going to be a very sore lesson for everyone at some point is that if anyone uses AI it becomes a burden for everyone. Even in projects that reject all AI usage.

What I can do is create 50 personas that all contribute patches. 40 of them get called out and are distrusted, but 10 make it through. I can give more focus on those 10 to ensure their trust level increases. Then slowly have them all come together to shepard some subsystem where I'm going to be the only real person involved and can sign off on my own work in a that looks like I have oversight from the outside.

In the past this was possible but took a very high cost. You need a bunch of competent software engineers who you can trust not to blab their secret mission. Today anyone can give it a try.

I don't disagree, and AI helps scaling many things: good work, bad work, malware.

However, I remember that a couple of university researchers (PhD candidates maybe?) thought it would be a good idea to introduce security issues in Linux, and managed to do it. Without AI and without a lot of resources.

A consequence of that was that Linux immediately reverted all the patches coming from that university, saying "we don't know if we can trust you guys" (but really I guess as a way to tell universities "if you fuck with us we ban you, now keep your people in line").

And that's what I was thinking about when I said that if too many contributors misbehave, as a maintainer I will just stop accepting contributions from people I don't know. And maybe that will happen. Maybe it will be harder and harder to just be accepted into the club of the people who can send a contribution and have it reviewed at all.

I've never been involved with Linux kernel work, but in terms of the "You, as a person, not the AI, are responsible for the quality" policy, this to me is a just an "obvious" policy that should be applied to any non-vibe-coded software.

It's just another way of saying, you can't have AI submit things on its own and you can't "blame" AI for anything you submit, you're expected to understand and be able to explain anything you're putting forward, if there is an issue with your submission, doesn't matter at all if you go back to AI to address it, so long as all issues are properly addressed.

The code is either of sufficient quality, or it's not, doesn't matter whether you or AI wrote it, it's your name on it, you're responsible for it and its your reputation on the line.

I agree, I was writing something along those lines but with more words (which is not a good thing) :-).

> should be applied to any non-vibe-coded software

Should be applied to anything someone is releasing without big disclosures.

At least until a few months from now when it will be clear that human code is the weak point.

The problem with this policy is that it works well when dealing with individuals, but you can still be swamped by "first-time sloppers" - sure, each one cannot ever submit again because it's low-quality slop, but the damage is done.

(And in reality EVERYONE's AI policy is a variation of this no matter how strict they get, because very few people will suddenly rip all of tridge's code out of Samba if he admits he used AI once, and nobody can withstand slopspam for long.)

Basically, you can't just post slop and then say, "Oh, sorry, the AI did that." If the comments are too wordy, or the patch is unnecessary or poorly written or contains errors or doesn't follow the style guide, you submitted it, so that's on you. If you get in the habit of posting bad patches, people may start ignoring you.

Don't forget having Linus Torvalds ridicule you in front of the entire world. That alone is reason to be vigilant that your code submitted isn't hot garbage.

Being responsible for the quality of the submission means that when other kernel developers say, "hey this part sucks, please fix it," you are obligated to fix it or defend your position, if you want the patch to be accepted into the kernel.

That last part is worth highlighting: you always have the option to not follow-up and abandon your proposed change, in which case it won't make it into the kernel. (Unless someone else picks it up and volunteers to get it into shape for that is acceptable for merging into the kernel, but that is vanishingly rare, unless the change is trivial.)

You aren't expected to hang around and maintain your patch once merged, that's what subsystem maintainers are for. But you would be making their lives a lot easier and earn a lot of respect if you did.