Skip to content

Open License Declaration

License artifact — instantiates Open Reuse Publication Infrastructure

A published rights file that states — in human- and machine-readable form — exactly what reuse is permitted and what obligations travel with the artifact, so downstream users never have to ask.

Every other part of the reuse surface quietly assumes the stranger is allowed to reuse the artifact. Open License Declaration is the mechanism that makes that assumption true and legible: a single, prominently placed rights file — a LICENSE, a data-use statement, a rights declaration — that spells out what a downstream user may do (copy, modify, redistribute, use commercially) and what they must do in return (attribute, share alike, preserve notices, honor data conditions). Its defining move is to convert permission from something you request into something already answered at the artifact. Where the registry makes the artifact findable and the identifier makes it citable, the license is the one component that makes it usable — legally, and without a private email to anyone's legal team.

Example

A city wants to release its parks-and-open-spaces boundary dataset so civic developers can build on it. A developer can already find and download the file, but without stated terms they cannot safely ship a product on top of it — is commercial use allowed? Must they credit the city? So the city attaches an explicit rights file: CC BY 4.0 for the accompanying documentation and the Open Database License (ODbL) for the database itself, each tagged with its standard SPDX identifier in the metadata, plus a two-line plain-language summary at the top.

Now the terms answer themselves before anyone asks: reuse permitted, commercial use fine, attribution to the city required, and derivative databases must stay open under share-alike. A developer three timezones away reads the file, sees the SPDX tag their tooling already recognizes, and builds a transit-overlay app without a single permission request. The license did nothing to the data — it removed the question that used to route every reuse through a phone call.

How it works

What distinguishes a real license declaration from "it's public, go ahead" is that it makes rights precise, standard, and machine-checkable:

  • Pairs canonical text with a standard identifier. The full legal text plus an SPDX tag (e.g. CC-BY-4.0) so tools — not just lawyers — can recognize and filter by license.
  • Separates permissions from obligations. What you may do, stated apart from what you must do in return, so neither gets lost.
  • Scopes rights to the right parts. Code, data, and documentation in one release can carry different licenses; the declaration says which covers what.
  • States the terms once, at the artifact. Co-located with the thing it governs, not buried in a distant terms-of-service page.

Tuning parameters

  • Permissiveness vs. reciprocity — public-domain and permissive terms (CC0, MIT) maximize uptake; copyleft and share-alike (GPL, ODbL) force derivatives to stay open. Turning toward reciprocity protects the commons but shrinks who can legally combine the artifact with their own closed terms.
  • License granularity — one license for the whole release, or distinct licenses for code, data, and docs. Finer granularity fits mixed artifacts but raises the risk of internally incompatible parts.
  • Attribution burden — how much credit and notice-preservation reuse must carry. Heavier attribution rewards authors but adds friction for aggregators who combine many sources.
  • Commercial-use stance — permit it (CC BY) or restrict it (CC BY-NC). Non-commercial feels safe but is famously ambiguous and blocks many legitimate reuses.
  • Warranty and liability posture — how firmly you disclaim fitness and cap liability. Stronger disclaimers protect the publisher; very strong ones also signal "no support."

When it helps, and when it misleads

Its strength is that it removes the single biggest reason strangers seek private permission, and — because it is standardized — it lets tooling filter, combine, and audit rights automatically instead of re-reading legal prose each time.

Its failure modes cluster around rights you don't actually control and terms that can't legally combine. The classic misuse is stamping "open" on an artifact without confirming you hold the rights to license it — or bolting a permissive license on after the fact to launder a release decision already made, which grants permissions you cannot back. A subtler trap is license incompatibility: two openly-licensed components whose terms cannot lawfully be merged, so a good-faith integrator is stuck. The discipline that guards against this is to verify the provenance of rights before declaring, use standard identifiers rather than bespoke wording, and check compatibility across everything the release bundles.[1]

How it implements the components

Open License Declaration fills the rights-and-permission slice of the archetype's machinery — only the components a license can actually populate:

  • license_and_rights_statement — it is the rights statement: permissions and obligations, in canonical and machine-readable form.
  • boundary_disclosure_and_use_warning — it carries the legal boundary: warranty disclaimers, liability limits, and permitted-use conditions that mark where sanctioned use ends.

It does not give the artifact a citable identity (persistent_address_and_identifier — that's Persistent Identifier Minting), make it findable (access_equity_accommodation — Public Artifact Registry), or supply the integration contract (interoperability_contract_payload — Schema or API Specification Publication); the broader technical, privacy, and safety warnings coordinate with the Boundary-Embedded Disclosure Design neighbour rather than living in this rights file.

Notes

A license binds the copies distributed under it. Relicensing later — even to stricter terms — does not retroactively reach copies already released; those remain usable under the terms they were published with. This is why the permissiveness choice is closer to irreversible than it looks, and why it deserves more deliberation than any other dial here.

References

[1] SPDX (the System Package Data Exchange license list) is a standardized set of machine-readable license identifiers, so a license can be recognized, filtered, and compatibility-checked by tooling instead of re-read by a human each time. Using a standard identifier rather than hand-written terms is the routine discipline that makes automated rights-checking — and therefore compatibility-checking — possible. ↩