Choosing a License: Four Questions and a Table

Pick MIT if you don’t mind what people do with your code, Apache-2.0 if you care about patents, GPL-3.0 if you want changes to come back, and AGPL-3.0 if those changes run on servers. That’s the whole chapter for most readers. The rest is for explaining the choice, applying it properly, and changing it later.

No license means no permission#

Copyright applies to code the moment it’s written. Publishing it on GitHub doesn’t change that: without a license, others can read your code, but not use, copy, modify or share it (choosealicense.com). A license is the permission.

An open-source license grants that permission under conditions. The Open Source Definition, maintained by the Open Source Initiative (OSI), lists ten criteria a license must meet to count: free redistribution, access to the source, the right to make derived works, no discrimination against people or fields of use, and six more. The OSI approves licenses against it. Stick to an approved one: companies’ legal teams already know them, and a license you write yourself is one they’ll have to read.

Four questions pick the license#

1. Is it code? For documentation, images or other content, use a Creative Commons license: CC-BY-4.0 to require credit, CC0-1.0 to waive everything. Creative Commons itself recommends against its licenses for software. Licenses for Things That Aren’t Code covers the rest: fonts, hardware, data. For code, go on.
2. Must modified versions stay open? If you don’t mind someone shipping a closed product built on your code, you want a permissive license: question 3. If you want their changes to come back as open source, a copyleft one: question 4.
3. Do patents matter? Apache-2.0 grants a patent license from every contributor, and withdraws it from anyone who sues over patents in the project. Companies often prefer it for that. If patents don’t matter to you, MIT says the same in far fewer words.
4. Where does the code run?
   • On servers that people use over a network: AGPL-3.0. Plain GPL only applies when a program is distributed, and a web service isn’t.
   • As a library inside other people’s programs: MPL-2.0 (changes to your files come back) or LGPL-3.0 (changes to your library come back). The program that uses it keeps its own license.
   • Anywhere else: GPL-3.0.

Ten licenses, side by side#

What each license asks of the people who use your code, from choosealicense.com’s summary of each text, with a project that uses each one (as of September 2026):

Every one of them also disclaims warranty and liability: the code comes as is.

Copyleft follows the code, not the project#

“Changes must come back” means something precise, and it depends on how the code is used.

• In an app you distribute, GPL code makes the whole program GPL: if you ship it, you ship its source under the same license.
• In a web service, GPL asks for nothing, because the program is never distributed: users only talk to it. AGPL-3.0 closes that gap, and asks you to offer the source of your modified version to the users who interact with it over a network.
• In a library, LGPL-3.0 and MPL-2.0 draw the line around the library or its files. A closed application can use them; changes to the library itself come back.

This is why AGPL-3.0 worries companies. Google’s open-source policy says code under it “MUST NOT be used at Google”, and many companies have similar rules. For some projects, that’s the point: Grafana moved to AGPL-3.0 in 2021 so that anyone who modifies it and runs it as a service shares their changes back.

Apply it in three places#

1. A LICENSE file at the root, with the full text, the year and the copyright holder. On GitHub, create a file named LICENSE, and a Choose a license template button fills it in (GitHub’s docs). GitHub then shows the license in the repository’s About box.

2. The license field of your manifest, with the SPDX identifier, so that package managers and compliance tools read it without guessing:

{ "license": "MIT" }

# pyproject.toml, since PEP 639
license = "MIT"
license-files = ["LICENSE"]

# Cargo.toml: the Rust ecosystem's usual dual license
license = "MIT OR Apache-2.0"

3. An SPDX header in each file, optional but precise when a repository mixes licenses. The REUSE specification and its reuse lint tool check that every file has one:

// SPDX-FileCopyrightText: 2026 Your Name
// SPDX-License-Identifier: MIT

For the GPL family, choose “only” or “or later”. GPL-3.0-only stays on version 3; GPL-3.0-or-later lets users apply a future version the Free Software Foundation publishes. The Linux kernel is GPL-2.0-only, one reason it never moved to GPL-3.0.

You can only relicense what you own#

Switching your own code to another license is easy: publish the next version under it. Code that others contributed is theirs, under the license they contributed it under. To relicense a project with outside contributions, you need the agreement of every contributor, or a contributor license agreement (CLA) they signed that grants you that right. The Developer Certificate of Origin (DCO), which the Linux kernel uses, only certifies that contributors have the right to submit their code: it doesn’t let you relicense it. CLA or DCO covers both, from each side.

Old versions keep their license, whatever happens next. That’s how OpenTofu and Valkey could fork Terraform and Redis from their last open-source versions, after both companies moved to licenses that aren’t open source. Relicensing has the whole timeline, and the licenses they moved to.

Tools#

• choosealicense.com, by GitHub: the licenses compared, and “no license” explained.
• SPDX License List: every identifier, with the full texts.
• licensee: the tool GitHub uses to detect a repository’s license. Run it to see what GitHub will see.
• REUSE, by the Free Software Foundation Europe: SPDX headers in every file, and a linter for them.

License Compatibility covers the other direction: the licenses of the code you include.

Do this now#

• Check that your project has a LICENSE file, and that GitHub shows its name in the About box.
• Put the SPDX identifier in the license field of your manifest.
• If you use a GPL-family license, decide between “only” and “or later”, and use the matching identifier.
• Look up the license of your three biggest dependencies, and check that it allows what you do with them.

Go further#

• choosealicense.com: the same choice, as a site, with each license’s text.
• The Open Source Definition: the ten criteria, and why each one is there.
• REUSE: licensing every file of a repository, and proving it.
• Reading a Repository in Five Minutes: the license is the first thing to check, from the user’s side.