Your repo needs a LICENSE file. Here’s the fast way.
You pushed the project to GitHub, the README looks decent, and then it hits you: there’s no license. Without one, technically nobody can legally use your code. Not the way you’d hope, anyway. The default in most countries is “all rights reserved,” which is the opposite of what most people putting code on GitHub actually want.
Pick a license from the dropdown. Type your name and the year. The full, legally complete text shows up on the right with the placeholders already swapped in. Copy it, or download a file literally named LICENSE, and you’re done.
Eight licenses, and which one fits
The big three you’ll reach for most:
- MIT is the crowd favorite. Six short paragraphs, permissive, easy to read. React, jQuery, Rails, and roughly a third of all GitHub projects use it.
- Apache-2.0 is MIT with a real patent grant baked in. If your code touches anything patent-adjacent, or you just want that extra protection, this is the safer call. Kubernetes and Android lean on it.
- GPL-3.0 is strong copyleft. Anyone who distributes a modified version has to release their source under the GPL too. Pick it when you want derivatives to stay open, period.
Then the rest: BSD-2-Clause and BSD-3-Clause (permissive, the 3-clause adds a no-endorsement rule), ISC (npm’s default, basically MIT with fewer words), MPL-2.0 (file-level copyleft, a middle ground), and The Unlicense if you want to throw the code into the public domain and walk away.
Not sure? MIT for almost anything small. Apache-2.0 if patents worry you. GPL if you care about keeping forks open.
A couple of things worth knowing
The author and year fields only matter for licenses that actually use them. MIT, Apache, GPL, BSD, and ISC all stamp a copyright line with your name. The Unlicense and MPL-2.0 don’t, so those fields gray out automatically. No guesswork.
GPL-3.0 deserves a flag. The complete GPL text runs thousands of words and the FSF asks you not to alter it. What you get here is the standard copyright notice plus the short boilerplate, with a pointer to the canonical full text at gnu.org. For a real GPL release, append that full text. Same goes for MPL-2.0, where the convention is a short header at the top of each source file rather than one giant blob.
Everything happens in your browser. The templates are embedded right in the page, so nothing you type gets sent anywhere. Type a name, watch it appear. That’s the whole loop.
One naming tip: call the file LICENSE with no extension. GitHub and GitLab both detect that automatically and show a tidy license badge on your repo page. LICENSE.txt works too, but the plain version is the convention.
FAQ
Which license should I actually pick?
For most personal and small open-source projects, MIT. It’s short, permissive, and universally understood. Go Apache-2.0 if you want patent protection, or GPL-3.0 if you want to force derivatives to stay open source.
Is the generated text legally valid?
Yep. These are the exact canonical templates from the license authors (OSI, the FSF, Mozilla), with only the year and name placeholders filled in. The wording itself isn’t touched.
Why are the name and year boxes sometimes disabled?
Because that license doesn’t use them. The Unlicense and MPL-2.0 have no copyright placeholder, so the fields switch off to keep you from typing into a void.
Does the GPL output include the entire license?
No, and that’s on purpose. The GPL-3.0 full text is enormous and shouldn’t be modified, so you get the official short notice plus a link to gnu.org for the complete document. Bundle that full text in your release.
Can I change my license later?
You can, for future versions. Code already released under the old license stays available under it forever, since you can’t retroactively revoke what people already received. Pick something you’re comfortable with up front.