How to Choose and Write a LICENSE File for Your Open-Source Project

Public code is not the same as open source code

You push a project to a public repository, and it feels shared. It isn't, quite. Until you add a license, people can read your code but they have no clear permission to use it. This guide covers how to choose a license, how to write and place the LICENSE file, and how to check that GitHub recognized it. It sits alongside our guides to writing a README people read and setting up issue and pull request templates. This is general information, not legal advice.

Why a repo without a license is not open source

According to GitHub's documentation on licensing a repository, a repository with no license falls under default copyright law. In that case no one may reproduce, distribute, or create derivative works from your work, and you keep all rights to your source code.

Public visibility is a separate matter. GitHub's terms let other users view and fork a public repository, but that is not a license to reuse the code in their own projects. You are not required to pick a license, though GitHub strongly encourages open source projects to include one. A license is how you say, in plain terms, what others can and can't do with your source code.

Pick a license: permissive or copyleft

Most choices come down to one question. Do you want people to be able to fold your code into closed-source products?

Permissive licenses

Permissive licenses such as MIT let others reuse your software in proprietary and commercial projects. FOSSA's guide to applying a license calls MIT the most popular permissive option. Apache-2.0 and the BSD licenses are other familiar choices. Want the fewest obstacles to adoption? Start here.

Copyleft licenses

Copyleft licenses such as the GPL require people who distribute modified versions to share their source code under certain conditions. The same guide notes that the GPL does not allow incorporating a program into proprietary software, which is often a dealbreaker for commercial users. If you want improvements to flow back to the community, copyleft fits. If you want maximum adoption by companies, it may work against you.

Check your dependencies and contributors

Two things can change the answer. First, the strictest license among your dependencies can impose obligations on your users, even if your own license is permissive. Second, if outside people will contribute, think about relicensing now. Without a contributor license agreement, changing the license later may require written permission from every contributor.

To compare options side by side, use choosealicense.com, the resource GitHub points to for this decision. For anything with real legal stakes, such as a company project, talk to a qualified professional.

Name it and place it in the repository root

Put the license text in a plain-text file at the top level of the repository. GitHub's page on adding a license to a repository says to name it LICENSE or LICENSE.md, in all capital letters. Names like LICENSE.txt and LICENSE.rst are also common.

Some projects only mention the license in the README. GitHub's recommended best practice is to include the actual file, so keep the README line as a pointer and not as a replacement.

Package formats may ask for more. RubyGems, for example, checks a license field in the package metadata against known license names. If you publish to a package registry, set that field to match your LICENSE file.

Add the file on GitHub or from the command line

In the browser

1. Open the repository and choose Add file, then Create new file.
2. Type LICENSE or LICENSE.md as the file name.
3. Click Choose a license template, pick a license, and review it.
4. Click Review and submit, write a commit message, and commit.

If you are on the default branch, GitHub suggests committing to a new branch and opening a pull request. The license picker is aimed at new projects, so on an existing repository you may prefer to add the file by hand.

From the command line

Copy the full text of your chosen license from its official source into a file called LICENSE in the repository root. Then:

git add LICENSE
git commit -m "Add MIT license"
git push

Swap "MIT" in the message with whichever license you chose. Template licenses such as MIT include placeholders for the year and the name of the copyright holder. Fill those in with your own details before you commit, and don't edit the legal wording itself.

On an existing project, FOSSA suggests committing and pushing the file and then creating a new release or tag. The license applies from that version onward, and later changes only affect future versions.

Edit the text on any device

A LICENSE file is just plain text, so any editor works. If you keep repositories on your phone or Mac, a text and code editor like Carets opens it like any other file, which helps when you need to fix the year or name away from your desk.

Check that GitHub detected it

GitHub uses a Ruby gem called Licensee to compare your LICENSE file against a list of known licenses. When it finds a match, the license name appears on the repository's main page. If the license does not display, the file may contain multiple licenses or extra text. The fix GitHub suggests is to simplify the LICENSE file and explain the complexity somewhere else, such as the README.

Conclusion

Choose deliberately, put a plain-text LICENSE in the root, fill in the placeholders, and confirm the license name shows on your repository page. Then tag a release so it is clear which version carries the license. While you are tidying the repository, it is a good time to review your .gitignore file too.

Frequently Asked Questions

What happens if I publish code without a license?

Default copyright law applies. Others may not reproduce, distribute, or create derivative works from your code, even when the repository is public.

Should the file be called LICENSE or LICENSE.md?

Either works on GitHub. GitHub's instructions say LICENSE or LICENSE.md in capitals, and LICENSE.txt and LICENSE.rst are also common. Keep it in the repository root.

Can I change the license later?

For code you wrote alone, you can add a new license for future releases. With outside contributors and no contributor license agreement, you may need permission from each of them.

Is this legal advice?

No. GitHub provides license information as-is and recommends a professional for legal questions about your code, and the same applies here.