Category Archives: IP Indemnity

This Week on The Web 2009-09-06

The things that happened around the web this week – maybe you already read about them, maybe you need to again.

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.


Notes from the “I told you so” file

Well, it didn’t take too long.  C-Net reports today that Google inadvertently shared some Google docs files with folks they weren’t supposed to be shared with.

Lifehacker ponders whether this is a “minor privacy blunder”.

Meanwhile, Google is busy blaming it on the user (italics are mine):  “We’ve identified and fixed a bug which may have caused you to share some of your documents without your knowledge.”

Yeah, Lifehacker, this isn’t minor.  It never is.  Especially to those individuals who have data that was shared without knowledge.  Oh, and C-Net, you shouldn’t downplay this either – so while mentioning that lost laptops are a security risk, too, it doesn’t do anything to resolve the issue at hand.

Look folks, any breach of privacy, especially in a SaaS/cloud-computing environment is a HUGE problem.  Shore up your contracts today, please (confidentiality, IP indemnification, and exclusions for breach of confidentiality in your limitation of liability language).  Need help doing it?  Just give me a shout.

Limitation of Liability

A contract is an allocation of risk and liability limits are a huge bone of contention.

Vendors want to limit their liability to very specific types of damages:  1.  They want to only be responsible for direct damages; and, 2. They only want to be liable up to a capped dollar amount.  Generally speaking, this is acceptable (we’ll talk about the dollar amount in a second), as it’s a question of reasonability.

With respects to the types of damages (direct, indirect, consequentials, specials, etc), direct damages (in a very layperson definition) are those that are connected to the cause of the liability.  So, for example, if Person A steals from Person B, the cost of the stolen goods would be direct damages.  But, in the event that the theft led to Person B being unable to complete another business transaction (and thus negatively impacting Person B), that negative impact would be “consequential.”  You can quickly see that damages other than directs can be hard to quantify or calculate – and someone who would be liable for more than directs would not have a good way to understand their total portfolio of liability.

For dollar amounts, most people used to say that you could reasonably ask for 3x the amount “spent” under the terms of the agreement.  But to be fair to both sides, any amount I might recommend here isn’t a fair assessment of damages.  When discussing software deals gone bad, I typically want every penny I’ve paid over the term of the agreement returned to me – this is less an exact science of knowing the amount of future damage and more of an understanding of what it costs to replace software once integrated into an environment.

With respects to both limitations on liability (type and amount), customers should be able to get three exceptions:  A.  Indemnification Obligations (including both IP and general indemnity), B.  Breach of Confidentiality, and C. Gross Negligence or Willful Misconduct.  These three things, in my (supported) opinion, are eligible for ALL forms of liability and without any financial limit, either.  In almost all cases, vendors do not challenge these exclusions from the limits.  They recognize, as does the customer, that indemnification is only valuable when unlimited, that breaches of confidentiality have far reaching implications, and that willful acts shouldn’t be capped, either.

However, even a generous vendor is only going to allow themselves to be “on the hook” for indemnification for software that they licensed in the form in which it was licensed, or for certain types of damages.  Modifications to the software, for example, usually prevent indemnification to the extent that the infringement is a result of those modifications and not based on the unmodified software received from the provider.  However, in many instances, vendors rely heavily on talking the customer through various issues via phone or via e-mail and they provide a variety of bug fixes in numerous ways.  It is advisable to change any language limiting liability as a result of modifications made by licensee to read “modifications made by customer unless authorized by provider.”  This allows for the ability of the customer to make changes to the software at the vendor’s direction but not remove the vendor’s liability for the changes that are made.

In some cases, vendors are concerned that even this language is not enough protection as the customer might not follow the directions/instructions provided by the vendor.  If that is the case, language such as “modifications made by customer unless authorized in writing by vendor and such modifications explicitly conform to the changes contained in the written authorization” can be used.  The net result is that the customer should not be harmed as a result of following the directions of the provider with respect to their software.

Recently, I’ve seen some significant push-back on the limitations section – a desire to avoid the exclusions and reductions in the financial amount, as well.  I’m pushing back and I continue to use one of my favorite bad-cop/jerk phrases when discussing what will happen if the vendor breaches confidentiality (“I want to own your company.”).  What’s happening in your deals?

Letters of Intent

When was the last time that someone referred to you as the Order Prevention Department? Business folks tend to think that a contracts staff is only there to stop them from getting their next purchase. We know better, of course, but it doesn’t change the fact that we are constantly having to show value and purpose to our existence in the fact of adversity.

