47 Open Source Licenses

A Developer’s Guide to Open Source Licenses: Understanding Your Options and When to Use Them

Open source software powers much of the modern tech world, from small tools to massive platforms. But to make your code truly “open source,” you need a license. Without one, your code is just publicly viewable—not legally usable.

This guide is structured in two main parts:

1. Introduction and Overview: We’ll first cover what open source licenses are, the major types, and provide a comprehensive table of all 47 licenses from ChooseALicense.com
2. Detailed License Information: Then we’ll dive deep into each license with specific descriptions, use cases, and links to full license texts

Let’s start with the fundamentals, then move to the complete breakdown of every license available.

What Are Open Source Licenses and Why Do They Matter?

An open source license is a legal agreement that lets others use, modify, and distribute your code under defined terms. When you write software, you automatically hold the copyright, meaning no one else can legally touch it without your permission. A license changes that by granting specific rights to others.

Without a license, your code isn’t open source—it’s just visible. For example, if you push code to GitHub without a license, others can look at it or fork it (per GitHub’s Terms of Service), but they can’t use it in their projects without risking legal trouble. A good license also protects you by limiting liability if something goes wrong with your code.

The Open Source Initiative (OSI) defines open source as software that:

• Allows free redistribution
• Provides source code access
• Permits modifications and derivative works
• Doesn’t restrict who can use it or for what purpose

This goes beyond “code you can see”—it’s about enabling collaboration and reuse.

Types of Open Source Licenses

There’s a wide range of open source licenses, each with unique rules. Here’s a breakdown of the main categories and examples, including their full text placeholders from ChooseALicense.com.

Copyleft Licenses

These “viral” licenses require derivative works to use the same or a compatible license, ensuring the code stays open source.

• GNU General Public License (GPL)

  • Ensures derivatives remain open source and freely available.
  • When to use: Ideal if you want to guarantee your code and its modifications stay in the open source community.
  • License text: GPLv3

• Affero GNU Public License (AGPL)

  • Like GPL, but extends to software accessed over a network (e.g., web apps).
  • When to use: Perfect for server-side software where you want users to access the source code.
  • License text: AGPLv3

• Lesser GNU Public License (LGPL)

  • A milder copyleft that allows linking to the software without forcing the whole project to be open source.
  • When to use: Great for libraries you want others to use freely without strict requirements.
  • License text: LGPLv3

Permissive Licenses

These give users freedom to use your code however they want, including in proprietary projects, with minimal obligations.

• MIT License

  • Simple and flexible, only requiring attribution.
  • When to use: Use this if you want your code to spread widely with no restrictions. It’s the most popular on GitHub (44.69% of licensed projects).
  • License text: MIT

• Apache License

  • Includes patent protection and requires documenting changes.
  • When to use: Good for projects where you want to encourage adoption and protect against patent disputes.
  • License text: Apache-2.0

• BSD Licenses (2-Clause and 3-Clause)

  • Similar to MIT, with slight variations (e.g., 3-Clause adds a non-endorsement clause).
  • When to use: Choose this for simplicity and flexibility, especially if MIT feels too basic.
  • License text: BSD-2-Clause, BSD-3-Clause

Creative Commons Licenses

Primarily for non-software works (e.g., docs, media), these mix-and-match terms like attribution (BY), share-alike (SA), no commercial use (NC), or no derivatives (ND).

• CC0 (Public Domain Dedication)

  • Waives all copyright claims.
  • When to use: Use if you want no restrictions, but note it lacks a warranty waiver.
  • License text: CC0-1.0

• CC BY and CC BY-SA

  • BY requires attribution; SA adds a copyleft-like requirement.
  • When to use: Great for documentation or datasets, not software (per Creative Commons’ advice).
  • License text: CC-BY-4.0, CC-BY-SA-4.0

Note: NC and ND variants aren’t open source because they limit use or modifications.

Public Domain and Similar

These aim to release code with no restrictions.

• Unlicense
  • Waives copyright but includes a warranty disclaimer.
  • When to use: Use this over raw public domain for liability protection.
  • License text: Unlicense

Specialized Licenses

For specific use cases like fonts or hardware:

• SIL Open Font License (OFL)

  • Keeps fonts open and usable.
  • When to use: Perfect for font projects.
  • License text: OFL-1.1

