Software liability is a bad idea
Because all software seems to contain bugs, some people have called for laws that require software vendors to assume the liability that the license agreements for software almost always let them avoid. This is a bad idea. Doing this will make software extremely expensive. Plus, people have clearly shown that they really prefer buggy software with lots of features to more secure and reliable software.
To understand why requiring software vendors to assume the liability of problems caused by their products will just make things worse, consider the work of Ronald Coase. Coase showed that the total cost of things doesn’t change if we change their ownership – it just moves around how it gets paid for. He was even awarded the Nobel Prize in Economics in 1991 for his work in this area, so it’s probably a fairly significant result.
Suppose that you have a buggy application that has a TCO of $200, but using this software also causes you $300 in damage from the security and reliability problems that using it causes. In this case, your total cost is really $500. Currently, most software license agreements do their best to absolve the software vendor of any responsibility for the damage that buggy products cause, so their customers end up, in effect, paying more for the software. In this example, the users’ true cost is really $500 instead of just $200.
How does this change if we require that the software vendor assume the $300 liability? In that case, they will just increase the price of the product by $300. So the customers will still pay the same total amount, but the additional cost is now more obvious, not hidden like it was before. The insight that won the Nobel Prize for Coase was that this is always the case. So businesses are already paying the higher price for using buggy software. Because it’s not just software licensing and support costs, this cost is probably in more than one part of their budgets, but it’s still there somewhere.
Requiring the liability to be reflected in the licensing and support cost of software will probably increase its cost even more that we would expect using Coase’s analysis. This is because we really don’t know what bugs a particular piece of software has until it has been used for a while in real operational environments. If vendors have to assume the liability for this unknown risk, they’re almost certain to be very conservative. After all, if they estimate too low, then they’ll quickly go out of business. So we should expect to pay too much for software under such a scheme.
On the other hand, businesses have demonstrated fairly convincingly that features other than security and reliability are more important when they decide on which software to purchase. In the early days of operating system security, for example, it was possible to get systems certified at levels of security that ranged from a low of D (minimal protection) to a high of A1 (verified design). This system was called the Trusted Computer System Evaluation Criteria (TCSEC), and was more commonly called the "Orange Book" due to the orange cover of the document.
A few security vendors actually spent the time and effort to get their systems certified at the A1 level, but found that this turned out to be little more than an expensive exercise in paperwork. Customers really didn’t want the highly-secure systems when they could get less expensive commodity systems that also had many more useful features and making highly-secure systems turned out to be a sure way to lose money.
Eventually the TCSEC evolved into the Common Criteria, but the use of the higher levels of security is still essentially confined to government customers. Governments are typically much more averse to risk than businesses are. The private sector accepts that losses will happen, and that cost-benefit tradeoffs need to be made when investing in risk management. From this point of view, if it will cost you $2 million to eliminate $1 million in fraud, then it’s better to just accept the loss as cost of doing business.
Governments, however, are less willing to accept this, and will often spend much larger amounts of money to eliminate relatively small losses, and their security spending behavior reflects this. Because of this, they’re the natural market for highly-secure yet expensive systems, but even government customers were historically uninterested in TCSEC level A1 systems and don’t seem that interested in systems that have been certified to the highest levels that the Common Criteria defines.
If not even government customers are willing to use such technology, there’s almost no chance at all that commercial customers will be. So it appears that there’s really little interest in highly-secure and reliable software when customers need to choose between the higher quality and additional features.
Thus the arguments for requiring software vendors to assume the liability for damages caused by their products are bad for two reasons. It really won’t make software any cheaper. Some businesses may even be reluctant to buy software at all if they have to pay all of its costs up front. It also seems that businesses have shown that they really don’t want higher quality software, so by requiring software vendors to assume the liability for their products we’re giving customers what they have shown that they really don’t want. Requiring software vendors to assume liability for damages caused by the use of their products just doesn’t make sense.