Data Licence Agreement Template: What To Include

Licensing data can be a smart way to grow your business, especially if you collect, clean, analyse or package information that customers can use to make better decisions.

But data is a little different from ordinary software or content. Your customer might want to combine it with their own systems, train models with it, share it with a related company, or create new insights from it. If your agreement is vague, those lines can get blurry very quickly.

A well-drafted data licence agreement helps you set the rules from the start, so your customer knows what they can do under your data licence agreement and you protect the value of the dataset you have built.

What Is A Data Licence Agreement?

A data licence agreement is a contract that gives someone permission to access and use your data on agreed terms, without transferring ownership of the data to them.

It can cover many kinds of data products, including:

• Raw datasets, such as market, location, pricing, weather or transaction data
• Cleaned, enriched or aggregated datasets
• Analytics reports, dashboards or benchmarking outputs
• Data feeds delivered through an API, portal, spreadsheet or file transfer under a data sharing agreement
• De-identified or anonymised data products

In Australia, the legal protection for data can come from a few places. Copyright may protect the way a database is selected, arranged or expressed, but it usually won't protect bare facts by themselves. Confidential information, contract terms, trade marks and privacy laws may also be relevant.

That means your contract does a lot of the heavy lifting. It should spell out exactly what your customer can do with the data, what they can't do, and what happens if they go beyond the agreed use, including any privacy policy obligations.

A data licence is different from selling a dataset outright. In a licence, you usually keep ownership and give the customer limited rights for a particular purpose, period and fee.

Do You Need A Data Licence Agreement To Licence Data To Customers?

Yes, if you're giving customers or partners access to valuable data, you should use a written data licence agreement.

You might be tempted to rely on a purchase order, email chain or standard terms. That can work for very simple sales, but data licensing usually needs more detail. Without clear terms, you may struggle to stop a customer from reusing the data in ways you didn't intend.

A written agreement is especially useful where:

• Your data gives customers a commercial advantage
• The customer wants to integrate the data into their own platform or product
• The customer will share the data with employees, contractors or related companies
• The data includes personal information or commercially sensitive information
• You charge recurring fees for ongoing access
• You need audit rights, usage limits or security obligations

For example, say you run a Melbourne data business that licences retail foot traffic analytics to shopping centre operators. One customer pays for 12 months of access for 5 internal users across 3 centres. If your contract doesn't restrict use, that customer might share the reports with an affiliated property group, upload the dataset into a group-wide dashboard, or keep using exported files after the licence ends.

Those aren't always malicious acts. Often, the customer just assumes they can use the data like any other business resource. Your agreement should remove the guesswork.

What Should A Data Licence Agreement Template Include?

A data licence agreement template should include the commercial deal, the licence rights, the privacy and security rules, and the consequences if either side doesn't meet their obligations.

A template can be a helpful starting point, but data arrangements vary a lot. A lawyer should tailor it before you use it, especially if the data is high value, personal, regulated or being used in AI, analytics or customer-facing products, where an AI model and data licence may be needed.

Here is a practical outline you can use to map out your document:

1. Parties And Background: Name the licensor and customer, and briefly describe the data product.
2. Data Description: Define the dataset, reports, outputs, updates, delivery method and any exclusions.
3. Licence Grant: State whether the licence is non-exclusive or exclusive, paid or free, revocable or fixed term, and limited to a purpose.
4. Permitted Use: Set out exactly what the customer can do with the data, including internal use, reporting, analytics or integration.
5. Restrictions: Ban resale, redistribution, scraping, re-identification, model training, public disclosure or competitor use where needed.
6. Users And Affiliates: Say who can access the data, such as named users, employees, contractors or related bodies corporate.
7. Fees And Payment: Cover licence fees, usage fees, GST, invoicing, late payment and suspension rights.
8. Ownership And Derived Data: Clarify who owns the original data, customer data, improvements, insights and outputs created from the licensed data.
9. Privacy And Security: Add Privacy Act 1988, Australian Privacy Principles, security controls, breach notice, data processing schedule terms and deletion requirements where relevant.
10. Warranties And Disclaimers: State what you promise about the data, and what you don't promise.
11. Liability: Set liability caps, exclusions and indemnities that match the commercial risk.
12. Term And Termination: Cover the start date, renewal, termination rights, post-termination use, return and deletion.

The goal isn't to make the document longer than it needs to be. It's to make the important boundaries clear enough that your sales team, customer success team and customer all understand the deal.

How Should You Control Permitted Use, Restrictions And Derived Data?

