Dataset Licensing and Ownership for Robot Demonstration Data

A robot demonstration is an odd artefact. It is part video, part sensor log, part human labour. When you record one episode on an SO-100, the file that lands on disk holds camera frames that behave like photographs, joint angles that behave like measurements, and a language instruction somebody typed. Copyright treats those three things very differently. The licence tag stamped on the repository treats them as one thing. That gap is where commercial robot-learning projects get hurt, usually about six months after the policy finally started working and somebody in legal asked where the training data came from.

This is a checklist for what you have to verify before you fine-tune a policy you intend to sell, deploy on a customer site, or ship inside a product. Everything below was checked against primary sources on 23 August 2026: LICENSE files in the repos, the YAML front matter on Hugging Face cards, the papers themselves, and the licence documents. Where upstream and a mirror disagree, I say so and give you the command to re-check, because these tags move without announcement.

What is actually protectable in a robot dataset

People argue about robot data licences as if a dataset were one work with one owner. A LeRobot dataset is a stack of layers with different legal weight, and the layer that carries the most risk is usually the one nobody thinks about: the video. A trajectory of joint angles is a measurement of a physical process. A frame from a wrist camera is a picture, and pictures are the classic subject matter of copyright. If your kitchen-manipulation dataset happens to include a person's face, a competitor's product on the shelf, or a customer's factory floor, the video layer is where that lands.

You inherit three licences, not one

Every training run pulls in three separate grants, and they are almost never the same grant. Confusing them is the most common mistake in this area, and it is an easy one to make because the repository that holds the code usually also links the weights and the data.

• The trainer code. Apache-2.0 for lerobot, Apache-2.0 for Isaac-GR00T, Apache-2.0 for openpi, MIT for the original ACT repo. This layer is almost never the problem.
• The base checkpoint. A separate artefact under separate terms, often set only in the card body and not in the machine-readable YAML. This is where non-commercial clauses hide.
• The dataset. Whatever the uploader declared, which may or may not match what the original authors declared.

Here is the layer-two picture for the five trainable policies as published on 23 August 2026. The trainer code column is uniform and boring. The weights column is not.

The N1.7 route is not free of obligations either. The NVIDIA Open Model License requires that anyone distributing the model gives recipients a copy of the agreement and includes the attribution notice "Licensed by NVIDIA Corporation under the NVIDIA Open Model License" in a Notice text file. In exchange, the ownership clause says that, subject to NVIDIA's underlying rights in the model, you are the owner of your derivative models, and that NVIDIA claims no ownership rights in outputs. Two caveats worth reading before you rely on it: the grant is revocable on the conditions in the agreement, and NVIDIA reserves the right to update the terms, at which point you comply or stop distributing. See the N1.7 against N1.5 comparison for what else changed between the two.

Pi0.5 has a different shape of obligation. The LeRobot checkpoint builds on a PaliGemma backbone, PaliGemma is listed in the appendix of the Gemma Terms of Use, and the card declares license: gemma. Those terms are contractual rather than a bare copyright licence. Section 3.1 says that distributing a model derivative means passing on a copy of the agreement, carrying the section 3.2 use restrictions through as an enforceable provision in your own downstream terms, marking modified files, and shipping a Notice file pointing at the Gemma terms. If you plan to hand the Pi0.5 checkpoint to a customer rather than serve it yourself, that flow-down clause is real work for your contracts team, not a formality.

When the licence changes under you

The GR00T family is the live example of why a licence audit has a date on it. The N1.5 and N1.6 cards both point at the OneWay Noncommercial PDF. N1.7 points at the Open Model License. Same vendor, same architecture family, same naming scheme, three model cards, and two different answers to the only question a product team cares about. Nothing announced the change; a Hugging Face card is a git repo and the licence line is a commit. The answer you got is an answer about a revision on a date, not a permanent property of the model. Google works the same way: the Gemma Terms of Use carry a last-modified date, 1 April 2026 at the time of writing, and the page links an archive of the previous versions.

The fix is to pin. Every Hub repo is git, and both the CLI and from_pretrained accept a revision, so the card you audited can be the card you actually train against. Record the commit sha alongside the licence finding and a release review becomes a diff instead of an investigation.

# pin the exact revision you audited, and store the sha with your findings
hf download nvidia/GR00T-N1.7-3B README.md \
  --revision 2fc962b973bccdd5d8ce4f67cc63b264d6886495 --local-dir ./cards/n17

hf download cadene/droid README.md --repo-type dataset \
  --revision c8fbc029c9786fd4377ea20d9535e86d88199c0f --local-dir ./cards/droid

