Category Archives: Negotiation

Tips, tricks and thoughts on legal negotiations

Aggregate Data Clauses – Accept or Push Back?

Posted on by
Reply

Before reflexively rejecting a vendor/provider’s aggregate data clause, determine whether pushing back is really necessary.

More than ever before, data is the driver of business. Companies are inundated with new data on a daily basis, which creates a number of business challenges. One of the more prominent challenges of late has been how best to protect data within a company’s infrastructure from inadvertent and improper access and disclosure. Another important challenge is how best to “mine” data sets through data analytics, the quantitative and qualitative techniques businesses use to analyze data in order to develop business insights, conclusions, strategies, and market trend data in order to provide guidance on operational and strategic business decisions. “Aggregate data” is key to data analytics; companies take existing data, anonymize it by removing any personal or other information that can be used to identify the source of the data, and aggregate it with other anonymized data to create a new set of data on which data analytics can be performed.

The strength of the conclusions and insights learned through data analytics is directly proportional to the amount of source data used. Aggregate data comes from two primary sources: (1) internal data sets within the company’s possession or control, such as transactional data, customer data, server data, etc.; and (2) external data sets such as free online databases of government data (e.g., US Census data) and data available from data brokers who have compiled aggregate data sets for purchase and use by businesses.

To ensure businesses have the right to use customer data in their possession for data analytics purposes, SaaS, cloud, software, and other technology agreements often contain an aggregate data clause. This clause gives a vendor/provider the right to compile, collect, and use aggregate data from customer information for the vendor/provider’s own business purposes. Many vendors/providers work hard to craft an aggregate data clause that fairly and adequately protects their data sources. Before reflexively rejecting a vendor/provider’s aggregate data clause, consider the analysis and questions in this article to determine whether pushing back is really necessary to protect your company’s interests.

The vendor/provider’s perspective

Customers often push back on aggregate data clauses for a variety of reasons, such as “it’s our policy not to give this right,” “why should you benefit from our data?” and “how can you guarantee someone won’t be able to figure out it’s us?” On the other side, a vendor or provider may argue that the aggregate data clause is a “table stakes” provision in their agreement. Under this argument, analytical data is used to generate macro-level insights which benefit both the vendor/provider and its customers, and as long as it is used in a way that does not identify a specific customer or client there is no potential harm to the customer in allowing its use for data analytics. Additionally, many vendors argue that the systems used to anonymize and aggregate data do not allow for exceptions on a per-customer basis. Additionally, vendors/providers often share insights and other conclusions drawn from data analytics with their customers and clients, e.g., through client alerts, newsletters, conferences, etc., and therefore clients benefit from allowing their data to be used in the vendor/provider’s data analytics efforts. Data analytics are often a critical part of a vendor/provider’s business plans and operations, and access to client data for analytics purposes is baked into the cost of using the service.

Is the aggregate data clause well-drafted and balanced?

Many vendors/providers take the time to craft an aggregate data clause that is fair and does not overreach. As long as the vendor/provider has protected the customer’s rights and interests in the underlying customer data, the use of a customer’s data for analytics purposes may be perfectly acceptable as a part of the overall contractual bargain between the parties. A well-drafted clause usually contains the following core provisions:

  • Grant of rights – A right for the vendor/provider to compile, collect, copy, modify, publish and use anonymous and aggregate data generated from or based on customer’s data and/or customer’s use of its services, for analytical and other business purposes. This is the heart of the clause. This clause gives the vendor/provider the right to combine aggregate data from multiple internal and external data sources (other customers, public data, etc.).
  • Protection of source data – A commitment that the customer will not be identified as the source of the aggregate data. While this is really restating that the data will be “anonymous,” some customers may want a more express commitment that the aggregate data can’t be traced back to them. I’ll talk more about this later in this article.
  • Scope of usage right – Language making clear either that the vendor/provider will own the aggregate data it generates (giving it the right to use it beyond the end of the customer agreement), or that its aggregate data rights take precedence over obligations with respect to the return or destruction of customer data. The common vendor/provider reason for this is that aggregate data, which cannot be used to identify the customer, is separate and distinct from customer data which remains the property (and usually the Confidential Information) of the customer under the customer agreement. Additionally, the vendor/provider often has no way to later identify and remove the aggregate data given that it has been anonymized.

Things to watch for

When reviewing an aggregate data clause, keep the following in mind:

Protection of the company’s identity. While language ensuring that a customer is not identified as the source of aggregate data works for many customers, it may not be sufficient for all. Saying a customer is not identified as the source of aggregate data (i.e., the vendor/provider will not disclose its data sources) is not the same as saying that the customer is not identifiable as the source. Consider a customer with significant market share in a given industry, or which is one of the largest customers of a vendor/provider. While the vendor/provider may not disclose its data sources (so the customer is not identified), third parties may still be able to deduce the source of the data if one company’s data forms the majority of the data set. Customers that are significant market players, or which are/may be one of a vendor’s larger clients, may want to ensure the aggregate data clause ensures the customer is not identified or identifiable as the source of the data, which puts the onus on the vendor/provider to ensure the customer’s identity is neither disclosed nor able to be deduced.

Ownership of aggregate data vs. underlying data. As long as the customer is comfortable that aggregate data generated from customer data or system usage cannot be used to identify or re-identify the customer, a customer may not have an issue with a vendor/provider treating aggregate data as separate and distinct from the customer’s data. Vendors/providers view their aggregate data set as their proprietary information and key to their data analytics efforts. However, a well-drafted aggregate data clause should not give the vendor/provider any rights to the underlying data other than to use it to generate aggregate data and data analytics.

Scope of aggregate data usage rights. There are two ways customer data can be used for analytics purposes – (1) to generate anonymized, aggregate data which is then used for data analytics purposes; or (2) to run data analytics on customer data, aggregate the results with analytics on other customer data, and ensure the resulting insights and conclusions are anonymized. Customers may be more comfortable with (1) than (2), but as long as the vendor/provider is complying with its confidentiality and security obligations under the vendor/provider agreement both data analytics approaches may be acceptable. With respect to (2), customers may want to ask whether the vendor/provider uses a third party for data analytics purposes, and if so determine whether they want to ensure the third-party provider is contractually obligated to maintain the confidentiality and security of customer data and if the vendor/provider will accept responsibility for any failure by the third party to maintain such confidentiality and security.

Use of Aggregate Data. Some customers may be uncomfortable with the idea that their data may be used indirectly through data analytics to provide a benefit to their competitors. It’s important to remember that data analytics is at a base level a community-based approach – if the whole community (e.g., all customers) allows its data be used for analytics, the insights and conclusions drawn will benefit the entire community. If this is a concern, talk to your vendor/provider about it to see how they plan to use information learned through analytics on aggregate data.

Duration of aggregate data clause usage rights. Almost every vendor/provider agreement requires that the rights to use and process customer data ends when the agreement terminates or expires. However, vendors/providers want their rights to use aggregate data to survive the termination or expiration of the agreement. A customer’s instinct may be to push back on the duration of aggregate data usage rights, arguing that the right to use aggregate data generated from the customer data should be coterminous with the customer agreement. However, if the data has truly been anonymized and aggregated, there is likely no way for a vendor/provider to reverse engineer which aggregate data came from which customer’s data. This is why many vendors/providers cannot agree to language requiring them to cease using aggregate data generated from a customer’s source data at the end of the customer relationship. One approach customers can consider is to ask vendors/providers when they consider aggregate data to be “stale” and at what point they cease using aged aggregate data, and whether they can agree to state that contractually.

