By extension should every device I own require me to have access to the source code and output data? Not a rhetorical question.
“I Want to Know What Code Is Running Inside My Body”
21–30 of 217 posts
Re: “I Want to Know What Code Is Running Inside My Body”
#22Another really good talk about the topic, "freedon in my heart" by Karen Sandler: https://www.youtube.com/watch?v=5XDTQLa3NjE It's mentioned in the article.
Re: “I Want to Know What Code Is Running Inside My Body”
#23Re: “I Want to Know What Code Is Running Inside My Body”
#24Reasons to NOT open up the code: 1> Loss of competitive advantage 2> Open source is not necessarily any safer (heartbleed bug ... ) 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. Who owns the liability in that case?
Re: “I Want to Know What Code Is Running Inside My Body”
#25By extension should every device I own require me to have access to the source code and output data? Not a rhetorical question.
If you're OK with someone else (who probably doesn't have your well-being anywhere in their list of priorities) controlling all of your devices, then the answer is no, you are not required to have access to the source code and output data.
EDIT: I didn't realize this was such a controversial statement. I stand by it, though; even as I knowingly own many such devices myself. I can certainly see, however, how I may want more control over a pacemaker than, say, my phone.
Re: “I Want to Know What Code Is Running Inside My Body”
#26She doesn't know the code that's running on machines inside her body.
I don't even know the code that's running my heart.
And yet, I trust it.
Re: “I Want to Know What Code Is Running Inside My Body”
#27Earlier quoted context omitted.
Even if we assume that these arguments are sound (which they aren't), they do not appear to provide a proper justification for letting a human being die . Put another way: If you had to explain Marie Moe's death to one of her relatives, which of your three points would make the relative understand your position?
These are sound arguments. Medical devices have to be certified in all applicable jurisdictions and companies want to protect their competitive advantage. This is no different from, say, new drugs, which are similarly proprietary and the maker retains exclusivity for several years. Further, medications too are risky black-boxes towards end-users.
We do not allow food companies to hide the ingredients of their products, because we know that companies (in the interest of profit) will fail to inform consumers about the dangers of eating unhealthily. Similarly, we do not allow meat producers to leave their meat ungraded because it endangers their "competitive advantage" - we understand (empirically) that doing so leads to food contamination and otherwise preventable disease.
Your choice of proprietary medicine as a counterexample is an interesting one. The pharmaceutical industry in the United States has a long history of "protecting its competitive advantage" at the cost of individual welfare - consider how frequently "reformulations" of the same base chemical are patented to continue milking a lucrative product that could improve the lives of thousands if genericized.
Perhaps even more pointedly, consider the fact that we deem it acceptable (and necessary) that the FDA step in and regulate the release of new drugs. Is there a valuable distinction to be drawn between the sort of regulation and evaluation that the FDA does and the sort that would be possible if programmers could openly evaluate medical devices?
Re: “I Want to Know What Code Is Running Inside My Body”
#28Does anyone know if at least the FDA is allowed to review the source code for pacemakers? Or is it a complete blackbox? Personally I would be appalled if even the FDA is not allowed to.
EDIT: Not sure what's up w/ the downvotes. There are well-established ways for regulatory agencies (whether FDA, FCC, etc) to obtain firmware for devices -- and it almost always involves a warrant under extraneous circumstances -vs- proactively receiving proprietary code.
Re: “I Want to Know What Code Is Running Inside My Body”
#29Reasons to NOT open up the code: 1> Loss of competitive advantage 2> Open source is not necessarily any safer (heartbleed bug ... ) 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. Who owns the liability in that case?
2) Open and closed are equally vulnerable. Closed may be even more vulnerable, since security researches have to attack a black box and can't run ordinary code linting tools.
3) Liability after update is a good question, but one which can be (and is) solved with traditional contract agreements. See cpap machines.
Re: “I Want to Know What Code Is Running Inside My Body”
#30Reasons to NOT open up the code: 1> Loss of competitive advantage 2> Open source is not necessarily any safer (heartbleed bug ... ) 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects. Who owns the liability in that case?
> 1> Loss of competitive advantage
Patient safety trumps business considerations. Skipping clinical trials would be a major competitive advantage (lower costs, quicker to market etc.), but we don't allow that for the same reason
> 2> Open source is not necessarily any safer (heartbleed bug ... )
I'll agree, in so far as saying making it open source doesn't necessarily make it safer. However, it should, at worst, be no less safe - the requirements on the manufacturer (testing etc.) should be the same regardless
> 3> If software for the pacemaker is allowed to be updated like that on a computer, someone will update it with buggy software that can cause adverse side effects.
You can open the code but, for example, required a signed binary before a device can be updated. The openness of the code and the openness of the device itself are linked but separate issues.