Software Warranties - Embedded.com

Software Warranties

In a free 168 page report from the National Academy of Engineeringcalled “Software for Dependable Systems: Sufficient Evidence?”(available from www.nap.edu,registration required),  the authors take a stab at much COTSsoftware:

“Clearly, no software should be considered dependable if it is suppliedwith a disclaimer that withholds the manufacturer's commitment toprovide a warranty or other remedies for software that fails to meetits dependability claims.”

Ouch. What application software comes without such adisclaimer?

Some might argue that so much COTS software is so complex that suchdisclaimers are inevitable. I suspect vendors worry more aboutprospective lawsuits. Yet cars come with warranties, and a failure, sayof the brakes, could result in plenty of liability.

A TV comes with a strong warranty. Tools do. So does an iPod, cellphone, and just about any physical product. I can buy something frommost reputable vendors and return it, no questions asked. If it causesdamages, the usual remedies are available. What's different aboutsoftware?

The disclaimer that comes with software is the total antithesis of awarranty. That disclaimer typically disavows every guarantee other thanthe integrity of the media. That's like claiming the cardboard box thata computer ships in will function properly, but if the computer doesn'twork or bursts into flames it's the consumer's problem.

Open source programs fare no better. Provision 15 of version 3 ofthe GPL reads (in all caps just as shown): “THERE IS NO WARRANTY FORTHE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHENOTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIESPROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHEREXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THEENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITHYOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALLNECESSARY SERVICING, REPAIR OR CORRECTION.”

Certainly there are very good reasons for this provision, not theleast is that holding a series of authors legally accountable willremove any incentive to contribute to the community.

But if software should only be considered dependable if it comeswith a strong warranty, GPLed code fails the test as miserably assoftware from the most difficult of proprietary code vendors.

In the PC industry this may not be much of an issue. Firmware isdifferent. We provide a component of a product, and that productcertainly will have a warranty. Building a guaranteed product out ofun-guaranteed, or un-guaranteeable, components is as absurd asconstructing a rigid skyscraper from packets of Jello.

The facts are stark. Users demand ever more functionality. Firmwaregrows at a staggering rate. More of us are turning to COTS to get thisadded functionality in a reasonable timeframe. But most COTS vendorsoffer only the weakest warranties.

What do you think? What's the role of warranties in dependablesoftware?

Jack G. Ganssle is a lecturer and consultant on embeddeddevelopment issues. He conducts seminars on embedded systems and helpscompanies with their embedded challenges. Contact him at . His website is .



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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.