home > press & publications

Press & Publications - Archives

"Disabling Devices in Software: Permissible or Impermissible Licensor Behavior," The DataLaw Report, November, 1996

By J. Christopher Erb

Introduction

Unlike many different types of sellers or lessors, software developers can build the capacity to self-destruct into their product. By inserting disabling codes into the software during development or by sending the code hidden in the guise of an update to the software user, developers can ensure that recalcitrant customers do not enjoy the use of the software if they have not paid for it. Indeed, more adventurous software sellers have stolen into the bits and bytes of their customer’s code in the dead of night, inserting disabling codes in the customer’s software via modem.

Unfortunately for developers, courts look with some skepticism to programmers’ use of logic bombs and other disabling tactics, agreeing to hear cases on contract and tort issues from conversion to warranty claims under the U.C.C. Now a ruling in the Central District of California may give unhappy customers a strong weapon against developers by allowing them to invoke powerful anti-hacking statutes against software providers who disable software without authorization.

The current case

In North Texas Preventive Imaging v Eisenberg, unpublished (?), a provider of software for computer enhancement of medical images sold a computer system to the plaintiff, a medical group. After paying 90% of the sales price the medical group attempted to cancel the contract, following a dispute as to the performance of the software and the amount paid. The defendant, who had been sending update disks to the defendant, sent an update disk with a disabling code in it shortly after the dispute arose. Unaware that the update included the disabling code, the defendant dutifully installed the update. The disabling code, which the court called a ‘time bomb’, was set to render the computer inoperable on a particular date. Once the time bomb was discovered the plaintiff complained and the defendant sent another update disk resetting the time bomb to a later date. The plaintiff then sued, alleging among other things violation of the Computer Fraud and Abuse Act (CFAA) §§1030(a)(5)(A) and (B) and breach of implied and express warranties. The CFAA was originally passed to prohibit unauthorized access to federal computers, but later amendments in 1986 and 1994 broadened the scope of the statute to compensate for the “broader range of techniques being used ... to wreak havoc on computer systems.” It provides that:

“Whoever, through means of a computer used in interstate commerce or communications, knowingly causes the transmission of a program, information, code, or command to a computer or computer system if -- (i) the person causing the transmission intends that such transmission will -- (I) damage, or cause damage to, computer, computer system, network, information, data, or program; or (II) withhold or deny, or cause the withholding or denial, of the use of a computer, computer services system, or network information, data, or program, and (ii) the transmission of the harmful component of the program, information, code, or command -- (I) occurred without the authorization of the persons or entities who own or are responsible for the computer system receiving the program, information, code, or command; and (II)(aa) causes loss or damage to one or more other persons ... [shall be punished as provided in subsection (c) of this section].”

The court, delving deeply into the legislative history, especially the statements of Senator Leahy, determined that the focus of the new law was “harmful intent and resultant harm” rather than just computer access. Noting that the senator felt that disabling codes which were used “pursuant to a lawful licensing agreement” would not be prohibited under the statute, the court suggested that the converse - use of disabling codes without such an agreement - might well be prohibited by the statute. The court then focused on the question of whether the access in this case was authorized. Noting that there were “no time restrictions or other disabling codes” when the software was first purchased, and that the defendant “did not disclose the existence of the time bomb” before the system was updated the court held that the lack of such disclosure was sufficient to raise a claim for unauthorized access under the CFAA. Absent some contractual stipulation to the contrary, failure to disclose a disabling code could be found to be an unauthorized transmission under the CFAA.

Two main themes arise in the court’s treatment of this case, whether the customer knew of the disabling codes and whether the customer had consented to the use of those codes, or “authorization.” By not contracting for the customer’s consent to disabling codes in the software and by failing to notify the customer of the presence of those codes in the software updates before they were loaded, the software provider has failed to get the authorization required under the CFAA to avoid liability for the resulting damage.

Prior Cases

This holding is in large part consistent with previous cases regarding time bombs and other disabling codes. In most of those cases, where there was a contract to purchase software with no time or title limitations and a failure to notify the purchaser of the existence of disabling codes prior to the execution of the contract or to installation of the codes, courts have found that the purchasers have stated a valid claim under tort or contract law.

