Well, for me the bar for plagiarism is apparently higher than for you, for me it is 'passing something off as your own' and that never happened here. I'm open to other definitions that I'm not currently aware of.
The commit log and associated metadata misrepresent the authorship of the code.
I am using the bar that you can find by googling 'plagiarism policy' and reading any number of documents explaining what constitutes plagiarism in an academic context.
Plagiarism is not a crime, so the kernel maintainers can choose to decide that it's socially acceptable in the context of kernel development if they want to.
I'm not sure if I'd agree with a 'very large chunk', but certainly I don't think this is an isolated incident. It's just that people don't usually make a fuss.
I think the basic issue stems from the fact that LKML sees patches as 'proposals' unless they can be included as is without further work. And any would-be contributor would be (heh) able to see that for themselves by looking at the many years of documented interaction between maintainers and the general public.
These long running projects all have their own styles and conventions for interaction (LKML itself being one of those) and the onus is on newcomers to familiarize themselves with that. Authorship, especially in the context of a project of this magnitude and with so many different people maintaining different parts of it is always going to be somewhat nebulous, because after all, you're changing a tiny little bit in a huge machine and anything worthy of copyright is usually expected to stand alone as a 'work'. That's definitely not the case here. And so the sign-off becomes a critical bit, if you omit that then you've just created a problem for the maintainer. Personally, I would never expect to be named author of a patch sent to the kernel mailing list, but if I wrote a sizeable subsystem then I would definitely expect that kind of recognition.
For patches like this your pay-off is the fact that they are taken into consideration at all.
