Free Software, a Matter of Life and Death 197
ChiefMonkeyGrinder writes "Software on medical implants is not open to scrutiny by regulatory bodies. Glyn Moody writes: 'Software with the ability to harm as well as help us in the physical world needs to be open to scrutiny to minimise safety issues. Medical devices may be the most extreme manifestation of this, but with the move of embedded software into planes, cars and other large and not-so-large devices with potentially lethal side-effects, the need to inspect software there too becomes increasingly urgent.' A new report 'Killed by Code: Software Transparency in Implantable Medical Devices' from the Software Freedom Law Center points out that, as patients grow more reliant on computerized devices, the dependability of software is a life-or-death issue. 'The need to address software vulnerability is especially pressing for Implantable Medical Devices, which are commonly used by millions of patients to treat chronic heart conditions, epilepsy, diabetes, obesity, and even depression.' Will making the source code free to scrutiny address the issue of faulty devices?"
Formal methods, not open code (Score:1, Insightful)
Just require that all such software rigorously use formal methods to mathematically prove that it functions as intended. The manufacturer could then send their proofs to some regulatory/standards agency to verify.
Makes sense (Score:5, Insightful)
To me, this is just common sense. This code doesn't necessarily have to be FL/OSS in my mind - let them keep the copyright, but it most definitely should have code available for public review. Would you be willing to take a new wonderdrug where the drug company won't tell anyone what's actually in it, but assures you that it'll work? If they must disclose the formula to their drugs, then they ought to be required to disclose the code to their software. Let existing laws like copyright ensure that no one else uses it.
Re:Makes sense (Score:3, Insightful)
Where is this ideal world where the FOSS? (Score:1, Insightful)
Re:Lots of tedious details (Score:4, Insightful)
Operator Error (Score:3, Insightful)
Re:Same article different day (Score:2, Insightful)
That's not specific to software-controlled devices though. If you're dependent on taking a pill every week to keep you alive and/or healthy, you're in trouble if the supply chain gets disrupted in any way.
Re:Makes sense (Score:3, Insightful)
Some level of documentation for such things will be available. How do you think A&P's all over the country work on them? Just pop the hood and figure it out as they go along?
And yes, I think that anything on which the safety of a life depends should be open to scrutiny. Alarm clocks and keyboards? Not so much.
The GPLv3 makes this completely impossible (Score:1, Insightful)
First of all, most device manufacturers would prefer to build based on a closed-source infrastructure so that they do not have to re-publish their source code. So it's unlikely that we will see much GPL software in medical devices. Look at how effectively threats of lawsuits over busybox completely removed Linux from consumer routers post-2005.
Second of all, the GPLv3 prevents you from signing a binary to run on a specific piece of hardware. So no GPLv3 on medical devices.
It is entirely within the rights of free software publishers to impose these restrictions. However, it is disingenuous for them to express surprise that their software is then avoided for certain applications.
Re:Double-edged sword (Score:5, Insightful)
But do you want to risk everyone being able to reverse-engineer the protocol used for adjusting the settings for such a device?
Yes. Security through obscurity is essentially no security at all. The only thing that should be secret is the private encryption key that is uniquely associated with the remote control, which should be under strict physical security at all times.
What you say? There's no encryption implemented in these devices? That's a big problem whether the code is open or not.
Re:Makes sense (Score:3, Insightful)
It's the same argument that an automobile manufacturer doesn't release the detailed specs of a vehicle, because the owners manual doesn't show a breakdown of the engine. They are available (for a price, of course) to the people that need the information.
Here's the list of manuals for a Boeing 777 [boeing.com].
But for both aircraft and auto manufacturers, I don't believe they release detailed specs of say the software that makes their vehicles work. I doubt A&P mechanics are fixing software flaws in the autopilot, just as auto mechanics can't fix the software in the cruise control. It's the same as a doctor wouldn't be able to change the software controlling a pacemaker.
I know plenty of automobile electronics have been reverse engineered, but that's due to the number available to work with, and the potential profit to be had from tuning the software. Most of us wouldn't know where to get our hands on a new or used pacemaker to begin reverse engineering it. I definitely wouldn't be able to get my hands on a new or used 777, nor have anywhere to store it. It's a bit bigger than most of our garages, and I can't imagine our significant others not minding that we have one in the garage.
Licensed Professional Software Engineers? (Score:2, Insightful)
Some mechanical devices and most bridges and buildings require licensed engineers or architects to put their stamp of approval on the designs. They do not require publication of the engineering or architectural drawings though.
I for one would welcome professional licensing for certain "it can kill you if it goes wrong" software, particularly in isolated devices whose software can't be tampered with undetectably.
If a licensed Professional Software Engineer puts his seal on a pacemaker or airplane, and the software kills someone, he's just as responsible as the civil engineer would be if a faulty bridge design kills someone. In both cases, the licensed professional's responsibility would come back to "was the engineer acting in accordance with professional standards at the time" and "was the device built and maintained in accordance with the design."
Re:Formal methods, not open code (Score:3, Insightful)
Formal methods on their own are not enough -- at least, not with the current state of formal methods. Formal methods and testing tend to expose different bugs. But the principle is right: maybe an independent safety assessor evaluates the process and products, and the manufacturer submits their argument as to why the system is acceptably safe to a regulator.
We need to be careful about what is "sufficiently safe" though. If somebody would die for sure without the implant then "the implant probably won't kill them" is a big improvement, whereas achieving "the implant almost certainly won't kill them" might price the implant out of reach of most people who need it so it goes back to the situation in which they die. As a rule of thumb, moving up one IEC61508 SIL increases costs by about an order of magnitude. Formal proofs mean that you're talking about SIL 4, so you're talking of the order of 10 000 times the cost of normal commercial standard software (treating that as SIL 0). Increase the development cost of a life-saving implant by a factor of 10 000 and unless you have massive economies of scale you're going to end up indirectly killing people by pricing it out of the market.
Re:The code is going to do you a whole lot of good (Score:2, Insightful)
^THIS
Implantable pacing devices, cardioverters, and pumps (life-sustaining devices) depend on complex custom hardware designs as their platform, and that hardware is *highly* interactive with the software. Many of these devices can only achieve their miraculous longevities on a primary cell by deferring functions to hardware. If you don't have access to the information re: the hardware, the code itself might as well be inscriptions in Atlantean glyphs. You'd have to bust trade-secret protection to get a public viewing of everything needed to review the code, because you'd have to see, *everything*.
Re:Same article different day (Score:3, Insightful)
Do you really want to have a corporation that you have absolutely no control over to be in control of a device that sustains your very life?
It can't be any other way.
The development, testing, and licensing of the device could cost ten million dollars, a hundred million. There is no upper limit - and any company taking over the production and distribution of the device is going to see costs on the same scale.
There simply aren't very many companies with the strength and experience to do that.
Re:Same article different day (Score:3, Insightful)
Do you also doubt that a pacemaker manufacturer would refuse to provide a critical software update unless each pacemaker user pays them for it?
Wait, do you mean before or after I talked to Action 9 news?
Re:Same article different day (Score:3, Insightful)
And how is that worse having a group of random self appointed individuals, over whom I have absolutely no control, in control of a device that sustains my very life?
From the number of FOSS projects I've seen die on the vine because the developers drift away to other interests or just drift away, I'm not certain that FOSS is any better. Making the assumption, of course, that for such a project as pacemaker code that a sufficient number of developers with the proper experience can be herded together at one time... This isn't a video codec or yet another word processor clone. This is a device upon which, as you said, people's lives depend. I'd be hesitant to trust 'some guy in a basement'.
Re:I've got to say... (Score:2, Insightful)
If this were important, then why is it so difficult to get to examine the software used in devices that can get your vehicle taken away, your drivers license suspended and/or revoked, and yourself thrown in jail for varying lengths of time?