Software Errors: Recovery Rights against Vendors
Schneider, Gary P., Barkacs, Linda L., Barkacs, Craig B., Journal of Legal, Ethical and Regulatory Issues
Businesses that experience problems with physical products they have purchased find that the legal system provides adequate redress for their grievances. Large verdicts or out of court settlements are not unusual for product liability in business-to-business transactions. Software vendors routinely immunize themselves from such product liability by including exculpatory language in the agreements to which users must agree as they install the software. This paper examines the rights of companies to collect damages from software vendors when their products introduce errors or fail to perform transaction processing tasks correctly. The paper also outlines future trends in this area.
ERRORS IN BUSINESS SOFTWARE
Software vendors regularly ship software that has defects that are known to the vendor and that the vendor does not disclose to the purchaser (Kaner and Pels, 1998). Some of these defects are quite serious. For example, in the case of Mortenson v. Timberline (2000), Mortenson used Timberline's Precision Bid Analysis Software to prepare a bid for construction of a medical center. The software contained errors that caused Mortenson to bid the job approximately $2 million lower than it should have bid. Bills (2002) reports a software glitch at the Bank of America that processed automated clearing house payments incorrectly, resulting in unauthorized charges to thousands of customer accounts.
Although individual examples of software errors are interesting to read, the true danger of the current situation is made clear by studies of the extent to which accounting software is plagued by errors and by estimates of the dollar impact of these errors. Financial Executive's News (2002) presented a feature report on a series of common errors in mid-level accounting software packages. Goodwin (2002) reports the results of a study of 45 financial software applications. The study found that more than half of the applications contained errors that could have been fixed easily if they had been detected during the design of the software. Estimates of the annual cost to U.S. businesses of software errors is approximately $60 billion (Jusko, 2002; Trembly, 2002).
The way that software errors enter the software production process and the final software product is also enlightening. If software errors were the inevitable outcome of a complex process, which some researchers have argued in the past (Foster, 2003 ; Nakashima and Oyama, 1999; Roush, 2003), then there might not be much that legal reform could do about the problem. Although it is true that some software error situations are probably beyond the control of software vendors (for example, the rapid development cycles of annual revisions of tax preparation software might make them the exception to the rule (Johnston, 2001)), most business software developers do not work on tight deadlines and rapidly changing tax rules.
Kaner and Pels (1998) report that some software publishers track the number of errors that are discovered in their software after it has been released, calling these bugs their "surprises." They only include errors in this category that had not been detected in the software development process by programmers, quality assurance technicians, or by their own customer support staff. A common experience among these companies is to have fewer than five "surprise" bugs surface after the software is released. Many of them report only one or two such "surprise" errors.
This means that the large number of bugs identified in the industry press is not a true reflection of some innate condition in software development. In fact, it suggests that most software vendors know about the vast majority of the bugs that exist in the software they release. They just are not telling their customers about the errors.
LIMITS OF TOLERANCE
An increasing number of writers are reporting that business managers and IT staff members are coming to believe that tolerating software errors is no longer necessary (Foster, 2003; Hunter and Boscher, 2003). …