December 06, 2000, 10:41 AM —
How should corporate customers design their software procurement contracts to
protect? Here's a short list of the things experts I've talked to recommend:
1. Governing law
The first and most obvious step is to have the law of the contract governed by a
state that shows no sign of passing UCITA soon. But as it's hard to say where the
software lobby might next concentrate its efforts -- and its green stuff -- a better
alternative might be a "bombshelter" governing law provision. Similar to the
legislation enacted in Iowa, the contract should say that in the event UCITA is enacted
in your state, the governing law remains the one that existed when the contract was
signed.
Don't overestimate how much protection this will give you. If your state does enact
the software industry's law and you find yourself in a contract dispute with a local
software vendor, there is no way to guarantee the court won't use UCITA principles in
adjudicating it. In fact, we've seen court decisions (Hill vs. Gateway, Mortenson vs.
Timberline Software) that used UCITA-like logic while it was still being drafted, so
you can't base your defense solely on governing law.
2. Disavowal of remote disabling
The contract should explicitly state that electronic self help will not be used to
prevent your use of the software and that you may only be deprived of its use through a
court order. More importantly, the vendor should warrant that the software will contain
no undisclosed restrictive code or automatic restraints that are not specifically
authorized in the agreement. (For example, if the vendor wants to include a metering
system to enforce a 100-user limit in the license, the contract must affirm they have
the right to include that restrictive code.) Further, they should warrant they will not
introduce any restraints at a future date via modem, software update or any other means
without first obtaining your approval in writing. And no limitation of liability or
consequential damages should apply to a breach of these provisions.
3. Product capabilities
As UCITA makes it very difficult to reject a product even for glaring defects, you
should spell out in the greatest possible detail all the capabilities the delivered
version must provide. The vendor should warrant the software will perform substantially
as promised in all product descriptions, literature, documentation and correspondence
provided to you. If the vendor fails to meet any of its express warranties, you should
at your option have the right to reject the tendered product in total or in part and to
withhold payment until all requirements are met.
4. Contract modifications
Every contract should state categorically that it cannot be modified without
a "written signature on paper" by both parties agreeing to the change. As the official
reporter's comments to UCITA make very clear, anything short of that language (such as
a requirement for "a signed writing") means that a negotiated and signed agreement can
be tossed aside by one mouse click accepting an unread clickwrap agreement included in
the software in bad faith at a later date. I know this sounds absurd, but that's UCITA
for you.
5. Duration of contract
If you believe you are acquiring the right to use the software as long as you like,
it is important that the contract explicitly says that you are receiving a perpetual
license to use it. Otherwise, you are likely to find yourself operating under the
default rule in UUCITA that says the license is granted only for a "reasonable time"
and can therefore be terminated at will by the licensor. Similarly, if you are
acquiring a site license for what you assume is an unlimited number of users at your
company, the contract should state that or you could be required to pay later for
adding more than a "reasonable number of users" as your company grows.
6. Notification
Any notification requirements in the contract should spell out what constitutes
actual notification and the rules for verifying receipt. Under UCITA, you are deemed to
have received notice even if an e-mail message is sent to an address that's no longer
valid or is purged by your spam filters without being seen.
7. Transfer of license
The contract should specify how restrictions on transferring the license apply to
change of ownership or corporate restructuring of licensee.
