Choosing a LICENSE
A LICENSE file at the root of your repo tells the world what they may legally do with your code. The default under copyright law is all rights reserved — without a license, no one else has permission to use, copy, modify, or redistribute your code, even though it is public on GitHub. If you want other people to use your project, you need a license.
The most common mistake
The licenses you will actually see
License | Type | In plain English |
|---|---|---|
MIT | Permissive | Do whatever you want, just keep my name in the LICENSE. No warranty. |
Apache-2.0 | Permissive | Like MIT, plus an explicit patent grant and stricter notice rules. |
BSD-3-Clause | Permissive | Like MIT, plus you cannot use my name to endorse your fork. |
ISC | Permissive | Tiny MIT-equivalent; npm default for years. |
GPL-3.0 | Strong copyleft | Use it freely, but anyone who distributes a derivative must also open-source it under GPL. |
LGPL-3.0 | Weak copyleft | GPL for libraries: link to it freely, but modifications to the library itself must be GPL. |
AGPL-3.0 | Network copyleft | GPL extended to network use: if you run a modified version as a SaaS, you must share the source. |
MPL-2.0 | File-level copyleft | Modifications to MPL files must be shared; other files in your product can stay proprietary. |
Unlicense / CC0 | Public domain | Effectively no rights reserved. Use without attribution. |
Permissive vs copyleft — the one decision
Permissive (MIT, Apache, BSD) — let anyone do anything, including build proprietary products on top. Maximizes adoption.
Copyleft (GPL, AGPL) — derivatives must also be open source under the same terms. Spreads software freedom virally.
Public domain (CC0, Unlicense) — no attribution required. Useful for code samples, libraries you want everyone to use without thinking.
How to pick
Want the maximum number of users and companies adopting your code? MIT or Apache-2.0.
Library used by other libraries? MIT is the path of least resistance in the JS/Ruby/Go ecosystems.
Project where you really want patent protection? Apache-2.0 (the patent grant is explicit).
You want every fork and SaaS that uses your code to also be open source? AGPL-3.0.
A drop-in library for desktop apps, but you do not want commercial forks staying private? LGPL-3.0.
Just sharing code samples? CC0 or MIT.
Adding a license on GitHub
On the repo home page, click Add file → Create new file and name it exactly
LICENSE(no extension).GitHub detects the filename and offers a Choose a license template dropdown.
Pick your license, fill in your name and year. Commit.
GitHub now displays the license name on the repo home page and on search results.
From the CLI with gh
# Create a fresh repo with a license picker gh repo create my-app --public --license=MIT --gitignore=Node # Or add to an existing repo: gh repo edit --add-topic open-source # (then add LICENSE through the web UI or paste from choosealicense.com)
The LICENSE file convention
Filename must be
LICENSEorLICENSE.md(orLICENSE.txt). GitHub matches on this.Lives at the repo root, not inside
docs/orlegal/.Contents are the full text of the license, unmodified, with your name and year filled in where placeholders exist.
Do not write your own license. Use a recognised one. Custom licenses confuse lawyers and discourage adoption.
License headers in source files
Some licenses (Apache-2.0 in particular) recommend a short header at the top of each source file. This makes attribution survive even when one file is copied out of the repo.
A standard SPDX-style header
// SPDX-License-Identifier: Apache-2.0 // Copyright 2026 Your Name // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0
For permissive licenses, a single SPDX comment is enough:
SPDX one-liner
// SPDX-License-Identifier: MIT // Copyright 2026 Your Name
License compatibility
You can usually combine code under different licenses only if the licenses are compatible. Permissive licenses (MIT, Apache, BSD) generally are compatible with each other and with GPL. GPL-licensed code can be combined with MIT, but the resulting product becomes GPL. AGPL combined with MIT is AGPL. When in doubt, pick the more restrictive license for the combined work.
Combining | Result |
|---|---|
MIT + MIT | MIT |
MIT + Apache-2.0 | Apache-2.0 (most strict) |
MIT + GPL-3.0 | GPL-3.0 |
Apache-2.0 + GPL-3.0 | GPL-3.0 only (not GPL-2.0) |
Anything + AGPL-3.0 | AGPL-3.0 |
Anything + proprietary | Cannot redistribute the proprietary part |
Private / proprietary repos
For internal company code, do not add an OSS license — it sets the wrong default. Either include a short LICENSE.proprietary saying "All rights reserved. Internal use only." or no license file at all (the legal default).
A minimal proprietary notice
Copyright (c) 2026 Acme Corp. All rights reserved. This software and associated documentation files are proprietary and confidential. Unauthorized copying, distribution, modification, or use is strictly prohibited.
The resources to actually use
choosealicense.com — GitHub-run tool that walks you through a few questions and recommends a license. Use this if you are unsure.
spdx.org/licenses — the canonical list of license identifiers used in
SPDX-License-Identifierheaders.tldrlegal.com — plain-English summaries of every common license.
Open Source Initiative (opensource.org) — definitive list of approved open source licenses.
Updating or relicensing
Adding a more permissive license later is generally fine (you owned the code, you can grant more rights).
Switching from permissive to copyleft is harder — older versions remain under the old license forever; only new contributions are governed by the new license.
Switching the license of code with outside contributors usually requires their explicit agreement (a Contributor License Agreement, CLA, or DCO sign-off).