Data Licensing vs Data Selling: What Actually Changes?

1. The transaction is a bundle of rights and permissions

A dataset is not necessarily one indivisible asset owned in full by one company. It may contain records generated by customers, staff, software, suppliers and third parties. Different rights and obligations can attach to the collection, its contents, its structure and the way it is accessed.

For example, UK guidance distinguishes copyright in an original selection or arrangement of database material from database rights that may protect database contents when the required investment criteria are met. Those are not universal rules for every jurisdiction or dataset, and they do not establish that a company owns every record it holds. UK IPO guidance on database rights

It helps to separate four things:

Exhibit 1. Rights and transaction components

A licence is permission to do specified things that would otherwise be restricted by relevant rights or agreements. A transfer or assignment may transfer specified rights to another party. For copyright, UK government guidance distinguishes licensing use from transferring copyright through an assignment; the precise position depends on the right, contract and applicable law. UK guidance on licensing and selling copyright

The useful executive question is therefore not simply, “Are we selling or licensing the data?” It is:

What exactly are we allowing the recipient to do, with which material, under whose authority, for how long, and what remains under our control?

That question should be answered in the contract, not left to the commercial label or an informal description in a pitch deck.

Why the legal perimeter can be narrower than the technical package

A useful distinction is between delivering a copy of information and conveying an enforceable intellectual-property right. A company might deliver an export containing facts that are not individually copyright-protected, copyrighted staff or supplier texts, proprietary database structure and confidential customer material. The fact that the technical export can be downloaded does not mean that the seller has authority to authorise every reuse. WIPO distinguishes an assignment, which transfers ownership of specified intellectual-property rights, from a licence of specified uses; that distinction must still be applied to the actual rights available rather than to an imagined unitary property right in 'all data'.

Permission reviews should proceed source by source: ownership or licence authority; contractual restrictions; confidentiality; personal-data obligations; then the proposed recipient and processing purpose. An attractive commercial contract cannot create a missing right against a third party. Conversely, a restriction affecting only one source or use case may sometimes be managed by excluding those records or adopting a narrower purpose. This is why a rights inventory is not a clerical appendix but can determine the saleable population.

2. Define the permitted use before negotiating price

A buyer’s use case determines the rights and controls it needs. “AI use” is too vague to be a reliable grant: training a model, testing it, grounding answers with retrieved records, and evaluating outputs can involve different data flows and different risks.

The table below is a scoping aid—not legal advice or a claim that every buyer will require every permission.

Exhibit 2. Permitted-use scoping matrix

A practical example

Suppose an equipment-maintenance archive contains:

asset_id
equipment_type
fault_code
reported_at
technician_notes
parts_replaced
repair_duration
repeat_failure_within_30_days

A buyer could use this material to evaluate whether a model can classify faults from technician notes. That does not automatically mean the same buyer may use it to train a commercial assistant, retain the underlying records indefinitely, or provide access to another company.

A clear permission set might distinguish:

• a time-limited evaluation on a defined sample;
• training on specified fields and versions;
• internal access by named teams or approved contractors;
• whether the buyer may use resulting model checkpoints in a specified product;
• whether customer-facing retrieval is permitted;
• whether the buyer may sublicense data or provide it to affiliates;
• what must be returned, deleted or retained at the end.

The distinction matters technically as well as contractually. If evaluation examples later enter training, they may no longer provide an independent measure of performance. If personal or confidential information is present, a broad “AI use” phrase does not itself resolve the relevant privacy, confidentiality or security obligations.

For personal data, the provider and recipient must determine their actual roles and responsibilities; contractual labels alone do not settle whether each is a controller, processor or joint controller. The UK ICO’s guidance makes this distinction and recommends clear agreements describing data items, purposes and the organisations involved in controller-to-controller sharing. ICO guidance on data sharing ICO guidance on data-sharing agreements

Rights should follow the data through the chain

A provider should be able to explain where the data came from and which permissions or restrictions apply. For the maintenance archive, that may mean checking:

• whether customer or supplier agreements restrict secondary use;
• whether technicians’ notes include personal, confidential or third-party material;
• whether software vendors’ terms affect extraction or reuse;
• whether staff-created material is covered by employment or contractor arrangements;
• whether any data were imported from another source with separate terms.

The provider may be able to grant some permissions but not others. If it cannot demonstrate authority to grant a particular use, that right should not be implied by broad wording.

The practical rule: scope the permission at the level of the data, activity, recipient and downstream use—not merely by saying “dataset licence” or “AI training”.

3. Exclusivity trades future options for negotiated value

An exclusive licence can prevent the provider from granting the same rights to others; depending on its wording, it may also restrict the provider’s own use. A sole licence commonly allows the provider to keep using the material while excluding other licensees. A non-exclusive licence allows the provider to license the material to more than one recipient. The contract must state which arrangement applies. UK government guidance describes these distinctions in its licensing materials. GOV.UK intellectual-property licensing guidance