Recently, I was engaged in the beginning of a deal that would end with the purchase of a large technology system. The evaluation was done via an almost picture-perfect RFx process, spearheaded by a business owner who knows the value of a corporate contracts group and for whom I hold great respect. As the selection process neared conclusion, the business got anxious. They “needed” to start work immediately to meet their internal deadlines and thus wanted to do a…

… wait for it …

… bu, bum, baaaah…

Letter of Intent!

I wanted to cry. Here we were, humming along beautifully, and they wanted to derail it with a Letter of Intent (LoI).

Now, if you’ve never heard of a LoI, it is to a contract what a golf cart is to a car. In other words, it might eventually get you to your destination, but without the protection afforded by an enclosed vehicle. LoI’s are one of the banes of a contract negotiator’s existence – a poor excuse for a contract and they are sometimes seen as the easy way out to get a deal done quickly.

In the particular example above, the business wanted to use it as a bridge to get work started while we negotiated the full agreement. Since LoIs take at least some time, there’s a choice to devote some effort to the LoI rather than review the full agreement. Granted, the full contract will require MORE time, but I don’t think it outweighs the risks of the average LoI.

When confronted with a request to review a LoI (and when you can’t negotiate with the business to just forge ahead with the full agreement), then remember to at least lock down the following things:

1. Term. Place a limit on how long this interim agreement is going to last. The shorter the term, the less the risk.

2. Fee/Rate. Clearly state the rate/fees and how they will be calculated. A fixed fee is always best (and even better if that fee is $0.00). If you really want to protect yourself, include a cap on the total amount of money that can be expensed under the LoI. Remember always that a one-week engagement isn’t equal to only 40 hours – 2 resources = 80 hours, 3 resources = 120 hours. Multiply against your listed hourly rate and you can see “small” agreement add up quickly. Oh, and don’t forget about capping expenses, too.

3. License. If you’re getting access to software without a full license – WATCH OUT. All of the standard license issues still apply (IP indemnification and virii for example). Also remember that if for any reason the full agreement doesn’t get signed, it’s most likely that your license will terminate.

4. Services. Clarify ownership for anything created as a result of services performed. What happens if the full agreement isn’t completed? Do you lose ownership? How about work that includes your confidential information?

5. Warranty. Depending on how long the LoI lasts, or how any deliverables are created and delivered, you may need/desire a warranty for those deliverables.

6. Indemnification. As mentioned above, and for deliverables/services, too, you will want to be indemnified in the event that the vendor uses something they don’t have the right to use in performing the work. You will also want a general indemnification if the vendor is going to be onsite at your facilities in the interim term.

7. Confidentiality. Hopefully you’ve already completed a Non-Disclosure or Confidentiality Agreement with any vendor that you’re willing to use a LoI with – but if not, include your standard confidentiality language.

8. Termination. As with any other license or services agreement, include standard termination for breach language. Make sure you also retain the ability to terminate the LoI at any time, for any reason. It’s probably reasonable that you will have to pay for services performed up to the moment of termination, but don’t forget to tie it to ownership over work completed and paid for.

9. Governing Law. Fairly self-explanatory, but don’t forget to cover governing law. And remove jurisdictional statements, just like always.

Oh, and to make matters even worse, each of the terms you negotiate in the LoI may change in the full agreement, as the risk you (or the vendor) are willing to tolerate in a short-term agreement may be drastically different than the risk you (or they) are willing to take in the long run. The usual saving grace in all of this is that the vendor probably doesn’t want the LoI either – work together to make it palatable.

Take this EULA… and shove it!

[Note: The following is an article written for Soft*Letter early this year. I got a few calls about EULAs the other day, and like NDA’s, I felt they deserved a shout out. The article is a bit long and does cover some topics already discussed – the advice given herein is specifically for EULAs and is from the customer’s perspective.]

Have you (or your sales team) ever gotten this call?

“Hi! I’m Jeff from the contract management group at yournextcustomer. I’m calling about the End User License Agreement (EULA) that your distributor would like us to agree to before purchasing your product. I just have a few issues with it and want to know where to send a redline.”

Do you know what is happening or about to happen? The call above is not fabricated, as it is a conversation I have personally started hundreds of times with a variety of software vendors over the last several years. The companies I’ve worked for believe they are large enough to not have to agree to a one-sided contract and I was hired for the express purpose of negotiating a more favorable license agreement with each of our vendors. Invariably, I start with the sales contact, get passed to management, and I usually end up with a contract more favorable to my company than it is to yours.