• CERN Open Hardware Licenses

  • Covers hardware designs (permissive, weakly reciprocal, or strongly reciprocal).
  • When to use: Use for open hardware projects like furniture or electronics.
  • License text: CERN-OHL-P-2.0, CERN-OHL-W-2.0, CERN-OHL-S-2.0

When to Use Which License

Choosing a license depends on your project’s goals and dependencies.

Standalone Projects

• Copyleft (e.g., GPL, AGPL): Pick this if you want to enforce openness in all derivatives—ideal for ideological projects or tools you want to stay free.
• Permissive (e.g., MIT, Apache): Go this route if you want maximum adoption, including in commercial products, with minimal rules.
• Specialized (e.g., OFL, CERN): Use these for non-software works like fonts or hardware.

Check what similar projects use for inspiration. ChooseALicense.com can help narrow it down.

Projects with Dependencies

Your license must be compatible with the licenses of code you build on:

• GPL-licensed dependencies: You’ll likely need to use GPL too due to its viral nature.
• Mixed projects: Use multiple licenses (e.g., MIT for code, CC BY-SA for docs), but clarify what applies where.

Key Considerations

• Understand it: Read the license. Changing it later is tough, especially with contributors, as you’d need everyone’s permission.
• Liability: Most licenses (except raw public domain) limit your liability—don’t skip this protection.

How to Add a License

1. Pick a license from ChooseALicense.com or the list above.
2. Add a LICENSE.txt file with the full text to your project root.
3. Mention it in your README.
4. Optionally, add a license header to source files.

GitHub will detect it and display a summary.

Final Thoughts

Open source licenses aren’t just legal boilerplate—they shape how your project lives in the world. Whether you choose a restrictive copyleft license or a free-for-all permissive one, make sure it fits your vision. And don’t forget: no license means no sharing.

Overview: All 47 Open Source Licenses at a Glance

Before diving into the detailed descriptions, here’s a comprehensive table of all 47 open source licenses from ChooseALicense.com, organized by category:

1. Permissive Licenses

These licenses let others use your code freely, even in proprietary projects, usually just requiring attribution.

• 0BSD (BSD Zero Clause License)

  • Description: A super-simple BSD variant with no attribution requirement—basically public domain with a liability disclaimer.
  • When to Use: Perfect if you want no strings attached, not even credit, for maximum reuse.
  • Full Text

• AFL-3.0 (Academic Free License v3.0)

  • Description: Offers broad permissions with patent protection and a notice preservation clause.
  • When to Use: Great for academic or research projects needing patent clarity.
  • Full Text

• Apache-2.0 (Apache License 2.0)

  • Description: A popular choice with patent grants and attribution requirements.
  • When to Use: Ideal for encouraging wide adoption, especially in commercial settings, with patent protection.
  • Full Text

• Artistic-2.0 (Artistic License 2.0)

  • Description: Balances permissiveness with some rules on modifications; tied to the Perl community.
  • When to Use: Use for Perl-related projects or if you want a permissive license with a slight protective twist.
  • Full Text

• BlueOak-1.0.0 (Blue Oak Model License 1.0.0)

  • Description: A modern, plain-language permissive license with patent and trademark clauses.
  • When to Use: Pick this for readability and simplicity in permissive licensing.
  • Full Text

• BSD-2-Clause (BSD 2-Clause “Simplified” License)

  • Description: A minimal permissive license requiring attribution and a non-endorsement clause.
  • When to Use: Go for this if you want a lightweight, widely compatible option like MIT.
  • Full Text

• BSD-2-Clause-Patent (BSD 2-Clause Plus Patent License)

  • Description: BSD-2-Clause with an explicit patent grant.
  • When to Use: Use when you want BSD simplicity plus patent protection.
  • Full Text

• BSD-3-Clause (BSD 3-Clause “New” License)

  • Description: Adds a non-endorsement clause to BSD-2-Clause.
  • When to Use: A solid choice for permissive licensing with a bit more formality than MIT.
  • Full Text

• BSD-3-Clause-Clear (BSD 3-Clause Clear License)

  • Description: A variant of BSD-3-Clause with clearer wording.
  • When to Use: Opt for this if you prefer a polished version of BSD-3-Clause.
  • Full Text

