The Tech Law Guy

A Software Checklist

2010-04-05T12:13:00.000-07:00

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

2010-03-30T11:41:00.000-07:00

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

2010-03-16T10:51:00.000-07:00

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?

2010-03-16T08:55:00.001-07:00

(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?

2010-03-03T12:24:00.000-08:00

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

2010-03-02T12:46:00.001-08:00

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

2010-02-17T09:53:00.000-08:00

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"

2010-01-19T12:26:00.000-08:00

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

2010-01-19T12:12:00.000-08:00

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

How Bad Can It Be?

2009-11-27T10:06:00.000-08:00

From the Milwaukee Journal/Sentinel, Nov. 26, 2009:

A digital radio system that has cost the Milwaukee Police Department about $17.5 million since 2003 still is not fully operational, and the system's dispatch consoles - which cost a total of $1.9 million and were installed in 2004 - are becoming obsolete and must be replaced by 2012, according to department and city officials.

Read the complete story of this tech deal gone wrong:

http://www.jsonline.com/news/milwaukee/74212577.html

I Paid For It, Don't I Own It?

2009-11-18T13:35:00.000-08:00

My expert on Internet telecom is unavailable until later this week. As a result, the promised article on VOIP systems will be delayed by a couple of days. In the mean time, let's discuss ownership of intellectual property.

In the last fifteen years or so, "intellectual property" has become one of the favorite buzz words in industry. Everyone wants to have it, protect it and, most of all, exploit it. Which begs the question, what IS intellectual property?

As the name suggests, intellectual property ("IP") is ideas, in particular ideas that are both new and useful. A car engine that would remove greenhouse gases from the atmosphere would be an example of particularly valuable IP asset.

IP is covered by different sets of laws:

Utility patents protect tangible inventions or discoveries, things you can hold in your hand or which perform a useful function. The light bulb is the classic example.

Design patents protect the look or styling of a product. Think of the distinctive shape of a Coca Cola bottle, or the racy lines of your favorite motorcycle. A design patent can help prevent a competitor from copying these "looks" too closely.

Copyrights protect "works of authorship," such as books, music and computer software. (Just to add to the confusion, software can also be patented.)

Trade secrets protect information that is valuable, but not publicly known. Col. Sander's fabled "eleven herbs and spices," is a famous example. Reportedly only a handful of senior executives know the recipe.

Trademarks and service marks protect company logos, such as the Nike "swoop," the yellow Kodak film box, and even the name "Kodak." If I tried to exploit Kodak's good name by bringing out a film product named "Coldack," the good people in Rochester would probably be able to shut me down, claiming that my name is too similar to the name they have used for years.

For today, however, I'd like to focus on patents and copyrights, as they seem to generate the bulk of confusion regarding ownership and use rights.

The default rule in American law is that the person who creates or discovers an IP asset owns it. Or, to put it another way, the law automatically sees the discoverer or creator as the owner, unless he or she has made an agreement that gives ownership to someone else. The legal term for such an agreement is an "assignment" and the new owner is generally referred to as the "assignee."

There is an exception to the default rule, called the "works for hire" rule. It provides that, in certain conditions, assets created by employees in the course of their employment belong to the employer, not the employee. The rule is not as clear as it might be, and employers are encouraged to include assignment language in their personnel handbooks. In addition, if an employee is being hired to do research and development, she or he should be asked to sign an individual agreement, assigning rights to any assets created in the course of employment. "Better safe than sorry."

The default rule can be particularly troublesome when work is outsourced to a contractor. It would seem logical to assume that "I paid for it; I own it." Logical, but contrary to the default rule. You may recall that ten or fifteen years ago, when the Web began to boom, companies discovered that they did not own their Web sites, because they had not secured proper assignment of the page design from the Web developer. The same, or worse, can happen if the "developer" is a third party programmer who happens to create the key part of the new application that will help you dominate your industry. Without proper assignments, you may not have this vital new asset under lock and key. Rather, the third party might be in a position to charge you outrageous support fees, prevent you from modifying "her" product or even market it to your competitors. Any of those would be difficult to explain to the boss.

For all that, one does not always need, or perhaps want, to own all rights to every bit of software one pays to develop. One may front the cost of vendor's development of THEIR new killer application, in return for a great deal on maintenance and upgrades. Or one may pay for the development, and allow re-sale of the new product, provided, it is not sold to your direct competitors and provided you get a cut of the profits. I once effectively owned a major software vendor for several days because no one told me my client was funding vendor's new flagship product. I therefore provided that my client would own all rights to the new product. Their attorneys did not see the problem until after the contract had been signed and delivered.

The lesson is that American law protects the person who creates the IP asset, not necessarily the person who pays for the creation. Care, and often good legal counsel, are needed to ensure that your company secures the rights it wants and needs product it is paying for. But do not stop your analysis with "We paid for it, we want to own it." Ask, rather "What rights do we need to secure the competitive advantage this product offers?" and then "After we've secured our competitive advantage, can we make additional money off the new product?"

If you can transform Project X from an expensive sunk cost into a competitive advantage AND a revenue stream, that would be something to tell the boss.

Some Shameless Self Promotion

2009-11-16T11:50:00.000-08:00

DID YOU KNOW THAT:

The State of Wisconsin has written off $100 million in IT contracts?

Barnes and Noble is being sued for allegedly breaching a confidentiality agreement relating to its new electronic text reading device (the “Nook”)?

Novell and SCO have been involved in litigation regarding ownership of the Unix operating system since January of 2004?

Each of these is an example of a no-win situation. Reputations will be damaged, time and business opportunity will be lost. No one will be significantly better off when the dust settles (except perhaps for the lawyers handling the cases).

Yet such disputes and losses are not inevitable. We can train your personnel to negotiate and draft IT, IP and nondisclosure agreements that are clear, effective and which help ensure the success of the underlying projects. We call them “Contracts That Work.”

Topics include:

Protection of trade secrets
Proper identification and use of confidential information
Ownership of intellectual property
Payment schedules that help ensure performance
Avoiding “project creep”
Securing the rights that you need
Getting the “best price”
Avoiding unexpected delays and unforeseen charges

Sessions are limited to fifteen participants and can be tailored to address the specific needs of individual companies or units.

Contact us at thomasj.hall@gmail.com

About Tom Hall:

Tom Hall is formerly Of Counsel in the Nashville office of Baker, Donelson, Bearman, Caldwell & Berkowitz, PC. He was a member of the firm's business and technology practice group. He has over twenty years experience, both with law firms and as in-house legal counsel. He therefore possesses a unique understanding of the legal and business issues involved in IP and IT transactions.

Tom is co-author of three books on IT and IP matters:

Application Service Provider and Software as a Service Agreements Line By Line
Patent License Agreements Line By Line
Joint Development Agreements Line By Line

(All written with Kelly L. Frey, Sr. and published by Aspatore.)

When 99.9% Availability Isn't Good Enough

2009-11-12T10:08:00.000-08:00

One of the characteristics of Application Service Provider and Software as a Service agreements that give users pause is the question of down time and availability. If the system crashes, will the vendor commit sufficient resources to bring it back on-line in a commercially reasonable time? (By the way, what is a "commercially reasonable time"?) Alternatively, will someone in the vendor's operation take the system down at noon on a Friday, so he or she can perform routine maintenance and still leave early for the beach? If a system is hosted and run in-house, most users feel they have far more control over these exposures.

To address these situations, certain language is found in standard ASP and SaaS contracts, such as:

The System shall be operational, and the Services shall be Available 99.9% of the time each month, with the sole exception of scheduled maintenance periods, which shall last no longer than one (1) hour per day and which shall take place each morning between the hours of 3 a.m. and 4 a.m.

(I have omitted the three pages of technical specs spelling out how availability is measured.)

At first reading, this language appears more than adequate. The system is to be operational virtually around the clock, except for scheduled maintenance, which is to take place well outside normal business hours. Yet at least two exposures remain:

What if the 0.1% permitted downtime occurs when user is struggling to complete its response to a large RFP?

What if user specifically wants to use the service between 3 and 4 a.m.? What if, for example, user is a large investment bank that needs to do complex number crunching, and needs the processing power, and reduced pricing available with "off peak processing"?

The first exposure is a technical one - it arises from possible hardware failures or errors by vendor or software glitches. The proper response is due diligence - verify, before signing the contract - that vendor runs a quality operation AND has appropriate, and redundant, backup systems in place. If Server A fails, Server B should take over automatically and user should never notice the transition. The more critical the service is to user, the more important it is for user to select a user whose practices make it unlikely that unscheduled downtime will ever occur.
As for when scheduled maintenance will occur, that is a risk user can and must control. A user who does not read the contract and does not realize that Vendor X performs maintenance during user's peak demand time really has no grounds to complain. Neither should users expect vendors to readily agree to altering their schedule. The business models of ASP and SaaS vendors call for volume and standardization. Fast food burger joints make money by selling the same burger, millions of time each day. Customization disrupts the system. Rather than attempt to force Vendor X to bend, a prospective user may be better served by thanking X for her time and continue looking for a vendor whose services meet user's needs.

Next week: Let's talk gadgets, not law. A look at VOIP telecomm systems. What are they and how can they contribute to your bottom line?

Case Study – Wisconsin’s $100 Million Loss

2009-11-04T12:54:00.000-08:00

Note: The promised piece on ASP and SaaS availability standards has been postponed for one week.

It has been said that IT projects are always late and over budget. The most commonly given reasons are:

Vendor errors;
Vendor misconduct;
Changed circumstances;
Unforeseen obstacles.

Regarding “vendor misconduct,” it is easy to find IT executives willing to believe that vendors deliberately under estimate cost and time requirements to win contracts, only to have the true cost become apparent as the project unfolds. Such “low balling” undoubtedly occurs, but more often vendor and customer must share responsibility for a troubled project. If “blame” is to be assigned, perhaps it should fall upon customers who ignore the ancient maxim: “caveat emptor.”

Remarkable examples of “how projects go wrong” are provided by the State of Wisconsin, which in late 2006 and early 2007 confronted a number of troubled projects, with an exposure of some $100 million. The figure is all the more significant when one considers that the State’s annual IT budget is roughly $400 million. A quick survey of the troubled projects will help set the stage:

In 2006 the University of Wisconsin discontinued a program to update its salary and benefits system, after spending five years and $26 million.
As of Spring, 2007, a new system to track unemployment taxes was 3.5 years late and $12.2 million over budget.
A new voter registration system was more than two years late (i.e. ready two years after the deadline set by Federal law).
New sales and use tax software required a $5.7 million fix.
Work on a new system to track unemployment claims was suspended in February, 2007, after an expenditure of $23.6 million.
A new system to handle automobile registrations was abandoned. It was at least a year late, $9.4 million over budget and had significantly increased wait times at the DMV offices.

This string of difficulties prompted members of the State legislature to request a formal audit by the Legislative Audit Bureau (Wisconsin’s equivalent to the Federal General Accounting Office). According to the Bureau, these projects had much in common:

Failure to appreciate the complexity of the projects;
Failure to define the final function of the various systems;
Failure to observe contracting best practices, such as standard procedures and incentive/penalty clauses.
Lack of leadership and oversight.

Significantly, ALL of these variables were within the control of the State.

As a case study, Wisconsin’s difficulties are rich in lessons, for it appears the State made virtually every mistake in the proverbial book. It made many of them repeatedly:

Failure to realistically allocate resources;
Failure to plan in detail;
Failure to plan with an end in mind.

Of these, perhaps the most damaging was the failure to plan with an end in mind. Without a clear goal in mind, it is not possible to set meaningful specifications. In turn, an absence of meaningful specifications opens the door to “mission creep” as each user tacks on items from his or her wish list. Cost and time requirements can and probably will increase dramatically. Even without mission creep, ambiguous specs are a recipe for failure. Vendor may believe that customer wants and expects “X,” while customer is expecting something quite different. Unfortunately, the misunderstanding might not be discovered until late in the project, after much time and cash has been invested. Also, without clear specs, it is not possible to develop reliable cost estimates or time tables. In a very real sense, the various Wisconsin projects were not over due or over budget, for they had never been properly planned or budgeted. Quite simply, the State did not know what it was getting into, and paid the price.

Taken as a whole, the Wisconsin projects suggest an IT unit in disarray:

Lack of necessary expertise;
Lack of leadership willing to set reasonable expectations;
Lack of uniform contract forms and contracting procedures to guide personnel who might not be versed contractual matters;
Lack of oversight.

The lack of oversight bears special consideration. The various projects discussed here fell primarily within the responsibility of the Department of Administration (aptly known as “DOA”). That department failed in its responsibilities because it was pre-occupied with two troubled tech projects of its own. A second level of supervision is, in theory, provided by committees of the State legislature. Those committees, however, have been inactive since at least 2005.

Wisconsin’s misadventures offer a sobering example of the many ways IT projects may go wrong:

Failed leadership, leading to unreasonable commitments. These commitments led, in turn, to unreasonable expectations and burdens on personnel.
Lack of a core of personnel trained in the art and science of managing large projects (not to mention negotiating large contracts). As a result, individual units were left to fend for themselves, with unfortunate and expensive results.
Absence of standard forms and procedures to guide users when they were indeed forced to fend for themselves.

A word should also be said about the broader consequences of these difficulties. The responsible CIO has returned to the private sector and the State has represented that all is not lost – that portions of these troubled projects can still be put to productive use. In a private company, the results might have been more dramatic. Such losses, combined with the evidence of failed oversight and leadership, might well cause a wholesale dismissal of management, not to mention the possibility of shareholder derivative suits.
Whatever the political or economic consequences, Wisconsin illustrates the importance of professional, systematic management of IT contracts (indeed, of all contracts) and the importance careful, detailed planning by trained and experienced personnel.

Towards a Successful ASP Agreement, Pt. 2

2009-10-20T13:55:00.000-07:00

Where Has All My Data Gone?

Microsoft and T Mobile are currently receiving lots of bad press relating to the loss of data from users of T Mobile's Sidekick device. Because Microsoft was essentially acting as an ASP for those users – storing data for them – this event raises some interesting questions.

What happens if my ASP loses my data?

That depends on whether the data is critical to the operation of your business. If you were using thousands of Sidekicks to run a world-wide enterprise, you would probably be out of business. In a more likely scenario, if you had out-sourced complex calculations or processing of a large volume of information, you might still face a serious business interruption. Orders may not be filled correctly, or on time, trading (or reporting) deadlines might slip past or payroll checks might not issue on time.

Of course “What happens if my data is lost?” is the obvious question. A better one is “What is the appropriate response to such a loss?” While the answer is obvious – restore the data – it begs a number of questions:

Who is responsible for the restoration?
Who will pay the cost?
Where will the information for the restoration come from?

According to media reports, in the Sidekick case both the main and backup databases were lost due to a server malfunction. From that it would appear Microsoft observed one of the main commandments of computing: Back up your data. Whether the back ups were made in an appropriate manner is not clear from published reports. For example, were the main and back up files stored on the same server, meaning that one failure would interrupt access to both?

User difficulties were apparently compounded by the fact they did not have copies of their data on their PCs or their Sidekick devices. They could not simply update Sidekick from PC (or vice versa) and continue with their lives while Microsoft and T Mobile sorted things out. They had put “all their eggs in one basket,” and lost the basket.

The lessons are not new:

Back up your data
Observe appropriate back up protocols (e.g. off-site storage of back up data)
Keep your own copies, just in case

What safeguards should I observe?

The first safeguard has just been mentioned – keep your own copies. The second is to require the provider to keep its own back ups, and to observe appropriate processes and protocols. At a minimum the contract should require back ups, and specify the protocols to be observed. Failure of provider to meet these obligations should be defined as a material breach of the agreement, constituting grounds for subscriber to terminate the contract. But mere words on the page may be insufficient, particularly if the data is critical, sensitive or protected by law. After all, the ink on the page will not rise up and compel provider to perform. Even a court order enforcing the written words might come only after significant, if not irreparable, harm, has been done to your business. The more important the information is to your business, therefore, the more important it is to verify provider's data protection practices before the contract is signed, and to inspect provider's facility periodically to ensure compliance during the contract term. To avoid any doubt or dispute on the question, the right to inspect should be written into the agreement.

Yet the ASP model contains an exposure not presented by the Sidekick occurrence – loss of functionality. Users could still access the various functions of their devices, but could not retrieve their stored data. But what if the software that enabled each device to communicate with the servers had failed? What if software used by your payroll processor abruptly doubles everyone's salary?

Mitigating this exposure in the ASP context requires a bit of care. Should subscribers require their providers to have off-site back up facilities, able to begin processing in the event a disaster strikes the primary site? Absolutely, if the provider is providing services critical to subscriber's business. Again, the need for careful drafting by counsel and due diligence by business personnel rises in direct proportion to the importance of the services. If provider cannot, or will not, provide such a mirror back up site, consider creating one of your own, complete with copies of the necessary software, licensed for use in the event of catastrophic failure by provider. (Care would also be needed to define what constitutes a “catastrophic failure”.) But if subscriber is compelled to create its own emergency back up site, is the ASP investment cost effective?

What are my remedies?

“What are my remedies?” is simply a polite way of asking “What does my provider owe me?” Assuming the contract has been properly researched, drafted and enforced, the answer should be “Nothing.” A failure at provider's facilities should pass virtually unnoticed by subscriber, certainly without loss of critical information or functionality. That would be an excellent example of a contract that works. After all, even if a court eventually orders provider to hand over a sack of money equal to the value of the interrupted services, it may be too little and too late to pay for your attorneys, lost business and loss of goodwill.

COMING SOON: Part 3 - When is a warranty of 99.7% availability a bad deal?

Steps Towards a Successful ASP, Part 1

2009-10-07T11:40:00.000-07:00

The Application Service Provider ("ASP") model has many attractions:

Someone else pays for the hardware, software, maintenance, updates, etc.
Subscriber pays a fraction of the total cost of implementation.
Competition gives each provider an incentive to continually improve their offerings.

But there are also potential down sides. Someone else controls the:

Hardware
Software
Personnel
Security
Back up
Disaster recovery

If your ASP crashes, will it take along your critical processes?

Setting aside the worst case, there are other reasons an ASP may be unsuitable.

A third part will be given access to subscriber's data.
The services offered may not precisely meet subscriber's business needs or processes. Because many ASP business models are based on standardization and volume, provider may be unwilling to offer custom solutions for individual subscribers. In that event, is it cost effective for subscriber to revise its policies and practices to accommodate the proposed application?
Provider, not subscriber, controls when and how changes to the application are made. If changes effect the "look and feel" of the application, subscriber may encounter unexpected costs and delays for re-training personnel. Alternatively, subscriber may not want the added features, and extra cost, of Version X +1, while provider may not want to continue to support Version X.
In general, neither provider nor subscriber controls the transmission lines, creating an exposure - interruption - that neither party can fully control.
Quitting a provider can be problematic. For example, will the provider simply block subscriber's access to the application or provide transition assistance. If assistance is provided, what will it cost?

Some of these concerns can be addressed through careful contracting, some cannot. If granting provider access to subscriber's data violates privacy laws, or if provider's business model does not allow for needed customization, no amount of brilliant lawyering will make the deal work.

What then, are the foundations of a successful ASP project? A full answer would require a book (See shamless plug below), but I can address some highlights here.

1. Due Diligence

As mentioned, if provider's offerings do not meet subscriber's needs, the relationship will be rocky, at best. But diligence must extend beyond matching needs to services.

Is provider financially sound?
Are its personnel adequately trained?
Does vendor have all the necessary permits and licenses?
Does vendor implement appropriate physical and logical security?
Are appropriate disaster recovery measures in place?

It is important that subscriber verify this information before signing the contract. Afterwards, one can always sue if, for example, there is a disaster and provider does not have in place the recovery safeguards required by the contract. Subscriber might well recover money damages, but those will be cold comfort if he/she has been put out of business.

2. Interim Remedies

In fiction, at least, the appropriate response to any business disagreement appears to be "So Sue Me!" A better approach might be to build in "safety valves" to permit discrete disagreements to be resolved without derailing the entire project. Examples would be meet and confer requirements, permission to withhold payment of disputed balances and a narrow list of circumstances in which provider may suspend or terminate services.

3. Objective Standards

When will the application be available?
What processing speeds will be provided?
What response times will be accepted?
In what format will subscriber's data be stored?
In what format will reports and other output be delivered to subscriber?

To protect both sides, it is important that these and other standards be stated clearly and be subject to objective measurement. Without objective standards, subjective judgments ("It's too slow!") could put the project at risk.

4. Testing

We will purchase an auto after a 20 minute test drive and a house after a walk-through and home inspection (and a little haggling). Outsourcing business functions, however, merits more detailed examination. The more critical the processes, the more important it is to thoroughly test the application in the most realistic setting possible.

5. Business Continuity

If the provider's servers fail, will subscriber's business come to halt? Thus the need to verify that provider observes proper security, back up and recovery procedures. For truly critical processes, consider requiring a source code escrow (which must be kept current) or maintenance of a mirror site that could easily be taken over by subscriber.

We will explore these and other features of a successful ASP contract in greater detail in future postings.

This article is derived from "Application Service Provider and Software As A Service Agreements Line by Line," Kelly L. Frey, Sr. and Thomas J. Hall. Published by Aspatore Press, 2007.

Note - my friend and colleague Kelly Frey had no part in drafting this post. Any errors in it are mine alone.

He's Back

2009-10-01T13:20:00.000-07:00

After a summer of medical challenges, I am once again able to sit up at the keyboard and string two thoughts together.

Sorry for my long silence.

Now let's all get back to work designing Contracts That Work.

Tom

"B" Is For Boilerplate

2009-10-01T12:22:00.000-07:00

Lawyers are fond of boilerplate language. It is quick to add, it covers a wide variety of exposures that might otherwise be overlooked and, since many of the phrases have been around for ages, the meaning is not likely to be debated. It is quick, it is easy, but it can also miss the mark.

Non-lawyers are now asking "What is boilerplate?" It is a lawyer-speak for language that is considered more or less standard in all contracts, such as a disclaimer of consequential damages: "Vendor hereby expressly disclaims any and all liability for consequential damages, whether or not foreseeable and whether or not Vendor was advised of the possibility of such damages." Boilerplate is generally found under the heading of "Miscellaneous."

Difficulties arise, however, when boilerplate is cut and pasted without regard for the transaction in question. For instance, this language comes from an agreement for custom programming service:

Each party to this Agreement shall keep in force during the term of this Agreement a policy or policies of insurance providing the following coverages in commercially reasonable amounts from reputable underwriters:...comprehensive automobile liability, covering all owned, hired, and nonowned vehicles of a party or its affiliates.

Setting aside the questions of what are "commercially reasonable amounts" and how to identify a "reputable underwriter," I am still wondering why auto insurance is relevant to this deal. If memory serves, customer and vendor met twice - when customer drove to vendor's offices. That would not create an exposure for vendor. After the work was awarded, all communications were via telephone, Web conference and email. I struck the language (and vendor agreed) because I saw no raise questions as to whether customer was carrying insurance that would contribute nothing to the deal.

Two of my favorite bits of boilerplate:

1. Mask Works

"Vendor claims all right, title and interest in and to, works of authorship, inventions, mask works, discoveries and other intellectual property created in the performance of this Agreement." But what is a mask work?

According to Wikipedia, a mask work is:

A mask work is a two or three-dimensional layout or topography of an integrated circuit (IC or "chip"), i.e. the arrangement on a chip of semiconductor devices such as transistors and passive electronic components such as resistors and interconnections. By extension, it also refers to the copyright-like intellectual property right conferring time-limited exclusivity to reproduction of a particular layout. The layout is called a mask work because, in photolithographic processes, the multiple etched layers within actual ICs are each created using a mask, called the photomask, to permit or block the light at specific locations, sometimes for hundreds of chips on a wafer simultaneously.

Clearly a mask work can be quite valuable, and such works are specifically protected by US law (17 USC Section 904). At the same time, mentioning mask works in a contract for custom database design merely invites question and confusion, without adding to the protections given to either party.

2. All Rights Anywhere In The Known Universe

"Licensor hereby retains all right, title and interest in and to the intellectual property anywhere in the known universe."

Yes, I have seen this language in genuine contracts. I generally reply that, to my knowledge, the Martians have not agreed to recognize American patents and copyrights. According to one of my very senior colleagues, this language started in a New York firm when satellite communications started to become common. The reasoning was that a radio wave continues forever and ever, and that the copyright owners need appropriate protection. Of course, broadcasts do NOT continue forever, but will eventually dissipate into nothing. More importantly, if the Martians ARE watching reruns of "Lucy" and "My Mother The Car," copyright claims would have to be pursued in Martian courts.

There are, as far as we know, no Martians or Martian courts, but the example is a useful illustration. Copyrights and patents granted in the US provide protection in the US, and not necessarily in other countries. If you plan to market your new Killer Application or Better Mouse Trap in the EU, China, and South America, make sure you have enforceable rights in each region or nation. A boilerplate statement that "Vendor reserves all intellectual property rights anywhere in the world," may simply not do the job if you will be doing business in a nation that requires special registrations or which does not recognize US grants of rights.

Boilerplate can be a drafter's friend, if he/she has a collection generally tailored to his/her field of practice. But both parties are best served if they read the boilerplate with the same care as the main business terms. After all, an error in the boilerplate may not be simply "harmless error" that will not disrupt the deal.

A Bit Of International Law

2009-08-11T10:47:00.000-07:00

A reader has asked about laws governing international transactions, and particularly what law controls if vendor is in one nation and customer is another. While international transactions are not one of my strengths, I've done a few and can offer some insights.

To begin, the transaction must be legal in each nation. While that would seem obvious in theory, in practice it an yield many surprises. Years ago I ordered some rare earth magnets from a well known and well respected vendor of woodworking supplies located in Canada. Rare earth magnets are very powerful for their size, and woodworkers use them in all sorts of ways. I glue them to the wall of my workshop and hang tools from them. A few days later I received a call from a very nice, but rather embarrassed fellow at vendor, who advised that it was (then, at least) illegal to ship such magnets across the US/Canadian border. He apologized for the inconvenience, the rest of my order arrived in due course, and to this day I wonder why magnets, of all things, should receive such treatment from government. The moral however, is that government restrictions can pop up in the most unexpected locations. IT, of course, often receives special scrutiny from regulators. I sometimes think one could make a career simply dealing with US government controls on the export of technology.

Assuming the transaction is permitted in both nations, the next question is how to enforce the agreement. If I, as an American, hire a German company to build a factory in Mongolia, where do I file suit if something goes wrong? Despite all the progress of globalization, there is no “international commercial court” to hear such disputes. My choices would appear to be the US, Germany or Mongolia.

Although Mongolia has long fascinated me, I have no knowledge of their system of commercial law. Perhaps their courts would not even hear a case between two foreigners over a project that just happened to be located in Mongolia. Indeed, if the money is merely flowing between the US and Germany, the Mongolian courts may not have effective jurisdiction. Even if I were to win in the Mongolian courts, I would still have to locate the bank accounts (or other assets) of my German vendor and persuade a court there to enforce the Mongolian judgment.

If we presume the contract was signed in the US, I would have a good case for filing suit in that nation. Again, even if I were to win, I would have to find assets to satisfy the judgment. That could be difficult if my vendor only has a small sales force. In that case my US judgment would be useful only if I can enforce it in Germany.

There are, of course, treaties between most nations promising to respect the judgments of one another's courts. But that does not guarantee success. The German judge might discover some defect in the American proceedings and refuse to confirm the judgment. That would leave me with one option – filing suit in Germany.

In this case I have made at least three mistakes:

I did not insist that the contract specify what law would apply;
I did not insist that the contract specify where any litigation would be filed;
I did not make certain that vendor had assets where I could reach them easily (assuming I won my case).

As a result, I condemned myself to play hide and seek across the world with my vendor.

A better course would have been to:

Hire a US attorney skilled in this type of transaction and the applicable government regulations;
Hire an attorney in Mongolia to ensure compliance with all local laws;
Reach an agreement with the foreign vendor regarding where any disputes will be heard, and what law should apply;
Require the vendor to set up assets or other security within my reach (Vendor, of course, will want similar protection in the event they have to bring suit against me.).

Better to plan and agree how disputes will be handled than to leave the question open and creating something additional to argue about.

"B" is for "Breach"

2009-07-09T11:39:00.000-07:00

The term “material breach” is a familiar one. It appears routinely in contracts, generally in the termination provisions:Ether 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.

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?

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.

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

“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.”

We Have Questions! (Part 1)

2009-06-29T14:13:00.000-07:00

"What shall I write about today?" is always a vexing question.

Happily, readers have come to my rescue with a variety of tough questions. I'll start with two:

1. What clauses would you recommend to protect, assist with and reduce the costs associated with software compliance audits?

To limit the likelihood of "fishing expedition" audits, I typically use language such as:

"Vendor may audit Customer's compliance with this Agreement no more than once each year during the Term hereof. Such audits shall be:

Conducted by properly trained personnel and in a manner designed to minimize disruption of Customer's business operations;

Restricted to those records, files and machines as are reasonably necessary to provide accurate verification of Customer's use of the licensed software; and,

Solely at Vendor's expense."

Vendors might respond "We need a right to audit more than once a year if we receive credible evidence of license violations," and "If we discover a significant violation, Customer should pay for the cost of the audit." These are commercially reasonable requests, but need not be "freebies." If an audit discloses a violations, it may make sense for customer to pay for the audit cost, and pay the necessary additional license fees, but nothing more. Unless the audit discloses deliberate attempts to pirate vendor's software, customer should not incur additional penalties.

The best response to an audit, however, is to maintain careful records of licensed and installed software and to actively enforce policies against the use of unauthorized software. If you know what you have "in house," you will have no need to worry when the auditor knocks at the door. And, if you can present the auditor with complete records that answer all his/her questions, you may very well cut down the time needed for the audit.

2. Please comment on ways to protect a creative invention while searching for funding.

The short answer is "Consult a patent attorney."

A patent attorney is an attorney registered to practice before the Patent and Trademark Office. They are trained in the rules governing what can, and cannot be patented, and in the procedures for filing a patent (in legal-speak, "prosecuting an application). I am not a patent lawyer, but I can comment on the obvious pitfalls.

Create an invention disclosure.

Write up a narrative describing what you invented, when and how. Have your signature notarized and lock the original away in a safe place. Share only photocopies, not the original.

Use a nondisclosure agreement.

Before you disclose the invention to anyone, require them to sign a nondisclosure agreement.

Beware of the "on-sale bar."

Once you publicly disclose the invention, or offer it for sale, the clock begins to run. If you do not file for patent protection within 12 months, you can lose your all right to patent protection.

Be prepared for rejection

If you approach large corporations, be prepared to be turned away without any opportunity to make your pitch. They may have someone already working on a similar invention. If they look at your idea, they could be opening the way to an expensive and frustrating lawsuit.

Remember Rollin White

Rollin White invented the "bored through" revolver cylinder used in modern handguns. He sold his patent to Smith & Wesson and probably expected to die rich and happy. But he overlooked the clause in the sale agreement that required him to sue all those who might infringe on the patent. Despite earning a fortune, Mr. White died so broke that we don't even have a photo of him. He spent it all on lawyers and lawsuits.

Which brings us back to my first point: Talk to a patent attorney. It will be money well spent.

PLEASE KEEP THE QUESTIONS COMING!

Are Your Contracts Litigation Waiting to Happen?

2009-06-24T10:17:00.000-07:00

The law school definition of a “contract" is simple: offer, acceptance and consideration. I offer you $100 for a “car.” You pocket the money and hand over a set of keys. We have formed and performed a contract and all is right in the world. Unless I expected the keys to a Ferrari and received keys to a rusty, unreliable East German Trabant. You might say "My mistake, let me get the correct keys.” More realistically, you might respond “You want a Ferrari for $100? Here, take your money back; I can't afford such a deal.” If I insist that you took my money and are now required to deliver a Testarossa, you might respond: “So sue me.”

Our lawyers will begin shopping for vacation homes, while you and I start taking money from productive programs and setting aside time for depositions, discovery and hearings. Consider the vast array of issues our learned counsel may dispute:

Was there a "meeting of the minds"?

Was buyer simply mistaken or confused?

Did seller mislead buyer?

Would it be against public policy to enforce the deal as buyer understands it?

Was buyer hoping to take advantage of a seller he thought to be unsophisticated (i.e. one who didn't know the true value of that “strange looking” foreign car)?

Of course, the fireworks may be short - circuited by an impolitic question from the judge: ''What does the contract say?''

You may have noticed that I have made no mention of a written contract. Therefore the case is merely my word against yours. Did you really offer a Ferrari for $100? Did I hand over my money without at least specifying what make and model vehicle I expected in return? This uncertainty explains the old legal proverb that “oral contracts are not worth the paper they are written upon.” Without a document setting forth the agreement, and without any witnesses regarding whether you offered me a Ferrari, the judge has limited options. She can tell me to accept the Trabant, or a similarly priced vehicle, or take my money back.

This example, although a bit extreme, illustrates the value of a written agreement. That document provides an independent source of information regarding the nature, extent and terms of the agreement. It provides a reference a third party – typically a judge – may consult when asked to enforce the agreement. As such, it forces the parties to focus on the details of the transaction. Winston Churchill once quipped that “there's nothing quite like being fired upon to focus one's attention." The business equivalent is being asked to sign a contract, to say, in effect, “I believe this document, this deal, represents a good deal for MY company." By signing, one also implies that "I have done my homework on this transaction and we are adequately protected."

Yet, even if our agreement for “a car,” had been put in writing, dispute would not have been precluded. We failed to define the “car,” to specify make, model, year, color, engine, interior, etc. We would have given our attorneys lots to argue over. Despite the risks that can result from a poorly prepared contract, drafting is often an afterthought. “We'll let the attorneys fill in the details later” may get the project started quickly, but it also creates a variety of potential exposures, such as:

Lost savings opportunities;

Late or flawed performance;

Expensive, time consuming disputes over what is, or is not, to be delivered;

Delivery of unsatisfactory services or final product.

A sound contract will tell a story, without any unanswered questions. It will identify who will do what, when, how, why, and for how much. It will also provide a “safety net” of remedies to protect the parties in the event something goes wrong. A contract that addresses both obvious and reasonably foreseeable contingencies is one with reasonable chances of success. In contrast, a contract filled with undefined terms and unanswered questions is a litigation waiting to happen.

Today in Techno History

2009-05-29T18:31:00.000-07:00

May 29, 1944, Colossus Mark II Became Operational

"Colossus was the world's first electronic programmable computer, located at Bletchley Park in Buckinghamshire. Bletchley Park was the British forces' intelligence centre during WWII, and is where cryptographers deciphered top-secret military communiques between Hitler and his armed forces. The communiques were encrypted in the Lorenz code which the Germans considered unbreakable, but the codebreakers at Bletchley cracked the code with the help of Colossus, and so aided the Allies' victory."

Sources

The citation above comes from:

http://www.scienceandsociety.co.uk/results.asp?image=10307385&wwwflag=3&imagepos=3

For a more detailed discussion of WWII code breakers, see The Code Book, by Simon Singh.

Working With Your Attorney, Part One

2009-05-21T15:46:00.000-07:00

Once upon a time I was in-house counsel and had a close working relationship with Jim, Contracts Manager in the IT unit. One day Jim sent me a request for a contract. “Vendor is ABC, price is $2.5 million, split 40/60. Product is a custom program called Killer App.” I drew up the appropriate contract. We would pay $2.5 million, with 40% up front (not always a wise thing to do) and 60% upon final delivery (and passing acceptance tests). All of the work product would belong to us, including all intellectual property rights. My CIO signed; ABC’s lawyers reviewed it and their CEO signed. I filed the executed agreement and went to the next project.

A few days later Jim called and said “We need to change the ABC agreement.”

“Why?” I asked. “I thought they had signed off.”

Jim explained that there had been a mix-up. Our company wanted to front the money to develop ABC’s new flagship product. In return, we would receive a no-charge license and free support ad infinitum. “They want a new agreement that says they own the work product,” Jim said.

I was in a bit of a quandary. ABC’s lawyers had blessed the contract. More, I had been a business lawyer too long to simply give away an asset. I replied “What’s it worth to them?”

Jim laughed and said he’d follow up with management. Later that day our CIO called. He complimented my mercenary instincts, but directed me to make the necessary changes. I did, but I also “extorted” a coffee mug from ABC’s sales rep. I wanted something to commemorate the occasion.

I like this story because it illustrates several things, including the need to involve lawyers in the transaction process. Had I known more about the deal, I could have got the contract right the first time. I would not have an amusing story, but the companies would have saved time and money.

Jim and I took a cue from this transaction and revised our procedures. We created a standard contract request template requiring internal clients to fully describe the transaction. When in doubt, we asked for more information. The CIO also endorsed a requirement that Jim sit in on all negotiations over a certain dollar amount. I also sat in on these from time to time, with the informed consent of the vendor.

An attorney can only draft from what he/she knows. If that knowledge is flawed or incomplete, the contract will be flawed, resulting in unnecessary delay. In addition, regarding the lawyer as merely a scribe, to be involved only at the last minute, can deprive the parties of the lawyer’s experience and insight. No one will be pleased if the lawyer is asked to provide a contract “tomorrow,” and he/she replies “But you have overlooked this, and this, and this and this.”

"L" Is For "Leverage"

2009-05-20T15:22:00.000-07:00

“Make him an offer he can’t refuse,” is a brilliant example of leverage in negotiations, although it has two small flaws:

Violence is generally bad for business; and, on the other hand,
Most businesses are not willing to pay any price for a deal.

Rather, Vendor wants to make the most money possible, and Customer wants to spend the least. The final deal will reflect the skill, tenacity and leverage possessed by each party. In addition, successful performance of a contract may be directly influenced by the leverage retained by Customer.

During negotiations, leverage is directly proportionate to Customer’s options. The more options – the easier it is to say “No” to any one Vendor – the more leverage Customer has. I can recall when, many years ago, “negotiating” with IBM for data services meant haggling over volume discounts and service hours. There were competitors in the market, but none of them rivaled IBM’s reputation for service and cutting edge technology. With little competition, IBM had no incentive to change its standard terms and conditions.

Today there is vigorous competition in most sections of the IT market. Few companies dominate their fields, giving Customers room to negotiate. But it is all too easy for Customer to surrender that advantage to Vendor. Once Customer has said “You’ve got the deal,” Vendor has no incentive to make concessions. Better to award the contract only after the competing vendors have made their best offer on price and terms and standards and service levels and warranties, etc. Also, consider requiring vendors to comment on your standard contract terms as part of RFP. Vendors who request unreasonable changes, or an unreasonable number of changes, may be weeded out early in the process. Time spent on needless negotiation will only delay project completion and a difficult negotiation may portend a difficult relationship.

For a Customer, at least, leverage should not end when the contract is signed. If the agreement calls for Customer to pay in full up front, or at specified interval (e.g. at 30, 60 and 90 days), Customer will lose a major lever – withholding payment if work is late or not up to the agreed standards. This approach requires care if it is to be successful. Timetables and standards must be reasonable and mutually agreed. Standards must be subject to objective measurement. That was Customer will be protected against a delay of “a few days,” that turns into a few weeks, while Vendor is protected against a Customer’s decision that they don’t like (or can’t afford) the product.

Legend has it Archimedes said “Give me a lever and I will move the world.” The business lawyer might well say “Give me more leverage and I’ll get you a better deal.”

The Wordsmith Is In, Part One

2009-05-11T19:49:00.000-07:00

Lawyers have a reputation for being poor writers. We are regarded as wordy, repetitive, wordy, given to overly complex sentences and wordy.

Some complexity in legal drafting cannot be avoided. After all, many contracts record complicated transactions.

But that does not mean lawyers should stop trying to draft contracts that are as clear and brief as possible

To that end we offer some suggestions from George Orwell. His essay, "Politics and the English Language," was first published in May, 1945.

A scrupulous writer, in every sentence that he writes, will ask himself at least four questions, thus:

What am I trying to say?
What words will express it?
What image or idiom will make it clearer?
Is this image fresh enough to have an effect?

And he will probably ask himself two more:

Could I put it more shortly?
Have I said anything that is avoidably ugly?

AND.....

I think the following rules will cover most cases:

Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
Never us a long word where a short one will do.
If it is possible to cut a word out, always cut it out.
Never use the passive where you can use the active.
Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
Break any of these rules sooner than say anything outright barbarous.

These rules sound elementary, and so they are, but they demand a deep change of attitude in anyone who has grown used to writing in the style now fashionable.

"R" is for "Remedy"

2009-05-06T17:44:00.000-07:00

A “remedy” is a tool used when a contract goes bad. Statutory law provides a set of “default” remedies, but they are far from perfect. They are designed to “make a party whole,” to deliver “the benefit of the bargain.” In most cases that “benefit” is measured in cash, and the definition of “benefit” might seem unduly narrow. In addition, statutory remedies are retroactive, and do little to promote performance of the agreement.

Example:

A contracts with B for 100 widgets, at $1.00 each. B fails to deliver and, after a ten day search, A finds C, who provides the widgets for $1.20 each. Also, because of the delay, A incurs a $20 penalty to D. How much does B owe A?

The first claim would be for the extra $20 for the widgets. A expected to pay only $1.00 each, and bid the work based on that price. A incurred the extra cost only because of B (something B would dispute). A may also want to claim the cost of personnel time and lost productivity incurred in the search for a replacement supplier. In addition, A may feel B is liable for the performance penalty.

A’s claims for personnel time and the performance penalty are problematic. Courts tend to focus on the contract price, and are reluctant to add extra costs not contemplated in the agreement. The claim for personnel time could be dismissed as a cost of doing business, and as something A could have controlled, either by making sure B was ready and able to deliver on time, or by having a backup plan. The same logic could apply to the performance penalty, unless the contract between provided that B would pay for it, or the contract contained a “time is of the essence” clause, which would allow A to argue that B should bear the costs. If A recovers only $20, after spending much time and money on litigation, A is unlikely to feel it was “made whole.”

Statutory remedies are not the only ones available to commercial parties. They are free, within reason, to fashion their own remedies. The statutory remedies exist as a default to serve those parties who do not stop to fashion their own.

In the case of A and B, A might have built in a timetable, with penalties if B failed to deliver on time. In return, B might have insisted that A have a viable backup plan, or B could have bought insurance to cover its own exposure.

The more complex or sophisticated the transaction, the greater the likelihood that statutory remedies will be inadequate. All the more reason for parties to design their own. These should:

Encourage vendor to perform on time and within budget;
Provide that timely performance will result in full and prompt payment.

A carefully crafted set of remedies will help keep the project on track. Certain approaches have repeatedly demonstrated their value:

Tie payment to performance, not merely to the passage of time. Pay when X is completed, not on the 30th day after the contract is signed.
Define “success” clearly and in terms that can be objectively measured.
If the project is large or complex, break it into separate phases, permitting customer to call off further work after each phase.

Other Tools:

Mutually agreed acceptance testing standards and procedures, combined with an opportunity for vendor to correct defects. Customer also may want the right to bring in a third party, at vendor’s expense, if vendor is unable to promptly solve the problem.
Warranty coverage, beginning on with first productive use, rather than delivery or installation.

Specifications, specifications, specifications.

What will the product do?
How will performance be measured?
When will it be ready?
What will it cost?
Who will do the work?

Careful planning can eliminate unreasonable expectations and reduce the chance of unpleasant surprises. As Poor Richard taught us: “An ounce of prevention is worth a pound of cure.”

ACCEPTANCE TESTING

2009-04-07T16:38:00.000-07:00

The project is complete. The hardware, bright, shiny and new is in place, with glowing lights and drives humming with new software. The vendor rep performs the initial log in, demonstrates a few features, pockets the last check and leaves. Over the next few days, problems begin to manifest:

The new system is painfully slow to boot;
The automatic backup feature will not run reliably;
The system will not interface with two of your legacy systems;
The system incorrectly calculates withholding taxes when printing paychecks.

The system commits yet another error and remits an incorrect amount of withholding taxes to the IRS;It completely corrupts the accounts receivable file.

Vendor sends in a technician, who announces that all is well with the system and attributes the difficulties to user error. He leaves behind a large bill for his time.

Could this situation - which is deliberately exaggerated - have been avoided?

Certain questions come immediately to mind:
What did vendor commit to deliver"
What did customer expect to receive?
What does the contract say customer was to receive?
What performance standard does the contract specify?

In this instance, the contract refers only to “published specifications” and contains no testing procedures. Of all the safeguards that may be built into a contract, acceptance testing is perhaps the most important. They are the best way to ensure the deliverables:

Performance promised; and
Meet customer's needs.

To be effective, the performance standards and testing procedures must be:

Mutually agreed; and,
Objectively measurable.

Such acceptance procedures protect customer and vendor. Vendor is protected against a customer who, for whatever reason, wants to escape the contract. Customer is protected against a product that does not perform as customer needs and wants it to.

Vendors occasionally balk at acceptance testing. Not because they object to demonstrating the quality of their work, but because, typically, customers will withhold final payment until acceptance is successfully completed. Vendors, like everyone else, prefer to be paid in full, and as quickly as possible. Clear, objective standards can do much to overcome this concern. If the customer cannot withhold payment arbitrarily, then timely payment depends only on the quality of vendor’s work.

Acceptance testing will not ensure that a project will be on time or within budget, but it will do much to ensure that the final product will perform as promised, and as needed.