Managing and sharing big data creates technical challenges unlike anything found in traditional data-sharing relationships. But big data contracts don’t involve a whole new field of legal knowledge. If you’ve already worked on cloud computing agreements or traditional data licenses, you have most of the tools needed for big data licensing. (Actually, cloud computing contracts often include big data licenses, as we’ll see.) What you need, then, is an issue-spotter: a list of concerns to address as you draft and negotiate. That’s what this article offers. It lists forty issues to consider, for both licensors and recipients,[1] focusing primarily on U.S. contracts.

Let’s start by defining “big data” and discussing the legal protections that surround it. “Big data” has lots of definition, but I think it’s fair to say it refers to a collection of information in electronic form that’s so massive, and possibly so fast-changing, that traditional 20th Century data management systems can’t handle it. However you define big data, two central features stand out. First big data is useful. Any archive that big has got to reveal statistics businesses and governments can exploit: consumer tastes and preferences, economic trends, health trends, political views, etc. Second, big data is guaranteed to include sensitive information, particularly company secrets and individuals’ private information.

Big data “license” agreements are contracts calling for sharing of big data. They crop up in a variety of deals. Many cloud computing contracts include big data licenses, whether their terms acknowledge it or not, since the vendor will be holding and managing the customer’s data. And of course, many contracts expressly license big data. In some cases, the licensor hires the recipient to help it analyze and exploit data — for marketing campaigns, to identify new product needs, to understand markets and competitors, etc. In others, the recipient uses the data for its own purposes, or resells it or sells statistics derived from it, and buys rights from the licensor.

Data is information, and in general, information belongs to everyone. But intellectual property (IP) and other laws create exceptions to this rule; they create ownership rights in data, as well as rights that look like ownership. First and foremost, data may be protected by trade secrets laws — if it has competitive value and if the would-be owner makes reasonable efforts to keep it secret.[2] So to protect ownership of trade secrets in big data, licensors need reasonable internal and external procedures to protect secrecy, including contractual confidentiality terms and limits on vendor employee access—all discussed below. Big data may also be subject to copyright protections. Of course, copyright does not give rights to information itself. It’s the would-be owner’s compilation of big data that creates rights under copyright. That’s why licensors should require that recipients acknowledge the investment and effort that went into the compilation—again as discussed below.

Other sources of law may provide ownership-like protections, including the Computer Fraud and Abuse Act[3] and common law rules surrounding conversion and trespass to chattels. These systems of law don’t create new forms of property; rather, they give “owners” remedies for hacking and other unauthorized access to information. Finally, EU member countries’ laws provide ownership-like rights to databases, though only within the European Economic Area.[4]

All in all, would-be owners of big data should craft their contracts to enhance and protect IP and related legal rights. Ownership based in IP law may be more useful than contract rights to data because it’s easier to enforce against third parties. But the law doesn’t provide clear, firm ownership rights, so contracts play a vital role in exercising control over big data.

What then should those contracts say? Here’s the issue-spotter:

1. Defining the Data: First and foremost, a big data license agreement should describe and define the data in question. In some cases, the definition is easy, referring simply to all the data in a set of databases at a given time. In other deals, the recipient wants a more functional definition, to be sure it’s getting what it paid for. For instance: “‘Licensed Data’ refers to all data in electronic form in Licensor’s possession or control generated through transactions processed or monitored by the following Licensor computer systems: _________.” And in cloud computing relationships, the customer often wants as broad a definition as possible, to ensure that customer ownership and vendor protection responsibilities cover everything. “‘Customer Data’ means all information processed or stored on computers or other electronic media by Customer or on Customer’s behalf, or provided to Vendor for such processing or storage, as well as any information derived from such information. Customer Data includes, without limitation: (a) information provided to Vendor by Customer’s customers or other users or by other third parties; (b) personally identifiable information from such customers, users, or other third parties; and (c) information derived from the foregoing generated through database management, database hygiene, or database build services performed by Vendor or its subcontractors or other agents.”[5] (The preceding example includes “derived” data in the definition. That won’t always work, as explained further in bullets 19 and 20 below.)
2. Format for Delivery: In addition to defining the data, the recipient should require that the licensor provide it in a useful format (at least before committing to pay for it). Consider in particular compatibility with technology platforms. Also, will the data be provided in a single data dump or on a repeated basis, as it grows? Both parties should also think through the mechanism for delivery: specified communications technology, security covering the transmission, etc.

