| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 | ||||
|
|
|
||
|
||||||||||||||||||||||||||||||||||||||
 NEWSIT negotiating points By Ed Foster August 18, 2000 1:01 pm PT 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:
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 UCITA 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. 8. Noninfringement warranty Warranties of noninfringment msst specifically state they apply to "worldwide" rights to use the software. By default, warranties of non-infringement under UCITA apply only to U.S. rights, even if the license is being granted for international use. A few other things experts suggest is that the vendor warrants the product has been no known defects other than those they have disclosed to you, does not send data back to the vendor or other sites, and has been tested for viruses. If nothing else, what you need to take away from this is the unfortunate fact that negotiations on software contracts in UCITA states are going to be more difficult than they used to be. You'll need more lawyers and you'll need them in situations where you didn't need them before, and so will the small software developers. Isn't it funny how a bunch of lawyers sat down to write a law to make software transactions easier and instead produced one that's just going to make a bunch of lawyers richer? SPONSORED WHITE PAPERS 
SPONSORED LINKS
|
||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
