A dataset can be technically excellent and still useless to anyone outside the lab that made it — either because nobody settled who's allowed to use it, or because nobody can tell what it actually is. The first problem is licensing. The second is provenance. They get conflated constantly, but they fail independently: a well-licensed dataset with no provenance record is a legal green light pointing at a black box, and a well-documented dataset with no license is a black box someone can't legally open at all. This guide covers both, deliberately, as separate problems with separate fixes. None of it is legal advice — for a specific release, get counsel.
Who owns the data you just collected
Before the ownership question is a licensing question, it's a contracts question. Robot demonstration data is usually produced by someone other than the entity that ends up wanting to release or monetize it — a contracted operator, a partner lab, a crowdsourced workforce — and the default legal assumption about who owns work product varies by jurisdiction, by employment classification, and by whether anything was signed. Assuming you own data because you own the robot, the software, or the storage bucket is not a safe assumption anywhere.
A collection agreement worth having in place before the first session states, explicitly:
- Who owns the resulting data — the collecting organization, the operator, or something shared.
- What license-back rights the operator or partner retains, if any.
- What uses are permitted — internal training only, public release, commercial resale, or all three.
- What happens to identifiable content — an operator's own image or voice, if a session captures either.
This is unglamorous paperwork that pays for itself exactly once: the day someone wants to publish, sell, or license out a dataset and discovers the ownership chain has a gap in it. Fix it before recording, not after the dataset has become valuable enough for the gap to matter.
Choosing a license for a public release
For datasets you intend to publish, the Creative Commons suite covers most practical cases, and the choice communicates something real to downstream users.
| Permissive | Copyleft / restrictive | |
|---|---|---|
| CC0 | Public-domain dedication; no attribution required, no restrictions | |
| CC BY 4.0 | Reuse and adapt freely; attribution required | |
| CC BY-SA 4.0 | Reuse and adapt freely; derivatives must carry the same license | |
| CC BY-NC | Non-commercial use only — excludes most industry reuse |
CC BY 4.0 is the common default for research releases because it maximizes reuse while still requiring credit — most of the constituent datasets in Open X-Embodiment, the largest public robot manipulation aggregation, use it. CC0 goes further and waives even attribution, which some funders and open-science initiatives require outright. CC BY-SA is worth choosing deliberately if you want a dataset's derivatives and extensions to stay open rather than getting incorporated into a closed downstream release.
Apache-2.0 is a different category of license entirely — it's a software license, with explicit patent grant and notice-file requirements built for source code, not for data. It doesn't address the sui generis database rights that apply to datasets in some jurisdictions the way Creative Commons licenses are written to. Use Apache-2.0 for the loader scripts, conversion tools, or SDKs you ship alongside a dataset; use a Creative Commons license for the dataset itself. Mixing the two — Apache-2.0 code, CC-BY-4.0 data — is standard practice and worth stating explicitly in both the repo and the datasheet rather than leaving one license to be assumed to cover both.
License is not provenance
A permissive license answers "am I allowed to use this." It says nothing about what the data actually is, how it was produced, or whether it means what its documentation claims. Those are provenance questions, and a dataset needs both answers independently. A CC0-licensed dataset with no provenance record is legally free to use and practically unusable for anything that requires trusting the data — which is most robot learning applications, where an episode's validity depends entirely on the sensing and calibration configuration that produced it.
What a provenance record must contain
At minimum, a provenance record needs enough detail that someone outside your lab could judge whether a given episode is comparable to another one, or whether a policy trained across two collection batches is learning a real task or an artifact of a calibration drift between them:
- Rig
- Arm, gripper, and sensor models plus a serial or rig identifier
- Calibration
- A content hash of the calibration file, not just a filename, plus calibration date
- Firmware
- Controller and any embedded microcontroller firmware versions
- Operator cohort
- Who collected the data — internal team, contracted operators, crowdsourced — and how many distinct operators
- Protocol version
- Which version of the collection protocol or task instructions was in force
- Collection dates
- Start and end dates per batch, not just a single dataset-level date
- Consent basis
- What operators and any incidentally captured people agreed to, and under what terms
For the full mechanics of turning this into a versioned, content-addressed record — shard-level hashing, immutable release tags, and a machine-readable manifest a loader can validate against — see Reproducible Robot Datasets: From Capture to Citation, which walks through the manifest format in detail rather than repeating it here.
Datasheets for datasets
Gebru et al.'s "Datasheets for Datasets" (Communications of the ACM, 2021) proposed a standard question set — motivation, composition, collection process, recommended uses, distribution, and maintenance — answered once and shipped alongside a dataset, modeled on the datasheets that accompany electronic components. Answer it with the ownership and licensing decisions from this guide already resolved, so a reader doesn't hit a distribution question the datasheet can't actually settle. A generic answer to "composition" or "collection process" also undersells a robot dataset specifically — row counts don't tell a reviewer what sensors or control rate produced the data, and "who collected this" without rig and calibration detail leaves the provenance record above doing work the datasheet should be pointing back to, not repeating.
A datasheet is a prose document aimed at a human reviewer — a grant committee, a paper reviewer, a downstream team deciding whether to build on your dataset. It's a companion to the machine-readable provenance manifest, not a replacement for it: the datasheet answers "should I trust this," the manifest lets code answer "does this file match what it claims to be."
Personal data that shows up incidentally
Robot demonstration cameras record whatever is in frame, and that regularly includes people who were never the subject of the recording — an operator's hands and sometimes face, someone walking past in the background, a reflection in a metal surface. This is personal data under most privacy frameworks regardless of intent, and it needs handling before a dataset leaves the organization that collected it, let alone before public release.
Practical steps: minimize incidental capture where the task setup allows it (camera framing, workspace boundaries); run identifiable frames through face detection and blur or redact before release; disclose the practice and its limitations in the datasheet rather than asserting a dataset is "anonymized" without having verified it; and check which privacy regime applies given where the data was collected and who it's being released to. Consent from operators should cover what they're agreeing their session will be used for, in writing, at collection time — not inferred after the fact from the fact that they showed up to work.
Citing datasets like research artifacts
A dataset that gets used and never cited is a dataset that stops getting maintained, because nobody outside the immediate team has a durable incentive to keep it around. Make a public release citable the way a paper is: mint a DOI through Zenodo or the Hugging Face Hub's DOI integration, tag an immutable version so the DOI resolves to fixed bytes rather than a moving target, and publish a BibTeX entry alongside the dataset card. Combined with the provenance manifest and datasheet above, that turns a folder of recordings into something a reviewer, a grant committee, or another lab can actually build on — see for research for how this fits into an academic release workflow specifically.