How do you add a license to a GitHub repository?

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.

Adding a license to an existing repository

Exactly the same steps. Nothing about an existing repository makes it harder: add the file, commit, done. GitHub detects it on the next push.

One detail worth knowing. The licence covers the code you distribute with it. Earlier commits were published without one, so if it matters that the licence covers the whole history, say so in the README.

Changing the license on a repository

Replace the contents of LICENSE with the new licence text and commit. GitHub re-detects it and updates the sidebar.

What does not change is everything already published. Every copy taken under the old licence keeps the old licence, permanently. And if other people have contributed, their code is theirs: you need their agreement, or a contributor licence agreement they signed, before you can relicense it. Why that is, and why projects that skip this get stuck, is in dual licensing.

Using more than one license in one repository

Two common patterns.

A choice of licences for the whole project. Ship both texts, usually as LICENSE-MIT and LICENSE-APACHE, and state in the README that users may choose either. Much of the Rust ecosystem does this with MIT or Apache 2.0.

Different licences for different parts. A root LICENSE for most of the code, plus a separate licence file in the directory it governs, for example documentation under a Creative Commons licence or a vendored library under its own terms.

Either way, GitHub’s sidebar shows one licence or “Other”, because detection reads the root only. The README is where the real answer has to live.

SPDX license identifiers

SPDX identifiers are the standard short names for licences: MIT, Apache-2.0, GPL-3.0-only, BSD-3-Clause. They are what goes in the license field of package.json, Cargo.toml or pyproject.toml, and what tools use to check licence compliance automatically.

They also work as a one-line header in each source file:

// SPDX-License-Identifier: MIT

Combinations are written as expressions: MIT OR Apache-2.0 means the user picks, MIT AND BSD-3-Clause means both apply. GitHub uses the same identifiers when it shows which licence it detected.

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. What copyright covers by default is in is code protected by copyright. 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: $500+ each to AI labs.             │
│                                                                      │
│  [ See what my 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.

If you want to sell the software rather than give it away, the file you need is a different kind of licence altogether: proprietary software licences covers what goes in one.

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. How to set that, and why it has to be from the start, is in how to make a GitHub repository private. 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