You should control permitted use by describing the customer's allowed activities in plain, specific language, then separately listing what is prohibited.

A common mistake is to say the customer may use the data for business purposes. That sounds reasonable, but it can be too broad. Does it include building a competing product? Training an AI model? Sharing benchmark data with customers? Using the data across the customer's global group?

Try to define the permitted use by reference to:

• The customer's business unit, project or product
• The number and type of authorised users
• The territory, if location matters
• The licence term
• The delivery method, such as API access or monthly CSV files
• Whether the data can be copied, stored, downloaded or exported
• Whether the customer can show outputs to clients, investors or regulators

Restrictions should then deal with the risky uses. Depending on your model, you might restrict the customer from:

• Reselling, sublicensing or redistributing the data
• Publishing the data or making it available online
• Reverse engineering, scraping or bulk extracting your database
• Combining the data with other sources to re-identify people
• Using the data to train, test or improve AI models
• Using the data to create a substitute or competing dataset

Derived data needs special attention. This is data or insight created from your dataset, often after the customer combines it with their own information.

For example, Priya runs a SaaS platform that licences anonymised hospitality spending trends to restaurant groups. A customer pays $18,000 plus GST for a 12 month licence to use the data internally for menu planning. The customer then combines Priya's data with its own point-of-sale data and creates suburb-level demand forecasts.

Who owns those forecasts? Can the customer sell them? Can Priya use aggregated learnings to improve her own platform? The agreement should answer those questions clearly, rather than leaving them for a dispute later.

What Privacy, Security And Liability Terms Do You Need?

You need privacy, security and liability terms that match the type of data, the way it's delivered, and the harm that could flow if something goes wrong.

Privacy And Personal Information

If the dataset includes personal information, or if it could reasonably identify a person when combined with other information, the Privacy Act 1988 and the Australian Privacy Principles may apply. Many businesses must comply with the Privacy Act, including businesses with annual turnover over $3 million, health service providers and businesses that trade in personal information.

Your agreement should cover:

• Whether the data includes personal information, sensitive information or only de-identified data
• The purpose for which personal information can be collected, used and disclosed
• Whether each party is responsible for its own Privacy Act compliance
• Controls on re-identification, matching and linkage
• Notifiable Data Breaches scheme obligations, including when the customer must notify you of a suspected eligible data breach
• Return, deletion or secure destruction at the end of the licence

Privacy risk often turns on context. A dataset that looks anonymous on its own may become identifying when matched with location, transaction or device data. If your product uses de-identified data, your agreement should still prohibit re-identification attempts.

Security Controls

Your security clause should be practical, not just a promise to keep data safe. You might require access controls, encryption, secure storage, logging, personnel controls, subcontractor limits and prompt notice of security incidents.

If the customer can download your data, think carefully about what happens after download. API controls are helpful, but they won't protect a spreadsheet sitting in a customer's shared drive unless your agreement sets rules for storage and access.

Warranties, Disclaimers And Liability

You should be clear about what you warrant and what you don't. Many data providers warrant that they have the right to licence the data and that they will provide it with reasonable care. They often avoid promising that the data is complete, error-free, suitable for every purpose or guaranteed to produce a particular commercial result.

The Australian Consumer Law can also imply guarantees into some business dealings, and some guarantees can't be excluded. Your liability clause should be drafted with that in mind.

Common liability settings include:

• A cap on liability, often linked to fees paid under the agreement
• Exclusions for indirect loss, lost profits and loss of opportunity where appropriate
• Indemnities for misuse of data, privacy breaches, IP infringement or unauthorised disclosure
• Carve-outs for serious risks, such as confidentiality breaches or deliberate misuse

The right balance depends on your bargaining power, the value of the data and the customer's use case. A low-risk analytics report won't need the same settings as a live data feed used in a customer's regulated decision-making process.

Key Takeaways

• A data licence agreement lets you give customers permission to use your data without handing over ownership.
• Your permitted use clause should be specific, especially around users, purpose, sharing, downloads, AI use and redistribution.
• Ownership of original data, customer data, derived data and analytics outputs should be dealt with clearly.
• If personal information is involved, your agreement should address the Privacy Act 1988, the Australian Privacy Principles, security controls and breach notification.
• Liability, warranties and indemnities should reflect the real commercial risk of the data product and how customers rely on it.
• A data licence agreement template is useful for planning, but it should be tailored before you rely on it with customers or partners.

If you'd like help with your data licence terms, privacy and security clauses, permitted use restrictions or ownership of derived data, you can reach us at 1800 730 617 or team@sprintlaw.com.au for a free, no-obligations chat.