# before a release, diff the current card against the one you cleared
hf download nvidia/GR00T-N1.7-3B README.md --local-dir ./cards/n17-now
diff ./cards/n17/README.md ./cards/n17-now/README.md

What DROID, Open X-Embodiment and BridgeData V2 actually say

These three are the datasets people reach for when they want scale beyond their own recordings. We have written up what is inside each one elsewhere: DROID, Open X-Embodiment and BridgeData V2. This section is only about the paperwork. Two of the three have a clean, single, quotable licence. One does not, and it is the biggest.

The Open X-Embodiment row is the one to read twice. OXE is not a dataset with a licence; it is a registry that pooled 60 pre-existing datasets from 34 labs, each released by its own authors under its own terms. The repo's blanket CC-BY line covers the materials Google DeepMind itself published. I exported the official dataset spreadsheet linked from that README as CSV and read the header row: 21 columns covering robot, episode count, file size, morphology, gripper, action space, camera counts, language annotations, collection method, scene type, control frequency, registered dataset name, citation and description, over 72 dataset rows. There is a Citation column. There is no licence column. If you want to know whether a specific OXE component permits commercial training, you go to that component's own paper and repo, one at a time, for as many of those 72 rows as your mixture touches. Even the headline counts disagree between official sources: the project site says 60 datasets from 34 robotic research labs, while the paper abstract says 22 robots collected through a collaboration between 21 institutions.

The mismatch is not only in the tag. cadene/droid describes itself as DROID ported from the TensorFlow Dataset format to LeRobot format, and its meta/info.json reports 92,233 episodes and 27,044,326 frames at codebase_version v2.1, against the 76k demonstration trajectories the paper describes. A repo id containing the word droid therefore does not tell you which slice of DROID you have. "We trained on DROID" is not a provenance record; the repo id plus the commit sha is.

The Apache-2.0 default nobody chose

There is a mechanical reason the ecosystem is full of apache-2.0 data. Look at the signature of the upload helper in lerobot 0.6.2, in src/lerobot/datasets/lerobot_dataset.py. The licence is a keyword argument with a default, and almost nobody passes it.

# lerobot 0.6.2, src/lerobot/datasets/lerobot_dataset.py
def push_to_hub(
    self,
    branch: str | None = None,
    tags: list | None = None,
    license: str | None = "apache-2.0",   # <- this is the default
    tag_version: bool = True,
    push_videos: bool = True,
    private: bool | None = None,
    allow_patterns: list[str] | str | None = None,
    upload_large_folder: bool = False,
    **card_kwargs,
) -> None:

You can watch the effect at scale. Paging the Hub API for datasets filtered on LeRobot and counting the license tag on each repo gives this distribution over the first 12,000 results returned on 23 August 2026. This is a measurement, not a published statistic, and the script in the audit steps below reproduces it.

Two conclusions follow. First, an apache-2.0 tag on a LeRobot dataset carries close to zero information about what the uploader intended, because it is what the tool writes when the uploader intends nothing. Second, Apache-2.0 is a software licence being asked to do a data job: it grants copyright and patent licences and never mentions the sui generis database right, which is exactly the right that attaches to a large curated collection of episodes. CC-BY 4.0 does cover it. Section 4 of its legal code extends the grant to sui generis database rights and requires the same attribution conditions when you share a substantial part of the contents. If you are publishing rather than consuming, that difference is the main argument for cc-by-4.0, odc-by or cdla-permissive-2.0 over the default, and all three are valid Hub identifiers. The mechanics are in our guide to collecting high-quality VLA training data.

Auditing a repo before you spend money on a GPU

The audit is short and worth doing before every run that has a commercial destination. Read machine-readable metadata rather than the rendered page, follow each licence to its actual text, and write down what you found next to the checkpoint so the answer survives the person who ran the job.

1. 1
   Read the card metadata, not the web page

   The rendered card can show a licence chip that came from prose, or show nothing while the body text carries the real terms. Query the API instead. Both GR00T cards return None here and state their terms only in the body.

   python

   from huggingface_hub import HfApi
   api = HfApi()
   
   def audit(repo_id, repo_type="dataset"):
       info = (api.dataset_info(repo_id) if repo_type == "dataset"
               else api.model_info(repo_id))
       card = info.card_data or {}
       return {
           "repo": repo_id,
           "license": card.get("license"),
           "license_name": card.get("license_name"),
           "gated": info.gated,
           "last_modified": str(info.last_modified),
           "sha": info.sha,
       }
   
   for r, t in [("cadene/droid", "dataset"),
                ("KarlP/droid", "dataset"),
                ("IPEC-COMMUNITY/bridge_orig_lerobot", "dataset"),
                ("nvidia/GR00T-N1.7-3B", "model"),
                ("nvidia/GR00T-N1.5-3B", "model"),
                ("lerobot/pi05_base", "model"),
                ("lerobot/smolvla_base", "model")]:
       print(audit(r, t))

