Killer clauses: The 'gotchas' in software contracts

Computerworld - "Some vendors are like Disney villains," says Brad Peterson. "They're manifestly evil, and you have to watch them." The villains among vendors don't make their big money on initial software licenses, he says, but once you start building your company around the software, they go into "harvest mode," charging substantial fees if you want to continue using that software after mergers, acquisitions or outsourcings, or even if you need to let consultants or contractors use it at your site.
"If no one has taken a look at a little clause like 'right to transfer software,' that's where their profit is," says Peterson, co-author of The Smart Way to Buy Information Technology (Amacom, 1998) and a partner in the outsourcing practice of Mayer, Brown, Rowe & Maw LLP in Chicago. "You really have no choice but to go back to them and ask them how much money they want."
Your only real protection is to understand those "little" clauses before you sign the contract. Here are nine of the more dangerous ones:

1. Scope of use
   What to watch out for: Who is entitled to use the software, and where are they entitled to use it? Is the scope clause narrowly crafted to current use?
   It's very common to want to add users over time, and that includes consultants or contractors, says Paul Roy, also a partner at Mayer, Brown. But even if it's an indirect use -- like an outsourced payroll clerk who needs access to your project management software to see employee work records -- you need consent from the vendor. "It's enormously costly and time-consuming, and the vendor can hold you up for ransom," Roy says.
   Whether it's named users, geographical limits, the number of users or particular machines, "every clause that narrows the scope is an opportunity for the vendor to collect more money when your world changes," he says. Keep definitions broad enough to include users you might add later, and be sure you can do so at the original per-user rate.


2. Statement of work
   What to watch out for: Is it vague or incomplete?
   Never sign a contract without a very detailed statement of work, says Lawrence A. Thomas, a partner who specializes in technology law at Thomas & Opp PA in Minneapolis. You may be tempted to include some 30,000-foot view of the project because the statement of work isn't completed, everybody is eager to move the work forward, and you trust the vendor, he says. But the vendor can later claim that the project has gone beyond its original description and will have to be completed at additional cost. Without a detailed statement of work in the contract, "you're stuck," says Thomas. "You just keep paying and paying."



3. Ownership
   What to watch out for: Who has the rights to custom software you co-develop with a vendor?
   Unless you've spelled it out otherwise in the contract, the vendor has the right to license to others whatever software you develop together, including any best practices or proprietary processes you've built in, Roy says.
   Development agreements should spell out ownership of whatever improvements or input you provide. You should withhold from the commercial product any proprietary processes that give you a competitive edge, Thomas says, but the vendor should be free to license other enhancements. For enhancements that fall in the middle, compromise by holding them back from the market for a year to allow you to get a jump on your industry.


4. Confidentiality
   What to watch out for: Do your employees understand the confidentiality clauses in the software they use? Do you?
   If not, your company may be held responsible for the actions of employees who no longer work there, says Diana J.P. McKenzie, a partner at Gordon & Glickson LLC, a technology law firm in Chicago.
   For example, your company signs a contract with Software Vendor A that stipulates that your company won't compete with the vendor. Jane, your chief architect, later leaves to form a software company that competes directly with Vendor A. "Vendor A isn't going to sue Jane unless she's a rip-roaring success on Day 1," McKenzie says. "It's going to sue the company with the deep pockets, which is you."
   You're responsible for explaining the rules to Jane and having her sign a noncompete agreement, McKenzie says. "But in a world where we're all trying to cut expenses, some of that detail can get cut out of your process. And that's a really bad idea."


5. Warranty
   What to watch out for: Is the vendor promising to meet your business needs or just provide software?
   You may think you've bought the solution to your business problems, when you've really bought only the right to use the software, which may or may not meet your needs, Peterson explains. Regardless of what the salesperson promised, he says, "the contract is the final statement of all obligations of the parties."
   Resist pressure to do the deal quickly, he says. List your specific needs and what the software has to do to meet those needs. Then get the vendor to commit in the contract that the software meets those needs. "Think it through, write it down, and determine whether you've got a commitment," he says.


6. Implementation delay
   What to watch out for: If you allow a vendor to postpone an implementation deadline, can the vendor delay completion of the implementation indefinitely?
   
   "You have to be careful when you push back the timing that you don't wind up giving the vendor an unfettered right to never complete," McKenzie says. When you let a deadline slide, there's a tendency to just say the new deadline is whatever the parties agree on, she says. But if the vendor has other, newer priorities, it may never agree.
   If you decide to change any dates, be very careful and put the new deadline in writing, she says. "And make it clear it's a one-time-only deal."


7. Limitational liability
   What to watch out for: If everything goes wrong, can the vendor pay a relatively small fee and leave you holding the bag?
   In virtually every contract, McKenzie says, there's a limitational liability clause that lays out the maximum a vendor would have to pay if it did everything wrong. But in this economy, some vendors are using such clauses to get out of bad deals. "If the vendor is losing money on the deal, we sometimes see them just hand you the limitational liability and walk," she says. "We're seeing those more than ever before."
   Negotiate a limitational liability clause that's very large or even unlimited, she says. Then the vendor has to make the engagement work or finance your transition to another vendor.


8. Upgrades
   What to watch out for: Do you have to pay for major software upgrades?
   Upgrades are normally included in the maintenance costs of a contract, but vendors like to add a clause stating that when they believe an upgrade is major, you have to pay for it, Peterson says. If you allow such a clause, you've got no leverage, he says. "You can't decide to stay on the old version, because after a while it's not supported, and switching systems is very painful."
   Negotiate the right to upgrades. "You're protecting your future and making sure you don't have large, unexpected costs," Peterson says.


9. Response times
   What to watch out for: Is there an objective warranty regarding response times?
   "The biggest reason CIOs get fired is response times are too high," says McKenzie. "You don't want a system where you hit 'Enter' and you can go have a cocktail while you wait for the screen to come back." Make sure you have a warranty for response times that's based on objective standards, typically less than a second for critical functions, she says.

Read more about Applications in Computerworld's Applications Topic Center.