How do you add a license to a GitHub repository?
Create a file called LICENSE in the repository root and paste the full text of the license you have chosen, filling in the year and copyright holder. GitHub detects it automatically and shows the license in the sidebar. You can also use Add file, then Create new file, type LICENSE, and pick a template from the chooser that appears.
Two minutes of mechanics, then the part people get wrong.
The fastest way
In the repository, choose Add file, then Create new file. Type LICENSE as
the filename. A “Choose a license template” button appears next to the
filename box. Click it, pick a license, and GitHub inserts the full text with
the year and your name already filled in. Commit.
GitHub then detects it and shows the license name in the sidebar and in search results.
The manual way
Create a file named LICENSE in the repository root, paste the full text of
your chosen license, and replace the placeholders for year and copyright
holder. Commit and push.
Use LICENSE, LICENSE.md, or LICENSE.txt, and put it at the root.
Automatic detection depends on the name and location; the legal effect does
not, but you want both.
What GitHub is actually doing
Detecting, not deciding. It matches your file against known license texts and displays what it found. It confers nothing and verifies nothing.
Two consequences worth knowing. If you modify the text of a standard license, detection may fail and the sidebar will say “Other”, even though your terms are perfectly valid. And detection applies to the root file only, so a repository with per-directory licensing will be reported by its root file alone.
The part people get wrong
public repo, no LICENSE file
│
└── default copyright applies
│
├── may others use it? ────────► no
├── may they modify it? ───────► no
├── may they redistribute it? ─► no
└── may they read it? ─────────► yes, that is all Publishing code is not licensing it. Copyright arises automatically and no licence means no permission. A public repository with no LICENSE file is the most restrictive thing you can publish: everyone can look, nobody can use.
Almost nobody intends that. People publish expecting “public means free to use” and it does not.
The reverse error is rarer but more expensive. Adding a permissive licence is irreversible for every copy already distributed. You can change the licence on future versions; you cannot revoke the grant on what is already out there. Decide before you publish rather than after.
┌─ WORTH CHECKING ─────────────────────────────────────────────────────┐ │ │ │ Private, finished, owned by you, and doing nothing. │ │ │ │ [ See what your repos are worth ] │ │ │ └──────────────────────────────────────────────────────────────────────┘
Related files worth adding
NOTICE. Required by Apache 2.0 if you are distributing a modified work that had one. Carries attribution that must travel with copies.
COPYRIGHT or AUTHORS. Optional. Useful on projects with many contributors.
CONTRIBUTING.md. Not a licence, but the place to state that contributions are accepted under the project’s licence, which saves an awkward conversation later if you ever want to relicense.
The decision underneath the mechanics
Adding the file is easy. Choosing what goes in it is the actual question, and it is covered in open source licenses compared.
The short version: Apache 2.0 for most things you want widely used, MIT if you prefer brevity over the patent grant, AGPL if you are publishing a service and do not want a closed hosted competitor built on it.
One thing this does not decide
Whichever licence you pick, publishing the repository settles its commercial future: public code has already been collected into training corpora and there is no licensing market left for it.
That is not an argument against open source. It is an argument for being deliberate about which repositories you publish at all, because the ones you keep private are the ones that retain value. That case is made in your MIT-licensed repo is worth nothing.
What to read next
- Open source licenses compared, choosing what goes in the file
- Software license types, including the non-open-source options
- Archiving a GitHub repository, what to do with repositories you are finished with
Common questions
- What happens if a repository has no license?
- Default copyright applies, which means nobody has permission to use, copy, modify, or distribute it. Public and unlicensed is the most restrictive state a public repository can be in, and it is usually not what the author intended.
- Does the file have to be called LICENSE?
- For automatic detection, use LICENSE, LICENSE.md, or LICENSE.txt in the repository root. Other names and locations still function legally but GitHub may not display the license in the interface.
- Can I license different parts of a repository differently?
- Yes. A common pattern is a LICENSE file at the root plus a separate license file in a subdirectory that it governs. Document it clearly in the README, because tooling will usually only detect the root file.
- Do I need to add a copyright header to every source file?
- Not for most permissive licenses, though some organisations require it and Apache 2.0 recommends it. A single root LICENSE file is sufficient for MIT.
- Does adding a license to a private repository do anything?
- Nothing practical while it stays private, since nobody has access to rely on it. It matters at the moment you publish, and it is worth deciding before then rather than after.