LICENSE RIGHTS

3. License Limited to Customer Service: Cloud services agreements generally authorize use of data solely as necessary to support the customer. “Customer hereby grants Vendor a non-exclusive right to reproduce and use the data solely to the extent necessary to provide the Services to Customer.”
4. Broader License: Some licenses give the recipient far broader rights, particularly where the recipient is paying for data access. “Licensor hereby grants Recipient a non-exclusive right to reproduce and modify the Data.” In some deals, that’s the extent of the license clause, though very often other clauses restrict the recipient’s use of data. (For restrictions, see bullets 7 through 15 below. And for more on data modification — derivative works — see bullets 22 and 23 below.) You might also craft a narrower license: “Licensor hereby grants Recipient a non-exclusive right: (a) to reproduce the Data and use it solely as set forth in Section __ (Data Use); and (b) to modify the Data solely as set forth in Section __ (Data Modification).” In a clause like that, the key action is in the referenced sections, on “Data Use” and “Data Modification.”
5. License to Distribute: Some licenses grant the recipient the right to re-distribute the data—or in some cases revised data, like an anonymized version. (See bullet 10 below.) “Licensor hereby grants Recipient a non-exclusive right to distribute the Modified Data; provided: (a) Recipient does not distribute the Modified Data, or permit its distribution to Licensor Competitors (as defined in Section __, Competitors); and (b) Recipient is in full compliance with the requirements of Sections __ (Data Use Restrictions) and __ (Anonymization and Contents of the Modified Data).” Obviously, the licensor should approach distribution with care, since it may extinguish any trade secret rights—unless the recipient distributes only to a limited number of customers and imposes confidentiality and data security restrictions on each. (See bullets 24, 25, and 26 below.) Distribution may also, of course, create licensor liability to third parties who contributed to the data, particularly consumers.
6. Licenses Conditional upon Compliance with Other Terms: Licensors should consider conditioning the license on compliance with the contract’s most important other provisions. The point is to provide that breach of those particular provisions invalidates the license, so that the offending recipient has infringed the licensor’s copyright and other IP rights, in addition to breaching the contract. At the end of the sentence granting license rights, add something like, “… provided Recipient complies with the requirements of Sections __ (No De-Anonymization), __ (Data Security), and __ (Confidentiality).” Don’t just incorporate the whole contract, because you threaten to render the incorporation meaningless. (That fact that you haven’t made the license conditional on a given clause doesn’t mean you can’t terminate the contract, including the license, for any material breach of that clause. The issue, instead, is whether breach of that clause just breaches the contract or also infringes IP.)

USE RESTRICTIONS AND AUTHORIZATIONS

