# The Researcher's Guide to Open Source Licenses A permissive license lets anyone use, modify, and redistribute your code with almost no conditions, while a copyleft license requires that anyone who redistributes a modified version must release it under the same license. The rule of thumb is simple. If you want the widest possible reuse of your analysis code, scripts, or package, pick a permissive license such as MIT, BSD 3-Clause, or Apache 2.0. If you want every downstream improvement to stay free and open, pick a strong copyleft license such as GPLv3. That one decision shapes who can build on your work, whether companies can adopt it, and how easily a reviewer can rerun your analysis. This guide walks through the main open source license for research code options, the pros and cons of each, worked scenarios from real research software, and a reproducibility checklist that turns a good license into a genuinely reusable release. ## Why the License Decides Whether Your Code Gets Used Sharing code is the exception, not the rule, in most of the life sciences. A review of research funded by the Nathan Shock Centers found that 92% of published articles had no code availability statement at all, and only 6% pointed to code in a repository [1]. In clinical prediction model research, an AI-assisted scoping review of 3,967 articles citing TRIPOD or TRIPOD+AI found that only 482 articles, 12.2%, included any code-sharing statement [2]. A review of real world evidence research in population data science found that zero of 41 eligible articles provided a link to the analytical code [3]. The consequences show up in reproducibility audits. When leading economics and political science journals enforced mandatory data and code sharing policies, more than 85% of published claims could be computationally reproduced by independent teams [4]. That result is the strongest available evidence that making code genuinely available, not just promised on request, is what enables reproducible research. A license is what turns "the code exists somewhere" into "other people are legally allowed to run, adapt, and redistribute it." Surveys of researchers across disciplines identify the practical barriers clearly. For code sharing, the most commonly reported barriers were lack of time to prepare documentation (65%), publication pressure (51%), and insufficient funding (42%) [5]. A good license does not remove those barriers, but it prevents you from spending scarce time relitigating permissions with every collaborator, journal, or company that asks. There is also a legal default that surprises many researchers. Copyright attaches automatically the moment you write code. If you publish code on GitHub or in a repository supplement without a license file, the default is "all rights reserved." That means, technically, no one may copy, modify, or redistribute it, not even to run your method with their own data. An unlicensed repository is a closed repository wearing an open costume. ## What a License Actually Controls ![Comparison table of permissive, weak copyleft, and strong copyleft licenses across closed reuse, patent terms, compatibility, and maintenance burden.](/article-images/illustrations/open-source-license-for-research-code-permissive-vs-copyleft.webp) Software licenses govern copyright in the source code. Three rights matter most in research settings. 1. **Running and internal use.** All recognized open source licenses allow anyone to run the code for any purpose. You never need to worry that a colleague on another continent is "violating" your license by executing your pipeline. 2. **Modification and redistribution.** This is where licenses diverge. Permissive licenses allow modified versions to be redistributed under any terms, including inside closed commercial products. Copyleft licenses require modified versions to carry the same license and source code. 3. **Attribution and notices.** Every license in this guide requires preserving the copyright notice and license text in copies. This is how your priority claim survives reuse. Two things licenses do **not** control deserve emphasis. First, a license does not restrict who may *use* your published results or cite your paper. Second, a code license does not govern your data, figures, or paper text. Data and written works are usually shared under Creative Commons licenses, and conflating the two families is one of the most common mix-ups in repository preparation, covered below. ## Open Source License for Research Code Options: Side-by-Side Comparison This table is the core of the guide. The "family" column separates permissive licenses (minimal conditions) from copyleft licenses (share-alike conditions) and public domain dedications (no conditions at all). | License | Family | What recipients may do | What they must do | Watch out for | |--|--|--|--|--| | MIT | Permissive | Use, modify, sell, sublicense, and include in closed products | Keep the copyright notice and license text with the code | No explicit patent grant | | BSD 3-Clause | Permissive | Same as MIT | Keep the notice, and do not use authors' names to endorse derived products | The non-endorsement clause must be reproduced in distributions | | Apache 2.0 | Permissive | Same as MIT, plus an express patent license from contributors | Keep the NOTICE file, state significant changes, keep the license text | Longer legal text, slightly more to preserve in forks | | GPLv3 | Strong copyleft | Use, modify, and redistribute | Distribute the whole derived work under GPLv3 with source code | Combining your code with incompatible code creates legal conflicts | | LGPLv3 | Weak copyleft | Link the library from proprietary software | Open only modifications to the library itself | Linking details matter, especially for static linking | | MPL 2.0 | Weak copyleft | Combine MPL files with proprietary code in one project | Keep the MPL-licensed files open under MPL | File-by-file boundaries need clean project structure | | AGPLv3 | Strong copyleft | Same as GPLv3, extended to network services | Offer source to users who interact with the software over a network | Can reach web apps and hosted services that GPL would not touch | | CC0 / Unlicense | Public domain | Anything, with no conditions | Nothing | CC0 was drafted for data and creative works, not software, and its waiver language is untested for code in some jurisdictions | | CC BY (and other CC licenses) | Not a software license | Depends on the variant | Attribution (BY), and possibly share-alike (SA) or no-derivatives (ND) restrictions | Written for papers, figures, and datasets. The terms do not map cleanly onto source code | All of the software licenses in the table above are recognized open source licenses under standard community definitions. The last two rows are included because researchers reach for them constantly, usually by mistake. ## Permissive Licenses Explained ### MIT The MIT license is one short paragraph. It grants everyone permission to use, copy, modify, merge, publish, distribute, sublicense, and sell the software, with the single condition that the copyright notice and permission text travel with the code. **Pros.** Maximum adoption. Journal editors, reviewers, collaborators, and companies all understand it instantly. It is the most common choice for small research tools. The three open source dental applications described in a 2026 technical innovation report, including a Blender add-on for CBCT-derived STL conversion and a 3D Slicer extension for mesh comparison, were all released under the MIT license on GitHub [6]. **Cons.** No express patent grant. In fields where methods are heavily patented, this can matter, although for most academic analysis code it does not. MIT also does not require contributors to state what they changed. ### BSD 3-Clause The BSD 3-Clause license works like MIT with one addition. Recipients may not use the names of the copyright holders to endorse or promote derived products without written permission. **Pros.** Same permissiveness as MIT with a light guard against your lab's name appearing in marketing for a product you never tested. Long history in scientific computing, which makes established collaborators comfortable. **Cons.** The third clause must be reproduced in all redistributions, so downstream documentation carries slightly more text than MIT. The endorsement restriction occasionally confuses contributors who assume any named clause is restrictive. ### Apache 2.0 Apache 2.0 is permissive with two important additions. It grants recipients an express license to any patents the contributors hold that cover their contributions, and it terminates that patent license for anyone who sues over patent infringement. It also requires preserving a NOTICE file and stating significant changes. **Pros.** The patent grant is the reason corporate and foundation-backed projects standardize on Apache 2.0. If your code might attract industrial collaborators, or if your institution is patent-active, Apache 2.0 removes an argument that MIT leaves open. **Cons.** The license text is long. Contributors and redistributors must track the NOTICE file. For a 200-line analysis script, this is overhead without much benefit. ### Public Domain Dedications (CC0 and the Unlicense) CC0 and the Unlicense waive as many rights as legally possible. Some researchers like the simplicity. The drawback is that CC0 was drafted for data and creative works rather than software, and the enforceability of its waiver language varies by jurisdiction. If your goal is "as close to no license as possible," the Unlicense is the safer software-specific choice. If your goal is simply maximal reuse, MIT achieves it with cleaner legal footing. ## Copyleft Licenses Explained ### GPL Version 3 (GPLv3) GPLv3 is strong copyleft. Anyone may use and modify the code, but if they distribute a derived work, the whole derived work must be released under GPLv3 with source code. This is sometimes described as viral, and the description is roughly accurate at the level of combined works. **Pros.** Copyleft guarantees that the community version of your tool stays open. If a company takes your pipeline, improves it, and ships a product, the improvements come back to the community. GPLv3 also includes explicit patent retaliation terms. **Cons.** Strong copyleft deters some commercial and clinical partners outright, and it creates real compatibility problems when your code needs to link against libraries with incompatible licenses. If your goal is adoption breadth, GPLv3 works against you. ### LGPL and MPL 2.0: Weak Copyleft Weak copyleft licenses draw a smaller circle around the share-alike requirement. - **LGPLv3** applies copyleft only to the library itself. Proprietary applications may link against an LGPL library, which makes it the standard choice for reusable libraries that need industrial users. - **MPL 2.0** applies copyleft at the file level. You can combine MPL-licensed files with proprietary files in a single codebase, as long as the MPL files themselves stay open. **Pros.** You get a guarantee that direct modifications to *your* code stay open, without blocking mixed proprietary projects. **Cons.** Both require contributors and maintainers to reason about boundaries (which files, which linking cases). For a small lab project with occasional outside contributors, that reasoning is often more overhead than the benefit justifies. ### AGPL Version 3 AGPLv3 extends GPLv3 with a network clause. If users interact with your software over a network, such as a hosted web service, the operator must offer them the source code. This closes the "hosting loophole" that plain GPL leaves open. It is relevant when your research output is a deployed web application rather than a downloadable tool. ## Open Source License Pros and Cons for the Criteria That Actually Decide Beyond the per-family summaries above, five practical criteria separate these licenses in real research decisions. 1. **Reuse inside closed or commercial tools.** MIT, BSD, and Apache 2.0 all allow it. GPLv3 forbids it for derived works. LGPL and MPL 2.0 allow it with conditions. If a diagnostics company or pharma partner is a plausible adopter, strong copyleft is a barrier by design. 2. **Patent protection.** Only Apache 2.0 and the GPL family include explicit patent terms. MIT and BSD leave patent questions to default law. 3. **License compatibility.** GPLv3 code can generally incorporate Apache 2.0 and MIT code. The reverse is not true. If you publish under GPL, permissively licensed projects cannot pull your code into their codebase without changing their own license. This asymmetry is the single most common reason a "helpful" copyleft choice fragments a community. 4. **Journal and funder expectations.** Journal data policies overwhelmingly emphasize that code be available and reusable, with substantially less attention to which specific license applies. A survey of 171 materials science journals found that expectations for research software lag well behind those for data, with limited attention to versioning, [persistent identifiers](/knowledge/bioinformatics/persistent-identifiers-in-bioinformatics-selection-criteria-and-implementation-workflow), dependency disclosure, and reproducible execution environments [7]. Any recognized open source license satisfies the typical requirement. No license satisfies it. 5. **Maintenance burden.** Permissive licenses are one decision with no ongoing obligations. Copyleft licenses generate recurring questions from contributors and downstream users about boundaries and combining works. ## Choosing the Best Open Source License for Research Code: Worked Scenarios ### Scenario 1: An analysis pipeline accompanying a single paper You have R or Python scripts that produce the figures in one manuscript. Nobody plans to maintain the project as a product. The best open source license for research code here is MIT or BSD 3-Clause. Both maximize the chance that a reviewer or reader can legally rerun and adapt your analysis, which is the entire point of the release. This matches the pattern in the dental applications released under MIT on GitHub, where the goal was public availability of functional prototypes rather than controlled ecosystem growth [6]. ### Scenario 2: A package or method you want the community to adopt Your laboratory has built a computational method with real reuse potential, such as an end-to-end pipeline that converts cine cardiovascular magnetic resonance images into time-varying biventricular meshes. The biv-me pipeline was released with code, models, and documentation together, validated across five publicly available datasets and 1,313 imaging studies [8]. For a project at this scale, Apache 2.0 is a strong default. It keeps adoption friction near zero, adds a patent grant that reassures institutional and industrial users, and scales cleanly if outside contributors appear. BSD 3-Clause and MIT remain perfectly good alternatives if your institution has no patent concerns. ### Scenario 3: A dashboard or application built for non-programmers Code-free interfaces lower technical barriers for investigators, particularly in resource-limited settings. The GBD Analysis Suite, an open source R Shiny dashboard consolidating 11 analytical modules for burden-of-disease research into a single web interface, exists precisely to remove that barrier [9]. Similarly, NCA Assistant provides a browser-based R/Shiny interface for non-compartmental pharmacokinetic analysis and bioequivalence testing, designed for research and teaching [10]. For applications of this kind, the license choice is usually less consequential than the deployment choice, because most users interact with a hosted instance rather than the source. If you host the application yourself on a public server, AGPLv3 is the license designed for exactly that situation, guaranteeing that users of the service can obtain the source. If you expect others to install their own instances and possibly embed modules in commercial tools, a permissive license fits better. ### Scenario 4: A pipeline that depends on a commercial or restrictively licensed component Suppose your tool is built in MATLAB and distributed as a compiled standalone application, as CADENCE is for cardiac optical mapping data, combining signal conditioning, feature extraction, and analysis across four species and three tissue preparations [11]. Your own code can carry an open license, but the MATLAB runtime is governed by the vendor's terms, and your license cannot grant rights you do not hold. The same problem appears in genomics. Cell Ranger, the proprietary multiomic pipeline, uses an end-user license that forbids redistribution of analysis pipelines that include it, which is a stated reason the Chromap Suite project built its open alternative around permissively licensed components [12]. Before choosing a license, inventory every dependency. Your license must be compatible with everything your code links to, loads, or bundles. ### Scenario 5: A community database or platform Sustained research infrastructure favors open source over proprietary systems, which may involve costs, licensing constraints, or limited customization, and over locally developed databases that are hard to maintain over time. U-Plant, a fully open source database for botanic garden collections management with a public engagement portal, illustrates the model of a community-supported open platform [13]. For infrastructure meant to outlive any single grant, copyleft (GPLv3 or AGPLv3 for a web platform) protects the commons character of the project across institutional turnover. For infrastructure meant to be forked freely by many organizations, permissive licensing lowers friction. ## When Licenses Collide: Dependencies, Data, and Downstream Users ![Flowchart from listing dependencies through flagging copyleft or commercial components to choosing a compatible license and stating it in the README.](/article-images/illustrations/open-source-license-for-research-code-dependency-license-check.webp) Three collision points cause most real problems. **Dependency licenses.** If your code imports a GPL library and you distribute your code, copyleft obligations can extend to your distribution regardless of what your LICENSE file says. Before releasing, list every dependency and its license. Package managers and dependency checkers can automate most of this, and a one-time hour of checking prevents years of ambiguity. The Chromap Suite project shows the constructive version of this process. Faced with a restrictive upstream license and incompatible tool runtimes, the developers extended permissively licensed components and hardened them with a regression-test matrix so the open stack could stand on its own [12]. **Data and model licenses.** Your code license covers scripts and source files only. Datasets, trained model weights, figures, and documentation need their own decisions. Privacy constraints add a further layer. In work on deidentified Japanese electronic health record narratives, the analytic framework had to balance privacy protection against reproducible entity extraction, because the underlying narratives could not be shared at all [14]. When data cannot be released, sharing well-licensed, well-documented code becomes the main route to independent verification. **Downstream expectations.** Users of research software judge openness by whether they can actually obtain and run the code. In the Nathan Shock Centers assessment, among articles that did claim open data or code, the materials could be located for 63% and 81% respectively, which means a meaningful share of claims did not hold up [1]. A clear license, stated in the repository and in the manuscript's availability statement, is the cheapest way to make your claim verifiable. ## A Reproducibility Checklist That Puts Your License to Work A license alone does not make code reusable. Reporting studies keep finding the same gaps. In the clinical prediction model review, repositories showed substantial heterogeneity in reproducibility features, and the authors called for clearer expectations covering documentation, dependency specification, and executable structure [2]. Radiological AI researchers similarly found that limited availability and usability of data and code restrict independent verification even when resources are nominally shared [15]. A Delphi consensus study of 73 experts from 34 countries, run as part of the EU iRISE project, prioritized measures and interventions for strengthening reproducibility, including shared standards for methods and data reporting [16]. Use this reproducibility checklist before every code release. It converts your license decision into something a stranger can actually act on. 1. **Add a LICENSE file** to the repository root with the full license text, not just a mention in the README. 2. **Write a README** that states what the code does, what paper it belongs to, and how to cite it. 3. **Pin your environment.** Record software versions, including the R or Python version, since a meta-research screen of Global Burden of Disease papers checked precisely these details, reported R versions and code availability, when assessing analytical transparency [17]. 4. **Declare every dependency** with versions, so the license compatibility check above stays auditable. 5. **Include a small runnable example** with test data so a new user executes the pipeline end to end before touching their own data. 6. **Tag a release and archive it** with a persistent identifier, addressing the versioning and identifier gaps that journal policy surveys identified as underdeveloped for software [7]. 7. **Update the manuscript's data and code availability statement** to match exactly what is in the repository, since vague statements are the point at which availability claims most often fail [1]. 8. **Document limitations honestly**, including any steps a reviewer cannot rerun, which is what transparent reporting standards ask of AI-focused studies [15]. 9. **State the license in the availability statement itself**, for example "code available under MIT at (repository)," so the legal status is verifiable in one line. 10. **Plan for the sharing burden.** Documentation time is the top reported barrier to code sharing [5], so budget it as part of the project rather than leaving it to the revision stage. ## Common Mistakes and Limitations - **Publishing without a license file.** Without a LICENSE file, the default is all rights reserved, and technically nobody may reuse your code. This single omission undoes the entire point of code sharing. - **Applying Creative Commons licenses to source code.** CC licenses were designed for text, figures, and data. Their terms do not translate cleanly to software concepts like source code and object code. Use a software license for code and reserve CC BY for papers, figures, and datasets. When the code and data ship together, state both licenses separately in the README. - **Treating "available on request" as sharing.** Requests fail in practice, and audits show that a share of claimed-open materials cannot be located when someone actually tries [1]. Repository deposition with a license is the verifiable option. - **Assuming an open license overrides an upstream restriction.** You cannot grant rights to code you do not own or to a commercial runtime covered by a vendor's end-user agreement [11]. If your pipeline must include a restrictive component, say so explicitly in the README and license only what is yours. - **Ignoring your employer's and funder's intellectual property policies.** Universities and funders may hold rights to code produced under grant funding. Check before you choose a license, especially for copyleft choices that affect commercialization pathways. - **Choosing GPL for a small analysis script and fragmenting reuse.** Strong copyleft on a paper-accompanying script prevents permissively licensed projects from incorporating your method, which usually serves nobody. Match the license strength to the project's intended life. - **Relying on AI-assisted development without provenance checks.** AI-assisted workflows are now producing real research software, including applications built by a single clinician without formal programming training [6] and pharmacokinetic tools developed with a large language model as a coding assistant [10]. That development style makes it easier than ever to accidentally incorporate code whose license terms you have not checked. Verify the origin of substantial generated components before release. - **A note on limitations.** Licensing choices interact with institutional policy, patents, and jurisdiction-specific copyright law in ways this guide cannot resolve for a specific project. For high-stakes releases, for example a tool headed toward clinical deployment or a startup spinout, have your technology transfer office or counsel review the choice. ## Frequently Asked Questions ### What is the best open source license for research code? For most research code, MIT, BSD 3-Clause, or Apache 2.0 is the best choice, because permissive terms maximize reuse by journals, reviewers, collaborators, and industry. Choose Apache 2.0 if patent reassurance matters, and choose GPLv3 only when you deliberately want to force downstream improvements to stay open. ### Can I put my research code in the public domain instead of using a license? Yes, through a dedication such as CC0 or the Unlicense, but it is not the recommended path for software. CC0 was written for data and creative works, and the legal effect of its waiver language for code varies by jurisdiction, so MIT or BSD achieves the same practical openness with clearer terms. ### If I upload code to GitHub without a license, can other researchers use it? No. Copyright attaches automatically, and the default is all rights reserved, so other researchers may read your code but may not legally copy, modify, or redistribute it. Adding a LICENSE file to the repository is what grants those rights. ### Which license should I pick if my script depends on commercial software such as MATLAB? Choose a permissive license for your own code, such as MIT or BSD 3-Clause, and document the dependency clearly. Your license cannot grant rights to the commercial runtime or any restrictively licensed component, so state in the README that users must obtain those under the vendor's own terms. ### Does an open source license affect where I can publish? Not adversely. Journals generally require only that code be available, and surveys of journal policies show software-specific licensing requirements are far less developed than data policies. Any recognized open source license satisfies the typical availability requirement, and stating the license in your data and code availability statement strengthens it. ### Can I relicense my research code later, for example for a commercial version? Yes, if you hold the copyright, which depends on your institution's intellectual property policy and any contributor agreements. You can relicense future versions at any time, but versions already released under a copyleft license stay under that license for everyone who received them. ## Sources 1. [An assessment of data and code sharing in research funded by the Nathan Shock Centers, 2017-2022: a meta-research study.](https://pubmed.ncbi.nlm.nih.gov/42770081/) 2. [AI-assisted scoping review of code sharing in clinical prediction model research.](https://pubmed.ncbi.nlm.nih.gov/42855584/) 3. [Extent of Open Science Practices in the Reporting of Real World Evidence Research.](https://pubmed.ncbi.nlm.nih.gov/42016902/) 4. [Reproducibility and robustness of economics and political science research.](https://pubmed.ncbi.nlm.nih.gov/41922705/) 5. [Exploratory Insights into Barriers and Open Practices for Computational Reproducibility in Scientific Research.](https://pubmed.ncbi.nlm.nih.gov/42728931/) 6. [AI-assisted software development in digital dentistry: A technical innovation report with three open-source applications.](https://pubmed.ncbi.nlm.nih.gov/42361884/) 7. [Journal research data policies in materials science.](https://pubmed.ncbi.nlm.nih.gov/42306234/) 8. [biv-me: Open-source software for generating time-varying biventricular meshes from cine cardiovascular magnetic resonance imaging with multi-cohort validation.](https://pubmed.ncbi.nlm.nih.gov/42579973/) 9. [Open-Source R Shiny Dashboard (Global Burden of Disease Analysis Suite) for Multimethod Burden of Disease Research: Development and Evaluation Study.](https://pubmed.ncbi.nlm.nih.gov/42727936/) 10. [NCA Assistant: An Open-source R/Shiny Interface for Non-compartmental Pharmacokinetic Analysis, Bioequivalence Testing and Study Planning.](https://pubmed.ncbi.nlm.nih.gov/42806221/) 11. [CADENCE: Open-source software for signal conditioning, feature extraction, visualization and analysis of cardiac optical mapping data.](https://pubmed.ncbi.nlm.nih.gov/42926439/) 12. [Chromap Suite: an open-source single-binary platform for agentic multiomic RNA + ATAC profiling.](https://pubmed.ncbi.nlm.nih.gov/42282561/) 13. [U-Plant and U-Plant DISCOVER: an open-source database for botanic garden collections management and public engagement.](https://pubmed.ncbi.nlm.nih.gov/42765505/) 14. [Balancing Privacy Protection and Reproducible Entity Extraction in Real-World Data in the Development of a Framework for Deidentified Japanese Electronic Health Record Narratives Using BERT: Retrospective Observational Study.](https://pubmed.ncbi.nlm.nih.gov/42993904/) 15. [Transparent reporting is central to reproducible radiological AI research: A call to action.](https://pubmed.ncbi.nlm.nih.gov/41806464/) 16. [Prioritising measures and interventions to strengthen research reproducibility: a Delphi consultation study.](https://pubmed.ncbi.nlm.nih.gov/42393780/) 17. [Paper mill or paper mine? A tentative answer to the sharp increase in research papers based on the Global Burden of Disease database.](https://pubmed.ncbi.nlm.nih.gov/42624337/)