When I initiate the call, I am usually confident about two key things. The first is that you want our business. As a large buyer in a particular industry, you may want to leverage experience in that industry into more lucrative deals. I count on the fact that you realize that an initial purchase is almost never the final purchase, and that getting your foot in the door with a negotiated agreement is better than no deal at all. Secondly, and perhaps more importantly, I know that I can use that “want” of business to leverage you into using my template license agreement. Truthfully, neither of these two facts will probably change. You will still want your customer’s business and will still be willing to make concessions in order to reach that goal. The important next detail, then, is an awareness of the various options available when a customer refuses to agree to your EULA.

Initially, you have three possible options, depending on your comfort level and pre-planning: a) Offer the customer a negotiable Software License Agreement, b) Negotiate the terms of the EULA itself, or c) Use the customer’s template Software License Agreement. Obviously, if possible, you would want to use option (a) first. It’s probably longer than your EULA, but it also has probably been written in a way that would allow for some concessions to various terms and conditions.

Options (b) and (c), however, pose more difficult challenges. EULA’s are now distributed to the customer by one of two main conduits, either as a click-through agreement or as a PDF, sent prior to the sale or attached to the ordering document. As a negotiator, I prefer to use an electronic form of the agreement, so having a word-processing document format would be advisable. Using e-mail to send the document to your customer subtly tells the customer that you have a document from which you want to start and it opens the door for negotiation without agreeing to use the customer’s template.

Regardless of which document you end up negotiating, there are key license and other terms that you need to consider with respects to margin, liability and feasibility issues. In essence, you need to evaluate the language with an eye to profitability, exposure and whether you can actually live up to the agreement. Your answers to these issues, of course, are unique to your business, but the following sections are usually considered the most crucial to any software license and should be paid special attention.

License Grant
While the nature of software licensing versus sales is beyond the scope of this article, suffice it to say that you will be granting your customer a set of rights to your software. These rights can be as simple as the ability to use the product, and as complex as the ability to create and/or own derivative works from your product. Additional considerations such as backup copies, location-based restrictions and other options results in your need to clearly understand what you want to allow your customers to do with your product and what rights they will need to accomplish their purpose for licensing.

In days of yore it was once common to see a one-year warranty. More common now, however, is a short-term warranty of anywhere from 30 to 90 days. The reduction in length is a function of the real purpose of a warranty, namely, to show to the customer that your product works as advertised. The complex nature of customer environments discourages software vendors from offering a longer term warranty, as the risk of issues increases the longer the product is installed. On the other hand, most customers believe a warranty to act in the form of an insurance plan – a way to guaranty that the product continues to work over a longer period.

Customers also have a tendency to believe that warranties are the free version of maintenance or support services. To their credit, this was a functionally accurate description until the late 1980s, when many software vendors started offering maintenance programs designed to provide long-term support and product updates. Once the two types of help (at the time of installation versus in the future) were delineated, customers were often confused by the software vendor’s attempt to separate these concepts in the contract.

Today it is imperative that a warranty describe those things that you guaranty will never happen, and those things that will be fixed at no charge (for some limited period of time). Amongst this list would be warranties that protect the customer against problems resulting from ownership issues, conformance to documentation, processing four-digit years and a warranty protecting the customer from the introduction of malicious code.

When a customer licenses software, one of the last things they want to have to worry about is a situation where the software vendor does not have the right to license or is not the owner of the product licensed. This scenario creates substantial financial liability that the customer believes they are paying the vendor to assume. As a result, the concept of indemnification is used by vendors to promise to customers that they will be receiving an unencumbered license (based on the license grant as discussed above). Indemnification obligations are most often a) limited to only cover the most recent version of a particular product, but b) offer unlimited financial protection to the customer (the cost of the product, attorney’s fees and any damages awarded to a true owner). An EULA may offer little or no indemnification, but the desire by a customer to include an indemnification section should not come as a surprise to a software vendor.

Another common, but often overlooked provision is one detailing the confidential information of each party and the obligations the recipient of confidential information will have to the discloser. Confidentiality terms should almost always be mutual. Each side should have an identical obligation to the other side with respects to how they are going to treat information they receive. Software would be included within the definition of confidential information for the vendor, whereas specifications, drawings and other work product might be information special to the customer.

There are five standard exclusions from protection: 1) information already known by the recipient, 2) information later received from someone not under a confidentiality agreement, 3) information put into the public domain, 4) information you’re later told by the discloser is no longer confidential, and 5) information required to be disclosed by a court of law (so long as recipient gives the discloser reasonable notice that they’re being compelled to provide confidential information).

