A Software Checklist

Documentation

Will you receive all the copies you need?

At what cost?

May you make and distribute copies for internal use?

Term and Termination

Are there any provisions that restrict your ability to simply stop using the software?

In what circumstances may vendor your right to use the software?

Do those circumstances include anything more than:

• Your failure to pay undisputed balances when due?
• You've pirated the software?
• Vendor needs to replace the software to resolve an intellectual property infringement claim from a third party?

Breach

Does the contract provide for the termination of a material breach?

Does it define the term “material breach?”
If it doesn't, how will you know when you have the right to end the agreement and seek a refund?

Remedies

• What happens if things go wrong?
• What are your rights?
• What are your obligations?
• What are your options, short of litigation?

Fees

Is the license fee fully paid up or must you pay year and year out?

If the latter, what will you receive in return?

Are maintenance fees required or optional?

If required, why?

In either case, what will you receive in return?

What will happen if you elect not to pay?

Performance

Must you pay for maintenance releases, bug fixes and the like?

Are new releases and upgrades extra cost items? Why?

How do the parties determine when an extra charge is appropriate?

What are the performance standards for the product?

If you are disappointed, can you point to an objective standard that hasn't been met?

Warranties

Do they start when the product is ordered, shipped, delivered, installed or when you begin using it in production?

What remedies does the warranty provide and are you protected if vendor fails to respond promptly or fails to resolve the problem?

Payments

Are you permitted to withhold disputed payments?

May you hold back a substantial final payment until the software passes its final tests?

Acceptance Testing

Does the contract set out objective performance standards?

Mutually agreed testing procedures?

Timetables for correction, if the software does not pass the acceptance tests?

IP Indemnification

Is vendor required to respond promptly in the event a third party makes an allegation of infringement?

Does vendor have the resources – both technical and financial – to handle such a claim?

Escrow of Source Code

Everyone seems to want a source code escrow. Assume your contract provides one and a release event has occurred. Do you really have the wherewithal to put the source code to productive use?

Limitation of Liability

Imagine a worst-case scenario. How much harm could vendor cause you?

Does the limitation of liability match that exposure?

Insurance

Look again to that worst case scenario. Does vendor have the liquid assets to make you whole? If not, it would be sound business to require vendor to carry the appropriate levels of insurance, from reputable and financially sound carriers.

The Bundle of Sticks

Intellectual property ("IP") types tend to describe IP rights as "a bundle of sticks."  The phrase is meant to illustrate that these rights may be parceled out in different ways to different parties.  Jo Author may sell the rights to publish her book to Acme Publishing, the right to film it to Mega Productions, permission to turn it into a TV series to Sitter In A Box.  She might even give a license to write sequels to Ghost Writers, Inc.  Neither should we forget merchandising - toys, action figures, games and clothing.  Jo would be a very astute business person.  Let us  hope her IP attorney is up to the task!

In the IT world we encounter the bundle most frequently in software licenses.  Indeed, a license is one of the sticks - it is permission to use the asset in a certain way, but not in others.  As a general rule, there is no such thing as implied IP rights.  If your contract does not contain a certain stick that you  happen to need, you don't have the right to use it.  Thus, a software license that grants use rights to a number of  named individuals is a problem  waiting to happen.  If one of those individuals leaves the company, may her successor use the software?  (The answer could well be "Of course.  For a price.")

As a result, a software acquisition requires a bit of care:

