4 ms·

> The simple fact is: He did contribute, he just didn't get credited. The credit they deserves is identifying the issue - not for writing a patch that didn't p

> The simple fact is: He did contribute, he just didn't get credited. The credit they deserves is identifying the issue - not for writing a patch that didn't pass the bar (especially on security-report where maintainer gives critical priority, speedy review, extra focus on correctness, etc.). Had this been done on a non-security mailing list, their patch would probably have gotten in after a few iterations. EDIT: The original reporter was credited as "reported-by" in the patch, so removed the section saying there should be a standard for that.

birdyrooster 3y ago
If I submit a patch and a maintainer (or anyone else) reads it and writes their own based on it, then they have edited my work. If they don’t attribute me at all, then they are plagiarizing. Maybe there is no law to protect me, but it’s social contract.
- arghwhat 3y ago
  If it was taken verbatim, sure - while perfectly fine under the license, that would be a dick move. But you should also note that the commit contains an additional essay or two's worth of analysis and justification, and includes test sign-off from other people. Even if you disregard the difference in code, the difference in commits is huge. And as mentioned elsewhere, this issue was submitted to security@, triggering a machine optimized solely for resolving issues quickly and correctly for the safety of the user-base, and not one suited for training new contributors. If this was submitted normally, it's quite likely that this would have gotten merged after an iteration or two - which could easily have taken a week or more.
  - bluGill 3y ago
    Just because the patch was urgent is not an excuse for not giving proper credit. Co-author appears to be the minimum credit.
- guenthert 3y ago
  There are typically multiple ways to write code to address a given issue. They might differ in aesthetics (including clarity of intend), but also performance, maintainability, extensibility and robustness. It's not uncommon that those who wrote the code to be fixed rewrite the patch in order to improve on aforementioned properties while avoiding lengthy back-and-forth when asking for improvement of the patch. They are often in a better position to do so due to familiarity with the code, it's history and (unwritten) development path. That is by no means plagiarism. If not communicated clearly, can however lead to disappointment of those who submitted the patch. An 'inspired-by' comment would have been nice.
  - fleshdaddy 3y ago
    Yeah it just seems like a bad strategy on the maintainers part. Seems like one of those perfect places to teach a new contributor style guides and make them more useful in the future. To me approaching it this way comes off as disinterest in welcoming new contributors, which maybe now they’re not needed, but being so unwelcoming could one day leave us with no one capable of maintaining these projects.
  - foldr 3y ago
    It is plagiarism by definition if you don’t give credit to the person who wrote the original patch. Paraphrasing a source without citing it is certainly considered plagiarism in non-programming contexts (even if you think that you improved the prose style).
    - jacquesm 3y ago
      A patch, by definition is a modification of an existing piece of code, in this case a very small one. Now, it is possible that copyright protection would apply to such a small piece of code in that context but plagiarism usually does not involve a perfect record (the mailing list where the patch was submitted) that states exactly where the original work was submitted, what was done to it to make it ready for inclusion as well as an admonishment that the patch was not usable because it wasn't properly signed off. Plagiarism means that the kernel maintainer included the code and pretended that it was their original creation and nothing of the sort happened so I don't think that word should be used in this context. Nobody doubts the OP wrote the code, nobody is saying that they did not and nobody passes it off as their own.
- PH95VuimJjqBqy 3y ago
  The maintainer is responsible for quality and correctness. I don't know the specifics of this patch, but it's absolutely not strange for a maintainer to make changes with these goals in mind. Hell, maintainers are usually more aware of broader concerns than the contributor.
  - Arnavion 3y ago
    I don't know the specifics of the patch either since OP has not linked their patch nor the final kernel commit. I don't understand why being a private list would be a problem since they can just post their patch on their website. Maybe they're waiting for the fix to hit mainline first. But when someone submits a patch to any of my OSS projects and I want to make modifications to it before I merge it, I either keep the original author as the Author and make myself as Co-Authored-By, or make myself the Author and keep the original author as Co-Authored-By, depending on how much change I had to make to the original patch. In either case I also have the original author review my version to get their approval of my version. The only case where I would not credit the original author at all (or only as Reported-By) is if my version had absolutely nothing to do with their patch, say they fixed the symptom in file X and I fixed the cause in file Y. Edit: https://news.ycombinator.com/item?id=37674872 https://news.ycombinator.com/item?id=37674872 found the patches. If it was my project I'd consider these in the Author/Co-Authored-By category because they're basically the same patch.
light_hue_1 3y ago
The patch absolutely passed the bar. The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.
- sdflhasjd 3y ago
  I'd argue the differences are not just style changes and even "just style" changes are not trivial. The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
  - jabradoodle 3y ago
    After he did none of the hard part.
    - sangnoir 3y ago
      I'm sure other people did the "hard part" too for the Row hammer and Heartbleed bugs; which were even harder. All they got was credit in identifying the bugs; kernel-contributor-status is not a prize for doing hard work finding bugs.
      - deleted 3y ago
        [deleted]
      - jabradoodle 3y ago
        * OP didn't identify the bug, it had been reported years prior. OP identified the root cause and suggested a working fix. * What then is the hard part, if this is the "hard part" * What is kernel contributor status a "prize" for then, if not for contributing to the kernel? * Why all the focus on OP wanting recognition for the work, and 0 on the dev who merged the patch. Why not have all patches be merged by a committe/ someone who isn't the author.