• BSD-4-Clause (BSD 4-Clause “Original” License)

  • Description: An older BSD license with an advertising clause.
  • When to Use: Rarely used now due to complexity; stick to newer BSD options unless required.
  • Full Text

• BSL-1.0 (Boost Software License 1.0)

  • Description: A concise permissive license, popular for C++ libraries like Boost.
  • When to Use: Excellent for libraries or tools needing minimal restrictions.
  • Full Text

• ISC (Internet Systems Consortium License)

  • Description: A simplified BSD license, common in networking software.
  • When to Use: Use for infrastructure projects wanting a short, permissive license.
  • Full Text

• MIT (MIT License)

  • Description: The go-to permissive license, requiring only attribution.
  • When to Use: Choose this for ultimate flexibility—perfect for web or JavaScript projects.
  • Full Text

• MIT-0 (MIT No Attribution License)

  • Description: MIT without the attribution requirement.
  • When to Use: Use when you want MIT’s simplicity but no credit needed.
  • Full Text

• MS-PL (Microsoft Public License)

  • Description: Permissive with a patent clause, used in Microsoft projects.
  • When to Use: Good for Microsoft ecosystem projects needing patent coverage.
  • Full Text

• NCSA (NCSA Open Source License)

  • Description: Combines BSD and MIT with a patent grant.
  • When to Use: Ideal for academic software needing both copyright and patent protection.
  • Full Text

• PostgreSQL (PostgreSQL License)

  • Description: A MIT-like license used by PostgreSQL.
  • When to Use: Use for database projects or to align with PostgreSQL’s community.
  • Full Text

• UPL-1.0 (Universal Permissive License 1.0)

  • Description: Permissive with an explicit patent grant, often for Java projects.
  • When to Use: Pick this for Java libraries or patent-sensitive projects.
  • Full Text

• Zlib (Zlib License)

  • Description: A short permissive license with a non-endorsement clause.
  • When to Use: Great for small tools or libraries needing minimal obligations.
  • Full Text

2. Copyleft Licenses

Copyleft licenses ensure derivatives stay open source, perfect for protecting project openness.

• AGPL-3.0 (GNU Affero General Public License v3.0)

  • Description: GPL with a network clause—source must be shared if accessed online.
  • When to Use: Use for web apps where you want all changes shared, even remotely.
  • Full Text

• CECILL-2.1 (CeCILL License v2.1)

  • Description: A French copyleft license, GPL-compatible.
  • When to Use: Choose for projects in France or needing French legal alignment.
  • Full Text

• ECL-2.0 (Educational Community License v2.0)

  • Description: Apache-based copyleft for educational use.
  • When to Use: Good for academic projects wanting to enforce openness.
  • Full Text

• EPL-1.0 (Eclipse Public License 1.0)

  • Description: Copyleft with patent clauses, used by Eclipse projects.
  • When to Use: Use for Eclipse-related work or patent-sensitive projects.
  • Full Text

• EPL-2.0 (Eclipse Public License 2.0)

  • Description: Updated EPL with better GPL compatibility.
  • When to Use: Pick this for newer Eclipse projects or GPL-friendly needs.
  • Full Text

• EUPL-1.1 (European Union Public License 1.1)

  • Description: Multilingual copyleft for EU projects.
  • When to Use: Use for EU-based or multilingual projects needing copyleft.
  • Full Text

• EUPL-1.2 (European Union Public License 1.2)

  • Description: Updated EUPL with improved compatibility.
  • When to Use: Go for this in modern EU projects needing copyleft clarity.
  • Full Text

• GFDL-1.3 (GNU Free Documentation License v1.3)

  • Description: Copyleft for documentation, often paired with GPL.
  • When to Use: Use for manuals or docs tied to GPL software.
  • Full Text

• GPL-2.0 (GNU General Public License v2.0)

  • Description: Strong copyleft requiring derivatives to stay open.
  • When to Use: Pick for older projects wanting robust openness guarantees.
  • Full Text

• GPL-3.0 (GNU General Public License v3.0)

  • Description: Updated GPL with patent and hardware protections.
  • When to Use: Use for new projects needing strong, modern copyleft.
  • Full Text

• LGPL-2.1 (GNU Lesser General Public License v2.1)

  • Description: Weaker copyleft allowing linking to proprietary code.
  • When to Use: Ideal for libraries used in proprietary software.
  • Full Text

