How to Describe Dataset Reuse Rights

A license is necessary but not sufficient. Attaching “CC-BY 4.0” to a dataset record tells a reuser which permissions apply in general terms, but it doesn’t, on its own, make those permissions easy for a human to find or for a machine to act on. Describing reuse rights well means doing three separate things: choosing the right license, stating it in a form both people and systems can read unambiguously, and putting that statement everywhere a reuser is actually likely to look. This guide covers the second and third — for the first, see CASRAI’s dedicated Creative Commons licenses for research data guide, which walks through CC0 vs CC-BY vs CC-BY-NC and why NC terms are a poor fit for most research data.

Start from a real license, stated precisely

The FAIR Guiding Principles are explicit that reusability depends on this being done properly: principle R1.1 states that “(meta)data are released with a clear and accessible data usage license,” specifically to avoid ambiguity that could “severely limit the reuse of your data by organisations that struggle to comply with licensing restrictions” (GO FAIR, R1.1). “Clear” has a specific, checkable meaning here — it isn’t enough to write “open license” or “CC” in a metadata field. A precise statement has three parts:

A standard identifier, not a paraphrase — e.g. CC-BY-4.0, not “Creative Commons” or “open.”
A resolvable URI pointing to the actual license text — e.g. https://creativecommons.org/licenses/by/4.0/.
The version number, always — CC licenses in particular carry real legal differences between versions (see CASRAI’s CC-licenses guide for why 4.0 vs 3.0 matters), so “CC-BY” without a version is genuinely ambiguous, not just informal.

The de facto standard for the identifier itself is the SPDX License List — a formally standardized (ISO/IEC 5962:2021), machine-readable set of short license identifiers, full names, license text, and canonical URLs, maintained by the Linux Foundation’s SPDX project. Pairing an SPDX identifier with its canonical URI is what most repository and metadata schemas expect in a rights field, covered next.

Machine-readable rights statements: where the “license” field actually lives

A dataset’s rights statement needs to exist as structured metadata, not just as prose on a page, if it’s going to be discoverable and machine-actionable. Three real, standardized vocabularies cover most of this ground:

DataCite’s rightsList

The DataCite Metadata Schema — the schema behind most DOI-minting research data repositories — includes an optional, repeatable rightsList property with four sub-fields: rightsURI (the URL of the license document itself), rightsIdentifier (a short standardized code, e.g. CC-BY-4.0), rightsIdentifierScheme (the naming scheme used, e.g. SPDX), and schemeURI (the URL of that scheme). DataCite’s own documentation example combines all four:

"rightsList": [
  {
    "rights": "Creative Commons Attribution 4.0 International",
    "rightsUri": "https://creativecommons.org/licenses/by/4.0/",
    "schemeUri": "https://spdx.org/licenses/",
    "rightsIdentifier": "CC-BY-4.0",
    "rightsIdentifierScheme": "SPDX"
  }
]

This is the field most open data repositories map their “select a license” dropdown into when they mint a DOI — filling it out correctly at deposit time is usually the single highest-leverage step, since it propagates automatically into DataCite’s public metadata index and, from there, into discovery tools that harvest it.

Dublin Core’s rights terms

Dublin Core Metadata Initiative (DCMI) Terms defines three distinct rights-related properties, and datasets are sometimes described with the wrong one: dc:rights is a general statement about rights held in or over the resource; dc:license specifically identifies “a legal document giving official permission to do something with the resource” (DCMI recommends identifying it by URI); dc:accessRights instead describes who is permitted to access the resource at all — a security/embargo/privacy distinction, not a reuse-permission one. A dataset under embargo with an open license afterward needs both fields populated correctly and separately: dc:accessRights describing the embargo, dc:license describing what happens once it lifts.

Journal/publisher-side precedent: NISO’s Access and License Indicators

Research data repositories didn’t invent the pattern of a machine-readable free-to-read flag plus a URI to the actual license — NISO standardized it for journal articles first. NISO RP-22-2021, Access and License Indicators (ALI), defines a free_to_read element (an access flag, separate from licensing, with optional start/end dates for moving-wall access) and a license_ref element (a URI to the actual license terms), with an applies_to attribute letting one article carry different license references for different versions or uses (version of record, accepted manuscript, text-and-data-mining rights, and the STM Article Sharing Framework). It’s formalized in the JATS Tag Library and adopted by Crossref. It’s not the schema you’d use for a dataset record directly, but the same underlying discipline — a flag for whether it’s accessible, and a separate, resolvable pointer to what you’re actually allowed to do with it — is the right mental model to bring to dataset rights metadata.

When a license alone isn’t enough: ODRL and complex reuse permissions

A single license identifier works well when the answer to “what can I do with this?” is the same for everyone. It works less well when reuse terms genuinely vary by use case — commercial vs. non-commercial reuse under different terms, different permissions for different data fields within the same dataset, an embargo that lifts on a specific condition rather than a fixed date, or a duty attached to a permission (e.g., “you may redistribute derivatives, but must notify the data provider first”). Free-text “special conditions” notes handle this for a human reader but aren’t machine-actionable.

The Open Digital Rights Language (ODRL) Information Model is the W3C’s answer to this — a W3C Recommendation (published 15 February 2018, current version 2.2), maintained by the W3C Permissions & Obligations Expression Working Group. ODRL provides a policy expression vocabulary built around three rule types: permissions (actions that may be exercised on an asset), prohibitions (actions that may not), and duties (obligations that must be fulfilled, either as a condition of a permission or a consequence of a violation). Rather than a single license flag, an ODRL policy can express a structured combination of who, what action, under what constraint, with what obligation attached.

