General

Eight Clauses in Data Agreements You Should Avoid (If You Can)

Published: Sep. 17, 2015

Updated: Oct. 06, 2020

I draft and edit a lot of data licensing and data services agreements for online, offline, social and mobile data. I often find myself revising or deleting certain reoccurring provisions because they invite disputes, raise confusion, forfeit rights or create business risk and potential disruption. This list catalogues some of what I consider the worst offenders: when you see them, you should at least consider whether they should be edited.

1. License grants with imprecise usage rights.

To avoid disputes, and to avoid giving up or receiving the wrong rights (and in the worst case, hurting your company’s strategic or competitive position), it’s important to precisely describe what data rights are licensed. Some agreements, for instance, license a data set and grant the licensee the right to, say, “employ the Data to fulfill the purpose of the agreement” – an imprecise and potentially confusing permission. Other agreements may, for instance, provide the licensee with the right to “model” data (and own those models), without describing what that means, which is risky because “modeling” can span a wide variety of data uses. A well-crafted license should leave little room for guesswork as to what data uses are and are not allowed.

2. Ownership provisions that are imprecise about who owns what data, and what rights remain after termination.

Some data contracts simply state that each party owns the data and infrastructure it began with. But when data is being transformed, modeled, or used to create a new service, that’s often not enough for comfort. For instance, if parties are working jointly to create an online cookie pool, who owns the cookies and who merely licenses them? If one party is creating data models to serve the other party, or a mutual client, who owns those models? These questions can sometimes be resolved with a “residual knowledge” clause that specifically defines “knowledge” and ideally provides examples.

3. Termination provisions that create business or operational risk for either party (but especially the licensee).

If you’re licensing a data asset, and it’s important to your business operations (e.g., you’re building a product or model around it or reselling it), you should avoid (or very carefully consider) provisions that could lead to termination of your access to data without leaving you enough time to replace that data. For instance, if a licensor can terminate your access to a key data asset simply upon 60 or even 90 days’ notice, it may not provide you enough time to find a replacement. Even where a termination provision kicks-in only upon the licensor’s acquisition, a similar risk is created.

4. Non-assignment clauses that don’t allow for assignment upon an acquisition.

If your company ever seeks to be acquired, a question asked during due diligence will be, “Are all of your contracts assignable?” Your answer should be “Yes” (or even better, “Yes, our lawyer made sure of that!”).

5. Security provisions that don’t require notice of a data breach.

Many contracts now set forth specific required data security protocols. But sometimes, data contracts that require indemnities against and insurance for data breaches (and similar protections) don’t require notice of data breaches. Don’t expect a data partner to notify you of a data breach unless it’s required by law – which it often isn’t. Breaches of customer lists and other personal information generally aren’t covered by data breach notification laws unless they include more sensitive (and generally, unencrypted) information, such as payment card, Social Security, banking or insurance data.

6. Lack of FCRA representations and warranties.

If you’re licensing data that could even conceivably be used for eligibility purposes covered by the Fair Credit Reporting Act (“FCRA”) (for example, if the data might be used to make a decision about whether to hire somebody or loan them money), it is wise to include a specific restriction against that use, setting out FCRA’s provisions. The FTC has (often) emphasized the importance of this, and recently has made rooting out FCRA violations a priority. Even data licensors can be liable if they haven’t reasonably prevented those violations. See, for instance, the FTC’s settlements with Spokeo and Equifax. (Alternatively, if you want your customers to be able to use the data for FCRA-covered purposes, there are ways to legally offer the data, but they involve contracting strategies and compliance obligations that are beyond the scope of this post.)

7. Confidentiality provisions that keep you in the dark.

As suggested in number 6, more regulators and government agencies have been looking at the data industry in the last couple of years (for a wide variety of reasons). If your licensor or licensee gets a request from the FTC or a State Attorney General that requires them to turn over your data, contracts, or other business information, you’d like to know about it as soon as possible and receive a copy of the subpoena or Civil Investigative Demand. Many confidentiality provisions don’t provide for this. Yours should. If a regulator is looking at your business practices, it’s of course in your interest to know as soon as possible.

8. Indemnification provisions that lack teeth.

Data licenses are sometimes created from templates for intellectual property licenses. As a result, indemnity provisions often provide for indemnification for violations of IP rights but little else. Indemnities should cover claims arising from the other party’s (a) violations of law, (b) violations of third party rights and (c) violations of representations and warranties in the agreement (and where applicable, data breach losses). What the precise reps and warranties are will vary depending on the data license, the use case, the data provenance and the practical risks.

This list is by no means exclusive, but the above examples of troublesome clauses are among the most common. (And the business rationales and incentives for each deal differ, so these suggestions may bend to the deal terms.)

Of course, the effectiveness of a data license agreement should be measured neither by its length nor by its complexity. Unduly lengthy or complex agreements can reduce deal velocity with only negligible legal advantages. Rather, an agreement’s effectiveness should be measured by whether you’ve inserted provisions to protect you from the right risks. Having the “wrong” provisions in a data license can lead to a loss of proprietary rights and enterprise value, as well as needless business disruption.

Disclaimer: As attorneys often say (and as you probably already know) what is on our blog isn’t formal “legal advice.”