Software License Agreements – The Key to Shrinkwrap Serendipity

Copyright law does not provide a publisher with any protection against possible law suits brought by users who are unhappy with the performance of the software or who have somehow been damaged by a serious problem with the software.

by Paul Goodman
MacTech Quarterly
Summer 1989 – Page 84

It’s finally finished. For the last two years your company has been working on its newest software product. Countless days, evenings and weekends went into design, programming, testing and debugging. All of the details are almost complete. The documentation is finished, the disks are at the duplicator and the design firm has just delivered a magnificent logo and packaging. But, hold everything. You realize that there is something you forgot: the software license agreement. “No problem,” you say as you grab for the packaging from that desk accessory you bought yesterday. All you have to do is copy what they have and you’ll be just fine.

This scenario might be slightly exaggerated, but in most cases it’s not far from what actually might happen. The license agreement included with a software package is often not given much thought. This is unfortunate — the importance of the license should not be underestimated. Should your software inadvertently cause damage to a user’s data the license agreement may be the only thing standing between your company and serious financial consequences. In this article we’ll attempt to unravel some of the confusing legal issues surrounding license agreements and provide some guidance for the befuddled software publisher. 

Why do I need one?

Often referred to as a “shrinkwrap license,” the software license agreement seeks to establish a contractual relationship between the publisher and the user that is separate and distinct from the contract of sale formed between the retailer and the purchaser. This contractual relationship (what law professors call “privity of contract”) is needed in order to protect the software developer from possible legal consequences arising out of a myriad of situations. Although published software is protected by the Copyright Act (presuming that you haven’t inadvertently placed it into the public domain) this protection is limited. The Copyright Act was designed to protect an author’s rights by preventing the unauthorized copying of the work (this right remains solely with the creator or anyone he has granted that right to). Although publishers should make sure that their software is protected by the Copyright Act, there are additional issues to be considered. Primarily, copyright law does not provide a publisher with any protection against possible law suits brought by users who are unhappy with the performance of the software or who have somehow been damaged by a serious problem with the software. For instance, just recently, a new release of a popular database management program was found, in certain circumstance, to have failed to retrieve specific records. Had this error caused a user to produce an inaccurate report or bill resulting in financial consequences, the user might try to hold the publisher liable for any associated monetary damages.

In addition, a software license agreement is needed in order to counter the very liberal warranties created by state law, most notably, the Uniform Commercial Code (“UCC”). The UCC is a series of laws adopted by 49 of the 50 states covering a wide variety of commercial transactions. This has virtually created a unified national legal context under which to do business. Article 2 of the UCC deals with the “sale of goods” and provides a set of warranties assuring the performance of all goods sold. The UCC defines a good as “all things which are moveable… at the time of the contract.” Does computer software fit this definition? The definitive answer is maybe. Years ago, when most computer software was custom made, it was treated by the courts as a service rather than a good, and thus exempted from the UCC. However, today’s purchase of computer software seems little different than the purchase of any good. Although there is a lack of court decisions discussing the status of software, it is legally prudent to treat software as though it is covered by      the UCC. 

Uniform Commercial Code Warranties ∆  Under the UCC, every sales transaction creates two types of warranties, those that are expressed and those that are implied in the transaction. Express warranties can be created several different ways under the Code but are most often created whenever the purchaser relies upon statements regarding the performance of the software. The software is then warranted to perform in accordance with the statements. In addition, any description of the software can also create an express warranty that the software will perform as described. If the performance does not live up to these representations, the purchaser

has the basis for a breach of warranty      law suit.

Besides express warranties, the UCC also provides potentially ominous im-plied warranties. An implied warranty is one that is considered to be part of every sales transaction regardless of whether or not the warranty is expressed to the purchaser. In specific, the UCC provides two different implied warranties, the implied warranty of merchantability and the implied warranty of fitness for a particular purpose. We will deal with                  each separately.      