For CASRAI’s audience, the honest framing is: ODRL is an emerging, standards-track approach for expressing reuse permissions that are genuinely more complex than “pick a license,” not yet a default expectation for a typical open dataset deposit the way a DataCite rightsList entry is. Most repositories don’t have a native ODRL-authoring interface for dataset records today. It’s worth knowing about — and worth adopting deliberately — specifically for datasets with tiered, conditional, or negotiated reuse terms (e.g. sensitive human-subjects data released under a data use agreement with specific permitted-purpose restrictions) where a single CC license genuinely can’t capture the actual terms.

A related, narrower vocabulary worth knowing for a different edge case — when copyright status itself is unclear rather than the permissions being complex — is RightsStatements.org: a standardized, machine-readable set of rights statements (available as JSON-LD, RDFa, and Turtle, each with its own resolvable URI) originally built for cultural heritage aggregation, used to flag things like “no known copyright” or “in copyright” rather than to state permissive reuse terms. It’s a good fit for datasets built from digitized historical or archival material where the rights status, not the license, is the ambiguous part.

Where to put the rights statement

The same rights information needs to appear in at least three places, because a reuser doesn’t reliably encounter a dataset the same way twice — and because file bundles and metadata records have a way of getting separated from each other over time.

Repository metadata fields, at deposit time. This is the structured, machine-actionable copy — the DataCite rightsList (or equivalent schema field) filled in with the SPDX identifier, the resolvable URI, and the scheme, not just selected from a UI dropdown and left unverified. This is also what propagates to schema.org Dataset markup on the landing page (see below) and, from there, to discovery tools like Google Dataset Search, which explicitly lists license — given as a full URL, not free text — among the properties it recommends indexing (per Google’s own Dataset structured-data documentation). See CASRAI’s Google Dataset Search guide for the full markup pattern.
The dataset landing page, visible to a human without downloading anything. A short, plain statement near the top of the page — license name, version, and a link to the full text — before a reuser has committed to downloading the files. This is also where the corresponding Dataset JSON-LD’s license property should be embedded in the page’s markup, so the human-visible statement and the machine-readable one stay in sync rather than drifting apart.
The README bundled with the data files themselves. Files get copied, mirrored, and shared independently of their original landing page — a README travels with the actual files in a way a web page doesn’t. Cornell Data Services’ guidance on writing dataset READMEs recommends stating the license explicitly within the file itself, alongside the other minimum contents (a dataset overview, file list, and variable definitions) — see Cornell’s README guidance for a fuller template. Repeating the license here is deliberate redundancy, not duplication for its own sake: it’s the one copy of the rights statement guaranteed to still be attached to the data if everything else gets separated from it.

Keep the three copies word-for-word consistent — same identifier, same version, same URI. A README that says “CC-BY” while the repository record says “CC-BY-NC” is worse than no license statement at all, because it forces a reuser to guess which one is authoritative.

Common mistakes

Naming a license without a version or URI. “CC-BY” alone doesn’t specify which version’s terms actually apply.
Conflating access rights with reuse rights. “Free to download” (an access question) and “free to reuse, adapt, and redistribute” (a license question) are different claims — stating one doesn’t imply the other, and DCMI’s dc:accessRights vs dc:license distinction exists precisely to keep them separate.
Putting the license only in the metadata record, not in the README. Once files are copied out of the repository, the metadata record’s statement doesn’t travel with them.
Using a non-conformant “open” license for data that’s meant to be genuinely open. The Open Definition explicitly excludes CC-BY-NC from its list of conformant licenses — see CASRAI’s CC-licenses guide for why NC terms undermine most research-data reuse cases.
Reaching for a complex ODRL policy when a plain license would do. Complexity is only worth the overhead when reuse terms genuinely vary by use case or user — for a straightforward openly-licensed dataset, a correctly filled-in rightsList entry is the right amount of machinery, not an under-implementation of the standard.

Frequently asked questions

Is a license statement the same as a rights statement?

Not quite. A license is one specific, common way of expressing reuse rights — a pre-written, standardized bundle of permissions (like CC-BY). “Rights statement” is the broader category, which can also cover access restrictions, embargoes, unclear copyright status, or the more granular, conditional permissions ODRL and similar vocabularies are built to express. Most datasets only need a plain license; some need the broader vocabulary.

Do I need to use ODRL to describe reuse rights for my dataset?

No, not for most datasets. A correctly stated open license — SPDX identifier, version, resolvable URI, in the repository’s rightsList-equivalent field, on the landing page, and in the README — covers the large majority of research data deposits. ODRL is worth adopting specifically when reuse permissions genuinely vary by purpose, user category, or condition in a way a single license can’t express.

Where should the license actually be selected — at data collection time, or at deposit?

Ideally decided (or at least anticipated) as part of the data management plan, before collection — funder and institutional data ownership terms, any third-party or human-subjects data restrictions, and co-author agreement all affect which license is even legally available, and are far harder to resolve retroactively at deposit time. See CASRAI’s DMP worked examples and the Data Management Plan dictionary term.

What if my dataset can’t be openly licensed at all (e.g. sensitive data)?

State that clearly and specifically rather than omitting a rights section — describe the actual access mechanism (data use agreement, controlled-access repository, IRB-approved request process) using dc:accessRights-style language, distinct from any reuse-permission statement. This is exactly the case where a structured, conditional approach (ODRL, or a repository’s own controlled-access metadata fields) does real work that a single license identifier can’t.

Related CASRAI resources

Creative Commons licenses for research data: CC0 vs CC-BY vs CC-BY-NC — choosing the license itself
How to choose a metadata schema for a dataset
Making datasets discoverable via Google Dataset Search
How to make your dataset FAIR: a step-by-step checklist
How to cite a dataset: a practical guide with real examples
Reuse license (dictionary term)
Data availability statement (dictionary term)
NISO Access and License Indicators (ALI) (dictionary term)