7. Typical Restrictions on Vendor and Employee Data Use: If drafted well, the license grant itself will include restrictions on data use, as in the example in bullet 3 above. But the licensor may need other restrictions. In a typical cloud services relationship, the key restriction is often simple: “Vendor will not use Customer Data for any purpose other than as necessary to provide the Services to Customer.” And big data licenses of all types tend to include another restriction: “Recipient will not give any of its employees or other staff-members access to the Data for any purpose, except as strictly necessary to exercise Recipient’s rights granted in this Agreement.”
8. Restrictions on Marketing, Territory, and Devices: Where the recipient gets to do more than just provide services to the licensor, you should consider tailored restrictions. For instance: “Recipient will not: (a) use the Data to identify, market to, or otherwise make contact with any individual or entity; (b) store or process the Data or access it from anywhere other than the United States of America and the member states of the European Union; or (c) store or process the data from any device other than an Authorized Device (as defined in Section __, Authorized Devices).”
9. Compliance with Promises Made to Consumers and Privacy Policies: One of the licensor’s key protections has to do with promises to consumers. If it’s possible to identify the promises made to consumers when the data was collected, the licensor should impose those promises on the recipient. “Recipientwill not use the Data in any way inconsistent with the Licensor Privacy and Data Use Policy attached to this Agreement as Schedule __.” And whether the licensor can identify specific promises made to consumers, it should consider restricting the recipient to some privacy policy — either the licensor’s own or the recipient’s.
10. Anonymization: In some contracts, the licensor restricts the recipient’s rights to “anonymized” versions of the data: data “cleaned” so that it doesn’t include individuals’ names or other personally identifiable information. (Anonymization creates a derivative work, addressed in bullets 22 and 23 below.) “On or before _____, Recipient will (a) remove all personally identifiable information (‘PII’) from the Base Data and (b) destroy any and all copies of the Base Data on its computer or otherwise in its possession or control, exercising reasonable efforts to ensure that no element of the Base Data may be restored by any means. The revised data created pursuant to Subsection __(a) above is referred to herein as the ‘Anonymized Data.’ Licensor hereby grants Recipient the following rights to Anonymized Data: _________.” In other contracts, the licensor provides only anonymized data, and it wants to be sure the recipient won’t ever recreate PII. “Recipient will take no action that does or reasonably could lead to the identification or discovery of PII in the Anonymized Data. Without limiting the generality of the foregoing, Recipient will not reverse engineer the Anonymized Data or combine it with other data that might facilitate discovery or extrapolation of PII.” Licensors also sometimes ask for prompt notice if the recipient does discover PII in anonymized data, or discovers weaknesses in the anonymization process.
11. E-Discovery: Licensors should consider terms requiring that the recipient promptly provide a complete copy of the data, or unrestricted access — and terms requiring that the recipient follow the licensor’s own procedures regarding data retention and destruction. The licensor’s concern is e-discovery. In litigation, the licensor’s opposing party may have the right to discover some of the data. If the recipient has data that the licensor doesn’t, the opposing party may be able to subpoena that data, directly from the recipient. Then it’s the recipient’s lawyers, not the licensor’s, who decide what to disclose. But if the licensor has access to the exact same data as the recipient, it can probably get the court to require that all e-discovery demands be directed at the licensor itself, rather than the recipient. As for data retention and deletion, litigation creates obligations to preserve data that might be relevant to the case, and the parties can face hefty fees if they delete that data. So the contract needs terms assuring the licensor that, if the recipient holds the only copy, it won’t get the licensor into trouble with the court through unauthorized deletion. (You can download free samples of these e-discovery terms on the Clauses page of the Forms library at TechContracts.com. That’s the website for my book, The Tech Contracts Handbook: Cloud Computing Agreements, Software Licenses, and Other IT Contracts for Lawyers and Businesspeople.)
12. Sublicensing: The license should address sublicensing, either authorizing it or forbidding it. If you do authorize sublicensing, the licensor should consider specifying the purpose of any sublicense rights and, in some cases, list the authorized sublicensees by name or description. And of course, licensors should try to keep ultimate liability with the recipient: “Recipient will be responsible and liable for all its sublicensees’ acts and omissions related to the Data.” And licensors should consider requirements that all sublicensees agree by contract to observe the recipient’s restrictions on data use, including confidentiality and security restrictions. Licensors should also consider terms providing that they’re third party beneficiaries of any sublicense contract. Recipients, on the other hand, should try to limit liability for sublicensee conduct where possible. In deals where the licensor has approved the sublicensee, the recipient has a good argument that it should not be responsible for that sublicensee’s conduct. That’s particularly common where the sublicensee is a well-known IT vendor: a cloud infrastructure (IaaS) or platform (PaaS) vendor, for instance, like Amazon Web Service or Salesforce’s Force.com platform. “Recipient will have no responsibility or liability for any act or omission of the Host Provider.” (The recipient’s best tool in those cases, however, is to require a contract between the licensor and the third party vendor in question, so that it’s not a sublicensee.)
13. Exclusivity: In typical cloud services relationships, the vendor’s rights to data will be “non-exclusive,” as in the examples in bullets 3 and 4 above. But the simple addition of the word “exclusive” before “license” or “right” will mean no one but the recipient can exploit the data as authorized by the contract — not even the licensor.
14. Notices on the Data: Many licensors require reproduction of notices with the data. “Recipient will not remove or obscure any notice included with the Data and will preserve all such notices, in substantially similar form, on all derivative works of the Data.”
15. Other Restrictions: You can write any other restrictions you need, and you shouldn’t hesitate to be creative. Describe your restrictions in detail — and if you’re the recipient, don’t assume vague restrictions benefit you. Bright lines are usually better.

