Comment by alxlaz
4 years ago
This is, at the very least, worth an investigation from an ethics committee.
First of all, this is completely irresponsible, what if the patches would've made their way into a real-life device? The paper does mention a process through which they tried to ensure that doesn't happen, but it's pretty finicky. It's one missed email or one bad timezone mismatch away from releasing the kraken.
Then playing the slander victim card is outright stupid, it hurts the credibility of actual victims.
The mandate of IRBs in the US is pretty weird but the debate about whether this was "human subject research" or not is silly, there are many other ethical and legal requirements to academic research besides Title 45.
> there are many other ethical and legal requirements to academic research besides Title 45.
Right. It's not just human subjects research. IRBs vet all kinds of research: polling, surveys, animal subjects research, genetics/embryo research (potentially even if not human/mammal), anything which could be remotely interpreted as ethically marginal.
If we took the case into the real world and it became "we decided to research how many supports we could remove from this major road bridge before someone noticed", I'd hope the IRB wouldn't just write it off as "not human research so we don't care".
I agree. I personally don't care if it meets the official definition of human subject research. It was unethical, regardless of whether it met the definition or not. I think the ban is appropriate and wouldn't lose any sleep if the ban also enacted by other open-source projects and communities.
It's a real shame because the university probably has good, experienced people who could contribute to various OSS projects. But how can you trust any of them when the next guy might also be running an IRB exempt security study.
Okay, by that logic we should ban anything that comes out of Facebook
There are a lot of people who in fact do consider “research” that comes out of social media companies to be both ethically and, in many cases, procedurally tainted, and thus unusable and unpublishable as-is.
>It's one missed email or one bad timezone mismatch away from releasing the kraken.
I don't think code commits to the Linux kernel make it to live systems that fast?
I do agree with the sentiment, though. It's grossly irresponsible to do that without asking at least someone in the kernel developer's group. People don't dig being used as lab rats, and now the whole uni is blocked. Well, tough shit.
No, but they're very high-traffic and if the "this was a deliberately bad patch" message is sent off-list, only to the maintainer, things can go south pretty easily. Off-list messages are easy to miss on inboxes whose email is in MAINTAINERS and receive a lot of spam, you can email someone right as they're going on vacation and so on. That's one of the reasons why a lot of development happens on a mailing list.