> From the exchange between the OP and the kernel maintainer. Which may have been the whole issue.

Well, if it was, the maintainer didn't communicate that well/at all:

"I prefer my version".

That was made up by the OP.

> Well, if it was, the maintainer didn't communicate that well/at all:

You're making the mistake of accepting at face value a one-sided account of an issue, and in the process failing to even check what the answer actually was.

None of that changes the fact that the original patch is copyright by the author, and it is highly likely the courts will consider the changes style issues which do not change copyright ownership. Unless the kernel maintainer can show he didn't look at the patch, only the description of the issue and then recreated the patch from scratch.

Oh, we're going to court now?

Seriously, this is getting way out of hand: when contributing to a project that has been going for more than a few decades you need to first familiarize yourself with how things are done to set your expectations for the interaction appropriately. The Linux kernel group does a pretty good job and they have their own ways of doing things. It's custom - and polite - to get the lay of the land before yelling 'robbery' when what actually happened is exactly what is supposed to happen: the bug got fixed, you got credited for the report and the maintainer spent some of their - precious - time on getting your proposal - because that is what a patch sent to LKML is - fixed and included.

And that's ignoring for the moment the fact that the interaction wasn't at all like the OP suggested it was.

If it were me I wouldn't think it was getting out of hand. Kernel contributions are the kind of thing that goes on your resumé and can land you a dream job. I would look into courts too.

Then please never submit any patches to LKML because the last thing a maintainer needs is a court case from some entitled newbie that can't be bothered to read the documentation and on top of that is so focused on accreditation that they are willing to go nuclear over a teensy contribution.

FWIW a submission to LKML does not come with any kind of guarantees for either accreditation, use, timeliness or consideration. You are making a small gift to the Linux kernel and all of its users and as such you are being thanked. Hopefully you got more value out of the Linux kernel than you contributed on account of the work that others have put in. The LKML record will suffice to prove your claims of copyright but realize that your work does not stand on its own, it is always going to be within a larger context. Try affixing a (C) Worewood to a patch you intend for inclusion and send it to LKML and see how you'll fare.

The fact that this kind of kernel patch is in any way relevant to one's resume is exactly the thing that is getting out of hand. And the author links to his linkedin profile in the footer, and well, the reference to this patch/contribution/whatever is there, unsurprisingly (and it is the only thing there that they cared about enough to expand upon).

Going to court about this is a right. It might not be a good idea, it might not be worth it, but it is a right.

> The Linux kernel group does a pretty good job and they have their own ways of doing things

I'm not saying otherwise. However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change. Yes the maintainer spent time, but it appears like more credit is being claimed by the maintainer than is deserved, credit that should go to the patch submitter. It doesn't matter if this is normal Linux process, it is still wrong and the maintainers should change their process to be morally correct.

Of course I don't know if the interaction was as OP claims or not. I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)

> However their own ways of doing things appear to be illegal in regard to copyright, and if so they need to change.

I think they're doing things as 'by the book' as possible.

> Of course I don't know if the interaction was as OP claims or not.

Well, he documented it twice and those two accounts differ considerably.

> I'm not really interested in digging into it more. Unless I'm on a jury I won't (and a jury is not allowed to dig into it - but that is a different discussion)

Who will the OP sue?

For what exactly?

In which court?

None of this makes any sense. If you think the possible outcome of submitting an unsolicited small and broken patch to a security mailing list of a major FOSS project is going to result in you taking anybody to court for copyright infringement then it probably is a great idea not to contribute at all, this will save everybody time and grief. Besides that: the OP - as far as I'm concerned - has copyright to their contribution to LKML, note that nobody except for the OP claims that this is not the case.

It's interesting how for instance all of the comments written in this forum are technically copyrighted by their writers. But you don't control them after submitting them because of the way the forum is structured, the jurisdiction that it is run from and the expectations that come with forum comments. LKML patch submissions are like that as well: they come with a whole pile of baked in assumptions that the OP apparently wasn't familiar with. The idea that each and every minor patch author, especially of patches that are broken and that do not contain required elements is going to end up being hand-held through the process of making a proper contribution is ridiculous.

The maintainers work-load is such that the pay-off is that your contribution is looked at at all, better still if it results in a fix (even if it isn't literally yours). And if you want credit then you should at least state that up front so that the maintainer has a chance to work with you out of the spotlight until you're ready to submit your patch publicly.

Threatening to sue on account of something like this is exactly why I would never be the maintainer of a major open source project, life is too short to deal with all the drama and entitlement.