Technical Perspective: Liability Issues in Software Engineering

The following paper by LeMétayer et al. addresses one technical issue in a large and serious problem in the production of mass-market software (MMSW), that of the lack of liability by the producers of this MMSW. MMSW is software that is sold—actually licensed—to the consumer on the open market.

The Introduction puts the problem in perspective. It points out correctly that "Software contracts usually include strong liability limitations or even exemptions of the providers for damages^a caused by their products." The authors observe correctly that this lack of liability "does not favor the development of high quality software because the software industry does not have sufficient economical incentives to apply stringent development and verification methods."

It must be emphasized that the contracts being discussed are for MMSW. Such a contract is generally in the form of a shrink-wrapped, or click-yes-to-buy, end-user license agreement (EULA), which the customer must agree to in order to touch or download the MMSW. This EULA typically says that the producer warrants only the medium on which the software is supplied and nothing at all about the software’s functions, and that the producer’s liability is limited to the cost of the product, that is, you get your money back.

While the authors do not explicitly say so, the contracts of the paper do not include those for bespoke software (BSW) developed to do specific functions for one customer who intends to be the sole user of the BSW when it is finished. In the contract for such BSW, the producer promises to deliver specific functions and agrees to be liable should the BSW be delivered late, with functions missing or incorrectly implemented, and so on.

The difference between contracts for MMSW and contracts for BSW is the power of the customer in the contract negotiations. For BSW, the customer has a lot of power, able to go to a competitor if it finds that it is negotiating with an unreasonable producer. For MMSW, the producer dictates the terms, its lawyers having written the EULA even before the MMSW is put on the market. Basically the producer says to customers "Take it or leave it!"’

The paper cites several calls for MMSW producers to warrant the behavior of their MMSW and to be subject to liability for the behavior of their MMSW, as are manufacturers of consumer electro-mechanical devices. Among these calls was a paper I wrote in 2000, comparing the warranties for typical mass-market consumer appliances, such as vacuum cleaners, to the EULAs for typical MMSW. After observing that the appliances in my house were more reliable than the MMSW on my computers, I concluded that appliance manufacturers warrant and accept liability because they are required to do so by law in most jurisdictions and that MMSW producers warrant nothing and accept no liability because they are not required to do so by law and buyers show that they accept the situation by continuing to buy existing MMSW.

The following paper contributes a way to automatically apportion liability among the stakeholders of a system S constructed for the mass market. It describes the stakeholders of S as including the user and the producers of any of S’s needed hardware, software, and Internet supplied services. The paper assumes that all potentially liable stakeholders of S have executed an informal agreement, expressed in natural language. For each particular kind of failure of S to deliver promised behavior, the informal agreement apportions liability among the stakeholders based on the contributions of the user, hardware, software, and services to the failure. The informal agreement is translated into essentially a program P, written in set theory and predicate logic. When S fails to deliver promised behavior and the affected customer seeks compensation for that failure, P is executed to compute each liable stakeholder’s portion of the damages payable to the customer.

If the informal agreement is written in precise legalistic style with careful uses of "if," "then," "and," and "or," then its translation into P seems straightforward. Execution of P examines the trace of events leading to the failure in order to identify which components or user contributed to the failure and then it apportions the liability to the identified stakeholders. The paper gives a formal model of the information that must be in traces to allow this identification and apportionment. This trace examination is an extension of the traditional method of finding a bug’s source by examining a trace of the execution leading to the bug. These traces are negative scenarios,^b and traditional methods of identifying a system’s failure modes^c can be used to find these negative scenarios.

This contribution is an interesting application of lightweight formal methods.¹ The paper’s formal model of liability is intentionally strong enough for formalizing liability apportionment agreements, but not for traditional uses of formal methods, such as verifying correctness. The paper’s technique seems to be workable and should help manage liability for systems that are constructed out of components supplied by multiple stakeholders.

Back to Top

Back to Top

Back to Top