Reading Time: 9 minutes

Choosing an open-source license for research code is one of the most consequential decisions a researcher makes — and one that most graduate students and principal investigators encounter for the first time without any formal training.

Your license choice determines who can use your code, how they can use it, whether patent claims are addressed, and whether downstream modifications stay open. It directly affects reproducibility, attribution, and compliance with funder mandates. Yet the research community has no standard educational resource that walks researchers through the actual decision process, compares the major licenses in plain language, or explains the frequently confused intersection of data licensing and software licensing.

This guide addresses that gap. It walks researchers through the practical steps of choosing a license, compares the major options, explains funder requirements, clarifies the data-vs-code distinction, and outlines institutional considerations before you publish code.

Why License Choice Matters

The single most important misconception in the research community is that posting code without a license means it is public domain or freely usable. It is not. Under copyright law, code without an explicit LICENSE file remains fully copyrighted, meaning no one else can legally copy, modify, or distribute it — not even in academic settings. This is the foundational legal reality every research team must understand before sharing code publicly.

https://open-science-training-handbook.gitbook.io/book/02opensciencebasics/03openresearchsoftwareandopensource explicitly documents this misconception and lists other common myths about open-source licensing.

Beyond legal compliance, your license choice has direct consequences for three areas:

Reproducibility

An open-source license gives other researchers legal permission to run, modify, and reproduce your work. Without it, even researchers who want to reproduce your results face legal uncertainty — a barrier that undermines the reproducibility movement in computational science.

Attribution

Different licenses handle attribution differently. Permissive licenses like MIT and BSD require attribution in source redistributions, while copyleft licenses like GPL embed attribution requirements deeply into their terms. The license you choose determines how your contribution is credited downstream.

Funder Compliance

Major research funders now have explicit licensing expectations. NASA’s Software Data Policy 41a (SPD-41a) explicitly requires permissive open-source licensing for all project-developed software and generally bars proprietary or source-available licenses. Horizon Europe expects FAIR-aligned permissive licenses. NIH best practices guide toward public open-source licenses. Ignoring these requirements can create compliance violations after publication.

The Decision Process

Choosing a license is a structured decision, not a random selection. Follow these steps:

Step 1 — Clarify what you want others to do

Ask yourself: do you want others to use your code freely in proprietary projects, or do you want all modifications to remain open-source? This question drives the rest of the decision.

If you want maximum adoption — including use by industry, proprietary projects, and unrestricted commercial distribution — permissive licenses (MIT, BSD) are appropriate. If you want derivative works to remain open-source, copyleft licenses (GPL) are the choice.

Step 2 — Consider patent implications

If your research involves novel algorithms, machine learning methods, or hardware integration, patent risk becomes relevant. Apache 2.0 is the only widely used permissive license with an explicit patent grant. This means contributors grant downstream users a license to any patent claims held by contributors for code within the project. MIT, BSD, and GPL do not contain explicit patent grants (GPLv3 includes a patent retaliation clause but no contributor grant).

Step 3 — Align with community conventions

Study the licenses used by similar projects in your subfield. A numerical methods library in computational materials science should consider what licenses established frameworks use. Community alignment reduces friction for contributors and users.

For deeper context on open-source development workflows in research settings, see our guide on contributing to FiPy, which explains how community-facing code works in practice.

Step 4 — Check institutional requirements

Many universities require tech transfer office approval before releasing software under an open-source license. Employment contracts may restrict licensing decisions. Always verify institutional policy before applying any license.

Step 5 — Apply the chosen license

Place a LICENSE file in the repository root, named exactly as the license text (e.g., LICENSE.mit, LICENSE.apache, or LICENSE.gpl). Optionally add copyright headers to source files, though this is not required by most licenses.

Use choosealicense.com as an interactive tool to match your use case to a license recommendation.

License Comparison

The four licenses most commonly used in research software are MIT, BSD, Apache 2.0, and GPL. They fall into two families:

  • Permissive (MIT, BSD, Apache 2.0): allow proprietary use, require attribution, short and simple
  • Copyleft (GPL): require derivative works to remain open-source, stronger community protection

MIT License

The simplest of all widely used licenses. A single paragraph of text requiring attribution in source redistributions. No patent grant, no copyleft, no compatibility requirements for downstream libraries.

Best for: Maximum adoption. When you want your code used everywhere — in academic papers, proprietary products, and modified derivatives — without restrictions.

Research adoption: MIT is the most common license among licensed open-source projects (65%), according to a 2026 study by Jahanshahi. It dominates because of its simplicity and broad compatibility with other license types.

BSD License

Very similar to MIT. The two-clause BSD license is functionally equivalent to MIT. The three-clause variant adds an explicit no-endorsement clause, preventing others from using your name to promote derivative products.

