Guest Editorial on Code Liability
In a SANS NewsBites editorial a little over a week ago I lamented the fact that to date software companies have for the most part not been held responsible in legal cases for damages resulting from bugs in their code. I described this situation as “the single greatest enabler of bug-infested coding on the part of vendors.” A mentor and also friend of mine, the legendary Bill Murray, sent me a message with a plethora of excellent comments concerning the issue of liability related to software bugs. His commentary on this issue is so outstanding that I decided to (with his advance consent) publish it as a blog posting. Here goes:
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Murray’s first rule of computer security is “Be careful what you ask for….” Couple the current computing environment with “strict liability” and many, not to say most, software vendors would be a coin toss or a jury decision from bankruptcy. We want to be sure that in getting to where we want to go, we do not break something that we did not create and cannot repair, destroy something we cannot replace.
Key in your statement is “due to.” Rarely do damages have a single demonstrable cause. Moreover, most of the code errors do not result in damages. On the other hand, juries love to find someone with deep pockets to blame.
That said, having spent my early years developing in an environment where the computing environment was hidden from end users by purpose-built applications, I have always been skeptical of highly generalized and flexible environments with gratuitous features and functions. While these have created market numbers upon which developers could make money, they have also contributed to products whose use the developer could not make predictive statements and could not make statements about safe use, much less warranties.
To the best of my knowledge, the MVS Integrity Statement (user cannot increase his privileges) is the most successful software warranty ever. Of course, if the remedy had not been limited to fixing the code, IBM would never have offered it. Somewhere between the present remedy and liability for “consequential damages,” I think that IBM could have crafted a remedy stronger than the promise to fix the code.
One can contrast Word, Acrobat, Excel, sendmail, and Apache running on Windows and Unix, to 140K purpose built applications running on the iPhone. (Note that it takes a very large number of iPhones for developers to make money on applications with limited function and appeal.) The more specific the application, the easier it would be to define safe use and warrant the program. While not getting to strict liability, one might get to merchantability. Moreover, by providing a very limited UI, even Apple might be able to make warrantable statements about the iPhone operating system. For example, Apple might be able to say that process-to-process isolation is such that programs could not interfere with one another and data cannot leak from one program to another. One might even find enough competitive advantage over competitors, think Windows Mobile or RIMM, to encourage Apple to offer such a warranty.