Using the Dreaded L Word
No, Valentine's Day is past for this year, so I am not referring to the feeling of affection toward another human being. Rather, I'm referring to the specter that haunts all thinking software developers – the ghost of product liability. In the Feb. 24
th Wall Street Journal (
www.wsj.com; I would provide a direct link, but the site requires a paid subscription), a feature entitled Companies Seek to Hold Software Makers Liable for Flaws describes efforts by some customers of enterprise software to make software vendors reimburse for lost time, revenue, or labor due to bugs.
This should come as no surprise to any software veteran. The standard software license ('makes no representation of the utility of the software for any purpose) patently flies in the face of just about any product liability law or precedent. While courts are still holding that the software license represents a contract to which both parties must adhere, it is only a matter of time (and likely not very much time) that product liability statutes prevail.
The straw that broke this camel's back seems to be security. Applications and operating systems that make it possible for attackers and thieves to break in, disrupt operations, and steal data are costing companies both money and reputation. Legal and regulatory pressures on enterprises are compounding this problem, because software customers are being held liable for breaches by their own customers. The loss of personal data leading to identity theft of a growing number of people makes us all potential victims of security holes in the software we write.
Of course, Microsoft is coming in for its own share of criticism, due to the numerous security holes in Windows and Internet Explorer. One company cited in the Wall Street Journal feature wanted to charge Microsoft for the labor needed to install the litany of monthly patches across its thousands of PCs.
You might think that this is a fool's errand by software users. The problem is more than buggy software, although that is problem enough. There is simply no way of determining all of the potential conflicts between software that might be running on an enterprise network, or even on the same server. Even if a software vendor could compatibility test the universe of commercial applications and operating systems, there is no possibility of testing either with applications that do not yet exist, or that have been developed internal to the enterprise.
Yet critics claim that it is not only possible, but already being accomplished today by embedded system developers, whose code is typically an integral part of a cell phone, router, or other electronic device. The argument is that these developers know their code can't be patched, and simply do a more meticulous job writing and debugging their code. There is some truth to this assertion. While we occasionally hear of a bug or security vulnerability in a cell phone or other device (Paris Hilton comes to mind), these devices seem to work much more reliably than our enterprise applications.
But that is false analogy. It is certainly true that many embedded operating systems can put Windows to shame in reliability, and applications do tend to work as advertised, but both no doubt have their issues. Embedded systems work in a closed environment, with a relatively known platform and set of interactions. As devices become more Internet-friendly, it is likely they will encounter some of the same problems enterprise applications have today.
This recognition might open the door to an equitable compromise. There is no question that commercial software developers can do better testing, including better compatibility testing with other products. The standard software license should warranty against those tested environments and interactions. However, platforms and applications not tested with can't be reasonably guaranteed. And this type of warrantee might encourage enterprises to use the applications on the platforms they were intended, and not to expect that applications will continue to work correctly with new platforms and for new uses.
The software industry must take charge of defining the extent of its liability, and the concept of no liability simply won't work any more. If we don't define something that is both reasonable and legally defensible, those who don't understand the technology or the business will do so for us.
Posted by Peter Varhol on 02/27/2005