Positioning an objection to the aggregate data clause. As noted earlier, the right to use data for analytics purposes is considered to be a cost of using a vendor/provider’s software or service and a “table stakes” provision for the vendor/provider, and the ability to use data for analytics purposes is already baked into the cost of the software or service. Some customers may feel this is not sufficient consideration for the right to use their data for analytics purposes. If that is the case, customers may want to consider whether to leverage an objection to the aggregate data clause as a “red herring” to obtain other concessions in the agreement (e.g., a price discount, a “give” on another contract term, or an additional service or add-on provided at no additional charge).

The GDPR view on use of aggregate data

The European Union’s new General Data Protection Regulation (GDPR), which becomes effective on May 25, 2018, makes a significant change to the ability to use personal data of EU data subjects for analytics purposes. Under the GDPR, a blanket consent for data processing purposes is no longer permitted – consent to use data must be specific and unambiguous. Unfortunately, this directly conflicts with data analytics, as the ways a data set will be analyzed may not be fully known at the time consent is obtained, and there is no right to “grandfather in” existing aggregate data sets. Simply saying the data will be used for analytics purposes is not specific enough.

Fortunately, the GDPR provides a mechanism for the continued use of aggregate data for analytics purposes without the need to obtain prior data subject consent – Pseudonymization and Data Protection by Default. Pseudonymization and data protection principles should be applied at the earliest possible point following acquisition of the data, and vendors/providers must affirmatively take data protection steps to make use of personal data

  • Pseudonymization – Pseudonymization is a method to separate data from the ability to link that data to an individual. This is a step beyond standard tokenization using static, or persistent, identifiers which can be used to re-link the data with the data source.
  • Data Protection by Default – This is a very stringent implementation of the “privacy by design” concept. Data protection should be enabled by default (e.g., an option in an app to share data with a third party should default to off).

 

Data analytics is an important part of every company’s “big data” strategy.  Well-crafted aggregate data clauses give vendors and providers the ability to leverage as much data as possible for analytics purposes while protecting their customers.  While there are reasons to push back on aggregate data clauses, they should not result in a negotiation impasse. Work with your vendors and providers to come up with language that works for both parties.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He is a corporate generalist who specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The What, Why and How of SLAs, aka Service Level Agreements (part 2)

Posted on by
Reply

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

In Part 1 of this post, I walked through uptime and issue resolution SLAs.  In this second part, I cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Other Types of Commitments in SLAs

Other common types of SLAs in technology agreements include latency SLAs and customer service SLAs.

Latency SLAs. “Latency” is the time it takes for a server to receive a server request, process it, and send a response. For example, when you load a webpage, a server request is sent to a web server to deliver the webpage, the server processes the request, and sends a response with the code to render the page in the user’s web browser. Latency can be affected by a number of factors, including the geographic location of servers, network/Internet capacity, and server optimization. For companies using a vendor to provide services as part of its client-facing systems (e.g., an address verification service), minimizing latency to ensure a high level of performance is critical. A latency SLA is a commitment to a maximum roundtrip response time for a vendor server request. Latency SLAs typically exclude the time it takes to get from the customer’s server to the boundary of the vendor’s network, and vice versa (as this is outside of the vendor’s control).

Customer Service SLAs. In some vendor relationships, ensuring the prompt provision of customer support is a critical component of the relationship. For example, if a vendor is providing support to a customer’s clients or employees, or is providing level 2 escalation support, customer support SLA commitments may be important to the customer to ensure a high level of service.  Customer support commitments often include commitments on time to first response (the time from the submission of a request to the time an agent opens the support ticket to begin working on it); time to resolution (total time needed to resolve the issue); average speed to answer (the percent of calls answered within a maximum time, e.g., 85% of calls within 30 minutes, or percent of emails answered within a maximum time, e.g., 90% of emails within 4 business hours); and/or abandonment rate (the maximum number of calls being abandoned in queue before a support agent picks up the call).

SLA Remedies

In order to ensure the service level commitments made by a vendor have teeth, the SLA should have remedies available to the customer in the event of a failure to meet one or more SLA commitments. The remedies are often the most heavily negotiated section of the SLA. There are a variety of remedies that can be applied in the event of a SLA failure.

Service Credits. One of the more common forms of remedy is a service credit, often a percentage of fees paid by the customer for the period in which the SLA failure occurred.  For example, if a vendor fails to meet a 99.9% monthly SLA, a service credit equal to a percentage of the monthly fees paid by the customer would be applied to the next monthly invoice.  A credit is often provided on a tiered basis, up to 100% of the fees for the relevant period based on the size of the SLA miss. Vendors may want to include language ensuring that if multiple credits are available for the same reporting period (e.g., a credit for failure to meet the uptime SLA as well as the issue resolution SLA), only the greater credit will apply.  The credit is usually applied to the next invoice, or if there will be no additional invoice, paid directly to the customer.  For a service credit related to an uptime SLA commitment, instead of a percentage of fees some vendors will offer a credit equal to the fees earned by the vendor during the period of time during which the Service was unavailable during the previous measurement period (or an average of the amount during previous measurement periods), under the theory that the credit is an accurate reflection of the actual fees that would have been earned by the vendor had the service been available in compliance with the SLA.  Customers should carefully consider what fees are used to calculate the credit – customers will want this to be as inclusive as possible.

Termination. In the event of a SLA failure, another remedy commonly offered by vendors is a right to terminate. Vendors typically put restrictions around the exercise of this right, e.g., termination is the sole and exclusive remedy available; termination is limited to the service subject to the SLA failure, not the entire service agreement; it is offered on a “use it or lose it” right which can only be exercised for a period of time following the measurement period in which the SLA failure giving rise to the termination right arose; or the right to terminate is only triggered by multiple failures, such as failure to meet its SLA commitments in three (3) consecutive months or any two (2) out of three (3) consecutive calendar quarters. Customers should carefully consider whether the limits on these rights are appropriate (e.g., ensure that “sole and exclusive remedy” applies only to a SLA failure, and would not preclude the customer enforcing its rights and remedies for any other breaches of the vendor agreement; ensure a right to terminate extends to the entire service agreement if the affected service component is a significant portion of the value of the relationship to the customer; etc.)

Other creative remedies. Vendors and customers should consider whether other creative remedies for a breach of the SLA, such as waiver of fee minimums, waiver or imposition of other contractual obligations, or provision of additional services (e.g., a certain number of free hours of professional services), may be an appropriate remedy for the customer and an appropriate motivator for the vendor to meet its SLA commitments.

Closing Thoughts – Things to Watch For

  • Remember that most vendors are trying to provide as close to 100% uptime as possible, and the best possible service they can to their clients. A SLA is intended to be a floor on performance, not a ceiling.
  • Some vendors do not include a SLA in their standard service agreement, instead letting customers ask for one. In my experience, less customers will ask for a SLA than you’d think.  It’s always a good idea to ask a vendor to ensure they include their SLA with the service agreement at the outset of the contract negotiation process.
  • If the vendor will not agree to include a SLA, ask them why.
    • In some cases, vendors will not provide a SLA with credits to all but their largest clients, relying on the fact that as a multi-tenant platform all clients receive the benefit of the SLAs provided to their largest clients. In this event, customers should consider whether to fight for a direct SLA or rely on their commitments to larger clients (which commitments may change over time).
    • If you can’t get a SLA from a vendor, customers should consider whether to push for a termination for convenience right (and refund of prepaid but unaccrued fees) in the event they are dissatisfied with the service levels they are receiving from the vendor.
    • Customers should also ask whether the service is truly a mission-critical service. If not, it may be worth considering how hard to fight for the SLA, or if the customer can offer to concede the SLA to win on another open negotiation point of greater importance.
  • Customers should watch for language in the vendor agreement that gives the vendor the right to unilaterally change terms of the agreement, instead of having changes mutually agreed upon. This unilateral right is often broad enough to allow a vendor to change the terms of the SLA as well. If so, customers may seek to limit the scope to exclude the SLA, or ensure that the agreement includes a termination right as described above.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

