In-house counsel are often asked to negotiate technology agreements, such as for software as a service (SaaS) with vendors. Vendors, however, are often only willing to provide a limited warranty with a specific remedy, rather than providing indemnity rights to make the buyer whole. Buyers who have a specific risk in mind should consider articulating that risk and negotiating a corresponding indemnity clause.
Vendors are providing indemnification clauses to protect against intellectual property (IP) infractions — this has become a market expectation.
Buyers who have a specific risk in mind should consider articulating that risk and negotiating a corresponding indemnity clause.
The purpose of indemnity
The Latin root of “indemnity” is indemnis, which means without loss, unhurt, or uninjured. The goal is to make the injured party whole. The indemnifying party is responsible for the loss of the other party (the indemnified party) in circumstances in which it would be unfair for the indemnified party to bear the loss. In this way, an indemnity clause is a risk management tool.
It’s very common for technology vendors to indemnify buyers for third-party claims regarding the intellectual property rights related to the technology. However, vendors resist indemnifying for the buyer’s first-party losses and, instead, often offer limited warranty remedies or service credits to address service issues.
However, if there is a specific area of risk to the buyer that arguably should be a responsibility of the vendor, the risk is an area to pursue for indemnification. For example, another “market” expectation is indemnity for confidentiality or data-related liabilities given the huge increases in hacking and exposure for data related incidents.
Indemnity v. warranty
At its core, indemnification is a promise to reimburse the indemnified party for a loss incurred by that party. A breach of warranty normally does not give a right to terminate the contract (except for persistent issues if the contract provides for a termination right due to ongoing issues of a certain magnitude). A breach of warranty does not trigger indemnity rights.
A warranty is a contractual promise which, if triggered, would entitle the party benefiting from it to bring a claim. Sometimes, for material issues, warranties and indemnities are combined, which increases the risk mitigation provided by the warranty.
What to look for in contract clauses
In-house counsel should pay special attention to these areas of concern when evaluating the interplay between warranty and indemnification clauses.
Risk posed by inconsistency
If an agreement contains a broad indemnity clause requiring indemnification against all losses from specified causes, and also includes a waiver of consequential damage (saying neither party is liable for indirect damages), the agreement presents an inherent inconsistency unless there is an exclusion for indemnification for direct damages specified elsewhere.
If an agreement contains a broad indemnity clause requiring indemnification against all losses from specified causes, and also includes a waiver of consequential damage (saying neither party is liable for indirect damages),
the agreement presents an inherent inconsistency unless there is an exclusion for indemnification for direct damages specified elsewhere.
This is a concern because then neither party can depend on an outcome. The indemnified party does not know if reputational or other consequential damages will be indemnified, for example, and the vendor doesn’t know if its business is responsible for such damages.
Third-party claims are typically considered an indirect damage. Thus, if there is an indemnity obligation for third-party IP claims, as well as a consequential damage disclaimer (without an exclusion for these claims), there is an internal conflict. A judge or jury may have to determine the intent of the parties given the inconsistency.
One solution to this could be to make sure any clause regarding exclusion of consequential damages has a carveout for any direct damages provided for elsewhere in the contract (specifically stating “except as stated elsewhere herein”).
Warranty considerations
Although Article 2 of the Uniform Commercial Code (UCC) generally applies only to the sale of goods, some courts have, in certain circumstances, applied its principles to software and services contracts.
Will the technology be “on premises” or in the “cloud”? For key considerations on negotiating Public Cloud Agreements, read the ACC article, Top Ten: Protecting Your House - Practical Tips for In-house Counsel on Negotiating Public Cloud Agreements, by Elena Antonetti, executive counsel, contracts and technology legal, Travelers.
Does the agreement address that the vendor is providing a valid license to the software or deliverable, and are the support expectations adequately addressed (i.e., how quickly the vendor will respond to and resolve critical issues)?
Warranty period
How long is the warranty period? Ninety days from the effective date seems standard. However, for a SaaS product, there is an argument to be made that the warranty would be ongoing because the product is in the cloud so likely easier to update.
Documentation
The technology must comply with the documentation provided by the vendor at the time the technology was purchased. Be wary of phrases like “published documentation,” because the vendor could change it any time.
Consider referring to specific documents with versions if the vendor and buyer have negotiated a custom solution with non-standard specifications or features. If the document is not long, it may be helpful to include the specifications or feature document as an attachment or exhibit.
Are the specifications for the technology included as an exhibit?
Will the buyer receive any updates, changes, and enhancements (i.e., releases and new versions) to the product?
Sample contract language to address updates and upgrades
Application is a defined term meaning the SaaS product:
- "Update" means and includes the modifications, error corrections, bug fixes, workarounds or revisions made to an Application provided by Supplier to any of its Application licensees: (i) to improve upon or repair existing features and operations within an Application, (ii) to ensure compatibility with new releases of existing systems (including hardware, operating systems and middleware) and external services through standardized interfaces, or (iii) to comply with applicable laws, regulations, industry standards or market practice. An update includes those versions labelled with a revision to the right of the decimal point (for example, 2.1 to 2.2).
- "Upgrades" shall mean a new release or version of the Application containing one or more modification to the Application that alters the functionalities described in the Specifications without materially degrading the functionalities or performance of the Application prescribed by the Specifications. An Upgrade includes those versions labelled with a revision to the left of the decimal point (for example, 2.2 to 3.0).
Downtime considerations
The agreement typically sets out the customer’s remedies if the provider does not resolve service non-conformities within a specified period.
The agreement typically sets out the customer’s remedies if the provider does not resolve service non-conformities within a specified period.
Contract termination
Is there an ability to terminate the contract if there are persistent service or downtime issues? If this is a serious concern, but it is difficult to ascertain what would qualify as a persistent service or uptime issue, consider negotiating a right to terminate for convenience so that proof is not an issue.
If the vendor is resistant to the right to terminate for convenience, consider including a “discontinuance fee” that is roughly addressing lost profit over the number of months remaining in the term. This makes termination more of a business decision rather than potential litigation concern with unknown legal costs. Service availability should be in either full or material conformance with the service specifications.
Availability requirement
What is the uptime guarantee also known as an “availability requirement”? The market expectation seems to be 99.95-99.999 percent. This ensures the services are available and operable for access and use by the customer.
The clause should ensure that “available” has been defined to mean something like: “Customer and authorized users over the internet in conformity with the specifications. The subscription services are not considered available in the event of performance degradation or inoperability of the subscription services, in whole or in part.”
Are planned downtime and maintenance events excluded from the “availability requirement”? If so, does the buyer have the right to approve, or at least receive notice of planned downtime?
What is the period of measurement of uptime? Often the uptime will be measured over the course of each calendar month during the term. The customer generally should require a high level of availability during each one of a series of defined, relatively short (for example, monthly or shorter) periods in which it will use the service.
This way, the provider’s failure to meet uptime requirements during any one of these periods can be a cause for termination, service credits, or other remedies. However, providers often require that availability be measured over a longer period (for example, over an entire year, or over a billing cycle that is longer than a month).
Remedies for service availability failures
Credits
If the actual availability of the services is less than the “availability requirement” during any specified period, the failure should prompt a service credit as set forth in an exhibit or schedule.
Termination
If the actual availability of the services is less than the “availability requirement” in specified periods (market seems to be any two of four months), then the customer should be able to terminate no liability, obligation, or penalty to Customer by reason of such termination.
Indemnification
When should the vendor provide indemnity rights? In-house counsel should carefully evaluate the risks the agreement and services pose to the buyer. Go through some scenarios to anticipate what issues could occur if mission-critical technologies don’t perform as expected.
Go through some scenarios to anticipate what issues could occur if mission-critical technologies don’t perform
as expected.
Market expectations
Customers, per market expectations, generally expect the provider to provide an indemnity for third-party IP infringement claims, the provider’s breach of its confidentiality, or data security obligations, or there is a violation of applicable law.
The customer should seek broad indemnities that require the provider to indemnify it for risks the provider is better able to control.
Consider whether you need to negotiate a larger cap for certain material issues. Vendors often seek a cap on indemnity obligations so that they can seek insurance to cover those exposures and to enable some certainty on potential losses. However, if there is an issue that is most sensitive to the buyer, counsel should be willing to discuss it and seek a higher cap for that issue. For example, there is often a larger “super cap” for privacy or confidentiality breaches (like a data breach scenario). Under debate is whether there should be any cap on IP indemnity.
Under debate is whether there should be
any cap on IP indemnity.
The customer also should consider including a specific indemnity for bodily injury, death, or personal property damages caused by the personnel of the provider or its subcontractor, particularly if the vendor may perform any part of the services on the customer’s premises.
