How to Choose an Open Source License

Step 1: Define Your Goals for the Project

Before you compare specific licenses, clarify what outcome you want the license to produce. Different goals point to different licenses, and starting with the goal makes the rest of the decision much easier.

If your goal is maximum adoption, you want as many people, companies, and projects as possible to use your code. You do not care whether someone takes your code, modifies it, and sells the result without sharing their changes. You want zero friction. This points toward permissive licenses like MIT, Apache 2.0, or BSD.

If your goal is software freedom, you want to ensure that your code, and every derivative of your code, remains open source forever. You are willing to accept lower adoption from commercial users in exchange for the guarantee that no one can make your work proprietary. This points toward copyleft licenses like GPL v3 or AGPL v3.

If your goal is a dual-licensing business model, you plan to offer the software for free under an open source license while selling a commercial license to companies that want to avoid the open source license's obligations. This requires a copyleft license (usually GPL or AGPL) as the open source option, and it requires that you own or have assignment of all copyright in the codebase so you have the authority to offer alternative terms.

If your goal is academic sharing, you want to make research code available for others to build on, with minimal legal complexity. Most academic projects use MIT, BSD, or Apache 2.0 because these licenses are simple, well-understood, and create no barriers to adoption by other researchers or by companies that want to commercialize research results.

Step 2: Decide Between Permissive and Copyleft

This is the most consequential decision in the process. Every license falls into one of these two families, and once you know which family you want, the number of viable options drops from dozens to a handful.

Choose a permissive license if you want your code to spread as widely as possible, you are comfortable with the possibility of proprietary derivatives, and you do not need to enforce a particular set of values on downstream users. Most JavaScript libraries, developer tools, cloud-native infrastructure projects, and general-purpose utilities use permissive licenses. The three standard choices are MIT (simplest, most popular), Apache 2.0 (permissive with patent protection), and BSD (similar to MIT, used in operating system communities).

Choose a strong copyleft license if you want derivative works to remain open source. The standard choices are GPL v3 (the most widely used copyleft license) and AGPL v3 (GPL v3 plus a network distribution trigger for server-side software). Strong copyleft is common in operating systems, desktop applications, content management systems, and projects backed by the Free Software Foundation.

Choose a weak copyleft license if you want your code to stay open source but you also want to allow proprietary software to use your code as a library or component. The standard choices are LGPL v3 (copyleft for the library, permissive for linking applications) and MPL 2.0 (copyleft at the file level, permissive at the project level). Weak copyleft is common for libraries, frameworks, and components that are meant to be embedded in larger applications.

Step 3: Evaluate Patent Protection Needs

Patents are a significant concern in enterprise software, cloud computing, and any domain where large companies hold substantial patent portfolios. If your project could potentially implicate patents held by its contributors or users, you should choose a license with an explicit patent grant.

Apache 2.0 provides the strongest patent protection among permissive licenses. Every contributor automatically grants users a royalty-free patent license, and the patent retaliation clause revokes that license from anyone who files a patent lawsuit over the software. This is why Apache 2.0 is the standard choice for enterprise open source projects.

GPL v3 provides comparable patent protection in the copyleft family. Section 11 requires contributors to grant patent rights, and the license includes provisions to prevent patent holders from restricting users' rights through patent claims.

MIT and BSD do not mention patents. Users rely on the legal theory of an implied patent license, which has not been extensively tested in court. For small projects, personal tools, and code that does not implement patented technology, this is usually not a practical concern. But for enterprise software, infrastructure projects, or anything where contributors might work for companies with large patent portfolios, the explicit grant in Apache 2.0 or GPL v3 is worth the additional license complexity.

Step 4: Check Dependency License Compatibility

Your project's license must be compatible with the licenses of all your dependencies. If you choose a license that conflicts with a dependency's license, you cannot legally distribute the combined work.

The most common compatibility issues to watch for:

Apache 2.0 and GPL v2 are incompatible. If your project depends on GPL v2-only code (like the Linux kernel), you cannot use Apache 2.0. Apache 2.0 is compatible with GPL v3, so this is only an issue with GPL v2-only dependencies.

GPL is one-way compatible with permissive licenses. You can include MIT or BSD code in a GPL project, but you cannot include GPL code in an MIT or BSD project (because the GPL would require the entire combined work to be GPL-licensed, which contradicts the permissive license's intent to allow any downstream licensing).

Different copyleft licenses are generally incompatible with each other. You cannot combine GPL code with code under a different copyleft license unless one of the licenses explicitly allows it. The MPL 2.0 includes a provision for conversion to GPL-compatible terms, which makes it compatible with the GPL family. Most other copyleft licenses do not include such a provision.

Use automated tools to scan your dependency tree. FOSSA, Snyk, the OSS Review Toolkit, and license-checker (for npm projects) can all identify license conflicts before they become problems. Running these tools early in your project saves significant effort compared to discovering incompatibilities after your codebase is deeply entangled with a problematic dependency.

Step 5: Consider Your Community and Ecosystem

License choice is not made in isolation. Your project exists within an ecosystem of related projects, potential contributors, and downstream users. Matching the conventions of your ecosystem reduces friction and increases the likelihood that people will contribute to and adopt your project.

In the JavaScript and web development ecosystem, MIT is the overwhelming standard. React, Vue, Angular, Express, Next.js, and the vast majority of npm packages use MIT. Choosing a different license for a JavaScript library would be unusual and might raise questions from potential contributors.

In the cloud-native and infrastructure ecosystem, Apache 2.0 is the standard. Kubernetes, Prometheus, Envoy, gRPC, and most CNCF projects use Apache 2.0. The patent protection and detailed terms suit the enterprise context of these projects.

In the Linux and systems programming ecosystem, GPL v2 is common for operating system components, while permissive licenses (MIT, BSD, Apache) are common for userspace tools and libraries. The Linux kernel's GPL v2 license heavily influences the licensing choices of related projects.

In the scientific and academic ecosystem, MIT, BSD, and Apache 2.0 are all common. The choice often depends on institutional policy, funding requirements, and whether the researchers want to enable commercial use of their work.

If you are not sure what your ecosystem prefers, look at the ten most popular projects in your language or domain and check what licenses they use. Matching the majority choice is a safe default.

Step 6: Add the License to Your Project

Once you have decided on a license, applying it to your project is straightforward. Create a file called LICENSE (or LICENSE.txt or LICENSE.md) in the root directory of your repository. Paste the full text of the license into this file. For licenses that require it (MIT, BSD), replace the placeholder copyright year and copyright holder name with your actual year and name or organization name.

In your README, add a section that states the project's license and links to the LICENSE file. This makes the license immediately visible to anyone who visits the repository.

If your project has a package manifest (package.json for npm, Cargo.toml for Rust, setup.py for Python, etc.), include the license identifier in the appropriate field. Most package managers use SPDX license identifiers: "MIT" for the MIT License, "Apache-2.0" for Apache 2.0, "GPL-3.0-only" or "GPL-3.0-or-later" for GPL v3, and so on.

For projects with multiple contributors, consider whether you need a Contributor License Agreement (CLA). A CLA asks contributors to grant additional rights over their contributions, typically including the right to relicense the code. This is important if you might want to change the license in the future or if you plan to offer dual licensing. Major projects like Apache, Kubernetes, and many Google and Microsoft open source projects require CLAs.