For example, in Clayton X-Ray Company v. Professional Systems Corporation, 812 S.W. 2d 565 (Mo. Ct. App. 1991), the plaintiff purchased a computer system from the defendant. After a dispute over bugs in the software the plaintiff refused to pay the balance of the bill, and the defendant responded by putting a “lock-up program” in the plaintiff’s system without the plaintiff’s knowledge. When the lock-up program denied access to the files the plaintiff sued the defendant for breach of contract and conversion. The court held that the defendant “had no legal right ... to lock up [plaintiff’s] computer system” and that punitive damages could therefore be awarded. Id. at 567.

In a similar case, a New York court held that a plaintiff whose computer “system had been rendered worthless” by the “wrongful removal” of source code could make a claim of duress. In that case, the defendant “removed the source code from the system without the plaintiff’s knowledge or consent” after a dispute arose as to the performance of the computer system. Art Stone Theatrical Corp. v. Technical Programming & Systems Support of Long Island, Inc., 157 A.D. 2d 689, 690 (N.Y. App. Div. 1990). The contract for the purchase of the software from the plaintiff and the release which was signed after defendant’s actions had shut down plaintiff’s system could be voided based on the “wrongful” behavior of the defendant. Id. at 691.

In contrast, the user of computer software can be deemed to have consented to access by a software provider in order to disable the software where a contract is for the lease of hardware and software and stipulates that the lessor retains ownership, has the right to repossess, and could cancel the contract on default by the lessee. American Computer Trust Fund v. Farrell, 763 F. Supp. 1473 (D. Minn. 1991). After the lessee in that case stopped making payments on a seven year lease the lessor warned that it would “terminate all processing and support services.” Id. at 1492. The lessor did so shortly thereafter, and the lessee sued. The court found that plaintiff had a “legal right to deactivate the defendant’s software pursuant to the contract.” Id. at 1493.

In assessing that legal right the court noted that the defendants, by accepting the terms of the lease contract, had “consented” to access, id. at 1500, “authorized” access, id. at 1496, 1500, and “allowed” access to the computers, id. at 1494. Although the court never stated at what point the lessees had consented to the lessor’s invasion of their computer system for the purpose of disabling it, the court suggested that the periodic nature of the payments and the contract terms retaining an ownership interest in the software rendered the access authorized. The court concluded that, as a result, the defendants could “no longer claim that any alleged access was unlawful.” Id.

This case is unlike the others in that it is not a licensing contract, but also a lease of hardware and software from the provider to the customers. Because the contract reserved the right to repossess the hardware, the court seems to consider the use of disabling codes the functional equivalent of removing the computer equipment. The court appears to have read the contract provisions granting the lessor the right to retain ownership and to repossess as having granted the lessor the right to prevent the use of the hardware and software by electronic means as well.

The Revised U.C.C.

The proposed revisions to the U.C.C. articles dealing with licensing transactions attempt to address some of the above issues. The revisions are largely consistent with the existing caselaw, preserving the emphasis on consent and disclosure and the distinction between actions taken in the face of default and actions terminating the natural life of a licensing agreement. Section 2B-319(a) provides that parties may not introduce programs or codes which may “damage or interfere” with the computer system or data without first disclosing the intent to do so to the other party. Where the “circumstances or terms of the contract” put the other party on notice that disabling codes may be present, §2B-319(b)(1) states that the software provider is no longer required to disclose the presence of such codes.

Depending upon the type of contract, the disclosure must be made either before the transfer of rights or before the code is loaded into the system, whether received electronically or by means of updates. It is not clear, however, whether disclosure of the disabling code after the obligation to disclose but before the system is actually disabled would cure the failure to disclose, although the caselaw tends to suggest that such belated disclosure would not protect the software provider from liability. According to §2B-320(a), contractual terms allowing for the enforcement of contract performance through electronic means such as disabling codes are allowed only where the enforcing party is entitled to do so and only to the extent consistent with the express terms of the agreement. Therefore, if disabling code is included to enforce the end of a licensing agreement, or to prevent the use of features for which the purchaser did not contract the software provider may include that code. Any limitations imposed by the code must be consistent with the terms of the contract and, if added subsequent to installation of the software, are subject to the limitations on access imposed by the other sections.

Any electronic enforcement of contract terms must be expressly contracted for under §2B-320(b), with three exceptions. Codes which preclude use of software after the expiration of the term of a licensing agreement are allowed absent express contractual provisions provided the computer user is given “reasonable notice” before the software is disabled. Similarly, codes which prevent use of the software by an unauthorized number of users or at an unauthorized location need not be expressly stated. Presumably the number and location of authorized users should be fixed contractually. Finally, exceptions allow for the termination of certain limited-use applications, particularly Java “applets”, without express contractual terms under certain circumstances.