• Does the grant of license permit all the uses you want/need?
• Are there any restrictions that could be troublesome in the future, such as named users, named location, set number of users or named processor?
• Do you have rights to back up copies?
• May employees make a copy for home use?  May they access it remotely?
• Do you have the right to make and distribute copies of the Documentation?
• By the way, is the standard documentation sufficient for your needs or will you, or vendor, have to prepare something special?  If so, who will own the rights to that work product?
• Will you pay a one time license fee, or are installments or renewals due over time?
• If there are subsequent payments, what are  you getting for them?
• Are you protected against unexpected price increases over time?
• How will you, the customer, measure the performance and acceptability of the product?
• When, and why, should you have access to vendor's source code?
• Assuming you pay a one-time license fee, does that entitle you to any technical assistance or maintenance?  What are your options if smoke starts to rise from your data center as the vendor's car pulls out of your parking lot?
• Are you permitted to tinker with the product?
• If you tinker and wreck the system, is vendor required to come in and correct the mess?
• If you tinker and create something spectacular, do you own it or does vendor?
• If you create something spectacular from vendor's system, can you sell your new product?
• Can you control vendor's actions if he/she learns something from you and creates something spectacular on his/her own?
• If your unit is sold to another company, does the software go along, or must vendor agree to the transfer?
• May you use the software to process information or perform other work for affiliates or subsidiaries?
• May you freely transfer the software to one of your subsidiaries or affiliates?
• Does the contract require vendor to do anything to keep the software current with the latest technology? (In all honesty, that should probably be the subject of a separate article.)
• When, and why can vendor terminate your use of the software?
• Do you need to give vendor any notice if you decide to stop using the software?
• Does your license ever expire?
• Does the license give you the use rights you want/need?

That last point is a duplicate, of course, but it is deliberate.  It is one of the most important questions to ask - Will this product solve my current business need AND does the written agreement give me all the rights I want and need?


BEFORE signing on the proverbial dotted line, make sure are getting all the "sticks" you need to solve your business problem.

"D" is for Damages

The project is late.  Your team leader had emergency surgery, an earthquake put the server manufacturer two months behind in deliveries and Customer did not tell  you about a  half dozen legacy programs written in Fortran that require customized interfaces to operate with the new system.  You have just received a polite message from Customer that each day of delay is costing $10,000 in lost opportunities, and would you please pay up.  Are you liable?

In this scenario, the answer is "Probably not."  The delay in receiving servers, and the illness of your team leader would be events beyond your control, and would be covered by standard force majeure language,  which reads roughly:

"Neither party shall be liable to the other for loss, delay or disruption caused by events or circumstances beyond the control of said party, such as war, natural disaster, labor unrest or government intervention."

As for the $10,000 per day, the contract should contain language that excludes liability for lost business, lost opportunities and lost profits. More than that, you can object that the claim is speculative, that Customer cannot prove that he would have realized the 10 grand per day but for the delay in completing the new system.  Courts do not like to make awards if the damages cannot be quantified with relative certainty.  

Another scenario:  You deliver the system on time and on budget.  Two days before the warranty expires, you receive a report that smoke is rising from the new server array.  By the time you arrive, the heat from the servers has set off the sprinkler system and everyone at Customer's data center is irate and dripping wet.  Worse, when the data center went down, it took Customer's national network with it, the switch over to a back up center having failed.  When the data center is back in order, Customer discovers it has lost ten years of vital statistical data.  An investigation makes it clear that the initial problem - the over heating, and then the fire in the servers, was caused by your team.  Someone did not follow the manufacturer's instructions.  What do you owe Customer?

Part of the answer is easy - new servers, or repair of the originals.  The force majeure exception would not apply, because this failure was one your team could and should have anticipated and guarded against.  The law calls such damages, which are the reasonably foreseeable consequence of an error or omission "direct damages."  Direct damages are typically recoverable to the extent needed to make the injuried party "whole."  


The meaning of "whole" can lead to much litigation.  In our example, must you:

• Provide Customer with brand new servers of the same model and configuration?
• Repairs to the original servers?
• Servers of the same model and configuration, but refurbished by a third party?
• New servers using a new generation of processors, which just came out and cost one third more than those you originally installed?