The What, Why and How of SLAs, aka Service Level Agreements (part 1)

Posted on by
Reply

Every company uses technology vendors, such as Software-as-a-Service providers, to provide critical components of their business operations. One pervasive issue in technology vendor agreements is the vendor’s commitment to the levels of service the customer will receive.  A representation to use commercially reasonable efforts to correct product defects or nonconformity with product documentation may not be sufficient for a customer relying on a technology vendor’s service for a mission-critical portion of its business. In this situation, the vendor may offer (and/or a customer may require) a contractual commitment as to the vendor’s levels of service and performance, typically called a “Service Level Agreement” or “SLA.” Service Level Agreements (SLAs) ensure there is a meeting of the minds between a vendor and its customer on the minimum service levels to be provided by that vendor.

At a high level, a SLA does three things:

  1. Describes the types of minimum commitments the vendor will make with respect to levels of service provided by the vendor;
  2. Describes the metrics by which the service level commitments will be measured; and
  3. Describes the rights and remedies available to the customer if the vendor fails to meet their commitments.

In many cases, a SLA is presented as an exhibit or appendix to the vendor agreement (and not a separate agreement). In others, a SLA may be presented as a separate document available on a vendor’s website.  Think of the former as a customer-level SLA which is stated directly in (and quite often negotiated on a customer-by-customer basis as part of) the service agreement with that customer, and the latter as a service-level SLA which the vendor wants to apply equally to every user of its service.

In this two-part post, I’ll explain the contents of, reasons for, and important tips and tricks around technology SLAs.  Part 1 will cover uptime and issue resolution SLAs.  Part 2 will cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Common types of commitments in SLAs

The most common types of commitments found in technology SLAs are the uptime commitment and the issue resolution commitment.

Uptime SLA Commitment

An uptime commitment is generally provided in connection with online services, databases, and other systems or platforms (a “Service”). A technology vendor will commit to a minimum percentage of Service availability during specified measurement periods.  This percentage is typically made up of nines – e.g., 99% (“two nines”), 99.9% (“three nines”), 99.99% (“four nines”), 99.999% (“five nines”), etc.  Some SLAs will use “.5” instead of “.9”, for example, 99.5% or 99.95%”.   Uptime is typically calculated as follows:

(total minutes in the measurement period - minutes of Downtime in that period) / Total minutes in the measurement period

Definitions are key. The right definitions can make all the difference in the effectiveness of an uptime SLA commitment. Vendors may gravitate towards a narrower definition of “Downtime” (also called “Unavailability” in some SLAs) to ensure they are able to meet their uptime commitment, e.g., by excluding a slowdown that makes the Service hard (but not impossible) to use. Customers should look carefully at this definition to ensure it covers any situation in which they cannot receive substantially all of the value of the Service. For example, consider the difference between Unavailability/Downtime as a period of time during which the Service fails to respond or resolve, versus a period of time during which a material (or non-material) function of the service is unavailable. The SLA should define when the period of Unavailability/Downtime starts and ends, e.g., starting when the vendor first learns of the issue, and ending when the Service is substantially restored or a workaround is in place; customers should look at this carefully to ensure it can be objectively measured.

Mind the measurement period. Some vendors prefer a longer (e.g., quarterly) measurement period, as a longer measurement period reduces the chance a downtime event will cause a vendor to miss its uptime commitment. Customers generally want the period to be shorter, e.g., monthly.

Consider whether the uptime percentage makes sense in real numbers. Take the time to actually calculate how much downtime is allowed under the SLA – you may be surprised. For a month with 30 days:

  • 99% uptime = 432 minutes (7 hours, 12 minutes) of downtime that month
  • 99.5% uptime = 216 minutes (3 hours, 36 minutes) of downtime that month
  • 99.9% uptime = 43.2 minutes of downtime that month
  • 99.99% uptime = 4.32 minutes of downtime that month

One critical question customers should ask is whether a Service is mission-critical to its business.  If it’s not, a lower minimum uptime percentage may be acceptable for that service.

Some vendors may offer a lower uptime commitment outside of business hours, e.g., 99.9% from 6am to 10pm weekdays, and 99% all other times. Again, as long as this works for a customer’s business (e.g., the customer is not as concerned with downtime off-hours), this may be fine, but it can make it harder to calculate.

Ensure the Unavailability/Downtime exclusions are appropriate. Uptime SLAs generally exclude certain events from downtime even though the Service may not be available as a result of those events. These typically include unavailability due to a force majeure event or an event beyond the vendor’s reasonable control; unavailability due to the equipment, software, network or infrastructure of the customer or their end users; and scheduled maintenance.  Vendors will often seek to exclude a de minimis period of Unavailability/Downtime (e.g., less than 5/10/15 minutes), which is often tied to the internal monitoring tool used by the vendor to watch for Service unavailability/downtime. If a vendor wouldn’t know if a 4-minute outage between service pings even occurred, it would argue that the outage should not count towards the uptime commitment.