The implied warranty of merchantability assures the purchaser that the goods will be “merchantable.” For goods to be merchantable they must be “fit for the ordinary purposes for which such goods are intended” and must “conform to the promises or affirmations of fact made on the container or label.” The exact application of the implied warranty of merchantability to software has yet to be clearly defined by the courts but it certainly requires that a particular program will perform as well as any other programs of the same type. Thus, if you are marketing a new spreadsheet application, the program should perform its calculations as accurately as other spreadsheets already on the market. And, all programs should be able to do standard tasks adequately, such as save a file without trashing the remaining contents of the hard disk. As I previously mentioned, this warranty attaches to every sale governed by the UCC without any effort on the part of the buyer or seller. Fortunately, from the publisher’s point of view, with the proper license agreement, this warranty can be disclaimed and thus made ineffective.

The second implied warranty, of fitness for a particular purpose, applies to only those situations where the buyer relies upon the expertise of the seller to select goods to fulfill a specific purpose that has been communicated to the seller by the buyer. The warranty requires that the goods will be fit to perform that task. Since the implied warranty of fitness for a particular purpose requires interaction between the seller and buyer it will probably not be created by any action on the part of the publisher, but the publisher must protect itself from any such warranty created by the actions of the retailer who might be construed to be the agent of the publisher.

Disclaiming warranties

The UCC was designed, in part, to provide the parties to a contract for sale with a set of standard terms and conditions from which to pick and choose. Unless the parties agreed to the contrary, the UCC will govern many aspects of the transaction. Since the UCC does not seek to mandate specific terms for every agreement, the parties are free to exclude most provisions of the UCC from their agreement.

Each of the UCC warranties, express or implied, can be disclaimed or excluded when agreed to by the parties. This exclusion is one of the most important provisions of the license agreement. From the publisher’s point of view, the most important warranties to disclaim are the implied warranties of merchantability and fitness for a particular purpose. This is because it is these warranties which pose the greatest danger in any law suit brought by a disgruntled user of the software. The UCC (Section 2-316) provides that: 

to exclude or modify the implied warranty of merchantability or any part of it the language must mention merchantability and in case of a writing must be conspicuous, and to exclude or modify any implied warranty of fitness the exclusion must be in writing and conspicuous.

Thus, to disclaim the implied warranties there are two requirements — that the disclaimer be conspicuous and that the word “merchantability” be used. The requirement that disclaimers be conspicuous explains why disclaimers are often printed all in caps or in bold print (or both). Taking into account the UCC requirements, constructing an implied warranty disclaimer is not difficult. Commonly, it reads something like:

PUBLISHER SPECIFICALLY EXCLUDES ALL IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Along with the implied warranties, the UCC also permits the exclusions of any express warranties. However, there is a note of caution with regard to such exclusions. The UCC provides that if the seller makes any express warranties in one paragraph of an agreement she or he cannot turn around and exclude that warranty in the next paragraph. Publishers should be careful that any wording on packaging or in the software’s users manual can’t be construed in an express warranty. 

Limitation of Liability

Along with disclaiming warranties, the UCC permits parties to decide on an exclusive remedy in the event of a law suit arising from the sale of the goods. This allows a publisher to limit its potential liability in the event a user should commence a law suit concerning the software. Although many people tend to lump together this limitation of liability with warranty disclaimers they are actually two different concepts and need to be addressed separately. A disclaimer of warranty is a device used to control the publisher’s liability by reducing the number of situations under which they may be sued. A limitation of liability, on the other hand, restricts the legal remedies available to the buyer once a breach is established.

Limiting your liability is not quite the same thing as eliminating your liability altogether. Comments to the UCC clearly state that “it is of the very essence of a sales contract that at least minimum adequate remedies be available.” This is taken to mean that a total disavowing of all liability will not be effective. This is of particular danger to the publisher since the UCC also provides that if a limited remedy should fail of its “essential purpose,” the buyer will have available all remedies usually afforded to a buyer under the UCC.

