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.