Exclusivity is not a single on/off switch. It can be limited by:

• purpose: one application, such as fault classification;
• field: one industry or operational domain;
• product: one named product or product family;
• territory: specified countries or markets;
• time: a fixed period, renewal conditions or a milestone;
• data scope: specified fields, records, versions or future updates.

A narrow grant can preserve more options than a global, all-purpose exclusive licence. But exclusions must be explicit enough to work: vague carve-outs can create disputes over whether a later product or buyer falls inside the exclusive field.

Worked hypothetical: what must exclusivity compensate for?

The following figures are invented solely to demonstrate a decision method; they are not market benchmarks.

Assume a provider estimates the same preparation and support costs under either option:

• one-off preparation and legal work: £35,000;
• maintenance, security and refresh work over two years: £24,000.

The provider receives a hypothetical two-year exclusive offer of £120,000. Its simple net contribution before tax, financing and other overheads is:

£120,000 − £35,000 − £24,000 = £61,000

Alternatively, suppose a hypothetical non-exclusive arrangement would pay £55,000 for the first licence, with the possibility—but no guarantee—of additional licences at £45,000 each. The baseline £59,000 applies to the first transaction; assume a further £8,000 of clearance, support and contracting cost per additional buyer. This revised comparison therefore recognises marginal servicing costs rather than assuming every extra licence is costless:

Exhibit 3. Illustrative exclusivity and non-exclusive economics

Under these assumptions, exclusivity produces the higher simple net contribution if the provider expects zero or one additional non-exclusive licence; two additional licences would make the non-exclusive scenario higher by £9,000. The scenario excludes additional legal events, compliance incidents and the timing of cash flows. Real decisions also need to account for uncertainty, timing, sales effort, changing data, buyer concentration, operational capacity and the value of retaining future choices.

This is not a valuation of the data. It is a transparent way to ask: what expected opportunity are we giving up, and what consideration or commitment would justify that trade?

Protect against “exclusive in name, vague in practice”

Before accepting exclusivity, consider:

• Minimum commitment: Is there a minimum fee, usage commitment or delivery schedule?
• Activation: Does exclusivity begin only after payment, acceptance or a defined launch?
• Performance: Can the provider regain rights if the buyer does not use or commercialise the data?
• Scope: Does exclusivity cover only a named purpose, product, field and territory?
• Duration: Is the term short enough to reflect the data’s useful life and the provider’s opportunity cost?
• Renewal: Does renewal require affirmative agreement and updated economics?
• Future data: Are future records automatically included, or separately negotiated?
• Provider’s own use: Can the provider continue using the data operationally and improving its own services?
• Other commercial routes: Are derived, aggregated or independently created materials carved out where appropriate and lawful?

A buyer may request exclusivity because it needs assurance that competitors will not receive the same resource. That can be commercially legitimate. The provider’s task is to decide whether the scope and duration are proportionate to the commitment received.

Price the option being surrendered, not just today’s receipts

Exclusivity is particularly difficult to value when potential alternative buyers are uncertain. A forecast that assumes every theoretical counterparty will sign will overstate the opportunity cost of exclusivity, while treating additional counterparties as impossible will understate it. Management can instead assign scenario probabilities, document outreach and delivery expenses, and compare risk-adjusted contributions. A non-exclusive proposal with four plausible counterparties is not equivalent to four signed contracts; exclusivity may still reduce sales effort, administration and leakage risk. It might also create dependence on a single buyer whose changing strategy determines the asset’s future earning potential.

The boundary should be testable at contract level. A licence restricted to one equipment family, geography and model-evaluation task can preserve options for other uses, provided the underlying rights allow those separate licences. A broad restriction on 'any AI development' might unintentionally block the provider's own analytics and partnerships. Finance and legal reviewers should agree on the activity restrictions before they debate the exclusivity premium.

4. Compare total economics, not the headline fee

A headline payment is only one part of the commercial result. Preparing a reliable package may require extraction, schema mapping, deduplication, redaction, annotation, validation, documentation, secure transfer, legal review and ongoing refreshes.

A simple contribution model is:

Net contribution = licence and service receipts − preparation − legal/security − delivery/support − refresh − expected remediation

Use the model to expose assumptions, not to manufacture a market price. The costs may differ sharply between a one-off, de-identified historical sample and a frequently refreshed feed that requires ongoing quality controls.

Cost-and-value checklist

Exhibit 4. Cost-and-value due-diligence checklist

A deal can have positive revenue but negative contribution if preparation and service obligations are underestimated. A buyer may also value a narrow, well-documented sample more than a larger archive that is difficult to interpret or cannot be safely used. Size alone does not establish commercial value.

Separate training, evaluation and product rights

When a buyer says “we need the data for model development,” ask which stage is intended:

1. Training: changing model parameters or behaviour using examples.
2. Evaluation: measuring a model against held-back examples or reference answers.
3. Retrieval: making records available to a system at answer time without necessarily training model parameters on them.
4. Product deployment: exposing the model or retrieved information to employees, customers or the public.
5. Improvement and refresh: using later records, corrections or feedback to change the model or service.

These activities may have different retention periods, security requirements and downstream effects. The contract should describe treatment of source files, working copies, annotations, evaluation sets, checkpoints and other outputs as specifically as practical.

Do not assume that contract language can make every retained artefact technically removable on demand. If deletion, withdrawal or unlearning is important, establish in advance what is technically feasible, which copies or derivatives are covered, how the parties will verify completion, and what exceptions may apply.

Provider’s pre-signature diligence

A provider should be able to answer these questions before granting a licence:

• Scope: Which specific records, fields, versions and future updates are included?
• Purpose: Are training, evaluation, retrieval, internal analysis and customer-facing use separately addressed?
• Recipients: Which legal entities, affiliates, contractors or service providers may access the data?
• Downstream rights: May the buyer sublicense, redistribute, publish examples or offer derived datasets?
• Model and output treatment: What is permitted for checkpoints, embeddings, annotations, benchmarks and outputs?
• Exclusivity: Is it exclusive, sole or non-exclusive—and exactly within what boundary?
• Security: What controls, access logs, incident notices and audit evidence are required?
• Retention: When do active data, backups and working copies have to be deleted or returned?
• Change management: How are corrections, new versions and schema changes communicated?
• Assurances: Which statements about rights, quality and provenance can the provider substantiate?
• Economics: Are preparation, refreshes, support and remediation separately priced or included?
• Exit: What happens on expiry, termination, breach, withdrawal or a material change in the data?

A data-sharing agreement is not a substitute for a lawful basis, privacy analysis or appropriate security. The ICO notes that controller-to-controller sharing and controller-to-processor arrangements have distinct responsibilities. The parties should establish the actual roles and obligations before transfer. ICO: data sharing agreements

5. A practical decision framework for the deal room

Step 1 — Define the asset boundary

Write down what is included: fields, date range, source systems, data dictionary, documentation, annotations, refreshes and any derived material. Identify what is excluded, particularly records subject to third-party restrictions or unnecessary sensitive fields.

Step 2 — Map authority and restrictions

For each material source, identify who supplied or created it, which agreements govern it, and what permissions the provider can grant. Separate ownership of a database or protected work from mere possession of records. Rights differ by jurisdiction and subject matter; obtain legal advice where the position is uncertain.

Step 3 — Specify uses as operational verbs

Replace “AI use” with a list such as evaluate, train, fine-tune, retrieve, display, share with contractors, retain, refresh and commercialise outputs. For each verb, identify the relevant data, product, recipient and time period.

Step 4 — Choose the access and licence model

Decide whether the buyer receives a copy, gets controlled access, or receives a service or derived output. Then state whether the permission is exclusive, sole or non-exclusive and define its boundaries.

Step 5 — Cost the obligations and calculate the trade-off

Estimate preparation, security, legal, support and refresh work. Model the value of the fee and any foregone opportunities under explicit scenarios. Treat uncertain future buyers or revenue as scenarios—not guaranteed income.

Step 6 — Set controls, evidence and exit terms

Specify security, permitted onward access, retention, deletion, audit or reporting, correction handling, incident response and termination. Define what happens to copies and derivatives, and avoid promising outcomes the provider cannot verify.

Step 7 — Stop or narrow the deal if a critical permission is missing

A deal should be paused or narrowed if the provider cannot establish authority for the contemplated use, cannot meet a material privacy or confidentiality obligation, cannot explain the data sufficiently for safe use, or cannot perform a key operational commitment.

Red flags worth escalating

• “All data, all purposes, forever” language without an informed assessment of rights and future options.
• Broad exclusivity with no minimum payment, launch deadline or performance condition.
• An undefined right to sublicense or share with “partners” and affiliates.
• A blanket promise that all records are anonymous, complete, error-free or fully owned, without evidence.
• A deletion or unlearning promise that has not been tested against backups, checkpoints and downstream copies.
• A fee that ignores extraction, documentation, refresh, security and support costs.
• An evaluation grant that does not protect test-set independence.
• A data specification so vague that neither party can identify what was actually delivered.

Executive takeaway

A licence is not automatically safer than a sale, and a sale is not automatically broader. What matters is the rights chain, the permitted-use scope, the downstream treatment of copies and outputs, the operational burden and the options the provider gives up.

Before signing, be able to explain—in plain language—what the buyer can do, what it cannot do, how the permission ends, and how the provider will know that the agreement has been followed. The contract should then make those boundaries precise with qualified legal advice appropriate to the jurisdictions and data involved.