2. 2
   Pull the raw card and read the body

   A null in the license field does not mean permissive. Download the README and grep it before you conclude anything.

   bash

   hf download nvidia/GR00T-N1.5-3B README.md --local-dir ./cards/n15
   hf download nvidia/GR00T-N1.7-3B README.md --local-dir ./cards/n17
   grep -in -A3 'licen\|commercial' ./cards/n15/README.md ./cards/n17/README.md

3. 3
   Follow the licence link and read the operative clause

   Licence names are marketing; clauses are binding. For the NVIDIA noncommercial PDF the operative sentence is section 3.3 and it takes thirty seconds to find.

   bash

   curl -sL -o nv_nc.pdf \
     https://developer.download.nvidia.com/licenses/NVIDIA-OneWay-Noncommercial-License-22Mar2022.pdf
   pdftotext -layout nv_nc.pdf - | grep -n -A4 'Use Limitation'

4. 4
   Find the upstream original behind a mirror

   LeRobot conversions almost always name the dataset they were converted from, even when they relabel the licence. cadene/droid says "Ported from Tensorflow Dataset format" and links the DROID paper and homepage. That is your route back to the real terms.

   bash

   hf download cadene/droid README.md --repo-type dataset --local-dir ./cards/droid
   grep -in -B2 -A8 'Ported from\|Paper:\|Homepage:' ./cards/droid/README.md

5. 5
   Reproduce the ecosystem-wide picture yourself

   The 91.1 percent figure above is not published anywhere. It is a count over the Hub API, so re-run it rather than trusting the number in this article.

   python

   import json, re, urllib.request, collections
   
   url = ("https://huggingface.co/api/datasets"
          "?filter=LeRobot&limit=1000&expand[]=tags")
   cnt, n = collections.Counter(), 0
   while url and n < 12000:
       with urllib.request.urlopen(url, timeout=90) as r:
           page, link = json.load(r), r.headers.get("Link", "")
       for x in page:
           n += 1
           lic = [t.split(":", 1)[1] for t in x.get("tags", [])
                  if t.startswith("license:")]
           cnt[lic[0] if lic else "<none>"] += 1
       m = re.search(r'<([^>]+)>;\s*rel="next"', link)
       url = m.group(1) if m else None
   
   for k, v in cnt.most_common():
       print(f"{k:16s} {v:6d}  {v / n * 100:5.2f}%")

6. 6
   Write the answer down next to the data

   Six months later nobody remembers which repo id the run used. A two-minute file beats a two-week reconstruction. Keep it in the dataset folder so it travels with the data.

   bash

   cat > meta/PROVENANCE.md <<'EOF'
   source_repo:      cadene/droid
   source_sha:       c8fbc029c9786fd4377ea20d9535e86d88199c0f
   source_tag:       apache-2.0        # tag on the mirror
   upstream:         DROID, arXiv:2403.12945v2
   upstream_licence: CC-BY 4.0         # what the authors actually released
   attribution:      Khazatsky et al., DROID, CC-BY 4.0
   checked_on:       2026-08-23
   checked_by:       <your name>
   commercial_use:   permitted, attribution required
   EOF

pip install "lerobot[smolvla]"

# 1. what does the mirror claim
hf download cadene/droid README.md --repo-type dataset --local-dir ./audit/droid
head -20 ./audit/droid/README.md      # license: apache-2.0

# 2. what do the base weights claim
hf download lerobot/smolvla_base README.md --local-dir ./audit/smolvla
head -20 ./audit/smolvla/README.md    # no license field as of 2026-08-23

# 3. train, once you are satisfied with both answers
lerobot-train \
  --policy.path=lerobot/smolvla_base \
  --dataset.repo_id=<your-org>/<your-dataset> \
  --output_dir=./outputs/smolvla_run

Data you record yourself, and who owns it

The clean path is to own the data outright. Thirty episodes for SmolVLA and fifty for the other four is the documented minimum on this platform, which is a day of teleoperation rather than a research programme, and recording your first dataset is a solved problem. Own data also sidesteps the hardest question in public robot data, which is not the licence but the provenance: you know what is in frame, you know who was standing there, and you know what the task label means.