The last option - new servers with new processors can probably be excluded, as that would be a windfall for Customer.  He/she would be better off than before the failure.  But what if Customer wants the first option - new servers, and asks that you pay for them to be installed by your competitor?  Would the extra cost - paying your competitor - be a windfall to Customer or merely make Customer whole?  That is a question only the litigation attorneys would enjoy.  Thus a carefully drafted contract will provide that the remedy will be repair or replacement at vendor's option.  A very carefully drafted contract will also protect Customer - adding provisions to ensure that the work is done promptly and correctly.


What of the other damages - the network disruption, the cost of cleaning up from the sprinkler, the lost data?  The network disruption might turn on another question - why did the back up fail?  That is a question Customer needs to take up with its back up provider.  The lost data and the sprinkler clean up, however, are arguably "consequential damages" - they are indirect and unforeseeable results of the failure.  Consider: Shouldn't Customer have  had off site back up for the data, if it was critical to continued operations?  Was it reasonable design a sprinkler system that would inundate the entire center in response to a fire in one area?  Standard contracts routinely exclude liability for such remote, indirect and unforeseeable damages.


Assume the court (the jury and the judge) determine that it was foreseeable that a fire would trigger the sprinklers, which would damage equipment.  Are you liable for the entire cost of replacement equipment and clean up?  Here the limitation of liability provision of the contract would come into play.  Standard language will cap the potential liability of both parties, either at a dollar limit (e.g.  "shall not exceed $X") or using a formula, such as "X times the fees paid...."  Another approach is to tie the limit to the insurance coverage carried by the parties.  This method has the advantage of making sure there is a "deep pocket" - the insurer - on  hand in the event of a claim.  Of course the parties must take care to require that both carry adequate insurance, from reputable, financially sound companies.  

Questions we will address in the future:

• Appropriate insurance language
• Appropriate responses to a force majuere event
• Who should pay for the interfaces mentioned in the first paragraph, and why.

In The News - A Faster 'Net?

(Reuters) - U.S. regulators released a blueprint for upgrading Internet access for all Americans, with Internet speeds up to 25 times the current average, expanded coverage, and more airwaves for mobile services.  The FCC said it would leave open the possibility of taking action if broadcasters do not voluntarily give up spectrum for mobile devices and Internet utilization.

http://www.reuters.com/article/idUSTRE62D0ZX20100316?type=technologyNews

Meta-data or Mega Headache?

Meta-data is an interesting feature of electronic documents.  It refers to "information about information." That is not a terribly helpful definition.