Customers should make sure there are appropriate limits to these exclusions (e.g., force majeure events are excluded provided the vendor has taken commercially reasonable steps to mitigate the effects of such events consistent with industry best practices; scheduled maintenance is excluded provided a reasonable amount of advance written notice is provided.  Customers should watch out for overbroad SLAs that try to exclude maintenance generally (including emergency maintenance).  Customers may also want to ensure uptime SLAs include a commitment to take reasonable industry-standard precautions to minimize the risk of downtime (e.g., use of no less than industry standard anti-virus and anti-malware software, firewalls, and backup power generation facilities; use of redundant infrastructure providers; etc.)

Don’t overlook SLA achievement reporting. One important thing customers should look for in a SLA is how the vendor reports on SLA achievement metrics, which can be critical to know when a remedy for a SLA failure may be available. Vendors may place the burden on the customer to provide notice of a suspected uptime SLA failure within a specified amount of time following the end of the measurement period, in which case the vendor will review uptime for that period and verify whether the failure occurred. However, without proactive metrics reporting, a customer may only have a suspicion of a SLA failure, not actual facts. Customers using a mission-critical system may want to consider asking for proactive reporting of SLA achievement within a certain amount of time following each calendar month.

Issue Resolution SLA Commitment

Of equal importance to an uptime commitment is ensuring that a Service issue (downtime or otherwise) will be resolved as quickly as possible.  Many technology SLAs include a service level commitment for resolution of Service issues, including the levels/classifications of issues that may occur, a commitment on acknowledging the issue, and a commitment on resolving the issue.  The intent of both parties should be to agree on a commitment gives customers assurances that the vendor is exerting reasonable and appropriate efforts to resolve Service issues.

Severity Levels. Issue resolution SLAs typically include from 3-5 “severity levels” of issues.  Consider the following issues:

Impact Example Classification
Critical The Service is Unavailable
High An issue causing one or more critical functions to be Unavailable or disrupting the Service, or an issue which is materially impacting performance or availability
Medium An issue causing some impact to the Service, but not materially impacting performance or availability
Low An issue causing minimal impact to the Service
Enhancement The Service is not designed to perform a desired function

Issue resolution SLAs typically use some combination of these to group issues into “severity levels.”  Some group critical and high impact issues into Severity Level 1; some do not include a severity level for enhancements, instead allowing them to be covered by a separate change order procedure (including it in the SLA may be the vendor’s way of referencing a change order procedure for enhancements). Vendors may include language giving them the right to reclassify an issue into a lower severity level with less stringent timeframes. Customers should consider ensuring whether they should have the ability to object to (and block) a reclassification if they disagree that the issue should be reclassified.

Acknowledgment Commitment. Issue resolution SLAs typically include a commitment to acknowledge the issue. As with the uptime SLA, the definition of the acknowledgment timeframe is important (when it starts and when it ends). A vendor will typically define this as the period from the time it is first notified of or becomes aware of the issue to the time the initial communication acknowledging the issue is provided to the customer.  Customers should look at the method of communication (e.g., a post to the vendor’s support page, tweet through their support Twitter account, an email, a phone call from the customer’s account representative required, etc.) and determine if a mass communication method versus a personal communication method is important.

For critical and high impact issues, vendors (especially those operating multi-tenant environments) will often not offer a specific acknowledgment commitment, instead offering something like “as soon as possible depending on the circumstances.”  The argument for this is that for a critical or high impact issue, a vendor wants all available internal resources triaging and working the problem, not reaching out to customers to tell them there is a problem. In many cases, this may be sufficient for a customer provided there is some general acknowledgment provided to a support page, support Twitter account, etc. to alert customers that there is an issue. In others, a customer may want to push for their account representative, or a vendor representative not involved in triaging the problem such as an account executive, to acknowledge the issue within a fixed amount of time, putting the burden on the vendor to ensure it has appropriate internal communication processes in place.

Resolution Commitment. Issue resolution SLAs also typically include a time commitment to resolve the issue. One important thing to focus on here is what “resolve” means.  Vendors may define it as the implementation of a permanent fix or a workaround that temporarily resolves the problem pending the permanent fix; in some cases, vendors may also define it as the commencement of a project to implement a fix.  Customers should ensure that a vendor promptly implement a permanent fix if a workaround is put in place, and that failure to do so is a failure under the SLA. Many vendors are reluctant to provide a firm issue resolution timeframe, as the time required to resolve or implement a workaround is dependent on the issue itself, and are often unwilling to negotiate the resolution commitment or commit to a fixed timeframe for resolution.  Customers should ensure the resolution commitment is reasonable and that the vendor is doing everything it can to correct issues.  For example, for critical and high impact issues, consider an issue resolution commitment of “as soon as possible using continuous diligent efforts” – as long as the vendor is working diligently and continuously to fix the issue, they’re in compliance with the SLA. For lower impact issues, consider a commitment to implement a fix or workaround in the ordinary course of business.

In part 2, I’ll cover other types of technology SLA commitments, SLA remedies, and other things to watch for.

Eric Lambert has spent most of his legal career working in-house as a proactive problem-solver and business partner. He specializes in transactional agreements, technology/software/e-commerce, privacy, marketing and practical risk management. Any opinions in this post are his own. This post does not constitute, nor should it be construed as, legal advice. He is a technophile and Internet evangelist/enthusiast. In his spare time Eric dabbles in voice-over work and implementing and integrating connected home technologies.

10 Common Negotiation Positions and How To Work Through Them

Posted on by
Reply

One of the more frustrating things to run into during a contract negotiation is the “stock position.”  These are negotiation positions often used as tactics to shut down discussion on a point, or to push back on an otherwise reasonable request  Part of every attorney’s job is to find and leverage ways to make the negotiation cycle more efficient.  Being prepared for these 10 common negotiation positions, and knowing ways to work through them, can help you avoid a stumble on your way to the negotiation finish line.

10. It’s Locked Down (“We only send our agreement as a [PDF/locked Word document].”)
Why you hear this: Some companies try to limit redlines to their agreements by only distributing agreements as a PDF or a Word document locked against editing, making it very burdensome if you want to propose changes.
How to respond:  Propose capturing any changes in an amendment or rider to keep the agreement itself as-is, but ask for a Word version so you can show the changes you’d propose be captured in the amendment or rider.  If they won’t budge, consider creating your own Word version to redline (modern versions of Adobe Acrobat Pro have built-in OCR that lets you save a PDF in Word format, or you can print and then use Optical Character Recognition (OCR) to convert the PDF to an editable version). You can also create an unlocked version of a Word document for editing purposes fairly easily – see my earlier article on this topic.  If you create an editable version yourself, be sure to state in your cover note when sending the agreement back that you have created a Word version solely to facilitate your and their negotiation of the agreement, and reiterate that you would be happy to capture the agreed-upon changes in an amendment or rider to the agreement.

9. Can’t Help You There (“I don’t have the authority to negotiate that.”)
Why you hear this: The person you are negotiating with either doesn’t have the authority to approve changes to this provision, or wants you to think that he/she can’t make changes to it.
How to respond: If the change is important to your company, let them know why, and ask them if they can break out to seek approval from a person with authority (you’ll hold if on a call). Alternatively, ask if the person with authority can join the conference call or meeting so you can explain the importance of the change or provision directly.  If they balk, ask them to set up a follow-up call or meeting with the person with authority.  If they’re bluffing, asking them to bring in someone with authority may result in a change in position.

8. We’re The Best Around (“Do you know who we are? We’re the number one [vendor/supplier/provider/client] [of/to] [thing] in the [geographic area].”)
Why you hear this:  This response is the equivalent of “we’re the big fish in this pond – be lucky you’re working with us.”  They’re trying to use their market position to get you to back off your position or request.
How to respond: This is one of the reasons it’s important to have a credible backup partner/supplier/vendor waiting in the wings, or at least know who the other party’s major competitors are.  If your position or request is reasonable, you’ll need to stand your ground.  Let them know that while you are aware they are a major player, your request is important to your company, and that you hope they can negotiate on this point.  If you hold fast, you may have to drop the names of their competitors (if you know the name of a sales rep in your area, drop that) and let them know, expressly or by implication, that their willingness to work with you on this point is more important than your desire to work with the top player in the market.

7. Don’t Stop Us Now (“Why are you asking about that? You’re slowing the deal down/this [will/may] cause us to miss our [contract execution date/launch date/etc.].”)
Why you hear this: All too often, parties enter negotiation where one or both are already committed or invested in the relationship — implementation has already started, financial forecasting has already assumed the agreement is completed by a certain date, commitments regarding the agreement have been made to senior management, etc. The other side may be trying to leverage a “need for speed” on your company’s part to avoid discussion of potentially contentious or unfavorable points.
How to respond: It depends on what is more important to your company — getting the deal done quickly, or taking the time to negotiate your point.  If it’s a “nice to have” point, discuss the pros and cons internally of giving on the position in the interests of time.  If it’s a “must have,” call the other side’s bluff and let them know that while you understand that digging into this point may impact the negotiation or launch schedule, resolving this point must take precedence. If you do that, be aware that the other side may try to “forum shop” and reach out to one of the negotiating parties, or a superior, who they think is feeling pressure to close the deal and can exert leverage to get past this point. Propose alternative or compromise positions, and offer to work on a compromise in real-time on a call or via a WebEx or GoToMeeting session to keep the ball rolling.

6. Take Our Word For It (“I know the contract doesn’t say that, but it’s our practice.”)
Why you hear this: The contract template you are working from may be old and no longer tracks to the operational realities of the parties’ obligations and duties.  It’s also used where the other side is unwilling to commit contractually to a negotiating or marketing statement or position.
How to respond: Stress that the contract needs to accurately reflect the business and operational reality of the relationship.  If it’s their practice, they should be willing to give you a contractual commitment on it. If they refuse, let them know that if they can’t back up their statement with a corresponding obligation in the contract, that’s a red flag and you’ll need to discuss their position with your business team (in other words, give them a Don’t Stop Now). Consider ending the call/meeting early to huddle with your business team on this point – it can send a message to the other side that you are serious about this issue.

5. We Can’t Afford That (“That will affect our revenue recognition.”)
Why you hear this: The requested change could require them to spread the revenue across a longer period of time, or shift it from one fiscal month/quarter/year to the next. If the sales rep has already committed a contract close to the business, or is planning on it to meet quota or get bonus, this can be a major stumbling block for them. For example, a termination for convenience clause can often affect revenue recognition.
How to respond: This can be a legitimate argument.  However, there is often a creative way to structure terms that meets their revenue recognition requirements yet gives your company the flexibility it needs.  Put on the creativity hat and work with your business/legal counterpart, and your finance team, to try to find an alternative that will work.  If not, you’ll need to stand firm and see whether they want the business even with altered revenue recognition terms.

4. You Don’t Need To See That Now (“We don’t give our [customers/partners] our [documentation/policies] before they sign the agreement.”)
Why you hear this: If an agreement has policies that apply to your company and are referenced or incorporated by reference in the agreement (e.g., Terms of Use, Terms of Service, Vendor Code of Conduct, Conflict of Interest Policy, Trademark Guidelines, etc.), taking the time to review these policies can extend the negotiation cycle.  They agreement may also contain a warranty that the product or service conforms to the documentation, which you’ll need to review to understand how strong of a warranty you’re getting. If there’s anything in there that your company can’t abide by, you could be setting your company up for a problem out of the gate.
How to respond: Explain that your company can’t fully commit to an agreement until it has reviewed and signed off on all terms and policies related to the agreement. If they’re balking at providing documentation relating to a warranty section, let them know you need to see the documentation first.  See if there’s a group within your company that can play “bad cop” here, e.g., “Internal Audit needs to see it before we can sign.” Consider adding a 30-day right to rescind to the agreement in your client’s favor, which lets you sign first, but lets you back out if you don’t like the terms of their policies. Search online — many times you can find a policy on the other side’s own website.

3. I Can’t Believe You Said That (“We take offense to your position that we might [lose your data/breach the warranties, etc.]”)
Why you hear this: The “rightful indignation” argument is common when the other party wants to avoid a discussion on a topic, or truly doesn’t understand why you would be asking about that.  They may be confusing your risk management with an insinuation that you don’t trust they can live up to their obligations.
How to respond: Explain why the issue is important to your company.  If your company has been burned by the issue in the past, or your General Counsel/management team is focused on this issue, let them know — almost every company has some hot-button issue that can impact its contract negotiations.  You can also let them know you’ve seen recent articles about this issue and it’s top of mind.  Be sure to stress that you’re not playing Devil’s advocate and looking at the worst-case scenario, but you’re rather be prepared for the worst and have some extra words in the contract than be caught unprepared when the unthinkable happens.

2. That Comes Later (“We will [address/schedule] [your implementation/that topic] in a [SOW/Addendum] after we sign.”) 
Why you hear this: Punting on a contentious or time-consuming issue, such as ownership of deliverables, can help move the agreement to completion.  Once the contract is signed, however, you may lose your leverage to negotiate that provision.  Alternatively, the other party may attempt to include a provision in the SOW/Addendum that will take precedence over a corresponding provision in the base agreement, essentially renegotiating it.
How to respond: If a provision is material or critical to the agreement or to your company, insist that it’s negotiated as part of, or at the same time as, the agreement. Ensure you have a strong order of precedence clause so your negotiated wins in the agreement aren’t undone in a later document.

1. That One’s New (“No one has ever asked us for that before/we’ve never given that to anyone before.”)
Why you hear this: Unless a company is very new, it’s very uncommon that no one has ever asked for a particular request before.  It’s more likely that the person you are negotiating with has never heard anyone ask for that before.
How to respond: Ask them to confirm they are saying that no contract the company has ever signed has had that provision.  If they hold firm, use it as an opportunity to push for a contractual representation to that effect (putting their money where there mouth is), and/or push for a “most favored nations” (MFN) clause on that term so that if they do offer that term to anyone in the future it will be automatically incorporated into your agreement. These approaches often lead to a change of tune. They may try to limit a rep or MFN clause to similarly situated clients/partners – consider whether this makes sense.

Six Tips for Working Efficiently and Effectively With Your Attorney in Contract Negotiations

Posted on by
Reply

Some people dread having to go to their legal counsel with a contract for review and negotiation.  “It’s the department of business prevention”; “we’ll never get it done”; “my attorney doesn’t understand what the business needs.”  Quite the contrary. In-house counsel want to partner with you to facilitate the company’s business objectives and help the company succeed, while at the same time managing risk to our client – the company. Ensuring you and your attorney work together as effectively and efficiently as possible is key to this process.  Here are 6 tips to keep in mind when working with your attorney in contract negotiations.

  1. Contract negotiation is a partnership, not a handoff. Contracts contain both legal and business terms. We will largely defer to you on the business terms (unless it’s something we’ve seen before that we know is a problem), and will focus on ensuring the legal terms are in order. You need to be a part of the negotiation process to provide guidance and approvals on business terms as they are negotiated.  If you submit a contract for review and then just wait for an email saying it’s done and signed, it will slow down the process as we’ll have to reach out to you, or worse, make assumptions about what your business needs are or what you are OK agreeing to in the contract.
  1. Negotiations can take time – don’t wait until the last minute to engage Legal. Negotiations can take time, but attorneys don’t want to drag them out – we have a lot of work on our plate, and we want to enable you to start working with the company or vendor so you can meet our corporate objectives. However, part of our job is also to negotiate terms that protect the company, and to help you navigate around the pitfalls and mountains.  If you come to us at the last minute and there are major issues (e.g., risks we can’t accept without high level approval), it’s a no-win situation – we feel you’re not giving us time to do our job as attorneys, you’re unhappy because the agreement can’t get done by your desired completion date, your boss is unhappy because you missed your deadline, others whose work depends on the negotiated partnership or vendor relationship are negatively affected, etc.

Build time for the legal review process into your project timeline, and if you’re unsure ask your attorney how much time they think it will take before you even get to the contract phase.   Engage Legal with questions on business terms or legal terms early in the process if it will help streamline the negotiation later on — we can help you structure business terms up front while they are being negotiated, to make the negotiation process go more smoothly.

  1. Provide complete business terms when you submit your contract request. Unless you are requesting a standard form agreement on your company’s paper, we need to know as much detail on the business terms as you can provide when you submit a contract request to Legal. Otherwise, we may have to make assumptions about what you’re looking for, and if we’re wrong it will mean redrafting work which will slow down the process. If you have a term sheet, attach it. If not, summarize the business terms in the request with as much detail as you can provide.  Include the full legal name of the other party, and their street address.  We’ll call you to flesh out any terms on which we have questions or need more information or detail.  Also, read the draft carefully before you forward it to the other side.  If the contract doesn’t match the business terms that were discussed, we’ll stumble right out of the gate on the contract negotiation.
  1. When you get a draft or get back redlines, add your comments on the business terms before submitting it to Legal.  If you send a draft on the other side’s paper or you receive redlines from the other side, go through it before you send it to Legal and mark it up with your comments and edits to any business terms.  If you need to reach out to internal business owners for their input or approval (e.g., Finance on payment terms, IT on SLAs, etc.), either do it before sending the draft to Legal, or indicate in the draft that you’re following up on an open business point before you send it to Legal.  Otherwise, the internal discussion draft you get from Legal will just include notes on where you need to provide input on business terms, slowing down the process.
  1. Listen to your lawyer’s suggestions – we’ve done this before. We have been in many contract negotiations, and have seen most contract provisions before.  We often know what provisions work with the company’s internal processes and requirements, and how third parties are likely to negotiate and come out on a given provision. If you come in with a business term or a position on an open point that we think may be a tough sell to the other party or is “out of the box” from an internal process perspective, our experience can help you avoid going down dark alleys or dead ends in the negotiation.  Good attorneys don’t just spot problems, but also offer alternatives to try to find a workable solution.  We may be able to offer an alternative provision or wording that meets your business needs, works for the other party, and satisfies your internal processes.

Attorneys usually have a sense as to which approach to contract negotiation (exchanging redlines right away, hopping on a call with the other side right away, exchange redlines first then get on a call, etc.) will be most effective for a particular contract or third party.  Your instinct may be to jump on a call with the other side as soon as you send or receive a draft, but in some cases that may end up unintentionally slowing down the negotiation. Tech-savvy attorneys may also suggest leveraging technological tools to increase speed and efficiency, e.g., WebEx online conferencing to make edits to the draft in real-time as if all parties are sitting in a conference room together.

  1. Attorneys will advise on the risks and share their opinion, but the business needs to “call the ball.” Every contract involves risks and rewards.  My job is to shift as much risk as I can (e.g., through contract terms), and to help explain how to mitigate risks (e.g., through internal process or procedure to control it).  Any remaining risk needs to be accepted (we understand but the benefits are worth it) or rejected (the benefits aren’t worth it) by the business.  Unless something is illegal or there’s simply too much pure legal risk to proceed, the attorney isn’t the one who should be making that risk decision.  We may share our opinion, but we can’t make the decision.  You (or someone higher up in the company) needs to make the risk decision after weighing the pros and cons.  If no one wants to be the decision-maker, the negotiation will grind to a halt.

The Why, When and How of Confidentiality Agreements (Part 2)

Posted on by
Reply

Nondisclosure Agreements (NDAs), a/k/a Nondisclosure Agreements (NAs), Confidentiality Agreements (CAs), Confidential Disclosure Agreements (CDAs), and Proprietary Information Agreements (PIAs), are something most business leaders and lawyers deal with from time to time.  However, few companies have implemented policies stating why, when and how NDAs should be used.  In Part 1 of this article, I talked about the “why” and the “when.”  Part 2 covers the “how.”

HOW to use an NDA.  Once you’ve figured out the why and the when, use the following tips and tricks as you work with NDAs:

  • Keep them fair and balanced. While you always want to try to avoid getting bogged down in contract negotiations, this is especially true for NDAs typically entered into at the outset of a relationship or where disclosure of specialized information is needed to further a business purpose.  Counsel should work with business leaders to ensure the NDA template is fair and balanced. If a potential partner or vendor insists on their NDA, consider whether it is fair and balanced – if it is, it may not be the best time for a battle over whose form to use.
  • Make sure “purpose” is defined. NDAs should include a description of why the parties are sharing information (a potential business relationship between them, a potential business combination, to allow your company to participate in an activity, etc.)  This is usually defined as the “Purpose.” Defining the Purpose, and restricting the recipient’s use of your CI to the Purpose, can help ensure contractually that information you disclose is not misused.
  • Avoid sharing customer records or personally identifiable information under an NDA. Be very careful if you want to share customer or employee records or other personally identifiable information under an NDA. You generally need other security protections that aren’t in a standard NDA; your privacy policy might not allow it; you may not have the necessary permissions from the data subjects to share it; there may be specialized laws (e.g., HIPAA) that could be impacted; etc.  If you need to share data to evaluate a new product or service, use dummy data.
  • Ensure “Confidential Information” covers what you want to share. Make sure the definition of “Confidential Information” is broad enough to cover all of the information that you’re planning to share.  Whether you are disclosing financial projections, business plans, network credentials, samples of new products, or other information, if it’s not covered by the definition the recipient has no obligation to protect it.
  • Watch out for “residuals” clauses. One dangerous clause to watch out for (and avoid) in NDAs is the “Residuals” clause.  “Residuals” are what you retain in memory after you look at something (provided you don’t intentionally try to memorize it).  Residuals clauses let you use any residuals from the other party’s CI retained in your unaided memory.  However, it’s next to impossible to prove that something was in someone’s “unaided memory.”  Residuals clauses are a very large back door to NDA requirements.
  • Understand the “marking requirements.” NDAs generally require identification of confidential information so that the recipient knows that it should be kept confidential.  For example, you generally have to mark any information in written disclosures as “confidential” using a stamp, watermark, or statement in the header/footer (don’t forget to mark all pages of a document and its exhibits/attachments in case pages get separated).  Some NDAs require that confidential information disclosed orally has to be summarized in a written memo within a certain period of time in order to fall under the NDA – don’t lose sight of this obligation, and consider steps to mitigate the risk if you have this requirement (e.g., a reminder in your lead management system to summarize when a note of a sales call is included).  Other NDAs include a “catch-all” to keep confidential any information where, from the circumstances of disclosure, the disclosing party clearly intended (or the recipient can determine) that it should be kept confidential.  This last clause is a double-edged sword – it ensures the broadest possible protection for you, but also for the other party
  • Look at the “nondisclosure period.” Most NDAs have a defined period of time during which confidentiality obligations will apply to CI.  Once the period ends, your CI is no longer considered confidential by the other party.  If you are disclosing trade secrets, it’s important that they are kept confidential forever, or until the information enters the public domain through someone else’s acts or omissions. Also, consider language that requires the other party to securely dispose of your CI when there is no longer a business or legal need for them to possess it.
  • Control onward transfer. Ensure you’re controlling the onward transfer of your CI.  Generally, a recipient’s onward transfer of your CI should only be permitted when (a) the receiving party is a business partner of the recipient (a contractor, subsidiary, supplier, etc.); (b) the receiving party needs to know the CI in furtherance of the Purpose; and (c) the receiving party is bound by written confidentiality obligations at least as strong as those in the NDA between you and the recipient.  Make sure the NDA holds the recipient liable for any improper disclosure of CI by the third party so you don’t have to go after the third party, and requires that data be transferred securely.
  • Watch out for overlapping confidentiality obligations. As I noted in Part 1, it’s important to look out for duplicate confidentiality obligations governing the same confidential information.  In some cases, a party may suggest that each party sign the other’s NDA.  In other cases, a party might try to keep an NDA alive after a services or other agreement has been finalized and signed.  You should avoid having different confidentiality obligations govern the same agreement, as it can easily lead to a big fight over what contractual obligations and provisions apply in the event of a disclosure, distracting you from dealing with the actual breach of your CI.
  • Be mindful of your return or destruction obligations. In most NDAs there is a requirement for a recipient to return or destroy the discloser’s CI, either upon request and/or upon termination.  Sometimes the discloser gets to pick between return and destruction, sometimes the recipient.  In order to ensure compliance, make sure you limit disclosure of third party CI internally, and keep track of who has access to/copies of it.  Without tracking that information, it’s very difficult to ensure return or deletion when the time comes.
  • Be careful sharing access credentials. If you’re sharing any network or other computer access credentials as part of the Purpose, ensure the NDA contains additional security obligations to maintain appropriate safeguards to protect access credentials, to limit use of them (no onward transfer), notification in the event the credentials are (or are suspected to have been) compromised, and an indemnity if the security obligations are breached.  Remember, the Target breach began with the compromise of a subcontractor’s network credentials.
  • Consider using electronic signatures. As I described in my earlier blog post, using an electronic signature system for NDAs can make the nondisclosure process even more quick and efficient, letting your business team get to sharing information sooner.

There are other NDA issues as well, such as ensuring injunctive relief language is not too limiting or broad for your company’s needs.  As always, consult an attorney with expertise in NDAs (and a business-savvy approach) to ensure your company, its confidential and proprietary information and its trade secrets are properly protected.

The Why, When and How of Confidentiality Agreements (Part 1)

Posted on by
Reply

Nondisclosure Agreements (NDAs), a/k/a Nondisclosure Agreements (NAs), Confidentiality Agreements (CAs), Confidential Disclosure Agreements (CDAs), and Proprietary Information Agreements (PIAs), are something most business leaders and lawyers deal with from time to time.  However, few companies have implemented policies stating why, when and how NDAs should be used.  Quite often different people at the same organization take very different approaches to using NDAs, resulting in inconsistent protection of a company’s confidential or proprietary information (“CI”) — or worse, jeopardizing company trade secrets.  This two-part article provides a summary of the why, when and how of NDAs.  In Part 1, I talk about the “why” and the “when.”

WHY to use an NDA.  There are three primary, and sometimes overlapping, reasons why to use an NDA – for protective purposes, for strategic purposes, and for contractual purposes.

  • The most common reason for entering into an NDA is to ensure there are adequate (and binding) protections for your CI before you share sensitive information with another party.  If your company has trade secrets, failing to put confidentiality obligations in place with third parties who have access to your trade secrets can cost you your trade secret protection.
  • An NDA can also be used as a litmus test to gauge whether a party is truly interested and serious about discussions with your company.  If you’re asked to sign an NDA well before confidential information will be exchanged, this might be the reason.  An example is a requirement for potential vendors to sign an NDA before the RFP is provided to them, even if there’s nothing confidential in the RFP.  Requiring an NDA up front can also ensure that you don’t get down the road with a potential vendor or partner only to find that they are resistant to signing an NDA.
  • An existing confidential obligation to a third party may require you to put confidentiality obligations in place with any subcontractor or business partner with whom you need to share the third party’s CI for business purposes (more on this in Part 2).  If an existing agreement with your subcontractor or business partner doesn’t satisfy contractual requirements, a separate NDA may be needed.

If a third party questions why an NDA is needed, consider whether that should be a red flag in and of itself.  They may not view confidentiality as a significant concern or priority, may not be sophisticated about the importance of strong confidentiality practices, or may be trying to get you to reveal confidential information without an NDA in place.

WHEN to use an NDA.  Once you’ve determined that you need an NDA for one or more of the above purposes, you then need to determine when to use one.  Keep these questions in mind:

  • What is confidential information? In order to know when to use an NDA, you need to first know what needs to be protected.  This is often the MOST IMPORTANT question a company can ask.  What information is considered confidential or proprietary information, and what information is a trade secret?  Everything else should be considered non-confidential.  Look at your IT policies to see how data is classified at your company (many classify CI into levels) and use those classifications to determine what categories of information should be protected.  If it’s information you include in your marketing brochures or on your corporate website, it’s not confidential or proprietary information.  Use this test – if you would have a problem with the information showing up on the front page of your local paper or elsewhere for the world to see, or if it ended up in the hands of your competitors, you may want to treat it as confidential if it’s disclosed.  Educate your sales and other internal business teams as to what’s considered CI, and when an NDA is required — make sure to remind them that part of their job to protect your company’s confidential information.
  • Who is disclosing what? Not every discussion about a potential business relationship requires an NDA.  Look at what information may be disclosed and by whom.  If your company isn’t disclosing confidential information as part of the discussion, the onus should be on the other party to ask for an NDA.
  • Are there existing confidentiality terms? Sometimes an existing business partner or vendor will ask for an NDA before sharing information about a new product or service.  Before signing, check your existing agreement to see whether its confidentiality language is broad enough to cover the new information.  If it is, push back on the need for a separate NDA.  You should always try to avoid having multiple confidentiality terms governing the same confidential information (for more on this, see Part 2.)  If they insist, make sure the new NDA is limited in its purpose and does not overlap with the existing agreement.
  • When will sharing begin? Determine when in the in the sales cycle/vendor selection process you need to start sharing CI – that’s your “NDA point.”  Once you’ve determined your NDA point, make sure it’s build it into your SOPs and other business process documentation to minimize the chance that CI is shared without a valid NDA in place.
  • What is the right effective date? In business, the cart sometimes gets ahead of the horse when it comes to getting an NDA in place.  If your company gets out over its ski tips by disclosing CI without having the NDA in place first, ensure that the NDA applies retroactively to by setting the effective date as the date on which confidential information was first disclosed, not the date on which it was signed.

Feedback on feedback clauses

Posted on by
Reply

A feedback clause generally gives a party a right and license to use ideas, comments, suggestions or similar feedback provided by the other party. Companies that offer products and services like these clauses because they allow the company way to learn information that can help them continue to improve their offerings.  The standard argument in support of this type of clause is that it’s important to a product or service provider to ensure that simply discussing products in development with a client does not jeopardize their ability to use information they learn during that discussion.  While that’s not unreasonable, there are a few different flavors of feedback clauses – the taste depends on which side of the fence you’re on.

As noted above, a typical feedback clause gives a party defines “Feedback” (e.g., any ideas, comments, suggestions or similar feedback provided by one party to the other); indicates that the provision of feedback is completely voluntary; and provides some grant of rights to the receiving party to use feedback.  Think of this as the “base.”  There are things you can “mix into” the base to change or enhance it, including a feedback trumps confidentiality provision, a feedback ownership provision, and/or a feedback warranty provision. If you’re on the receiving end of feedback, these mix-ins may be worth considering adding into a base clause.  If you are on the disclosing end, these may be real causes for concern.  (If you’d like a copy of my standard mix-in clauses, send me an email.)

Feedback trumps confidentiality.  This mix-in states that any feedback provided, even if designated as confidential by the disclosing party, does not create any confidentiality obligation for the receiving party absent a separate written agreement, and the receiving party is free to use it the feedback without obligation or limitation.  To the recipient, this ensures that any feedback can be freely used if provided by a recipient, regardless of confidentiality obligations under the Agreement.  To the discloser, this can result in a “back door” around confidentiality.

Feedback ownership.  This mix-in states that the disclosing party agrees to transfer all right, title and interest in and to feedback to the receiving Party.  To the recipient, this ensures that they do not have to worry about creating derivative works of materials owned by a third party by using feedback.  To the discloser, this can result in an inadvertent surrender of its own rights to any of its underlying proprietary information disclosed as feedback to a third party.

Feedback warranty.  This mix-in is a warranty that the feedback does not infringe third party IP rights, is not subject to open source licensing obligations, and does not require payment of third party licensing fees.  To the recipient, this can give some important protections if the recipient uses the feedback.  To the discloser, this creates contractual representations for providing feedback, for which contractual damages may rise if the discloser breaches the warranty.

Here is my own base feedback clause where I represent MyCo (I flip this around and add in mix-ins on a case-by-case basis if warranted).  It requires designation of feedback as such, and protects confidential information if inadvertently provided with feedback:

“The Parties acknowledge that MyCo may from time to time provide YourCo with ideas, comments, suggestions, or other feedback on the features or functionality of YourCo’s product offerings which is designated by the disclosing party as “Feedback” in writing on any written feedback, or contemporaneously with disclosure if disclosed orally (collectively, “Feedback”).  The Parties agree and acknowledge that any Feedback is provided voluntarily by MyCo.  In the event MyCo provides YourCo with Feedback, MyCo hereby grants to YourCo a perpetual, royalty-free, worldwide right to use such Feedback for the limited purpose of improving and creating derivative works of YourCo’s Products (notwithstanding the foregoing, the foregoing right shall not apply or extend to any portion of Feedback provided by MyCo which is MyCo’s Confidential Information, MyCo Technology or MyCo Materials), and the obligations of confidentiality set forth in this Agreement shall supersede and have priority over any Feedback usage rights.”

Finally, one of the most important things you can do regarding feedback is educate your business teams on what to watch out for when sharing feedback with a contractual partner – as in many areas, sound business practices can go a long way towards ensuring reliance on the legal language never becomes a necessity.

Thoughts on software escrow

Posted on by
Reply

All too often a business person comes to me and says “we need to include escrow in that agreement we’re working on.” Sometimes it makes sense, sometimes it doesn’t. Sometimes it can be more trouble than it’s worth.

If your company licenses a piece of mission-critical software, it’s your job as the attorney (read: the risk manager) to ensure that the licensor continues to support and maintain the software (e.g., by releasing bug fixes and updates) for the term of your license. That’s typically done by adding terms to the license to ensure that they will make updates available to you either at no charge or a mutually agreed-upon charge (e.g., upgrade fees for feature releases and no charge for maintenance releases, bug fixes, new releases which correct security issues or are needed to comply with applicable law, etc.), or by executing a separate maintenance agreement for the software that gives you all updates for a monthly or yearly fee. You’ll also want to ensure that you are entitled to software support from the licensor (email, phone, in-person visits, user conferences in Bermuda, etc.).

That’s all well and good, but it rests on a very important assumption — (1) the company stays in business, and (2) the company doesn’t breach the agreement and you terminate (thereby terminating the license), either of which could leave your company hanging high and dry. The solution most often suggested? Software escrow. (There are other protections you can implement as well, such as ensuring you have a perpetual license and ensuring you have 365(n) language in your license agreement, but those are topics for another entry.)

Software escrow is, essentially, a form of insurance. A third party (such as Iron Mountain, called the “escrow agent”) will hold a copy of the source code for the software and other related materials “in escrow,” and release it to a party (such as the licensee of the software) if certain release conditions (usually called “release triggers”) are met. This way, if a release trigger occurs, you (the licensee) can go directly to the escrow agent and request a release of the escrowed materials, without necessarily involving the licensor. If the software is released from escrow, the licensee can use the source code to continue to update and support the software.

The simplest way to address escrow is to add an escrow provision directly into the license agreement. At a high level, the typical escrow provision (if you are the licensee) should contain the following at a minimum: (1) agreement on who the escrow agent is, (2) agreement on who will negotiate the agreement with the escrow agreement and pay for escrow services, (3) agreement on what materials will be escrowed, (4) agreeent on the release triggers, and (5) agreement on the licensee’s rights to escrowed materials upon release (make sure this is pretty broad if you’re the licensee).

I’ll note a couple of important considerations when drafting an escrow provision:

  • Materials to be escrowed. I’ve seen too often where an escrow provision says that the source code for the licensed application will be escrowed, and that’s it. That’s going to make escrow pretty useless, and result in your ops team yelling at you later on (and if an escrow release is needed, you can bet that it’ll be a “fire drill” situation so nerves will be on edge anyway, and they may be looking for someone to throw under the bus.) You want to ensure that the software in the escrow is updated regularly to ensure that the escrowed version is as close to the current release as possible (say, every quarter or six months); otherwise, you could be left with a significant out-of-date version of source code released from escrow. You also want to ensure that the software that’s escrowed is tested by the licensor (i.e., that they’ve taken the source code, compiled it, and have verified that it works). Most importantly, you want to ensure that the escrowed materials include detailed instructions on how to compile the software to make it usable, and what third party tools are needed to compile and use the source code. Otherwise, escrow is pretty useless. You should also ensure that any open source tools used in connection with the source code are included in the escrowed materials, to save your team the trouble of having to go find them.

  • Ensure you have access to licensor personnel for help. If there’s an escrow release, the best way to ensure you can work with the materials is to get help, ideally from the licensor’s own personnel. However, if your contract has a nonsolicitation or non-hire provsion, you could be prohibited from contracting with them. You should ensure your escrow provision allows you to engage the licensor’s personnel for assistance with use of the escrowed materials.

One other very important thought here…you can’t escrow a service or environment. I’ve seen requests for software escrow for the codebase for a licensed ASP application or other software as a service used by a company. A standalone software application is one thing, but an outsourced environment is a whole another ball game. The source code is all well and good, but if you don’t have the ability to replicate the platform and environment in which it resides, the source code won’t be much help to you. If you’re really willing to go there (and it’s that mission-critical), ensure that the escrowed materials includes network diagrams, lists of third party software/hardware needed to replicate the environment, and all other materials your business and operations teams will need to make a significant go at replicating the environment in which the escrowed code will reside. You may also want to consider requiring the licensor to meet with your operations team to walk through how this would work, and provide documentation on this outside of escrow, so that your ops team can hit the ground running.

IP warranty, indemnity, or both?

Posted on by
3

Lots of agreements involving technology have both an express warranty of non-infringement, as well as a third party indemnity against non-infringement. For instance, if you’re licensing a piece of your company’s software to a third party, the third party might ask for both a warranty of non-infringement, as well as a third party indemnity obligation. Sounds innocuous enough, right? An easy give in the negotiation? Maybe not.

Think about what could happen if someone comes out of the woodwork and asserts an infringement claim against your client. They’ll most certainly tender the claim to you for indemnification. However, if you have an IP warranty as well, they could conceivably also assert a breach of warranty claim against you for breach of the non-infringement warranty. This could allow the other side to “double dip” on damages, seeking both indemnification and direct damages.

“Good information,” you say. “No more warranties, just indemnification.” Not necessarily. An IP warranty does something that the indemnity does not…for certain types of IP claims, it can give the recipient of the warranty an “innocent infringer” defense to a claim of infringement, as they would allege that their allegedly infringing behavior was in reliance on the warranty. So, what you can do is give the warranty (it should be a “to the best of its knowledge” warranty ideally), but specifically state that the sole and exclusive remedy for breach of the IP warranty is indemnification pursuant to the IP infringement indemnity elsewhere in the agreement. This gives your client the best of both worlds, while ensuring you’re protecting your client.

On the flip side, if you’re licensing software, you always want to request both an IP warranty and an IP indemnity, and if the other side gives you trouble, just explain why the warranty is needed in addition to an indemnity, and offer the exclusive remedy language to placate any “double dipping” concerns they may have.