What are these remedies available to the buyer pursuant to the UCC? Essentially, there are three types of damages available to the buyer. The first would be the standard damages for breach of warranty, calculated as the value of the product as warranted minus the value of the product in its current defective state. This, by its nature, is limited to the purchase price of the software. However, the UCC, in certain situations, almost allows the buyer the more potentially dangerous “incidental” and “consequential” damages. Incidental damages are those which are incidental to the breach. This would include any out-of-pocket expenses incurred by the buyer because of the breach. Examples might be telephone calls to the dealer, the cost of hiring a consultant to analyze the source of the problem, etc. Consequential damages, on the other hand, are expenses incurred as a consequence of the breach. They are associated with whatever damage may have been done by the breach such as lost profit or the cost of replacing lost data.

Thus, any limitation of liability must on one hand protect the publisher from the specter of paying any consequential damages and on the other hand provide the buyer with a reasonable remedy (the “exclusive remedy”). A large number of license agreements in use provide as an exclusive remedy the replacement of a faulty disk with a new one. This is fine if the source of the problem is a faulty disk. However, if the breach should be caused by some latent malfunction of the software replacement, the disk will be of no value to the buyer (the new disk will contain the same buggy program). To protect against this situation, the license should also provide for a return of the purchase price in these circumstances. This makes an attempt at providing a reasonable remedy to the buyer (if the program doesn’t work, we’ll return your money).

As a result of these factors, typical wording of a limitation of liability clause might read as follows:

PUBLISHER OR ITS DEALERS SHALL HAVE NO LIABILITY WITH RESPECT TO THE SOFTWARE OR OTHERWISE FOR SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES EVEN IF PUBLISHER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN THE EVENT OF A MALFUNCTION OF A DISK PUBLISHERS LIABILITY SHALL BE LIMITED TO PROMPT REPLACEMENT. IN NO EVENT SHALL PUBLISHER’S OR PUBLISHER’S DEALER’S LIABILITY FOR ANY REASON AND UPON ANY CAUSE OF ACTION WHATSOEVER EXCEED THE PURCHASE PRICE OF THE SOFTWARE.

Will it stand up in court?

Now that the legal background has been covered it is time to turn our attention to the enforceability of software licenses. Let’s start off by looking at a typical scenario. 

A Macintosh owner walks into his local computer store and purchases a copy of a new word processor from that well known software publisher MacSoftCo. The salesman is pleased to give him the software which is packaged in an attractive, shrink-wrapped box, and rings up $89 on the buyer’s Visa account. Upon returning home, the buyer opens the box and inside finds a disk, a bound copy of the user manual and some miscellaneous promotional materials. Anxious to use his new software, the buyer opens the package and finds the following language printed inside the front cover.

MacSoftCo warrants this product against defects in materials and workmanship, assuming normal use, for a period of ninety (90) days from the date of original purpose. If a defect occurs during this period you may return the disk to us for replacement free of charge.

This program is sold on an “as is” basis. MacSoftCo excludes any and all warranties including warranties of merchantability and fitness for a particular purpose. In no event will MacSoftCo or its suppliers be liable for direct, indirect, incidental or consequential damages resulting from any defect in the software or manual, even if they have been advised of the possibility of such damages. In particular, they shall have no liability for any programs or data stored in or used with this MacSoftCo product, including the cost of recovering or reproducing these programs or data.

Our software buyer carefully reads  the agreement and becomes worried that should this product wipe out his hard disk he would have no recourse. Also, knowing a little bit about the law, he is perplexed about how a publisher can just say its not liable. Doesn’t he somehow need to agree to this? 

This scenario is not atypical of what software purchasers goes through. Besides some obvious technical problems with this disclaimer (confusion between disclaimer of warranty and limitation of liability and failure to use the word “merchantability” conspicuously), our hypothetical buyer is correct. Although this disclaimer is printed in the package, it is no sense an “agreement” between the parties (recall that the UCC says parties must agree to disclaim warranties).