• LGPL-3.0 (GNU Lesser General Public License v3.0)

  • Description: Updated LGPL with GPL-3.0 compatibility.
  • When to Use: Use for modern libraries balancing openness and flexibility.
  • Full Text

• MPL-2.0 (Mozilla Public License 2.0)

  • Description: File-based copyleft allowing proprietary mixing.
  • When to Use: Good for projects wanting partial copyleft with flexibility.
  • Full Text

• MS-RL (Microsoft Reciprocal License)

  • Description: Copyleft requiring same-license derivatives if original code is used.
  • When to Use: Use in Microsoft ecosystems needing balanced copyleft.
  • Full Text

• MulanPSL-2.0 (Mulan Permissive Software License v2)

  • Description: Permissive with weak copyleft, aimed at China’s market.
  • When to Use: Choose for projects targeting China with some protection.
  • Full Text

• OSL-3.0 (Open Software License 3.0)

  • Description: Copyleft with a network use clause like AGPL.
  • When to Use: Use for network software needing source disclosure.
  • Full Text

3. Public Domain and Similar

These waive most restrictions, aiming for maximum freedom.

• CC0-1.0 (Creative Commons Zero v1.0 Universal)

  • Description: A public domain dedication waiving all rights.
  • When to Use: Use to give up all control, but note no liability disclaimer in some regions.
  • Full Text

• Unlicense

  • Description: Public domain dedication with a warranty disclaimer.
  • When to Use: Pick this for a simple, legally safer public domain option.
  • Full Text

• WTFPL (Do What The F*ck You Want To Public License)

  • Description: Ultra-permissive with no conditions or protections.
  • When to Use: Use for a bold freedom statement, but it lacks legal weight.
  • Full Text

4. Specialized Licenses

Tailored for specific content like fonts, hardware, or documentation.

• CC-BY-4.0 (Creative Commons Attribution 4.0)

  • Description: Requires attribution for non-software works.
  • When to Use: Use for docs, datasets, or media needing credit.
  • Full Text

• CC-BY-SA-4.0 (Creative Commons Attribution-ShareAlike 4.0)

  • Description: CC-BY-4.0 with a copyleft clause.
  • When to Use: Pick for non-software where derivatives must stay open.
  • Full Text

• CERN-OHL-P-2.0 (CERN Open Hardware License v2.0 Permissive)

  • Description: Permissive for hardware designs.
  • When to Use: Use for hardware projects wanting broad use.
  • Full Text

• CERN-OHL-S-2.0 (CERN Open Hardware License v2.0 Strongly Reciprocal)

  • Description: Strong copyleft for hardware.
  • When to Use: Choose for hardware needing full openness.
  • Full Text

• CERN-OHL-W-2.0 (CERN Open Hardware License v2.0 Weakly Reciprocal)

  • Description: Weak copyleft for hardware, allowing some proprietary use.
  • When to Use: Use for hardware balancing openness and flexibility.
  • Full Text

• LPPL-1.3c (LaTeX Project Public License v1.3c)

  • Description: For LaTeX projects with distribution rules.
  • When to Use: Pick for LaTeX packages or docs in that ecosystem.
  • Full Text

• ODbL-1.0 (Open Database License v1.0)

  • Description: Copyleft for databases, requiring share-alike.
  • When to Use: Use for open data projects needing derivative openness.
  • Full Text

• OFL-1.1 (SIL Open Font License v1.1)

  • Description: For fonts, allows embedding but not standalone sales.
  • When to Use: Choose for font projects keeping them open.
  • Full Text

• Vim (Vim License)

  • Description: Charityware encouraging donations, used by Vim.
  • When to Use: Use to support charity, though rare outside Vim.
  • Full Text

Choosing Your License

With 47 options, here’s how to narrow it down:

• Permissive: MIT, Apache-2.0, BSD-2-Clause for max adoption.
• Copyleft: GPL-3.0, AGPL-3.0, MPL-2.0 for openness enforcement.
• Public Domain: Unlicense or CC0-1.0 for no restrictions.
• Specialized: CC-BY-4.0, OFL-1.1, CERN-OHL for docs, fonts, or hardware.

Sources

A Developer’s Guide to Open Source Software Licensing
Open Source License Usage on GitHub.com
List of Open Source Licenses
Choose an Open Source License