Best for: When you want maximum adoption plus protection against endorsement misuse. The three-clause BSD is common in government-funded research and high-performance computing communities.

Apache 2.0

The only widely used permissive license with an explicit patent grant. Longer than MIT or BSD (~200 lines), it includes additional terms about trademark use, copyright notices, and contributor patent retaliation.

Best for: Research with significant patent exposure — algorithms, AI methods, hardware integration, or community projects where contributors might hold patents relevant to the code.

Research adoption: Approximately 12% of licensed open-source projects use Apache 2.0, making it the second most common choice.

GPL (General Public License)

The most prominent copyleft license. GPLv2 and GPLv3 are the two main versions. GPLv3 includes anti-tivoization provisions (preventing hardware restrictions on running modified software) and a patent retaliation clause; GPLv2 lacks these protections. For modern research software, GPLv3 is the current choice.

Best for: When you need downstream code to remain open-source. GPL ensures that any modifications or derivative works distributed publicly must also be released under GPL.

Research adoption: Approximately 5% of licensed projects use GPL. It is less common in research because many researchers prefer permissive terms for maximum scientific reuse.

Comparison Table

The following table summarizes key features across the four licenses:

Feature MIT BSD Apache 2.0 GPL
Copyleft? No No No Yes
Patent grant? No No Yes (explicit) GPLv3 retaliation only
Copyright headers required? Yes Yes Yes Yes
Best for? Maximum adoption Adoption + no-endorsement protection Patent exposure, community projects Ensuring downstream stays open
License length? ~1 paragraph ~1 paragraph ~200 lines ~80 lines (GPLv3)
Compatible with proprietary use? Yes Yes Yes No (derivative works must stay GPL)

The comparison table above synthesizes guidance from https://safeguard.sh/resources/blog/open-source-license-comparison-mit-apache-gpl-bsd and https://ospo.library.jhu.edu/learn-grow/licensing-overview/choose-a-license/ (Johns Hopkins OSPO).

Recommendation

For most research code — numerical solvers, simulation tools, data analysis scripts — we recommend MIT. It is the simplest, most widely compatible, and allows your code to be used by anyone without legal barriers. The broad adoption of MIT means contributors face no license compatibility concerns when combining your code with other popular libraries.

Choose Apache 2.0 when:

  • Your research involves novel algorithms with patent exposure
  • You want an explicit patent grant to protect downstream users
  • You are building a community project where contributors may hold relevant patents

Choose GPL when:

  • You need to guarantee that modifications stay open-source
  • Your code is a framework or library where downstream dependency management matters
  • You prioritize enforcement of openness over maximum adoption

Funder Mandates

Research funders increasingly expect specific licensing practices. Ignoring these requirements creates compliance risk after publication.

NASA — SPD-41a

NASA’s Software Data Policy 41a (SPD-41a) requires permissive open-source licensing for all project-developed software. Proprietary or source-available licenses are generally barred for code created under NASA funding. This makes license choice a compliance requirement, not merely a strategic preference, for NASA-funded research teams.

NIH — Open Source Policy

The National Institutes of Health (NIH) best practices guide toward public open-source licenses. While NIH does not mandate a specific license, its Open Source Policy and Software-as-SHA guidance strongly encourage permissive open-source terms for software developed with NIH funding.

Horizon Europe

