Master data license with dataset schedules: structuring recurring deliveries

What is a master data license agreement?#

A master data license agreement is a framework contract that sets the legal terms for every dataset a supplier licenses to one buyer, with each dataset added through a short schedule or order form. The structure borrows from master services agreements with statements of work, adapted to records instead of services.

The framework suits suppliers who expect more than one package or more than one delivery: a software company adding later years of support tickets, a distributor sending quarterly order exceptions, a consulting firm adding project reviews after a first archive. Counsel negotiates liability, indemnity and security once, and later packages move at the speed of a scope discussion.

A single-purpose license remains the simpler choice for a one-time archive with no follow-on in view. Building a framework that never receives a second schedule only lengthens the first negotiation.

What belongs in the master and what belongs in each schedule#

The dividing line between master and schedule is stability. Terms that should not change from one dataset to the next live in the master license; terms that describe a particular package, its deliveries or its price live in the schedule.

Read the table as the contract's map. If a draft puts a schedule item in the master, every future dataset inherits it; if it puts a master item in a schedule, that protection can be renegotiated on every order.

What a dataset schedule should describe#

A dataset schedule should describe the package precisely enough that a third party could tell whether a given record is in or out. A label like customer support data invites disputes about what was promised versus what was delivered.

Published metadata standards make a useful checklist. The Data and Trust Alliance's Data Provenance Standards group dataset metadata into Source, Provenance and Use, and the Use group covers items such as confidentiality classification, consent documentation location, privacy-enhancing technologies applied and intended data use.

• 1Source systems and record families, such as Zendesk tickets linked to Jira issues.
• 2Date range, plus the cut-off rule for records still open at the boundary.
• 3Fields included, with a sample schema and approximate volume.
• 4Exclusions: named customers, client deliverables, privileged material, export-controlled items.
• 5Preparation applied: what was removed, masked or replaced.
• 6Permitted uses selected from the master definitions.
• 7Delivery method, format and cadence.
• 8Fees, payment triggers and any exclusivity, with its scope and end date.

How to structure recurring deliveries#

Recurring deliveries need rules that a first delivery never tests: what each increment contains, how changes are handled and what happens when a source system changes. Put these rules in the schedule, because cadence and content differ by dataset.

Add a schema change notice: if a field is renamed or a system is replaced, the supplier tells the buyer before the next delivery and either side can adjust or pause. Name what happens if a source system is retired mid-term, such as a final archive delivery and an early end to the schedule without penalty.

Keep a supplier right to pause any delivery over a rights or privacy concern, with fees adjusted rather than a breach declared. Each increment should pass the same release approval as the first, because new records can bring new customers, new contracts and new personal details.

Order of precedence, amendments and new datasets#

An order of precedence clause decides which document wins when the master and a schedule conflict. A supplier-friendly default is that the master controls unless a schedule expressly names the master clause it overrides, which stops a commercial order form from quietly widening permitted use or lifting a liability cap.

Define how new datasets are added: a signed schedule on the agreed form, never a click-through order or an emailed scope change. Decide whether schedules survive termination of the master; a common supplier position is that active schedules continue on master terms until they end, so a dispute over renewal does not cut off a paid delivery.

Watch cross-default. A breach under one schedule may justify suspending deliveries under all of them, but it should not automatically terminate unrelated licenses for data already delivered and paid for.

How fees and revenue timing work across schedules#

Fees work best when each schedule carries its own commercial terms: a fee per delivery, an annual license fee, or milestone payments tied to acceptance. Exclusivity, if offered at all, also belongs in the schedule with a defined scope and end date, because it is the term most likely to differ between datasets.

Revenue timing can follow the structure. Under ASC 606, revenue from a license is not recognized before the licensed IP is made available and the period in which the customer can use it begins, so revenue from a renewal is recognized no earlier than the start of the renewal period. How each schedule is treated depends on its terms, so review the structure with your accountant before signing.

Illustrative: a distributor adds schedules over time#

Illustrative: a fictional industrial distributor runs NetSuite for orders and a separate WMS for fulfillment and returns. Its first schedule covers a historical archive of order exceptions with resolution notes, delivered once from an export the operations team builds.

A second schedule, signed later, covers quarterly increments of the same record family, with a cut-off at quarter end and a rule that reopened exceptions are redelivered with a version flag. A third adds returns and credit memos but excludes two customers whose contracts restrict reuse.

When the distributor migrates its WMS, the schema change notice lets it pause one quarterly delivery, map fields to the new system and resume. None of this reopens the master license, so the general counsel spends review time on scope rather than on liability.

How SourceX structures recurring packages#

SourceX runs each dataset schedule through the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Rights and preparation work for a new schedule builds on earlier ones, but each schedule still gets its own review because records, customers and contracts change.

Each package that proceeds is documented in a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization. The supplier approves every step, including each recurring release, so a signed schedule does not turn into automatic sharing.