“Open licensing” is not one license or one legal instrument — it is a category of licenses and public-domain dedications that grant reuse permissions to the public in advance, rather than requiring every would-be reuser to ask permission first. Under default copyright, a research output — a dataset, a codebase, a manuscript, a figure — is “all rights reserved” the moment it is fixed in a tangible form, whether or not the creator files anything. Open licensing reverses that default for specific uses the licensor chooses to permit: reading, copying, redistributing, modifying, or building commercial products, depending on which license and which terms.
The practical difficulty is that “open licensing” spans two legal toolkits that were built for different kinds of work and are not interchangeable. Choosing the wrong toolkit for a given research output — a Creative Commons license on software, for example — creates exactly the kind of unclear, legally fragile reuse rights that open licensing exists to prevent.
Two toolkits, not one
Creative Commons (CC) licenses and the open-source software licenses approved by the Open Source Initiative (OSI) both grant broad advance reuse permission, and both get called “open licenses” in casual usage. They are built for different subject matter and are not meant to be swapped:
- Creative Commons licenses (CC BY, CC BY-SA, CC BY-NC, CC BY-ND, and combinations) are designed for content — text, data, images, media. They do not address source-code distribution or patent rights.
- OSI-approved software licenses (MIT, Apache License 2.0, the GPL family) are designed for code. They address things CC licenses do not: how source code must be made available on distribution, and, for Apache 2.0 and the GPL family, explicit patent grants and patent-litigation terms.
Creative Commons is explicit that its own licenses should not be used for software. Its FAQ states: “We recommend against using Creative Commons licenses for software,” pointing instead to the license lists maintained by the Free Software Foundation and the Open Source Initiative, and noting that CC licenses are not designed to be compatible with the major software licenses. The one CC instrument that is commonly and compatibly used on code is CC0, the public-domain dedication — because CC0 waives rights outright rather than attaching content-specific conditions like attribution, it does not run into the same incompatibility problem. See CASRAI’s guide to open-source software licensing in technology transfer for how MIT, Apache 2.0, and GPL/copyleft licenses actually work and how institutions decide between them.
CC0 and public domain dedication: not a license
CC0 (“CC Zero”) is not a license — it is a public-domain dedication. Applying it means the rights holder waives copyright and related/neighboring rights to the fullest extent the law allows, placing the work as close to the public domain as legally possible. Because it imposes no conditions (no attribution requirement, no share-alike requirement), CC0 sits outside the standard CC element system of Attribution (BY), ShareAlike (SA), NonCommercial (NC), and NoDerivatives (ND), and it is the one Creative Commons instrument commonly recommended for both content and software.
The permissive-to-restrictive spectrum
Within each toolkit, individual licenses sit at different points on a spectrum from maximally permissive to more conditioned:
| Position | Content (Creative Commons) | Software (OSI-approved) |
|---|---|---|
| Public domain / no conditions | CC0 (public domain dedication) | MIT License (effectively no conditions beyond preserving the copyright notice) |
| Permissive, attribution required | CC BY | Apache License 2.0 (adds an explicit patent grant and patent-retaliation clause MIT lacks) |
| Copyleft / share-alike | CC BY-SA (derivatives must carry the same license) | GPL family (distributed modified or combined versions must be released under GPL; AGPL extends this to networked/SaaS use) |
| Additional restrictions | CC BY-NC (no commercial use), CC BY-ND (no derivatives), and combinations | No direct OSI equivalent — the Open Source Definition’s own criteria rule out non-commercial or no-derivatives restrictions, so a NC- or ND-style term is not considered “open source” by OSI’s definition |
That last row matters: “open source” (a software-specific term defined by OSI’s ten-point Open Source Definition) and “open content” (the looser, CC-anchored convention for non-software works) don’t fully overlap. A CC BY-NC-licensed dataset is commonly described as “open,” but a NonCommercial-restricted software license would not qualify as open source under OSI’s definition. Precision about which sense of “open” applies avoids overstating what a license actually permits.
Choosing a license by artifact type
The most common practical question is not “which license is best” in the abstract, but “which toolkit and which license fits this specific output.” A rough decision path:
- Research data: Creative Commons (typically CC BY or CC0) is the default toolkit. Many repositories (Dryad, Zenodo) recommend or default to CC0 for data specifically, since data itself is often not protected by copyright the way creative expression is, and CC0 avoids attribution-stacking problems when datasets are combined. See CASRAI’s CC0 vs CC-BY vs CC-BY-NC guide for research data for the detailed comparison, and the FAIR data checklist for how licensing fits into findability, accessibility, interoperability, and reuse more broadly.
- Research software and code: an OSI-approved license (MIT, Apache 2.0, or a GPL-family copyleft license), chosen based on how much control the institution or authors want to retain over downstream commercial use and combination with other code. CASRAI’s open-source software licensing in tech transfer guide covers the institutional decision process, dual licensing, and how sponsor/funder rights (Bayh-Dole, 2 CFR 200.315) interact with the choice.
- Manuscripts, preprints, and text: Creative Commons, typically CC BY — and increasingly a funder-mandated default rather than an open choice (see below).
- Mixed outputs (a dataset with an accompanying code repository, for instance): license each component under the toolkit built for it — CC (or CC0) for the data, an OSI-approved license for the code — rather than trying to cover both with a single instrument. State each license separately and explicitly rather than leaving readers to infer which applies to which file.
Once a license is chosen, it needs to be stated in a way reusers and machines can actually find and parse — see CASRAI’s guide on describing reuse rights and permissions for a shared dataset for structuring that statement in repository metadata (DataCite’s rightsList, Dublin Core, or ODRL for more complex conditional permissions).
Gratis vs. libre: accessible is not the same as licensed
A common confusion is treating “freely available to read” as equivalent to “openly licensed.” The distinction, formalized by Peter Suber and Stevan Harnad in the early open-access literature, is between gratis open access (free to read, but still fully copyrighted — reuse beyond a narrow fair-use exception still requires permission) and libre open access (free to read and licensed for reuse beyond that, typically via a specific open license). A journal article or dataset can be freely viewable on the web and still carry no reuse rights at all. Open licensing is what converts gratis access into libre access — the license is the thing doing the legal work, not the URL being publicly reachable.
Funder and publisher requirements to check before choosing
For many research outputs the license choice is no longer fully discretionary. cOAlition S’s Plan S requires CC BY by default for funded outputs, with CC BY-SA or CC0 accepted as alternatives and CC BY-ND permitted only by funder-approved exception. NIH’s Data Management and Sharing Policy and individual NSF directorate DMP requirements increasingly expect a stated, specific license as part of a compliant data management plan rather than leaving reuse terms unstated. Before defaulting to a preferred license, check the funder’s policy and the target repository’s or journal’s own licensing requirements — a plan that names a license the funder doesn’t accept has to be corrected before an award or before publication, not after.
Common mistakes
- Applying a Creative Commons license to software. It doesn’t address source-code distribution or patent rights the way a software-specific license does, and Creative Commons itself recommends against it.
- Treating “openly accessible” as “openly licensed.” Gratis availability and libre reuse rights are different things; only the latter is created by a license.
- Leaving the license unstated or ambiguous. A dataset or repository with no explicit license, or an ambiguous one buried in prose rather than structured metadata, forces every reuser to either guess or seek permission — defeating the purpose of licensing it openly in the first place.
- Assuming CC0 is a license. It is a waiver/dedication, not a license, and that distinction matters in some legal contexts (for example, some downstream compatibility questions) even though CC0 functions similarly to a maximally permissive license in practice.
- Choosing a license before checking funder or publisher requirements. Retrofitting a data management plan or a submission after the fact because the stated license doesn’t match a mandate wastes a review cycle.
Frequently asked questions
Is “open licensing” the same as “open access”?
No. Open access describes a publication or output being freely accessible, which can be gratis (free to read only) or libre (free to read and reuse). Open licensing is the specific legal mechanism — a Creative Commons license, an OSI-approved software license, or a public-domain dedication like CC0 — that creates libre reuse rights. An output can be open access without being openly licensed.
Can I use the same license for my dataset and my code?
Not directly. Creative Commons licenses are not designed for software and Creative Commons itself recommends against using them that way; use an OSI-approved license (MIT, Apache 2.0, or a GPL-family license) for code and a Creative Commons license or CC0 for the accompanying data, stated separately.
Is CC0-licensed or MIT-licensed material always free to use commercially?
Both permit commercial use with minimal or no conditions, which is part of why they sit at the permissive end of the spectrum. But “permissive” is a property of that specific license, not of open licensing generally — CC BY-NC and copyleft licenses each restrict commercial use or downstream licensing terms in different ways, so the specific license text, not the general “open” label, is what actually governs.
Does choosing an open license mean giving up copyright?
No, except for CC0, which is a deliberate waiver. A Creative Commons license (CC BY, CC BY-SA, etc.) and OSI-approved software licenses like MIT or Apache 2.0 are grants of permission under copyright that the rights holder retains — the licensor still owns the copyright and can enforce the license’s conditions (such as attribution) against someone who doesn’t comply.