European Research Council and Horizon Europe funding expectations explicitly expect FAIR-aligned permissive licenses for research software. Katz and colleagues document how this policy evolved in recent funding rounds and how European research teams must align their licensing decisions with FAIR principles (https://open-research-europe.ec.europa.eu/articles/5-199).

Institutional RDM Guides

Many universities have formal Research Data Management (RDM) policies that address software licensing. The Max Planck RDM guide provides practical guidance on selecting licenses for research software (https://rdm.mpdl.mpg.de/2023/05/02/how-to-select-a-license-for-research-software/), while KU Leuven offers an explicit checklist for FAIR-aligned licensing (https://www.kuleuven.be/rdm/en/guidance/fair-research-software).

Practical guidance: If you are unsure about your funder’s licensing expectations, consult your grant’s terms and conditions or ask your research office. Most funder policies are published publicly and can be verified before publication.

Data vs. Code Licensing

One of the most common sources of confusion in research software is the relationship between data licensing and software licensing. Researchers frequently apply the same license to both, creating legal mismatches.

Creative Commons Does Not Work for Code

Creative Commons (CC) licenses were designed for data, publications, and educational content. They lack critical terms that software licensing requires:

  • Source code distribution terms
  • Executable binary distribution terms
  • Library linking terms
  • Patent retaliation clauses

Creative Commons explicitly recommends against using CC licenses for software. Applying CC-BY or CC-BY-SA to code creates legal ambiguity rather than clarity.

You May Need Two Licenses

For research projects that include both data and code, the correct approach is often two separate licenses:

  • CC license for data: CC-BY 4.0 for datasets and publications
  • OSS license for code: MIT, Apache 2.0, or GPL for software

https://www.rug.nl/digital-competence-centre/research-data/archive-and-publish/how-to-work-with-dataversenl/choosing-a-licence-for-your-dataset?lang=en provides explicit guidance on this distinction for research teams managing both datasets and software.

Practical Example

A project that publishes a numerical solver (code) alongside simulation output (data) should:

  1. Include LICENSE.mit for the solver code (MIT license)
  2. Include LICENSE.cc-by-4.0 or similar for the data files
  3. Document both licenses in the repository README

Institutional IP Considerations

Before publishing code under any open-source license, you must verify institutional intellectual property (IP) policy. This is the single most common administrative pitfall for academic researchers.

University Tech Transfer Offices

Most universities consider research code to be institutional intellectual property. A tech transfer office (TTO) or equivalent office typically holds copyright in code written by employees as part of their duties. Releasing such code under an open-source license without TTO approval can constitute an IP violation.

Employment Contracts

Many academic employment contracts contain IP clauses specifying who owns research output. Faculty members may have more flexibility than postdoctoral researchers or research staff. Verify your specific contract terms.

Funding Agency Restrictions

Some funding agencies impose licensing restrictions that go beyond the agency’s own licensing expectations. For example, certain DARPA or DOE programs may specify particular license families or require patent-related terms.

Practical Steps

  1. Contact your tech transfer office before publishing any code under an open-source license
  2. Review your employment contract for IP ownership clauses
  3. Check grant terms for licensing restrictions
  4. Document institutional approval in your repository or documentation

Practical Next Steps

If you have code to publish or code already published without a license, here is a practical action plan:

Before Publishing

  1. Clarify your licensing intent — Use the decision framework above (Section 2)
  2. Verify institutional compliance — Contact your tech transfer office
  3. Check funder requirements — Review grant terms for licensing expectations
  4. Select the license — Use choosealicense.com as a guide

After Selecting a License

  1. Download the license text from the official source (e.g., choosealicense.com for MIT, Apache, BSD; fsf.org for GPL)
  2. Create a LICENSE file in the repository root with the exact license text
  3. Name the file consistently — use LICENSE.mit, LICENSE.apache, or LICENSE.gpl for clarity
  4. Add copyright notice — the license text typically includes a placeholder for copyright year and author name. Fill this in.
  5. Document in README — state the license used, link to the LICENSE file, and explain how others may use the code

If You Already Have Published Code

  1. Add a LICENSE file immediately — even if the code was previously unlicensed, adding a license is a straightforward correction
  2. Update repository documentation — clarify licensing terms for existing users
  3. Notify existing users — if the code has users, communicate the new license terms

Summary

Choosing an open-source license for research software is not a minor administrative detail — it is a strategic decision that affects who can use your work, how they can use it, and whether your code complies with funder mandates. The landscape is stable and well-documented: permissive licenses (MIT, BSD, Apache 2.0) allow maximum adoption, while copyleft licenses (GPL) ensure downstream openness.

For most research code, MIT is the recommended choice due to its simplicity, broad compatibility, and dominant adoption (65% of licensed projects). Choose Apache 2.0 when patent exposure is relevant, and GPL when you need to guarantee downstream code stays open-source.

Always verify institutional IP policy before applying any license, distinguish clearly between data licensing (CC) and software licensing (MIT, Apache, GPL), and ensure compliance with funder requirements. The single biggest misconception — that code without a license is freely reusable — is the foundational reason every research team must explicitly choose and publish a license.

Related Guides

If you are interested in extending your research software practices beyond licensing, these related guides provide complementary coverage:

Checklist: Your License Selection in 5 Minutes

  1. What do you want others to do? Permissive (MIT/BSD) for maximum adoption; Apache 2.0 for patent protection; GPL for enforced openness
  2. Does your institution require approval? Contact tech transfer office before publishing
  3. Does your funder have requirements? Verify NASA SPD-41a, Horizon Europe FAIR alignment, NIH expectations
  4. Are you also publishing data? Use CC for data; use OSS for code
  5. Is the LICENSE file in the repository root? Add it immediately if missing

Follow this checklist before publishing any research code. It covers the essential compliance and strategic considerations that protect both you and your users.

If you are building research software for broader adoption, consider our guide on building sustainable research software communities, which covers contributor onboarding, governance models, and the community practices that complement good licensing decisions.

This article provides educational guidance on open-source licensing for research software. It does not constitute legal advice. Always consult your institution’s technology transfer office and legal counsel for compliance with specific licensing requirements and IP policies.