Tuesday, March 30, 2010

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.

Tuesday, March 16, 2010

"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.

Wednesday, March 3, 2010

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.

Tuesday, March 2, 2010

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:

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