Return to Bad Software: What To Do When Software Fails.



Cem Kaner, Ph.D., J.D. c/o Dept of Computer Sciences, Florida Tech
Law Office of Cem Kaner  150 West University Blvd.
kaner@kaner.com  Melbourne, FL 32901-6988

SELF HELP UNDER UCITA

Sharon Marsh Roberts and Cem Kaner
July, 23, 1999

The new self-help provisions are a praiseworthy attempt at a serious compromise, but they don't work. They are subject to three serious problems:

  • For vendors who legitimately need self-help, the 15 day delay is far too long.
  • For customers, the back door into their system (the one the vendor uses to shut them down) is a security risk.
  • For independent programmers (small licensors most likely to need to resort to self-help), the rules are so technical that they will probably get into trouble even if they act in good faith.

  • Comparisons to Article 9 are inapposite because self-help in the computer case does so much collateral damage. When you repossess a car, it is unlikely that the result will be that the customer's garage falls down. But these kinds of side effects (and much worse) are natural risks when part of a software system is shut down. The behavior of the rest of the system might do anything. (Take out accounts payable, and who knows what you'll do to the rest of the accounting system, for example).

    Introduction: A Fine Effort

    Self-help for software is a complex issue. The UCITA drafting committee has tried a staggering number of alternative approaches to self-help, looking for a proper balance between the rights of the vendor, the customer, and the innocent third parties who might be affected by a shutdown of the software.

    The current draft of Section 816 provides important restrictions on the use of self-help. It is not accurate to say that a vendor can unilaterally shut down a customer's system without reasonable notice and reasonable opportunity to respond.

    This is probably the best compromise language that can be developed to deal with this difficult problem. The UCITA drafting committee deserves high praise for its hard work on Section 816.

    Unfortunately, this compromise draft does not meet the legitimate needs of licensors or licensees.

    Licensors Sometimes Need Self-Help

    If a licensee uses a product without paying the fee, or allows too many of its employees to use the product, or uses it beyond the license period, self-help is a useful tool but not an essential one. The licensor can obtain an injunction and then damages without using self-help.

    But sometimes an injunction doesn't meet the need. Here are some examples:

    When you want to shut them down NOW, you can't. Not under Section 816. The 15-plus day delay in exercising self-help drastically diminishes its value.

    Licensees Need Secure Systems

    People whose systems are being trashed by the Back Orifice program (which exploits a security hole from Microsoft) have learned the hard way that application software can carry unintended security risks that can be exploited by third parties.

    When a licensor leaves a back door in its code, something that allows them to shut the software down with a single message:

    Independent Programmers Need Simple Procedures

    The procedures in Section 816 are highly technical. No rational person (except for independent programmers) would exercise self-help without involving an attorney throughout the warning and shut-down process.

    The press coverage of Section 816 is not going to walk readers through all of the safeguards and notice details and contingencies of the section. Nor will the how-to-be-an-independent-consultant books. The book publishers would edit out the details as unintelligible, in the unlikely event that the author understood them well enough to describe them in the first place.

    Imagine a contract for $20,000 in software services, resulting in modifications to your system. One of the modifications (not one you expect) will be a back door. (Didn't see it conspicuously in the contract? The contract was a handshake deal? Ooops, the programmer should have talked to a lawyer. Oh, well. ) Later, you receive an e-mail saying "Pay me for my work or I shut you down tomorrow." (Insufficient notice? Ooops, the programmer really should have talked with a lawyer.)

    The fact that the programmer will have to pay you damages after inappropriately shutting down your system is no consolation. The shutdown costs you $50 million. You get to repossess his pick-up truck, his dog, and his spare computer. And the $500 in his bank account.

    Complex procedures are a trap for the unwary, and independent programmers who do small contracts (less than $50,000) are usually unwary.

    Conclusion

    UCITA Section 816 is probably the best shot that the drafters of NCCUSL can take at being neutral. It is laudable, but it doesn't work. The drafting committee will have to take a side.

    We recognize that taking a side will be unfair. However, we see no alternative. Therefore we recommend that you take the approach that will do the least harm. In particular, we recommend that:

    Submitted by:

    Sharon Marsh Roberts
        Chairman, Government Relations Committee
        and Former National Chairman
        Independent Computer Consultants Association

    and

    Cem Kaner, J.D., Ph.D.


    [ Main | List of Articles | Bad Software | UCC 2B | Law of Software Quality | Digital Signatures | Bookstore | Court Cases | Links | Press Releases | About Us | What's New ]
    The articles at this web site are not legal advice. They do not establish a lawyer/client relationship between me and you. I took care to ensure that they were well researched at the time that I wrote them, but the law changes quickly. By the time you read this material, it may be out of date. Also, the laws of the different States are not the same. These discussions might not apply to your circumstances. Please do not take legal action on the basis of what you read here, without consulting your own attorney.
    Questions or problems regarding this web site should be directed to Cem Kaner, kaner@kaner.com.
    Last modified: July 25, 1999. Copyright © 1999, Cem Kaner. All rights reserved.