Put another way, meta-data is electronic information our computers generate and keep regarding our computer files. Meta-data can reveal who created a file, when it was last reviewed and how long the file was worked on. It can reveal changes to a document. While such information seems mundane, if not deadly dull, it can have serious consequences. In 2003, British Prime Minister Tony Blair was embarrassed when meta-data in official documents contradicted his position on the war in Iraq. (See http://www.zdnetasia.com/news/software/0,39044164,39191084,00.htm.)In a more ordinary context, imagine opening the Properties file of a document and discovering that your attorney spent 20 minutes drafting it, but charged you for two hours. Worse, a prospective customer used meta-data to discover that you had given a better deal to another customer (who happened to be a particularly good negotiator).

Because meta-data can provide a look "behind the scenes," shrewd litigators will ask for it to be produced during the Discovery process. When responding to a Discovery request, lawyers and IT professionals need to bear in mind that meta-data comes in two types:

• Application meta-data, which is embedded in each file and stays with that file when it is copied;
• System meta-data, which is stored separately in the computer's file system, and which may not be automatically copied.

Consequently, simply copying all the documents on Mr. X's hard drive may not capture all the meta-data and may not comply with the discovery request. Because the extraction is somewhat specialized, the use of a reputable third party vendor is generally recommended.

Of course, meta-data cannot be recovered from documents that have been purged.  However, purging documents after they have been requested will probably cause the court to impose sanctions for destruction of evidence.  Thus organizations need clear procedures to ensure that files, whether paper or electronic, are properly and promptly protected when they become part of of a litigation.

If your lawyers and IT professionals  have not discussed what they will need from one another in the event of a request for electronic documents, they need to do so, before a subpoena arrives.

Congress Considers Requiring Vendors to Protect Human Rights

According to the Wall Street Journal:



U.S. technology companies came under fire on Capitol Hill Tuesday for bowing to pressure by foreign governments to censor or block Internet sites in countries like Iran or China.
Senate Majority Whip Dick Durbin (D., Ill.), who chairs a Senate Judiciary Committee panel, said at a hearing he will introduce legislation "that would require Internet companies to take reasonable steps to protect human rights or face civil or criminal liability."
Companies argue that the laws of the countries in which they operate sometimes require censorship or Web-site restrictions.
This piece was written by Amy Schantz: Amy.Schatz@wsj.com



To read the entire article, go to:

http://online.wsj.com/article SB10001424052748704548604575097603307733826.html?mod=googlenews_wsj#printMode

We will continue to monitor this subject and advise of future developments.

Delivery vs. Installation vs. Successful Acceptance Testing

When should Customer be expected to pay for the new system?  (For this discussion, let's assume the system is a somewhat customized mix of hardware and software.)

When the system is ordered?  Perhaps, particularly if vendor is a reseller who must pay suppliers for the components.  Vendors may balk at fronting lots of money for customers.  The same analysis applies to paying upon delivery.  

But customer is left with a significant exposure.  What if some of the software disks are corrupted, or the hardware contains defective components?  Such deficiencies may not be detected until the system is assembled, installed and turned on.  Let's assume that when the power switch is thrown, something goes ZAP!! and a cloud of smoke rises from the system cabinet.  In an ideal world we would expect vendor to step up, identify the problem and make it right.  But we do not live in an ideal world and vendor may have moved on to the next project.  Requests for assistance might be met with suggestions that the problem resulted from user error, or recommendations to take up the question with the manufacturer.  (In fairness to vendors, we must acknowledge that some errors or failures may indeed be caused by the users.)  If vendor and manufacturers have been paid in full, customer has little leverage, little opportunity to compel them to pay attention. 

Which leads us to payments on the "installment plan": a portion upon order, a portion upon delivery and the bulk upon successful acceptance testing.  If a substantial portion of the contract price is held back until testing is complete, vendor will not lose interest in the project. 

Of course, vendors will not agree to large hold-backs if customer may arbitrarily decide not to pay.  It would not be good business to allow customer to refuse to pay simply because customer doesn't like the final product or now believes it "doesn't work."  As a result, to be successful, hold backs must be tied to testing standards that are mutually agreed and which can be objectively measured.  In that way, vendor and customer are both protected - customer can withhold payment if the system does not "work," while vendor must be paid if it does.

"L" is for "Limitation" and "Liability"

It’s a provision found in almost every commercial contract:
“Vendor shall be liable only for direct damages, in an amount not to exceed $X. In no event will vendor be liable for indirect, special, consequential, exemplary, or punitive damages or for lost profits.”

Although the actual words may vary, the meaning is the same:

•  The most vendor will pay is $X;
• For certain claims, vendor has NO liability.
  

Such provisions raise a number of issues: 

•  They are unfair. Vendor’s liability is capped, but customer’s is not. In other words, vendor knows his or her own maximum liability under the contract, while customer’s liability is unlimited.

• Vendor’s maximum liability - $X – may be inadequate. For example, “X” may be “no more than customer paid under this contract” or “no more than customer paid in the xyz months preceding the event giving rise to the claim for damages.” If we assume customer is paying 10 grand a month, and “xyz” is 12 months, then vendor’s liability is capped at $120,000. While that is not pocket change, is it adequate to cover damage that vendor could cause?
  

How much damage can a vendor cause?

•  How much is the contract worth?
• How much is the over-all project worth?
• Will the vendor have access to sensitive/valuable information?
• Will the vendor have access to sensitive systems or facilities?
  

Being good business persons, vendors will resist expanding their potential liability, and they will offer a variety of arguments in opposition. Some of these arguments carry more weight than others:

•  “We cannot accept unlimited liability.”
  

Customer is not asking for unlimited liability, just responsibility. Customer should not bear a loss resulting from errors or omissions of vendor. Curiously, standard language routinely exposes customers to unlimited liability.

• “Our pricing tied to the amount of liability we can accept.”
  

Again, customer is simply looking for responsibility. In addition, a great price combined with an unacceptable level of risk is not a good deal. A customer who is concerned only with price may be persuaded by this argument. Customers willing to assess the project as a whole may decide that the “great price” is not a good deal after all. There is nothing wrong with telling a vendor “No.”

• “We need a sum certain, so we can manage our risk and buy our insurance, etc.”
  

Customer has the same concerns, so it is only fair to make the limitation mutual. Also, customer has no objection to a sum certain; customer merely wants an ADEQUATE sum. Which is one of the questions we began with.

It may not be possible to determine with certainty how much protection is enough; in which case it is better to ask for too much rather than too little. A number of tools are worth consideration: 

• X times the fees paid and payable under the contract. Three times is a good starting point. Vendor cannot object that they cannot quantify the risk. But, is it adequate to cover the exposure?
• Vendor will be responsible for direct damages incurred. Vendor will object that “direct damages” cannot be quantified. But:
  
  • “Direct damages”- damages that are foreseeable and which flow directly from the breach or action – are the traditional measure of damages under contract law. This is the amount vendor, and customer, would be liable for if the contract did not contain a limitation of liability;
    
  • Presumably vendor carries insurance. (If they do not, why are you doing business with them?)
    
  • Is it unfair to ask the vendor to make good any harm that it causes?
    
  • One caveat. As with any legal term, the meaning of “direct damages” is open to interpretation, and debate, and debate.
    
  
  
• Vendor will be responsible for up to $X. We began with this approach, which is perfectly reasonable, provided X is sufficiently large. A $500,000 cap is terribly insufficient if the exposure is $2 or 3 million. In addition, with a specified cap, vendor cannot claim unknown and potentially unlimited exposure, AND Vendor can obtain the necessarily insurance more easily.
  
• Vendor will be responsible for up to the limits of its insurance. This approach removes the objection that the risk cannot be quantified and that it cannot be insured against. BUT:
  
  
  • The insurance limits must be sufficient to cover the possible risk;
    
  • Customer must require certificates of insurance, evidencing the existence of insurance (not to mention that the insurance must be from reputable companies, licensed to do business in your state);
    
  • Customer must monitor Vendor’s compliance.
    
  
  

All in all, focusing on the limits of vendor’s insurance may be the most productive approach. It overcomes most standard vendor objections AND it helps ensure that sufficient assets are available if things to wrong. Without insurance, vendor may not have sufficient liquid assets to cover the damages. A judgment against a vendor is of little value if it cannot be enforced.
A word about the types of damages to be covered. Contract law traditional protects against direct, foreseeable damages, not those that are so remote that they cannot be reasonably foreseen. The test of “reasonably foreseeable damages” is perhaps misleading. If vendor knows that dropping the ball will interrupt customer’s core business processes, vendor should reasonably expect that customer suffer lost profits. But what would those profits have been had the vendor delivered as promised? Would customer have earned the millions it expected, or would mistakes by customer, or changes in the market, have produced substantially less revenue? Better to exclude special, exemplary and punitive damages – which are awarded by the court (or jury) and have little direct relation to the value of the contract or the harm done, and specify a comfortable limit on damages – all damages, however described or characterized.
Too much protection costs vendor little or nothing. Too little could cost customer dearly.

Copyright 2010, Thomas J. Hall.  All rights reserved.

"M" Is For Material

The term “material breach” is a familiar one. It appears routinely in contracts, generally in the termination provisions:

“Either party may terminate this agreement if the other commits a material breach of any term hereof, and fails to cure such breach within thirty days of receiving written notice of the existence thereof.”

At first reading, this provision appears to be clear, fair and easily enforced. It is mutual – it protects either party. It provides notice and an opportunity to cure, in the event the breach was inadvertent. It permits termination only for serious - “material” - breaches. But what is a “material breach”?

In the legal world, a breach is failure to fulfill an obligation set forth in a contract. A “material breach” is a failure so severe that it threatens the value of the entire contract. For example, if a customer orders one ton of steel, she will probably not want to terminate the contract if the vendor delivers only 1, 998 pounds, rather than the 2,000 expected. Vendor might issue a credit or refund or promise to deliver the missing material immediately. Or customer might overlook the missing two pounds as inconsequential. In contrast, if the vendor delivers one ton of brass rather than steel, customer may wish to cancel the order or terminate the supply contract. If we assume the customer needs the steel for an office tower, the brass simply will not suffice; it is simply not strong enough. Clearly a material breach.

Or is it?

Assume the contract says “metal,” rather than “steel.” Brass is a metal.
Now assume customer wants to terminate the contract because she needs the steel immediately, and lacks the time to wait for vendor to deliver the correct product. Is timely and accurate delivery a condition of the contract? Is it a MATERIAL condition of the contract? Put another way, did vendor know that the contract required him to deliver the right product, at the right time?

What if the contract simply calls for “steel”? Does it matter whether vendor delivers the latest space-age alloy or a truckload of rusting auto parts?

Let's change industries. Customer orders a “computer.”

• Does it matter that the new device processes 16 million instructions per section, when the industry standard is 25 MIPS?
• Does it matter if customer paid a discount price?
• Does it matter if customer paid a premium price?
• Does it matter if the product is delivered “a little” late?
• That is “slightly” over budget? What is “slightly”?
• That it “doesn't quite” work? What is “doesn't quite”?
• That it runs fine as a stand alone, but won't interface with customer's systems?
• That it won't run customer's software?
• Does it matter whether that software is incidental or critical to customer's operations?

Lawyers have a method for finding answers to questions such as these. They call it “discovery.” It is one of the more expensive and time consuming parts of a lawsuit. If there is enough money at stake, vendor's lawyers will leave no file untouched, and no employee not-interviewed, in an effort to show that the alleged breach is not material – that the failure (assuming there was one) did not cause real and substantive harm to customer. Alternatively, vendor's lawyers will argue that the product or service complained about meets the standards set forth in the contract, or that customer never disclosed that requirement X would be central to the deal. Vendor's lawyers will suggest that, at best, customer is mistaken or confused; at worst they will suggest that customer is making a dishonest attempt to escape the contract, for whatever reason.

Which delivers us to a quandary: What is a drafter to do if the officially sanctioned term “material breach” is simply an invitation to dispute and litigation?

Change the definition.

The problem is not the term itself, but the meaning given that term by the law. But, in commercial contracts, laws, regulations, and legal definitions are generally DEFAULT provisions – they apply only if the parties do not set their own rules or definitions. (Within limits. A contract to commit a crime is still a crime, and unenforceable.)

Which of these provisions would you prefer to administer and enforce?
“Either party may terminate this agreement if the other commits a material breach of any term hereof, and fails to cure such breach within thirty days of receiving written notice of the existence thereof.”

OR

“Either party may terminate this agreement if the other commits a material breach of any term hereof, and fails to cure such breach within thirty days of receiving written notice of the existence thereof.  For the purposes of this provision, 'material breach' shall mean....”

Admittedly, the latter is more difficult to complete. Each party must ask itself “What would cause me to want to call off this deal?” Then they must persuade the other party to include those provisions in the agreement. Both steps run counter to the common understanding of the deal process - “Get it done” and “Be positive.” A more realistic rule is probably “Be thorough.” The more time spent up-front spelling out the details of a deal – and identifying the key parts of the deal – the less time will be spent arguing about perceived failings.

Or, as our parents always taught us: “Get it right the first time.”

Copyright 2010, Thomas J. Hall. All rights reserved.