Answer 4 questions
—
—
LICENSE
Add the license file to the root of your repository. Most package managers (npm, PyPI, crates.io) read it automatically. Reference the license in your README and in package.json / pyproject.toml / Cargo.toml via the license field using the SPDX identifier shown above.
Why your project needs a license
Code on GitHub without a license is, by default, fully copyrighted. Nobody can legally use it, modify it, or redistribute it — even if your README says "feel free to use this". The repository's "public" visibility doesn't grant any rights; it just lets people read the source. Adding a license file is the only way to give others the legal permission to do something with your code.
Pick something — anything is better than nothing. The legal default of "all rights reserved" prevents adoption, kills contributions, and creates ongoing risk for anyone who installs your package thinking it was free to use.
The six licenses that cover 99% of cases
- MIT — the most permissive popular choice. Anyone can do anything with your code as long as they keep the copyright notice. The shortest, simplest license. Used by React, Rails, Bootstrap, Vue, and most npm packages.
- Apache-2.0 — MIT-equivalent permissions plus an explicit patent grant (users get a patent license, anyone suing for patent infringement loses their license). Slightly longer; preferred for any project where patent litigation is a realistic concern. Used by Kubernetes, Android, TensorFlow, Swift.
- BSD-3-Clause — equivalent to MIT in practice, with an extra clause forbidding use of the author's name for endorsement. Used by Go, FreeBSD, PostgreSQL.
- MPL-2.0 — "weak copyleft" at the file level. Modifications to MPL-licensed files must be open-source; new files added to the project don't have to be. The Mozilla Public License — used by Firefox itself, terraform, and several Rust projects.
- GPL-3.0 — "strong copyleft". Any project that statically or dynamically links to GPL code must itself be GPL. This includes proprietary apps; using a GPL library in a closed-source product is a license violation. Used by GCC, GIMP, WordPress core (debatable).
- AGPL-3.0 — GPL plus the "network use" clause: if you run modified AGPL code as a public service, you must release the modifications. Closes the SaaS loophole. Used by MongoDB historically, Mastodon, Element / Matrix server.
For non-code work
The Creative Commons licenses are designed for content (writing, images, music, design files) rather than code. The most common variants:
- CC BY 4.0 — anyone can use, share, and adapt the work for any purpose as long as they credit you.
- CC BY-SA 4.0 — same, but derivatives must use the same license (copyleft for content). Used by Wikipedia and Stack Overflow.
- CC BY-NC 4.0 — non-commercial use only. Note: "non-commercial" is hard to define legally and limits enterprise contributions; consider carefully.
- CC0 — public-domain dedication. Use for anything, no attribution required. Closest to "I give up all rights".
Common mistakes
- Custom-written licenses. Resist the urge. An ambiguous home-rolled license creates legal uncertainty that scares away every potential user. Pick a standard SPDX-listed option.
- Inconsistent declarations. If your
LICENSEfile says MIT but yourpackage.jsonsays Apache-2.0, you've created a legal ambiguity. Keep them aligned and use the SPDX identifier exactly ("MIT","Apache-2.0","GPL-3.0-only"). - Forgetting the copyright year. Some licenses require a "Copyright (C) YEAR NAME" line. Templates leave this as a placeholder — fill it in with the actual year of first publication.
- Mixing GPL with proprietary code. If you pull in a GPL library, your project must also be GPL. This is the #1 audit finding in commercial codebases. Check your dependencies' licenses with
license-checker(npm) or similar tools. - License changes for existing contributors. Once people have contributed under MIT, you can't unilaterally switch the project to GPL without their permission. Get sign-off from contributors before changing licenses, or use a CLA from day one.
Common use cases
- Add a license to a new open-source project
- Choose between MIT and Apache-2.0 for a permissive option
- Determine whether you need AGPL for a SaaS project
- Pick a Creative Commons license for content (writing, images, music)
Frequently asked questions
MIT vs Apache-2.0 — which is better?
For most permissive projects: similar in spirit. Apache-2.0 adds an explicit patent grant (contributors waive patent claims) and is preferred when patent risk is a real concern. MIT is shorter and friendlier for tiny libraries. If in doubt, Apache-2.0 is the safer default.
When should I use GPL or AGPL?
GPL when you want any derived work to remain open-source. AGPL when you also want SaaS hosts to be required to share their modifications (closes the "I host your code as a service and never distribute it" loophole). Both significantly restrict commercial adoption — be sure that's what you want.
Can I use "no license"?
Technically yes — code defaults to "all rights reserved". Practically no: it prevents anyone from legally using your code, blocks adoption, and creates ambiguity. Even "Unlicense" or CC0 (public-domain dedications) is much better than nothing.
Can I change a project's license later?
Yes, but only with consent from all contributors. Once people have submitted code under MIT, you can't unilaterally re-license to GPL. A CLA (Contributor License Agreement) signed at contribution time gives you that authority.
For content rather than code, what should I pick?
Creative Commons. CC BY 4.0 (attribution-only) is the most adopted; CC BY-SA 4.0 if you want copyleft (Wikipedia uses this); CC0 if you want full public-domain dedication.