Generally, in order for someone to be bound by the terms of a contract she must be a party to a signed agreement. Since in the microcomputer industry software is almost never directly sold to the end user by the publisher, it would be impossible to have a user execute a written agreement prior to purchasing the software. Thus, there needs to be some mechanism whereby the purchaser agrees to the terms of the license without actually executing a written contract. And, it is obvious that the disclaimers from the fictitious MacSoftCo are ineffective (leaving them exposed to possibly substantial liability).

Originally, the laws of contract as handed down from the English (what legal scholars refer to as the “Common law”) required that in order to have an enforceable contract there had to be a “mutuality of assent” between the parties. This required that there be some demonstrative action by the parties to indicate their willingness to be bound by the terms of the agreement. Under the Common Law, this requirement was strictly construed. However, the UCC has done away with much of the strict doctrine of the Common Law. The UCC states:

A contract for sale of goods may be made in any manner sufficient to show agreement, including conduct by both parties which recognizes the existence of such a contract.

UCC Statement on Contract for Sale of Goods

In addition, pursuant to the UCC any offer to enter into a contract can be accepted “in any manner and by any medium which invites acceptance.” 

This flexibility led lawyers for software developers to create the shrinkwrap license. The key to the shrink wrap license is the software’s packaging. Visible through the clear plastic shrinkwrap is the license agreement printed on the packaging (usually on the back of the box). 

Clearly stated on the license is that the act of opening the package to access the software will be construed as an act of acceptance of the license agreement (relying on the UCC acceptance provision stated above). Does this create a valid license agreement? This question, like most of the others discussed in this article, does not have any definitive answer due to the lack of litigation of these issues. This lack of litigation, however, should not be taken by the publisher to mean that these issues are not important. The danger is quite present and it is just a matter of time before the stakes are high enough to justify the expense of a law suit. 

One major fault of the shrinkwrap concept is that the user never gets a chance to read the manual before “accepting” the license agreement. Another is that in today’s competitive software marketplace, the printing of an agreement on a program’s packaging may be seen by many companies as unacceptable from a marketing point of view. 

If the shrinkwrap mechanism doesn’t work, what might? To answer this question, one must analyze the objectives to be reached. The mechanism must allow the user access to the documentation to evaluate the program’s functionality and require some overt act by the user which will constitute acceptance of the software. One popular method is to package the program disks sealed inside of an envelope. The license agreement is either positioned prominently inside the manual or on a separate sheet. The envelope is sealed with a label reading something like this: “By Opening This Envelope You Are Accepting the License.” Now, the user has a chance to review the program’s documentation before accepting the license agreement. 

Another scheme being used by several publishers, including the publisher of a popular Macintosh database, involves a “key” used to activate the software. The program is modified to allow only limited use prior to the entering of the key, a code which is sealed inside of an envelope. When the user reaches the software’s artificial transaction limit they are prompted to enter the code. The envelope indicates that the entering of the key (or just the opening of the envelope) indicates acceptance of the terms of the license. This mechanism seems to present a much fairer chance for the user to evaluate the software before deciding whether or not to accept the license agreement. However, this arrangement might be leaving the publisher open for possible liability. Since the user can actually load and use the software before they accept the agreement there exists a chance for the software, should it be defective, to cause damage to the user’s system or data. If this were to happen during this “evaluation” period the publisher would not be able to protect itself by asserting the liability and warranty limitations contained in the license since the license would not yet be in effect (the user would not signify its acceptance until it entered    the key).

In light of this analysis, how should the prudent publisher structure the acceptance of a license agreement? Although there are no hard and fast answers, what does seem clear is that whatever scheme is chosen should give the user an opportunity to review the software’s documentation prior to accepting the license agreement but should not allow them to load and execute the software (since they may be using the program without being governing by the license agreement). The purchaser must also be given the option of returning the software for a full refund should she decide not to accept the license. The availability of this option makes it clear that the acceptance of the license is a voluntary act and not one of adhesion. Returning the software should not be a difficult task for the purchaser, and your dealers should be instructed to accept for full refund any software without explanation (or hassle) as long as the seal on the software’s envelope is not broken.

