How AI Data Licensing Works

An AI data license sets out what a buyer can do with the material you provide. For code, that might include source files and project history. For training tasks, it can also cover instructions, answers, scoring code, and access to working software.

A license grants permission to use rights you hold; an assignment transfers ownership of specified IP rights. WIPO explains this distinction.

At HUD, we build tools for these tasks and environments. The agreement needs to fit how the buyer will use each part. These are the questions to discuss with the buyer and your legal adviser before delivery.

List what is included

Start with the parts of the package and the rights that apply to each. Permission to share one part may not cover everything else. Review ownership, privacy, confidentiality, and security before sharing a sample or the full package.

Part of the package	Question to answer
Code and documents	Who owns them, and what terms apply to work from others?
Tasks and reference answers	Can the buyer train on them, test models with them, or both?
Scoring and runtime software	Can the buyer copy, change, or host it?
Inputs and test data	Are the planned uses and changes allowed?
Agent logs	Who can keep, share, or train on records of the agent's actions?
Updates and new tasks	Are they included in the price or ordered separately?

The answers can differ across the package. For example, a buyer might be allowed to run an environment and train on the logs it produces, with limits on sharing the source files.

Example of a task license

Imagine a task that asks an agent to fix a spreadsheet formula. The package includes a workbook, instructions, a reference answer, and code that checks the changed cells. It also includes the software used to open and edit the file.

Walk through what the buyer needs at each step. Can it copy the workbook into its own training system? Can it change the task to create new versions? Can it store the agent's actions and use those records for training? Who may inspect the reference answer?

The workbook may have a different owner from the scoring code. The software used to open it may have its own license. List those parts so the agreement can account for each one.

This exercise helps both sides spot gaps before delivery. A buyer may be able to run a task while still needing separate permission for another planned use. Writing down the full path makes that conversation easier than relying on a broad phrase like “AI training rights.”

Define allowed uses

Ask whether the buyer plans to train a model, fine-tune it, test it, create examples, or build new environments. Discuss use in commercial products, access by related companies or contractors, and permission to license the material to others.

Track which tasks have been used for training. Once a model has trained on the answers, those tasks may no longer provide a fair test of how it handles new work. Keep task versions and their uses clear in both the records and the agreement.

Set delivery requirements

For an archive, a file list can help confirm that everything arrived. A working environment also needs setup steps, software requirements, a starting state, and a way to check that it runs.

Agree on a few test runs, known limits, and how the buyer should report problems. Decide who pays for hosting, model use, maintenance, and fixes needed after software changes. Set the payment dates and any acceptance conditions that trigger payment. A one-time fee should have a clear boundary around future work.

DataVendor's buying guide explains how delivery differs. Repositories and bundles are downloaded. Buyers copy HUD tasksets and their environments into their team. Account for that delivery method when deciding who does what.

Agree on acceptance checks

A buyer needs a way to confirm that the package works as promised. Pick a small set of checks and record the version used. The same inputs and setup should give both sides a useful basis for discussing the result.

For the spreadsheet example, the checks could cover opening the file, applying a known correct change, and confirming that the scorer gives it credit. A known wrong answer should fail. Also check that the task starts with a fresh workbook each time, so one attempt does not change the next.

Keep package checks separate from promises about model performance. An environment can work as described even if a buyer's model struggles with the task. If the deal includes a performance target, define the model, settings, task set, and measurement before accepting it.

Agree on how the buyer will report defects, how long you have to respond, and which changes are included. That gives both sides a clear path if the setup works differently on the buyer's system.

Set rules for exclusivity and expiry

An exclusive license can limit sales to other buyers. The limit might cover a certain use, period, or version. Price it with those lost options in mind. A non-exclusive license can leave room for more deals, but does not guarantee them.

Agree on how long access lasts and what the buyer may keep afterward. Include copies, new datasets, and trained models. Ending access to files does not automatically undo earlier model training, so address that in the terms.

Plan updates

Working software changes over time. A new library version can alter setup, and a change to a scoring rule can alter results. Give each delivered task set and environment a version so the buyer knows what it is running.

Say whether the price covers a fixed release or future updates. If updates are included, define how often they arrive and what kinds of changes they cover. Adding a new subject area or rebuilding the environment for another tool can be a separate project.

When you change a task, explain why. A correction to a wrong answer key matters differently from a new task added to the collection. Keep enough history for the buyer to understand whether earlier results need to be reviewed.

Also decide how old versions will be handled. The buyer may need to repeat a past run, while you may be able to support only the latest release. Settle that expectation in the delivery plan instead of leaving it for a future support request.

Keep the license and delivery record linked to the version they cover. If you later add new source data or third-party software, check whether the same rights still apply before including it in an update. A technical change can also change what you are able to promise the buyer.

Prepare the agreement

Write a short delivery plan alongside the proposed price and license terms. List the parts included, allowed uses, checks, support, and anything left out. This gives the buyer and your legal adviser a clear starting point.

To offer a prepared package, create a DataVendor listing. To build and review the environment itself, explore HUD.

Frequently Asked Questions

What does an AI data license cover for training tasks?

Can different parts of a package have different rights?

Yes. Permission to share one part may not cover everything else. For example, a buyer might be allowed to run an environment and train on the logs it produces, with limits on sharing the source files.

Why track which tasks have been used for training?

Once a model has trained on the answers, those tasks may no longer provide a fair test of how it handles new work. Keep task versions and their uses clear in both the records and the agreement.

Should acceptance checks include model performance?

Does ending a license undo model training?

Ending access to files does not automatically undo earlier model training, so address that in the terms. Agree on how long access lasts and what the buyer may keep afterward, including copies, new datasets, and trained models.