In Short

The Situation: Whether warranties accompany software used in other products turns on many factors, including whether the designer is providing a "good" or "service," statements in advertising, representations made in sales pitches, contractual terms, and state law.

The Issue: How can software suppliers balance their interest in promoting and selling their software while protecting themselves from unexpected liability for breach of warranty?

Looking Ahead: Careful planning and scrutiny of projects, promotional materials, sales presentations, and contracts can reduce the risk of liability for software suppliers while not inhibiting product sales.

Software drives myriad products, including products that can injure people (such as autonomous vehicles) or damage property (such as robots). Software design is often the first step in the supply of technology, artificial intelligence, or components required for a product. When software is critical to product performance, the software supplier may be intimately associated with the design and development of the final product, and its technology may be touted in the marketing of the product (e.g., Intel inside). Yet, in other instances, the product manufacturer will deal only with component suppliers, which have the direct contact with the software supplier.

In either circumstance, if the product fails to perform properly because of a software defect, then the product purchaser or manufacturer may look to the software supplier for damages. To avoid or mitigate the risk of liability, the software supplier should plan carefully from the moment it begins to design, promote, and sell its software. We will use California law to explain a number of the factors to consider.

"Good" or "Service"

Courts find it difficult to determine whether the essence of a software transaction is providing a "good" or "service." Courts tend to define software as a "good" when a transaction involves pre-packaged software, even if there are service modifications or ancillary services incidental to the transaction. Courts view software as a "service" when a transaction involves designing software from scratch or acquiring a manufacturer's skill or knowledge in software design. The essence of such a transaction is the service of designing the software. The distinction matters.

The California Commercial Code ("Code") governs transactions involving "goods," including how manufacturers can disclaim the implied warranties of merchantability and fitness for a particular purpose. In addition, the Song-Beverly Consumer Warranty Act ("Act"), which provides buyers more rights and restricts sellers' rights, supplements the Code and applies to the sale of a "good." The Act prevents a component-part manufacturer from disclaiming implied warranties if it provides an express warranty. However, if the component-part manufacturer does not provide an express warranty, the Code will permit the component-part manufacturer to disclaim implied warranties and to limit remedies for breach of warranty through its agreement with the product manufacturer.

Common law contract principles govern a transaction for a "service." Common law principles give latitude to the parties to craft the terms of their agreement and, therefore, to limit or provide warranties and remedies.

The software designer and supplier may be able to shape the transaction to influence the determination of software as a "good" or "service." The supplier should be aware of and plan for the legal consequences, such as through contract terms or insurance.

Express Warranty

An express warranty is an explicit promise that software will perform in a particular way. An express warranty may arise from a representation that software meets an industry standard or a performance standard, such as functional safety under ISO 26262 or an Automotive Safety Integrity Level. An express warranty can result from agreement to certain specifications, factual statements of performance in advertising, or the providing of a sample or model. The legal principle is straightforward: a promise on which another person relies must be met. So, the word of caution is to scrutinize promises and representations closely before making them.

Readily Identifiable Software

A software supplier may become obligated to indemnify a retail seller or compensate a consumer if the software is readily identifiable and important to the consumer—for example, a name-branded component part with recognized software. The consumer must show an expectation for the software supplier to fix software issues with the product and reliance on the software brand to purchase the product. Marketing the software as part of selling the product, therefore, not only has benefits to the software supplier but also has a potential downside to consider.

Participation in the Design of the End Product

The more that the software designer takes part in the design specifications for the end product or the integration of the software into the product, the more risk it assumes for software design defects in the end product or for failure to meet representations, warranties, or consumer expectations connected to the software.

Implied Warranty of Fitness for a Particular Purpose

This implied warranty comes into play when the software supplier knows of the buyer's particular purpose for purchasing the software and knows that the buyer is relying on the supplier's skill and judgment to provide suitable software. The supplier also may have reason to know of the buyer's particular purpose through, for example, prior dealings. Therefore, the circumstances dictate whether a court will find this implied warranty to apply. A supplier can disclaim this implied warranty.

Implied Warranty Created by Conduct or Custom

Course of performance, course of dealing, or usage of the trade can create this implied warranty, which may contradict and supersede the terms of an agreement. Repeatedly accepting an obligation to replace defective software or honoring an implied warranty even if disclaimed can amount to course of performance. A court may use the parties' prior course of dealing to determine the parties' intent when interpreting an agreement. Usage of trade turns on standard, accepted practices in the field that are deemed to be part of the parties' agreement, such as a permissible level of coding errors.

Software suppliers need to analyze whether there is any course of performance, course of dealing, and usage of trade; act to avoid each in the first place, if they choose; and, if any such warranty may arise under the circumstances, be aware of the potential legal impact of each. Moreover, because courts often will rule that express contractual terms prevail, appropriate terms in a sales agreement can mitigate the risk from such an implied warranty.

Implied Warranty of Merchantability

This implied warranty, as its name suggests, promises that the software meets the standards of performance expected by merchants in the trade. Again, this implied warranty turns on industry standards and practice. Suppliers can disclaim this implied warranty or agree with purchasers to particular terms that will supersede it.

Disclaimer of Implied Warranties

Unless prohibited by the Act, the Code allows sellers to disclaim any express and implied warranty. Software suppliers may decide to provide a limited, exclusive, and express warranty (such as meeting a particular specification or industry standard) and then disclaim all other warranties. Disclaimers must be specific and conspicuous; state law and practice provides the important language and format for disclaimers. If the Act applies to a transaction, for example, the disclaimer must say that the goods are sold "as is" or "with all faults."

Warnings and Instructions

As with any product, specific warnings and instructions can help to avoid or reduce liability, if a manufacturer or consumer does not use the software consistently with the warnings and instructions. Software suppliers should evaluate the potential misuses or unintended uses of their software, its foreseeable failure modes, and the limitations on its functions or performance. This analysis will provide the technical foundation to consider the feasibility, format, and language of warnings and instructions that could accompany the software after sale—not just to the immediate purchaser but also to other known or foreseeable users of the software.

Although the considerations may seem complicated and time-consuming, they provide the "ounce of prevention" to mitigate the risk of future liability.

Three Key Takeaways

  1. Software designers and suppliers need to analyze from a legal perspective their transactions, agreements, advertising, sales pitches, industry standards and practices, course of performance, course of dealing, and other representations to determine their potential liability for express or implied warranties. Management needs to scrutinize all aspects of sales, marketing, and customer service to control the risk of legal liability.
  2. Software designers and suppliers can effectively disclaim express and implied warranties if they follow state law requirements.
  3. Software designers and suppliers should take special care to protect against liability risks when designing custom software, when working with product manufacturers to develop new software for their particular needs, or when software is promoted as part of the product.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.