Written and maintained by CASRAI Editorial Board
Last updated
An open source license is the legal permission that lets other people use, change and share your code. For research software it is the difference between code that others can safely reuse and cite and code that, by default, they cannot. This guide is for researchers and research software engineers who must choose a license for a project, apply it correctly, and understand what the common licenses require.
Short answer. The Open Source Initiative (OSI) states that open source licenses are licenses that comply with the Open Source Definition, and a license must pass OSI’s license review process to be listed as approved. For most new projects the practical choice is one of three families: a permissive license such as MIT or Apache-2.0, a copyleft license such as GPL-3.0, or a weaker copyleft such as MPL-2.0. This is general information, not legal advice; check your institution’s policy before you publish.
What an open source license does in research software
Copyright applies to code automatically. The Choose a License project explains that a creative work, code included, is under exclusive copyright by default, so without a license other people have no permission to use, modify or share it, and putting the code on a public host where it can be viewed and forked does not change that. A license is therefore the instrument that grants reuse rights while you keep the copyright.
That matters for research because reuse is the point of sharing software: reproducing a published analysis, building on a method, or citing a tool. The CASRAI dictionary entry on open source software sets out the ten Open Source Definition criteria; this page covers the next step, which is choosing and applying a specific license.
Permissive vs copyleft: the license families
Choose a License groups its listed licenses by what they require of people who redistribute your code. The wording in the table below follows that site’s own license descriptions (read 2026-11-08).
| License | Family | What the source describes | SPDX identifier |
|---|---|---|---|
| MIT | Permissive | A short and simple permissive license with conditions only requiring preservation of copyright and license notices. | MIT |
| Apache License 2.0 | Permissive | A permissive license whose main conditions require preservation of copyright and license notices. | Apache-2.0 |
| Mozilla Public License 2.0 | Weak copyleft | A weak copyleft license whose source-code obligations attach to the licensed files. | MPL-2.0 |
| GNU LGPLv3 | Copyleft (library variant) | Listed by Choose a License as a copyleft license. | see the SPDX License List |
| GNU GPLv3 | Strong copyleft | A strong copyleft license conditioned on making available complete source code of licensed works. | GPL-3.0-only (SPDX; Choose a License lists the older GPL-3.0 id); see the SPDX License List |
| GNU AGPLv3 | Network copyleft | Network use of a modified version triggers the source-code obligation. | see the SPDX License List |
| The Unlicense | Public-domain dedication | No conditions whatsoever; dedicates the work to the public domain. | Unlicense |
The practical reading: a permissive license lets downstream users keep their changes private as long as they preserve notices, while a copyleft license makes redistribution conditional on sharing source. The ladder runs permissive, then weak copyleft (file-level), then strong copyleft, then network copyleft.
OSI-approved vs merely “available”
The OSI license page lists MIT, Apache-2.0 and GPL-3.0 among its popular, strong-community licenses and also keeps categories such as redundant, voluntarily retired, non-reusable and special-purpose licenses. A license that is published but has not passed OSI review is not on the approved list, so “source available” terms should not be described as open source. Check the license’s name on the OSI list before you use the phrase in a paper or README.
Choosing a license for research software
- Check who owns the code. University and funder rules can decide who may license software you wrote. Read your institution’s intellectual property policy or ask the technology transfer office first; see open source software licensing in university technology transfer and the Bayh-Dole Act entry for federally funded work.
- Read your award and dependency terms. Read any licensing terms in your funding agreement and the license text of the code you build on before you decide. Choose a License says one of its listed licenses should work for most new open source projects.
- Pick from the table by the obligation you want to impose. If you want others to be able to reuse your code with only notice preservation, choose MIT or Apache-2.0. If you want improvements to be shared back as source, choose a copyleft license such as GPL-3.0 (or MPL-2.0 if only the licensed files should carry the obligation).
For the broader taxonomy of software licenses used when universities license code to third parties, see types of software license agreements and the software license agreement entry.
Applying the license to a project
- Select the license from the Choose a License list (choosealicense.com/licenses/) or the OSI list (opensource.org/licenses) and copy the full license text from that official source.
- Add the text as a license file in the top level of the repository (commonly named LICENSE).
- Add an SPDX identifier line to each source file. The SPDX project’s guidance is to add a single line, written in the comment style of the file’s language. The format is the comment opener,
SPDX-License-Identifier:, a space, the license identifier, and the comment closer if the language needs one. The SPDX page’s own example is// SPDX-License-Identifier: MIT; a Python or shell file would use#in place of//, as in the page’s# SPDX-License-Identifier: GPL-2.0-or-laterexample. - Keep existing copyright notices. SPDX identifiers carry license information only, and the SPDX page says not to remove or modify existing copyright notices when adding an identifier.
- Record the identifier in your metadata and citation. Use the SPDX short identifier (for example
MITorApache-2.0) in repository metadata, a software deposit or a data-sharing record so the license is machine readable. The SPDX License List (version 3.29.0, released 2026-09-16) gives each license a short identifier, full name, text and permanent URL. For how software is described and cited, see the FAIR4RS principles entry.
Why per-file identifiers: the SPDX guidance notes that if license information exists only in a top-level license file, downstream recipients may not know which license applies once a file leaves the repository; an identifier inside each file travels with it.
Reading the result and common problems
Code with no license
If the repository has no license, the default is exclusive copyright, so others have no permission to use, modify or share the software, even if it is public. Choose a License says that is a deliberate choice you can make, and that if you do make it you should say so in a prominent place such as the README so users do not assume an oversight. If you want reuse, add a license.
Mixing licenses in one project
Combining code under different licenses can create conflicting conditions, particularly where a copyleft license is involved. Read each component’s license text and, if the combination is unclear, ask your institution’s legal or technology transfer office. This page does not give legal advice.
Accepting contributions
Choose a License suggests that projects accepting outside contributions consider a contributor agreement, ideally with a lawyer’s help.
Free alternatives and related options
| Option | What it is, per the source | Use when |
|---|---|---|
| The Unlicense | No conditions whatsoever; dedicates works to the public domain (Choose a License). | You want to give up all conditions on code. |
| Public-domain dedication | Opts out of copyright entirely (Choose a License, “no permission” page). | You want no copyright claim at all. |
| Creative Commons licenses | For data and text rather than software; see Creative Commons licenses for research data and the Creative Commons entry. | Licensing datasets, figures or documentation that ship with the code. |
Frequently asked questions
What is an open source license?
A license that complies with the Open Source Definition and has passed OSI’s license review; it grants others the right to use, modify and share the software under stated conditions (OSI, read 2026-11-08).
What is the difference between permissive and copyleft licenses?
Permissive licenses such as MIT and Apache-2.0 mainly require preserving copyright and license notices. Copyleft licenses such as GPL-3.0 condition redistribution on making source available; MPL-2.0 applies this at the file level, and AGPL-3.0 extends it to network use of modified versions.
Do I need a license if my code is already public?
Yes, if you want others to be allowed to reuse it. Public hosting does not grant permission; without a license, exclusive copyright applies by default.
What is an SPDX identifier?
A short, standard name for a license, such as MIT or Apache-2.0, maintained in the SPDX License List so tools and people can read license information the same way.
Sources
- Open Source Initiative, Licenses: opensource.org/licenses (read 2026-11-08).
- Choose a License, Licenses: choosealicense.com/licenses/ and “No permission”: choosealicense.com/no-permission/ (read 2026-11-08).
- SPDX License List, version 3.29.0 (2026-09-16): spdx.org/licenses/ (read 2026-11-08).
- SPDX, Handling license info: spdx.dev/learn/handling-license-info/ (read 2026-11-08).