The terms of §2B-320 do not grant software providers the right to disable software on default by the purchaser. The notes to that section state clearly that even express terms do not “authorize ... codes that implement actions in the event of default.” The intent of the section is to allow software providers to “terminate a license at its natural end” or “restrict license use within contracted for parameters.” Therefore, limitations on the performance environment or work load of the software would be enforceable if expressly contracted for, but even express terms may be of little use in granting the software providers the right to disable software when the customer defaults on the contract.

Indeed, under §2B-712 the licenser is entitled to act on its own accord only if “there is a breach that is material as to the entire contract” and the action can be taken without breach of peace, risk of injury, or “significant damage to or destruction of information or property of the licensee.” Thus, the licenser can take action to disabled software upon default only if the contract breach is material, “substantially threaten[ing] or reduc[ing] the value to of the contract.” More importantly, such action may only be taken if the licensee has “manifest[ed] assent” to the self-help remedy of the software provider. As in the caselaw, the customer must at least be notified of the ability to take action disabling the software and must have in some way consented to that action. It would appear that a software provider would have to disclose the type and result of any disabling action before taking it, and that the customer must have the opportunity to prevent that action, either by refusing to enter into the contract, refusing to make updates, or by disconnecting the provider from the software. Even where the customer is unable to take action to prevent the disabling of the software, the customer can expressly or impliedly refuse to assent to the licensor’s self help, thereby rendering the use of electronic self-help remedies wrongful.

Even where the licensor’s self-help is disclosed and assented to, the licenser can be held liable for any damages which arise as a result of that action. If the breach of the contract is not material, or the proper assent was not made, the licenser is liable for both the damages which arise as a result of the action and any additional remedies available under contract and possibly tort law.

Conclusion

What does this mean for the software provider who is interested in enforcing the terms of a contract or lease? The most important issue is that of consent - the earlier the better. The customer must consent to any disabling codes or intrusive access via modems or during the course of maintenance activities. Most importantly, the consent should be given in writing, preferably as an express term in the licensing or sales contract. The term should state expressly what type of access is being consented to and under what circumstances.

Failing express consent to the access, the software provider should at least make sure that the customer has notice of the disabling code or the proposed access, preferably before the agreement is finalized and in any case before the software is disabled. Notice after the action is taken which will disable the software or after the software is actually disabled will potentially expose the provider to liability for actual damages as well as consequential and possibly punitive damages. Again, the notice should be in writing, preferably conspicuous, and reasonably clear in explaining what the codes or access will do to the software once activated. Acting surreptitiously, whether in sneaking disabling codes on a customer’s computer or in accessing the computer itself, is the surest way to arouse the ire of a court. Any action taken by software providers without notice or consent will expose them to potential liability for damages, including punitive damages or consequential damages.

The revised U.C.C. takes some of the guesswork out of determining when notice is necessary, but the rule of thumb is still that express terms in the contract defining the actions to be taken are ideal, and notice is important in all but the most unusual cases. Certain types of disabling actions, such as limiting the number of users or preventing use of the software after the agreement has expired, are permitted without express terms provided notice is given before the software is disabled. In any case, disabling software for default on a licensing contract (self help) will, however, expose the provider to liability for the resulting damages. Licensees must also be aware of the ramifications of these legal issues. The licensee should be sure to read and understand the terms of the contract, looking carefully for any clauses permitting the disabling of software, removal of code, or access to the licensee’s computer system by the software provider. Licensees should be wary of contract terms granting the software provider broad rights of access to the licensee’s computer system, clauses which could be read to allow the provider access to disable the software should a dispute arise. The licensee should also be sure to make the software provider aware of what damages might arise should the software be disabled - including costs associated with converting the data to another system and any operating costs which arise as a result of the downtime. By keeping the provider informed as to the licensee’s dependence on the software the licensee can ensure that the provider is aware of the potential damages arising from the disabling of the licensee’s software.

Most importantly, the licensee should make sure it knows exactly what is contained on an update disk, especially one which arrives after a dispute between the parties has arisen. By loading the update on a computer system with notice of the presence of disabling codes the licensee may have consented to the presence of those codes and the subsequent disabling of the computer system. If disabling codes are present, but the update must still be loaded, the licensee should object to the presence of the codes - in writing - before loading the update, requesting a version of the update without the offending codes.