Ownership of self-recorded data is a contract question, not a copyright question, and it has at least three parties. The operator who drove the arm produced the motion. The owner of the arm and cameras produced the recording. The platform that carried the session holds a copy. Copyright will not sort that out for you, because the interesting rights here are the database right in the collection and whatever the parties agreed in writing. If you run remote operators, whether through an operator programme or your own contractors, the assignment clause in that agreement is the document that decides who can license the resulting dataset. Get it in writing before the first session, not after the dataset is worth something.

One more piece of paperwork worth knowing. The Hugging Face Terms of Service, effective date 15 September 2022, say plainly that you own the content you create. But publishing to a public repo grants every other user a perpetual, irrevocable, worldwide, royalty-free, non-exclusive licence to use, display, publish, reproduce, distribute and make derivative works of your content through the Hugging Face services. That is the deal you accept when you push a dataset public, and it is irrevocable in the terms' own wording. Deleting the repo later does not unwind what people already pulled, so decide before the push. One clause cuts the other way: where content carries notice of a reasonable and customary licence, such as an open source licence, the terms say it is intended to remain under that licence and that neither party may remove the reference to it. A LICENSE file and an explicit card tag are worth writing even on a public push. The practical mechanics are covered in our data collection guide and in the platform's dataset documentation.

Does a trained policy inherit the dataset's licence?

This is the question everyone actually wants answered, and the honest reply is that it is unsettled and the two halves behave differently. Model weights are not a copy of the training data, so the copyright chain from a CC-BY dataset to a set of weights is weak. Creative Commons said as much in its own May 2025 legal primer: AI training is often permitted by copyright, which means CC licence conditions have limited application to machine reuse. If that reasoning holds, training on CC-BY data does not by itself make your checkpoint a licensed derivative that must carry attribution.

Contract-style model licences are a different animal. The NVIDIA agreements and the Gemma Terms of Use bind you because you accepted them to get the weights, not because copyright reached your output. Both define derivative models broadly enough to cover fine-tuning, and both say what you must do when you distribute one. Those obligations do travel. In practice this splits cleanly: dataset licences are a moderate risk you mitigate with attribution, and weight licences are a hard constraint you either satisfy or design around.

The checks that actually block a commercial policy

Reduced to the questions that have changed a shipping decision in practice, in the order they tend to bite:

• Is the base checkpoint non-commercial? This is the only item on the list that is a flat no rather than a condition. The GR00T N1.5 and N1.6 cards both link the OneWay Noncommercial licence; N1.7 does not.
• Does the weight licence flow down to your customer? Gemma-derived checkpoints require you to pass the agreement and the use restrictions on to recipients. If you ship weights rather than an API, that is a contract change.
• Did you verify the upstream licence, or the mirror's tag? Two of the most-downloaded LeRobot conversions disagree with their own upstream.
• For Open X-Embodiment mixtures, which components did your mix actually touch? There is no blanket answer, and no licence column in the official spreadsheet.
• Is a person identifiable in any frame? Video of an identifiable individual is personal data under the GDPR regardless of the dataset licence, and no licence tag fixes it.
• Is a customer's site, product or process visible? This is usually an NDA question, and NDAs do not care what licence you attached.
• Can you name the repo id and revision the run trained on? If not, you cannot answer any of the above later.
• Does anyone outside engineering know the answer? An audit nobody can find is an audit that did not happen.

What a clean re-run costs

The reason to run this audit before training rather than after is that the fix is cheap while it is still a training problem and expensive once it is a shipping problem. On this platform a run on the A100 or H100 tier, which is what GR00T N1.7, GR00T N1.5 and Pi0.5 need, takes 3 to 6 hours at 1.20 to 2.00 USD per hour, so roughly 4 to 12 USD. A SmolVLA or ACT run on a 24 GB card takes 2 to 5 hours at 0.30 to 0.60 USD per hour, so roughly 1 to 3 USD. Re-training on a differently licensed dataset, or switching from N1.5 to N1.7 because the product plan changed, is a rounding error against one hour of legal review. Current figures are on the pricing page.

If the licence question is genuinely blocking and you need something shippable, the pragmatic order is: train ACT on your own SO-100 recordings, because imitation learning from scratch inherits no weight terms at all and your own data inherits no dataset terms. It gives up the generalisation you get from a vision-language-action model pretrained on a million trajectories, and for a single well-defined task on a fixed setup that trade is often acceptable. When it is not, GR00T N1.7 with a Notice file is the next cleanest step up. The ACT against GR00T N1.7 comparison has the performance side of that trade.