DATA OWNERSHIP

16. Ownership of the Original Data: Relatively few big data licenses transfer ownership. If ownership stays put, the licensor — whether vendor or customer — should leave no doubt: “The Licensed Data remains Licensor’s sole and exclusive property, and Recipient receives no right, title, or interest in or to the Licensed Data, except to the limited extent set forth in Section __ (Data License).” Of course, if you do plan to transfer ownership, the transfer also requires clear terms: “Customer hereby assigns all its right, title, and interest in and to the Transferred Data to Vendor. The rights assigned pursuant to the preceding sentence include, without limitation, any and all copyrights, rights in trade secrets, and other rights to tangible or intangible property.”
17. Confirming and Protecting IP and Other Rights: Data licensors should include terms confirming and protecting their ownership rights in data—terms that bolster their ownership claims discussed above. “Recipient recognizes and agrees that: (a) the Data is valuable property of Licensor; (b) the Data includes trade secrets of Licensor; (c) the Data is an original compilation pursuant to United States copyright law; and (d) Licensor has dedicated substantial resources to collecting, managing, and compiling the Data.” In the preceding sentence, subsection (b) helps protect trade secret rights, while subsections (c) and (d) help protect copyrights. Some contracts go even further, adding restrictions on contesting ownership, similar to the restrictions you sometimes see in patent licenses. “Licensor may terminate this Agreement without advanced notice or opportunity to cure and without further obligation or liability if Recipient has contested any of Licensor’s right, title, or interest in or to the Data, including without limitation in a judicial proceeding anywhere throughout the world.” Or, you could just provide that contesting data ownership is a material breach, which should authorize termination as well as create a possible right to damages and other remedies.
18. Ownership of Derivative Works and Derived Data: Don’t forget that many big data licenses lead to generation of new data, and in most cases you should address who owns that data. See bullets 20 and 22 below.

DERIVED DATA AND DERIVATIVE WORKS