birdyrooster 3y ago

If I submit a patch and a maintainer (or anyone else) reads it and writes their own based on it, then they have edited my work. If they don’t attribute me at all, then they are plagiarizing. Maybe there is no law to protect me, but it’s social contract.

arghwhat 3y ago
If it was taken verbatim, sure - while perfectly fine under the license, that would be a dick move. But you should also note that the commit contains an additional essay or two's worth of analysis and justification, and includes test sign-off from other people. Even if you disregard the difference in code, the difference in commits is huge. And as mentioned elsewhere, this issue was submitted to security@, triggering a machine optimized solely for resolving issues quickly and correctly for the safety of the user-base, and not one suited for training new contributors. If this was submitted normally, it's quite likely that this would have gotten merged after an iteration or two - which could easily have taken a week or more.
- bluGill 3y ago
  Just because the patch was urgent is not an excuse for not giving proper credit. Co-author appears to be the minimum credit.
guenthert 3y ago
There are typically multiple ways to write code to address a given issue. They might differ in aesthetics (including clarity of intend), but also performance, maintainability, extensibility and robustness. It's not uncommon that those who wrote the code to be fixed rewrite the patch in order to improve on aforementioned properties while avoiding lengthy back-and-forth when asking for improvement of the patch. They are often in a better position to do so due to familiarity with the code, it's history and (unwritten) development path. That is by no means plagiarism. If not communicated clearly, can however lead to disappointment of those who submitted the patch. An 'inspired-by' comment would have been nice.
- fleshdaddy 3y ago
  Yeah it just seems like a bad strategy on the maintainers part. Seems like one of those perfect places to teach a new contributor style guides and make them more useful in the future. To me approaching it this way comes off as disinterest in welcoming new contributors, which maybe now they’re not needed, but being so unwelcoming could one day leave us with no one capable of maintaining these projects.
- foldr 3y ago
  It is plagiarism by definition if you don’t give credit to the person who wrote the original patch. Paraphrasing a source without citing it is certainly considered plagiarism in non-programming contexts (even if you think that you improved the prose style).
  - jacquesm 3y ago
    A patch, by definition is a modification of an existing piece of code, in this case a very small one. Now, it is possible that copyright protection would apply to such a small piece of code in that context but plagiarism usually does not involve a perfect record (the mailing list where the patch was submitted) that states exactly where the original work was submitted, what was done to it to make it ready for inclusion as well as an admonishment that the patch was not usable because it wasn't properly signed off. Plagiarism means that the kernel maintainer included the code and pretended that it was their original creation and nothing of the sort happened so I don't think that word should be used in this context. Nobody doubts the OP wrote the code, nobody is saying that they did not and nobody passes it off as their own.
PH95VuimJjqBqy 3y ago
The maintainer is responsible for quality and correctness. I don't know the specifics of this patch, but it's absolutely not strange for a maintainer to make changes with these goals in mind. Hell, maintainers are usually more aware of broader concerns than the contributor.
- Arnavion 3y ago
  I don't know the specifics of the patch either since OP has not linked their patch nor the final kernel commit. I don't understand why being a private list would be a problem since they can just post their patch on their website. Maybe they're waiting for the fix to hit mainline first. But when someone submits a patch to any of my OSS projects and I want to make modifications to it before I merge it, I either keep the original author as the Author and make myself as Co-Authored-By, or make myself the Author and keep the original author as Co-Authored-By, depending on how much change I had to make to the original patch. In either case I also have the original author review my version to get their approval of my version. The only case where I would not credit the original author at all (or only as Reported-By) is if my version had absolutely nothing to do with their patch, say they fixed the symptom in file X and I fixed the cause in file Y. Edit: https://news.ycombinator.com/item?id=37674872 https://news.ycombinator.com/item?id=37674872 found the patches. If it was my project I'd consider these in the Author/Co-Authored-By category because they're basically the same patch.

light_hue_1 3y ago

The patch absolutely passed the bar. The only difference between the patch that was accepted and the one that was proposed is where the fix is. In one case it's in an ifdef outside of an if. In the other it's in an inner if statement. That's it. This is a difference in style not a technical difference in the patch at all.

sdflhasjd 3y ago
I'd argue the differences are not just style changes and even "just style" changes are not trivial. The kernel style guide specifically mentions to avoid using conditional compilation where possible, and as a result, Michael Ellerman's patch is far cleaner.
- jabradoodle 3y ago
  After he did none of the hard part.
  - sangnoir 3y ago
    I'm sure other people did the "hard part" too for the Row hammer and Heartbleed bugs; which were even harder. All they got was credit in identifying the bugs; kernel-contributor-status is not a prize for doing hard work finding bugs.
    - deleted 3y ago
      [deleted]
    - jabradoodle 3y ago
      * OP didn't identify the bug, it had been reported years prior. OP identified the root cause and suggested a working fix. * What then is the hard part, if this is the "hard part" * What is kernel contributor status a "prize" for then, if not for contributing to the kernel? * Why all the focus on OP wanting recognition for the work, and 0 on the dev who merged the patch. Why not have all patches be merged by a committe/ someone who isn't the author.