Friday, November 27, 2009

How Bad Can It Be?

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.



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

Wednesday, November 18, 2009

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

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.

Monday, November 16, 2009

Some Shameless Self Promotion

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

Thursday, November 12, 2009

When 99.9% Availability Isn't Good Enough

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?

 

Wednesday, November 4, 2009

Case Study – Wisconsin’s $100 Million Loss

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.

Tuesday, October 20, 2009

Towards a Successful ASP Agreement, Pt. 2

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?

Wednesday, October 7, 2009

Steps Towards a Successful ASP, Part 1

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.

Thursday, October 1, 2009

He's Back

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

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.

Tuesday, August 11, 2009

A Bit Of International Law

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.

Thursday, July 9, 2009

"B" is for "Breach"

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?

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

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

Change the definition.

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

Which of these provisions would you prefer to administer and enforce?

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

OR

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

For the purposes of this provision, 'material breach' shall mean....”

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

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



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

Monday, June 29, 2009

We Have Questions! (Part 1)

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

Wednesday, June 24, 2009

Are Your Contracts Litigation Waiting to Happen?

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.

Friday, May 29, 2009

Today in Techno History

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.

Thursday, May 21, 2009

Working With Your Attorney, Part One

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

Wednesday, May 20, 2009

"L" Is For "Leverage"

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

Monday, May 11, 2009

The Wordsmith Is In, Part One

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:

  1. What am I trying to say?

  2. What words will express it?

  3. What image or idiom will make it clearer?

  4. Is this image fresh enough to have an effect?

And he will probably ask himself two more:

  1. Could I put it more shortly?

  2. Have I said anything that is avoidably ugly?

AND.....

I think the following rules will cover most cases:

  1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.

  2. Never us a long word where a short one will do.

  3. If it is possible to cut a word out, always cut it out.

  4. Never use the passive where you can use the active.

  5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.

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

Wednesday, May 6, 2009

"R" is for "Remedy"

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

Tuesday, April 7, 2009

ACCEPTANCE TESTING

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.