19. Defining Derived Data: The recipient may use the data to generate new information: “derived data” — also called “usage data” if created by a cloud services vendor through monitoring a system. “‘Derived Data’ refers to: (a) new information generated through analysis and other processing of Customer Data; and (b) information generated through monitoring or other observation of Customer’s and its end-users’ use of the System.” Derived data will often qualify as a derivative work of the licensor’s original data (and to that extent, it’s addressed in bullets 22 and 23 below) — but not necessarily. Some definitions separate derived data from derivative works: “‘Derived Data’ refers to new information generated through analysis and other processing of Customer Data, provided the original Customer Data cannot be identified, via reverse engineering or otherwise, through analysis of such new information.” Finally, in some cases you may need multiple categories of derived data, if the parties have different ownership and use rights related to different parts of the derived data. For instance, the contract could define “Derived Data” per subsection (a) in the example above and “Usage Data” per subsection (b). And you might need to break up the derived data into any number of other categories.
20. Ownership of Derived Data: IP rights in derived data may be complex and even self-contradictory, since copyright, trade secret, and other sources of rights may point to different owners. So the parties should generally specify in the contract who owns derived data. Often, cloud services vendors will want to own derived data resulting from observation of their customers’ use of a service: “usage data.” That’s generally more palatable to customers if no original customer data can be gleaned from the derived data, and if the data’s anonymized. Even in that case, though, the licensor will need to own derived data if it’s mixed into the original data and the two datasets can’t be separated. Also, keep in mind that, in the weird world of data ownership, confidentiality rights can create or stand in for ownership rights. So if a confidentiality clause protects derived data, think through whose Confidential Information it is. In general, confidentiality rights should go to the party that “owns” the data. (For more on data confidentiality, see bullets 24 and 25 below.)
21. License Back of Recipient-Owned Derived Data: Whoever owns derived data, the other party should consider getting a license back — like the data licenses in bullets 3 and 4 above.
22. Ownership of Derivative Works: In big data, a “derivative work” is a modified version of the data, with new data added or data removed. It might include derived data. If the recipient can create derivative works, the contract needs to say who owns them. If it says nothing, the recipient own information it added to the data, while the licensor owns the original—creating a hard-to-manage joint ownership situation. Joint ownership gets even more complicated if the recipient deletes data but adds nothing new. It still might have some sort of compilation rights under copyright, but the licensor owns the data too. So don’t leave ownership and control to the underlying law. Specify who owns what and who can do what with derivative works.
23. License Back of Derivative Works: Whoever owns derivative works, the other party may need a license to exploit them, like the data licenses discussed in bullets 3 and 4 above.

CONFIDENTIALITY, SECURITY, AND COMPLIANCE

24. Confidentiality in General: This almost goes without saying, but if you’re the licensor, say it: “Recipient will not disclose the Data or any part of it to any third party except as specifically authorized by this Agreement.” You should also consider a full confidentiality clause to protect the data (a nondisclosure agreement — NDA — incorporated into the contract). But keep in mind that classic NDA’s were created to protect confidential documents and oral disclosures, and many of their terms fit databases and electronic data loosely at best. So don’t rely solely on NDA/confidentiality terms; add data security terms (discussed in bullet 26 below). And think through provisions of the typical NDA/confidentiality clause that might not fit well. In particular, does confidentiality last only for a set period? That’s a bad idea for trade secrets and private information, both of which should remain confidential so long as they’re sensitive (forever, in many cases).
25. Confidentiality and Ownership: Trade secrets law may consider the “discloser” of confidential information — the party that can enforce confidentiality restrictions — its owner. Remember that when drafting confidentiality restrictions related to the data, derived data, and derivative works. Don’t list the wrong party as “Discloser.”
26. Data Security: Data security clauses govern the steps the recipient takes to protect the data from unauthorized exposure or disclosure. That often includes technical and physical steps, like encryption, passwords, intrusion detection software, and locked doors in server rooms. Data security clauses may also cover employee background checks, outside audits of data security procedures (SOC 2, SSAE-16, ISO 27001), internal audits and testing, penetration testing, and repair of inadequate systems. Data security often calls for long, complex terms. (You can download a free data security clause on the Clauses page of the Forms library at TechContracts.com. See Part II-H of the linked page.)
27. Compliance with Laws and Policies: Licensors are often eager to make sure their recipients “comply with all applicable laws and regulations governing the handling of Customer Data.” Any number of statues could govern data, particularly if it’s consumer personally identifiable information (PII or private information). Some laws to consider are the Health Information Portability and Accountability Act (HIPAA), the Health Information Technology for Economic and Clinical Health Act (the HITECH Act), the Fair Credit Reporting Act (FCRA), and of course, the Gramm-Leach-Bliley Act (GLBA), as well as statutes from the states with particularly strong privacy legislation, like Massachusetts and California. And of course, foreign law creates another set of compliance issues, particularly the European Union’s Data Protection Directive. For credit card data, licensors often want assurances of compliance with PCI: the Payment Card Industry Standard from the Payment Card Industry Data Security Standards Council.
28. Data Breach Cooperation: Licensors often request recipient commitments to provide notice of data breaches and to cooperate with the licensor and with law enforcement authorities. Licensors also often request that, if the recipient causes a data breach, it will provide credit monitoring services to any injured consumers—usually for one year. (You can find data breach terms in the data management and security clause on the Clauses page of the Forms library at TechContracts.com.)