Term and Termination
Software license agreements are usually found to be either perpetual (license the software once and there are no additional license fees) or term-based (license the software for a set period of time and renew the license afterwards if still needed). A third variety, the so-called “subscription model”, is essentially a term-based license for a set number of years and the license includes maintenance, support and upgrades. There is a faction of attorneys and negotiators that are concerned about the perpetual model, and thus resort to a 99-year term license. This is not a subscription, but a way to license the software well beyond its useful life. When negotiating, watch for the conversion of a term-based license to a perpetual license and for the inclusion of maintenance, support and upgrades.

Termination is also a consideration, as most EULAs will have broad termination rights for the vendor. It is not uncommon to have almost identical termination capabilities for both parties and to limit termination for cause to the breach of a party’s obligations. Customers sometimes desire the ability to unilaterally terminate the agreement without cause (you can’t force a customer to use the product). Vendors can usually accept this provision with the caveat that the licensee and/or maintenance fees for the current term still be paid as due under the agreement.

Perpetual and term-based licenses are designed to allow continued use of a product over a long period of time. In the meantime, the software vendor continues to develop their product line as well as provide support for the current products. Customers are usually offered the ability to purchase maintenance as a way to obtain those newly-developed products without paying the entire licensing fee all over again, as well as to enable the vendor to offer help in the event of a problem. Confusion sometimes happens when maintenance and/or support are separated into their component parts or when service capabilities are redefined to mesh with the customer’s needs. Care must be taken to be sure that what is sold is actually able to be provided and that what is provided is going to satisfy the needs of the customer.

Converting an EULA into a fully-negotiated contract is not usually advised, as the level of risk involved in the transaction can increase proportionately to the changes in language. If you do not have a full Software License Agreement and you are selling a product for more than $15,000-$20,000 (either a single product or an average sale), it is advisable that you have one developed, as buyers of that quantity of product expect the ability to negotiate. As starting the negotiation process from your preferred language is one goal of the EULA, maintain that advantage by developing a negotiable license as well.

Demo/Eval Agreements

Almost every large software purchase is predicated on the ability of the end user to review the product. When you’re buying something of that magnitude, it’s not unreasonable to have that testing time.

But vendors don’t just deposit software at even their most favorite customer’s facility without assurance that the software is going to have some sort of contractual fence protecting it from release, abuse or misuse. So the typical pattern for a customer to test software is a one-two contractual punch of a non-disclosure agreement (NDA) in addition to, or part of, an evaluation agreement.

We’ll talk NDA’s in the near future – today is about the eval.

Evaluation agreements (also called Demo Agreements) are used for GA software, not just software still in development or otherwise limited or restricted in some way. So invariably, the contract presented is a repurposed software license… which does, actually, have the right type of terms and conditions necessary to effect the temporary relationship desired.

The problem, however, is that temporary relationships have a tendency to become permanent simply by inattentiveness. And a contract that’s designed to be temporary has probably been given less review attention at the outset of the relationship. Which means that a long-term eval/demo agreement is essentially a possible perpetual license agreement. Combining the lesser review attention with the possibility of perpetuality, and you get a bad deal from the customer perspective.

The fix, of course, is diligence. Remember that each interaction between vendor and customer has the chance to last much longer than originally intended… the chance to apply to things never initially considered. And it is for this reason that many contract professionals have a negative visceral reaction to eval or demo agreements. The business people believe that it’s “just a demo”, and the contracts folks know that it can become so much more.

When reviewing an eval agreement, the most effective solution is to place a termination date in the agreement itself. This will cut short the demo/evaluation process (which the business folks must be aware of), but it will at least prevent the eval from becoming the more permanent software license for the purchased product. Of course, this doesn’t stop someone from amending the agreement to make it last longer, but at least there’s the chance that the someone will also at least ask the question of why there was termination for the eval in the first place.

If you have the time or wherewithal, evals should be reviewed in as much depth as any other normal software license agreement. This allows you the flexibility to slip into a longer term relationship without worry about the terms and conditions of the underlying agreement (and without additional review/negotiation time/expense). But it does require a more extensive up-front investment of time, which is often problematic for organizations that don’t have a lot of contract reviewing staff or are paying outside counsel for time to review agreements that might never lead to a purchase.

Oh, and by the way, NEVER accept any type of eval agreement without the same IP Indemnification clause you would get in any other software license. If you’re going to install the software at your organization, you need the same protections that you’d need from purchased software. Arguments from the vendor that the customer is not paying for the software and is thus not eligible for protection should not be paid any attention.

Whatever the solution that is right for you, just remember that the eval is just as binding as any other agreement… the term “eval” isn’t meant to describe the agreement.

