How to Choose an Open-Source License

The license you pick decides how every future user can legally use your code. This guide covers the practical criteria, the main license families, and the mistakes that quietly cause problems later.

Why the license matters

In most jurisdictions, code is copyrighted the moment you write it. Publish a repository with no license at all and you have reserved all rights: others can view it but have no legal permission to use, copy, modify, or distribute it. Posting to a public host like GitHub does not waive your copyright, and the platform's terms of service do not grant other users a usage license. A license is the document that says "here is what you are allowed to do."

A license also protects you. Every mainstream open-source license includes a warranty disclaimer and a liability limitation, so users cannot hold you responsible when the software breaks something. Skip the license and you lose that protection too.

Permissive vs copyleft: the core decision

Almost every choice reduces to one question: do you want to require that derivative works stay open? That splits licenses into two families.

Permissive licenses

Permissive licenses (MIT, BSD 2-Clause and 3-Clause, Apache License 2.0) let anyone use your code almost any way, including inside closed-source and commercial products, as long as they preserve your copyright notice and license text. Choose one when your priority is adoption and you do not mind your code being used in proprietary software.

Copyleft licenses

Copyleft licenses require that modified versions, and sometimes larger works that include your code, be distributed under the same license. The GPL (v2 and v3) is "strong" copyleft: a program that links your code generally must itself be GPL. LGPL is "weaker," designed for libraries so an application can link to them without becoming copyleft itself. MPL 2.0 and the EPL are "file-level" copyleft: changes to the licensed files must be shared, but you can combine them with proprietary code in separate files. The AGPLv3 closes the "SaaS loophole" by also triggering source-sharing obligations when users interact with a modified version over a network, even if no binary is distributed.

The decision criteria, step by step

Work through these in order; the first answer that clearly applies usually settles it.

1. How do you want your code used? Happy for it to appear in proprietary products? Lean permissive. Want every downstream version to remain open? Lean copyleft.
2. Do you need an explicit patent grant? Apache 2.0, GPLv3, and MPL 2.0 include an express patent license and patent-retaliation terms; MIT and BSD do not mention patents. For anything touching patentable techniques, an explicit grant reduces risk.
3. What do your dependencies require? License compatibility flows downstream. If you depend on GPL-licensed code and distribute the result, your combined work generally must be GPL too. Check what you already pull in before deciding.
4. Is it a library or an application? Libraries meant for wide reuse usually pick permissive or LGPL/MPL so they do not force a license on the consumer. Standalone applications can use strong copyleft more freely.
5. Is it network-delivered software? If the value is a hosted service and you want competitors who modify it to publish their changes, AGPLv3 is the relevant option. Note that some companies prohibit AGPL software internally, which can limit adoption.
6. Does a community standard apply? Many ecosystems have a de-facto default (much of the JavaScript and Rust world favors MIT, Apache 2.0, or a dual MIT/Apache combination). Matching the norm lowers friction.

When to choose each common license

If a no-rights-reserved release is genuinely your goal, Creative Commons CC0 and the Unlicense aim to place work in the public domain, though their legal effect varies by country. For most software, a permissive license is a safer, more portable choice than a public-domain dedication.

How to apply the license correctly

A license only helps if you install it properly so tools and humans can detect it.

• Add a file named LICENSE (or LICENSE.txt) in the repository root with the full, unmodified license text. Do not paraphrase it.
• Fill in the placeholders. MIT and BSD expect a copyright line such as Copyright (c) 2026 Your Name. Apache 2.0 keeps a fixed body but uses an optional NOTICE file for attributions.
• State the license in your project documentation so it is visible at a glance. Scaffold this with a README.md Generator, and generate the license text with a License Picker.
• For multi-file projects, an SPDX comment such as SPDX-License-Identifier: MIT at the top of each source file makes per-file licensing machine-readable.
• Keep release hygiene consistent: a .gitignore Builder avoids committing build artifacts, and a Changelog Generator documents what changed between versions.

Common mistakes to avoid

• Publishing with no license. The most common error. Without one, the default is "all rights reserved" and nobody can legally reuse your code.
• Editing the license text. Modifying the warranty or liability clauses creates a new, unrecognized license. Use the canonical text exactly.
• Ignoring dependency compatibility. You cannot relicense code you do not own. Combining incompatible licenses, such as redistributing GPL code under MIT, is not permitted.
• Confusing software and content licenses. Creative Commons licenses are designed for media and documentation, not source code; the CC organization itself advises against using them for software.
• Assuming a license is forever. You can relicense your own future releases, but you generally cannot revoke rights already granted, and outside contributors hold copyright on their contributions unless you collect a contributor agreement.

When in doubt, default to a well-known license rather than something custom. Familiar terms are easier for users, lawyers, and compliance scanners to trust, which is what gets your code adopted. For versioning the releases you license, see our guide on semantic versioning and the SemVer Comparator.

Frequently Asked Questions