Choosing a license for research code

A lot of research code is public and still not reusable. The repository is visible, the paper links to it, but there is no license file. In most jurisdictions that means the default applies: the author reserves all rights, and nobody else may copy, modify or redistribute the code without permission.

That is almost never what researchers intend. They published the code so people could use it. A license makes that intention legally real.

This is practical guidance, not legal advice. For anything involving patents, contracts or commercial plans, talk to your institution's technology transfer or legal office.

Why does research code need a license at all?

Three reasons:

• Reuse. Other researchers, especially at institutions with cautious legal teams, often cannot touch unlicensed code.
• Clarity. A license tells people what they may do and what they must do in return, such as keeping your copyright notice.
• Protection. Standard licenses include disclaimers of warranty. If someone uses your code to fly a drone into a lake, the license makes clear that was their call.

Use a standard license approved by the Open Source Initiative. Do not write your own. Custom terms create uncertainty, and uncertainty kills reuse.

Which licenses should you consider?

MIT

Short and permissive. Anyone may use, modify and redistribute the code, including in closed source products, as long as they keep the copyright and license notice. It is popular in research because it is easy to read and easy to comply with.

BSD (2-clause or 3-clause)

Very similar in effect to MIT. The 3-clause version adds a line saying others may not use your name to endorse their derived products. Common in scientific Python and many older academic projects.

Apache-2.0

Permissive like MIT and BSD, but longer, with two notable additions: an explicit patent license from contributors to users, and clearer rules about stating changes. If your institution worries about patents, or your code may end up in industry, Apache-2.0 is often the safer permissive choice.

GPL (version 3, or version 2)

Copyleft. Anyone may use and modify the code, but if they distribute a modified version, or software that incorporates it, they must release that under the GPL too. This keeps derivatives open. It also means some companies and some projects will avoid your code, because they cannot accept those terms.

There are also weaker copyleft licenses such as LGPL and MPL-2.0, which apply copyleft to your files but not to the larger work that uses them. They are worth a look for libraries.

Permissive or copyleft: how do you decide?

Ask what you care about most.

• Maximum reuse, including by companies: MIT, BSD or Apache-2.0.
• Keeping improvements in the open: GPL.
• Fitting into an existing ecosystem: use what your community uses. Many R packages are GPL. Much of the scientific Python stack is BSD. Matching the norm reduces friction.
• Your code includes GPL code: you will likely need to release under a compatible GPL license. Check before you choose.

If you have no strong view, a permissive license is a reasonable default for research code whose main purpose is to support a paper. The site choosealicense.com walks through the same questions in plain language.

Who actually owns your code?

This is the question researchers most often skip, and it can matter more than the choice of license. You can only license what you have the right to license.

• Employees. In many countries and institutions, code written as part of your job belongs to your employer. Many universities have policies that permit or encourage open source release, but you may need to follow a process.
• Students. Ownership varies widely. Some institutions claim rights, many do not. Check your institution's intellectual property policy.
• Funded projects. Grants and contracts sometimes include terms about software. Some funders require open release. Some industry partners require the opposite.
• Collaborations. If several institutions contributed, each may hold rights to its part.

The practical step: find your institution's IP or open source policy and, if it is not clear, ask the technology transfer office. Many of them handle open source requests routinely and respond faster than people expect.

How do you apply a license?

It takes a few minutes:

1. Add a file named LICENSE to the root of the repository with the full license text. Most hosting platforms offer templates.
2. Fill in the copyright line correctly, often with your institution as the holder.
3. Add the license identifier to your package metadata and your CITATION.cff.
4. Optionally add a short header to each source file using an SPDX identifier.

# SPDX-License-Identifier: Apache-2.0
# Copyright 2026 Example University

SPDX identifiers are short, standard names for licenses that tools can read automatically.

What about code that depends on other licenses?

Your code rarely stands alone. It imports libraries, and each of those has its own license. Simply calling a library usually does not constrain how you license your own scripts, but copying code into your repository or bundling it in a distribution can. Before release, list the third party code that is actually included in your repository, not just installed, and check that its license allows redistribution and is compatible with the one you chose. Keep the original license notices with any copied files. This takes a few minutes for most research projects and avoids awkward questions later.

What about data, figures and documentation?

Software licenses are designed for code. For data, text and figures, Creative Commons licenses or public domain dedications are more common. A repository can hold more than one: code under MIT, documentation under CC BY 4.0, for example. Just say so clearly in the README.

Can you change the license later?

You can release future versions under a different license if you hold all the rights. You cannot take back the license on versions already released. If others have contributed, you may need their agreement. That is a good reason to choose carefully the first time, and a bad reason to delay. An imperfect standard license today is far better than no license at all.