One last consideration would be to require that the user sign the registration card to signify her acceptance of the software. The problems associated with this are obvious. If the user never returns the card, a common situation, they will not be bound by the license terms.

License Contents

Now that we have covered both the need for and enforceability of a license we can turn our attention to the actual contents of the license. While there may be variations from product to product, every software license, at a minimum, should cover the following areas:

  • Introduction
  • Permitted use of the software
  • Warranties and warranty disclaimer
  • Limitation of liability
  • Assignment
  • Acceptance of the software

Introduction 

The license introduction should address the reasons for the agreement, how the user accepts it (by loading the software, etc.) and what the user should do if she does not wish to be bound by the terms of the agreement (such as return the software for a full refund). 

Ownership

This section should specify that the software is only licensed to the purchaser and that the purchaser has purchased only the right to use the software.

Permitted Use of the Software 

This section should make it crystal clear to the user just what she may and may not do with the software. It is in this section that you would inform the user that she may not make a copy of the software except for use as a back up, that she must own a separate copy for each simultaneous user, that she must not give or sell copies to anyone and that the software should not be de-compiled or reverse engineered in any fashion.

Warranties and Warranty Disclaimer

The warranty disclaimer specifically excludes the implied warranties set forth in the UCC. The UCC requires that these disclaimers specifically use the term “merchantability” and that they be conspicuous. 

It is here that the developer must make some distinction between what warranties are being excluded. A software package really contains two products, the software itself and the media that contains the software. The publisher’s main concern is to disclaim any express or implied warranty with relation to the performance of the actual software.

A standard software warranty exclusion might read as follows:

EXCEPT AS EXPRESSLY SET FORTH IN THIS PARAGRAPH, PUBLISHER MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

It should also be noted that in the event the publisher offers a warranty on the disk itself, the provisions of a Federal statute, known as the Magnuson-Moss Act, might apply. From the point of view of avoiding the requirements of the Magnuson-Moss Act, it may be best not to grant any warranty at all.

Limitation of Liability

Distinct from the disclaimer of warranty is the limitation of liability providing a limited remedy for any law suits brought on because of the software. 

Assignment

The license agreement should specify that the license and the use of the software should not be assigned, sold or given to any other party and in the event that it is, the new party will be bound by the terms of the agreement. This will assure that the person using the software is bound by the license.

Acceptance

Pursuant to the UCC, a purchaser has a reasonable period to inspect any goods (even if they have been paid for) before deciding whether or not they conform to the goods ordered. The decision to keep the goods is known as “acceptance” (yes, this term is used in two different contexts in contract law). In the event that the purchaser rejects the goods, she has the right to receive her money back and is entitled to other damages. The license agreement should indicate that the goods are accepted by the purchaser within one week of purchase unless the publisher is notified of the purchaser’s rejection.

Are software license agreement fair to the user? In many senses the answer to this question is yes. The dynamic and growing microcomputer software industry provides computer owners with a wide variety of software all at a moderate price (especially when compared to mini and mainframe computer software). If software publishers had to assume the risk of the possible consequences that an end user might face, publishers would be forced to charge far more money for their software in order to make this assumption financially worthwhile. There are also the additional factors of not being able to control either the hardware and software configurations that the software is being run on or the employees of the user. Thus, while the software license agreement shifts the risk of using the software to users it also affords access to plentiful and inexpensive microcomputer software.

About the Author

Paul Goodman is a partner in the New York City law firm of Elias and Goodman, P.C. where he specializes in computer law and in representing software developers. He also has earned a Masters Degree in Computer Science and is the author of four books on Macintosh programming. He welcomes your comments on this article (MCI Mail: PaulGoodman, AppleLink: Law. Goodman). This article is provided for informational purposes only. If specific legal advice is required, the services of a knowledgeable attorney should be sought.

Please follow and like us:

About the Author