RESPONSIBILITY AND LIABILITY FOR DATA

29. Licensor Disclaimers: Licensors often disclaim any kind of warranty related to their data, particularly where they’re not being paid. “LICENSOR PROVIDES THE DATA ‘AS IS’ AND AS AVAILABLE, WITH NO REPRESENTATION OR WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY OR PRIVACY RIGHTS OR ANY IMPLIED WARRANTY ARISING FROM STATUTE, COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. WITHOUT LIMITING THE GENERALITY OF THE FOREGOING: (a) LICENSOR DOES NOT REPRESENT OR WARRANT THAT THE DATA OR ACCESS TO IT WILL BE UNINTERRUPTED OR ERROR-FREE; AND (b) LICENSOR HAS NO OBLIGATION TO INDEMNIFY RECIPIENT AGAINST ANY CLAIM ARISING OUT OF OR RELATED TO THE DATA, INCLUDING WITHOUT LIMITATION CLAIMS OF INTELLECTUAL PROPERTY INFRINGEMENT OR VIOLATION OF PRIVACY RIGHTS.”
30. License Rights Warranties from the Licensor: In some cases, the licensor does warrant IP and privacy rights related to the data. It could warrant that it has all the rights necessary to license the data to the recipient: a typical warranty for software and “little data” licenses. But licensors should keep in mind how hard it is to know if every consumer and company contributing information to big data actually agreed. The licensor might instead offer more limited reps and warranties. “Licensor warrants that it has made reasonable efforts to secure the authority necessary to grant Recipient the rights set forth in this Agreement, without the further consent of any third party, and that it does not know of any third party right or claim that would interfere with such rights.”
31. Other Warranties from the Licensor: Licensors offer a variety of other warranties. For instance: “Licensor represents and warrants that: (a) it has exercised reasonable efforts to ensure that the Data is accurate; (b) it is not aware of any computer virus or other malicious code in the Data; and (c) it has not taken any action intended to render the Data or results derived from it unreliable.” The recipient should think through why it’s licensing the data from this licensor, and craft licensor warranties to fit those reasons, if possible.
32. Warranties from the Recipient: Recipients often provide no warranties. Their obligations come from promises regarding data use, security, etc., but without the higher level of liability imposed by a warranty. But some licensors insist that certain recipient obligations come in the form of a warranty. For instance, “Recipient represents and warrants that its systems for management of Credit Card Data are now and will remain throughout the Term compliant with the then-applicable requirements of the Payment Card Industry Data Security Standards.” Licensors should think through what promises led them to choose this recipient, and consider them as possible sources of warranty.
33. Indemnities from the Recipient: Data indemnities address third party suits triggered by data breaches — particularly suits by government agencies and injured consumers. In some contracts, the recipient indemnifies the licensor against suits triggered by its alleged failure to keep the data secure. In others, the licensor indemnifies the recipient against suits triggered by the licensor’s alleged failures, particularly inclusion of third party information that shouldn’t have been part of the data, or failure to obtain proper authorization to include third party data. And in some contracts, the parties seek mutual indemnities. All these clauses raise complex issues. In particular, who defends whom regarding an alleged data breach either party could have caused? If you do include data breach indemnities, think through what will happen when a suit gets filed, as well as how overbroad terms might force a party to defend a case triggered by the other’s mistakes.[6]
34. Liquidated Damages: Misuse of big data is an excellent candidate for liquidated damages because it can be so hard to determine the injured party’s damages.

TERMINATION

