In a free 168 page report from the National Academy of Engineering
called "Software for Dependable Systems: Sufficient Evidence?"
(available from www.nap.edu,
registration required), the authors take a stab at much COTS
"Clearly, no software should be considered dependable if it is supplied with a disclaimer that withholds the manufacturer's commitment to provide a warranty or other remedies for software that fails to meet its dependability claims."
Ouch. What application software comes without such a disclaimer?
Some might argue that so much COTS software is so complex that such disclaimers are inevitable. I suspect vendors worry more about prospective lawsuits. Yet cars come with warranties, and a failure, say of the brakes, could result in plenty of liability.
A TV comes with a strong warranty. Tools do. So does an iPod, cell phone, and just about any physical product. I can buy something from most reputable vendors and return it, no questions asked. If it causes damages, the usual remedies are available. What's different about software?
The disclaimer that comes with software is the total antithesis of a warranty. That disclaimer typically disavows every guarantee other than the integrity of the media. That's like claiming the cardboard box that a computer ships in will function properly, but if the computer doesn't work or bursts into flames it's the consumer's problem.
Open source programs fare no better. Provision 15 of version 3 of the GPL reads (in all caps just as shown): "THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION."
Certainly there are very good reasons for this provision, not the least is that holding a series of authors legally accountable will remove any incentive to contribute to the community.
But if software should only be considered dependable if it comes with a strong warranty, GPLed code fails the test as miserably as software from the most difficult of proprietary code vendors.
In the PC industry this may not be much of an issue. Firmware is different. We provide a component of a product, and that product certainly will have a warranty. Building a guaranteed product out of un-guaranteed, or un-guaranteeable, components is as absurd as constructing a rigid skyscraper from packets of Jello.
The facts are stark. Users demand ever more functionality. Firmware grows at a staggering rate. More of us are turning to COTS to get this added functionality in a reasonable timeframe. But most COTS vendors offer only the weakest warranties.
What do you think? What's the role of warranties in dependable software?
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at email@example.com. His website is www.ganssle.com.
I think most of the warranties cover replacement of the product, few extend to other damages as the result of the failure. For example, if your umbrella leaks, you can take it back to the store for a replacement, however, neither the vendor nor the manufacturer would compensate for damage on the 16th century water-color you were trying to protect using that umbrella.
A lot of the software we acquire come with free update (bug fix), kind of the equivalent of the warranty most physical products carry. But if you want coverage for the mission critical system the software is to control, there is service level agreement (SLA) to negotiate. This is like buying insurance -- when was the last time you were really happy with your insurance company?
- David Liu
I think there is a big difference between software for embedded systems and shrink wrap software for PC use.
When you sell a product with embedded software (cell phone, ignition system, MRI scanner, iPod, etc.), you have complete control over the environment that it runs on. In theory, you could (or should) test it in every possible state it could get into. You know what all the pieces are that the code interacts with and what speed everything is running at.
Not the case with shrink wrap software for PC's. Motherboards come with different with kinds of processors, chip sets, and memory arrangements, running at different speeds. The PC's owner can also plug in different accessory boards or use different video cards to further complicate the issue. Then add complicated specifications for supposedly standard things that leave room for interpretation. When looked at this way, it's a wonder shrink wrap software works as well as it does. In my experience, with shrink wrap software, the root cause of problems almost always involve interaction issues with the hardware and / or other software.
Recently I thought of an idea for a medical product that would almost totally cut out the traditionally hardware part and allow it to be run as a software application on a lap top instead. It could significantly lower costs and allow greater market penetration. But management said it wouldn't fly with the FDA because you can't guarantee the configuration of the system it would run on.
I would warranty software in situations where I had complete control of its run time environment, but I would not if I didn't.
- Randy Luck
When we write application programs for buyers of our board level controllers we give the following warranty:
1. We do not warrant it as being suitable for any particular purpose.
2. If the customer finds a defect within 12 months of signing off on it, meaning the program does not perform as specified, we will fix it. We will not accept the cost of any product recalls or rework.
The reasoning is simple. We are making stuff for OEMs. Typically our customers lack the ability to fully specify what they want the controller to do (in reality a virtually impossible task). Therefore, the onus MUST be on the OEM to ensure that the program we write does what he wants. He must take responsibility for his own product. We undertake to make what he asks for, nothing less (we often provide a lot more!). If he fails to test properly before he goes into production, he must pay the price of any recall or damages claims.
We apply the same rules to custom designed hardware, and once the prototypes are signed off the original specification is extinguished.
We have never had a customer complain that this is unreasonable, because it's not. On the contrary, they usually consider us very professional in our approach.
- David Gibson