Open Wha?

[OK… my bad… things got a bit busy yesterday.]

I live in Raleigh, NC – home to RedHat Software. Most of you have heard of RedHat as a result of their linux offering. But more than that, almost everyone has heard of RedHat because they sell free software. Initially, this was absolutely dumbfounding, confusing even seasoned contract negotiators with the world’s first broad introduction to the concept of free software, also known as open source software.

[Let’s clear something up just in case there are still any misunderstandings. “Free” software, is not actually free. The term “free” is meant to refer to access to the source code, not to financial costs. As a result, it’s better to use the term “open source” when talking about this access.]

Open source software, then, is based on the idea that the source code would be provided along with the object code at no additional charge. In other words, you still end up BUYING the object code, but you get the source for free and a license to make changes (and distribute the source code per the constraints of the license if you make said changes).

But all of this open distribution leads to an absence of definitive liability. The result is that if you have licensed open source products for use in an enterprise environment, you can have problems with indemnification, warranty, and other “missing” traditional contract terms. So the trick is to understand the scope of the open source usage in your environment in conjunction with the license provided. This obviously can become a large issue.

Additionally, there are currently more then 50 “accepted” open source standard agreements. Each one is unique in some form or fashion – and thus each one provides at least a small difference in terms of the rights and obligations apportioned. The net effect is that each of these licenses has to be read very carefully. Any vendor looking to use open source software (and any customer looking to use a vendor who uses open source software) needs to read, re-read, and triple-re-read the license to understand the specifics of what is provided, what has to remain “open” in the future and what kinds of protections you have in the event of a problem. At the end of the day, then, what you have is a completely custom software license that has to be read with a fine-tooth comb. DO NOT TAKE THE USE OF OPEN SOURCE SOFTWARE IN VENDOR PRODUCTS LIGHTLY!!!

ICN offers a slew of conferences and presentations on a variety of contracting and negotiation topics. In June, the Technology Procurement Conference in Chicago will offer attendees the chance to deep-dive into technology contracting-related topics in a series of 3-hour sessions. It sounds like one of the topics for this conference is going to be on Open Source procurement. Check it out (especially since I’m going to be there as a presenter)!

IP Indemnity

Intellectual Property Indemnification (aka IP Indemnity) clauses are common in software licenses. The specific language usually plainly states that the software vendor will indemnify, protect and/or defend the buyer from any claim made that the software violates the intellectual property rights of a third party.

Fundamentally, this type of protection makes sense. In first-world countries (and most second-world countries, too), intellectual property rights are pretty clearly delineated and it’s relatively easy to understand the scope of your property compared to that of another. So it’s not a stretch to be able to say that if you know what you own, you can offer assurance to a buyer/licensor that someone else claiming ownership of that property will receive swift action from you rather than the buyer.

Overall, though, it’s economic. If you pay for a software license once, you do not want to have to pay someone else for that same license. You want to know that the person receiving your money is the rightful licensor of the product. Pretty simple.

What makes it complex is that IP rights vary from country to country. So the surety you feel within, say, the United States regarding the ownership of your IP is not carried into some third-world countries (and even a first-world country or two, such as China) where a blind eye is turned towards piracy, copying and stealing. Some of these countries even have laws that protect the thief better than they protect the actual owner, depending upon the situation(s). As a result, IP indemnification is based on WHICH IP laws are being upheld by the parties to a software license.

The net result is that most software licenses, even on a global scale, offer IP indemnity based on one of a few country’s IP laws (the US or UK, primarily) because these two countries not only have established IP laws, but they also have a relatively fair system of legal enforcement of rights.

What you find in some global deals, however, is that the buyer wants IP indemnification under the laws of each country in which a product will be used or reside. This, beyond being potentially impossible to manage, is also fairly unreasonable. The inventor of the product, while desiring to sell as much of that product as possible, has to be able to manage the potential for damage in the event that someone claims IP infringement. By offering IP indemnification under the laws of all countries (and not just those with established IP rights and enforcement abilities), the seller opens themselves to a large amount of risk and, again from an economic perspective, it becomes an untenable deal.

This however, doesn’t mean that the buyer receives no protection in those countries. Rather, they still receive indemnification under claims made under the laws of the country offered in the IP Indemnification section. So, if IP indemnification is offered “for claims made that a product or software violates the copyright, trademark, trade secret or patent laws of the United States”, then even claims for products used in China or Niger are covered … so long as the claim is made that the product violates a US IP law.

The key is to remember that at the end of the day, the deal has to be economically feasible from both sides of the purchasing equation.