35. Return of Data in General: Usually, the recipient returns the data when the contract terminates. Licensors should consider terms governing the timing of return — “within __ hours [or business days] of termination of this Agreement” — as well as the format of returned data. Most likely, the terms governing the format for original delivery, addressed in bullet 2 above, will do the trick. But if the recipient will be returning derived data or derivative works, formatting needs may change.
36. Transfer/Return of Modified Data: Parties that don’t own derived data or modified data, or receive a permanent license, will generally be required to deliver it upon contract termination. “Within __ business days of termination of this Agreement, Vendor will deliver to Customer all Derived Data and derivative works of the Data in its possession or control as of the moment of termination.” Return of data should be subject to the same sort of terms as the original delivery, discussed in bullet 2 above.
37. Destruction of Data: If the recipient won’t be keeping data, the contract should in most cases require its total destruction. “Within __ business days of Licensor’s written acceptance of the returned Data, Recipient will destroy any and all copies of the Data on its computer or otherwise in its possession or control, exercising reasonable efforts to ensure that no element of the Data may be restored by any means.”
38. Transition Services and Storage: In many cases, the customer won’t be able to manage or even store its data until it’s found another vendor or invested in staff and systems. So if termination without sufficient notice is even possible, the licensor should consider transition terms. The contract might require, for instance, that the recipient continue to store the data and give the licensor access for some period of months, for a fee. And of course, many cloud services agreements provide for complete transition services after termination, where the vendor continues to provide the core service. (You could also use a long notice period for termination, but a transition system often works better because it preserves only specified obligations, terminating the rest of the contract. Plus, it’s hard to eliminate the risk of termination with a short notice period, for breach.)

MISCELLANEOUS

39. Compliance Audit: In some cases, the recipient’s restrictions won’t do the licensor much good without the right to check: to audit the recipient’s compliance with the terms. (This is separate from the data security audit discussed above in bullet 26.) “No more than once per calendar year, Licensor may audit Recipient’s computers, books, and records relevant to compliance with the provisions of Sections __ (Data License), __ (Restrictions on Data Use), and ___ (Payment). Such audit will be conducted at Recipient’s premises at such time as the parties may agree, provided each will negotiate in good faith regarding timing, and the audit will not unreasonably interfere with Recipient’s operations. Recipient may require that any information disclosed or revealed through an audit be subject to such reasonable nondisclosure agreement as Recipient provides. In the event that an audit reveals material noncompliance with the terms of this Agreement, Recipient will reimburse Licensor the costs of the audit, in addition to such other remedies as Licensor may have. The parties’ rights pursuant to this Section __ will continue for __ years following termination of this Agreement.”

40. Everything Else: Each party to a big data license should think through all the other terms common to technology agreements. What justifies termination for breach? Are some breaches so serious that they should justify termination without advanced notice or cure—like intentional or negligent exposure of PII? Can the recipient assign the contract—in general or as part of a merger or acquisition? Should payment be tied to the amount of data licensed or to the money the recipient earns from it (royalties), or should the fees section use some other metric? What sort of limit of liability clause should the contract include, and should it protect both parties? (For more issues to consider, see The Tech Contracts Handbook.)

———————————

endnotes:

[1] I use “recipient” because I find that “licensee” gets confused with “licensor,” since they sound and look alike, and so makes for confusing reading.

[2] See the Uniform Trade Secrets Act § 1.4.

[3] 18 U.S.C. § 1030.

[4] See, Directive 96/9/EC of the European Parliament and the Council of 11 March 1996 on the legal protection of databases.

[5] The preceding sentence is reproduced and modified with permission from my book, The Tech Contracts Handbook, Chapter II.H.1, “Customer Data Defined.” All rights are reserved.

[6] These issues are too complex for this bullet, but I cover them in detail in Chapter II.J, “Indemnity,” of The Tech Contracts Handbook. And the sample clauses at the Forms page at www.TechContracts.com provide language you can use for data indemnities.

—————

—————

© 2015-2018 by David W. Tollen. All rights reserved.