Open source · Licensing

Software Licenses Explained: MIT, Apache 2.0, GPL and How to Choose One for Your GitHub Project

Every public repository carries a question that nobody asks out loud: what am I allowed to do with this code? A software license is the answer. It is a short legal document, usually a file called LICENSE in the root of the repository, that tells other people what they may do with your source code. This post explains what licenses are, reads the MIT license line by line, compares the licenses you will meet most often, and helps you choose one for your next project.

1. What a software license is, and why code without one is not open source

A software license is a legal document that defines what other people are allowed to do with your source code when you publish a project. When you put an Android app, a Kotlin library, a Java application or any other project on GitHub, the LICENSE file tells other developers whether they can:

• Use your code in their own projects.
• Modify your source code.
• Distribute your application.
• Use your code commercially.
• Include your code in proprietary or closed-source products.
• Redistribute modified versions, and under which conditions.

No license does not mean free to use

The law gives you copyright over the code you write, automatically, the moment you write it. You do not need to register anything. So if you publish a repository with no license, the default is “all rights reserved”: nobody else may copy, change or redistribute your code without asking you.

Making the repository public changes only one thing: people can see it. GitHub’s terms let other GitHub users view and fork a public repository on GitHub, but that is all. A public repository without a license is not open source, and a careful developer or company will avoid copying it.

“Open source” also has a formal meaning. The Open Source Initiative (OSI) publishes the Open Source Definition, and a license counts as open source when it allows people to use, study, change and share the software freely. MIT, BSD, Apache 2.0, GPL, LGPL and MPL are all on OSI’s list of approved licenses.

2. A worked example: the MIT license, line by line

The MIT License is one of the most popular permissive open-source licenses, and it is a good first license to learn because it is so short. When a repository’s LICENSE file contains the MIT License, other developers can do all of this:

The conditions are short:

• They must keep the copyright notice.
• They must include the MIT license text when they distribute copies or substantial portions of the software.
• The author provides the software without any warranty.

In simple terms: people can use the code, even inside a commercial product, without asking the author for permission, as long as they follow the license. Here is the full text, with placeholders for the year and the copyright holder:

MIT License

Copyright (c) <year> <copyright holder>

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Reading it line by line

3. The licenses you will meet most often

Licenses fall on a spectrum. On the left are licenses that ask almost nothing of the people who reuse your code. On the right are licenses that require derivative work to stay open too.

MIT: very permissive

People can use, modify, distribute and sell the code, including inside closed-source software. They keep the copyright and license notice. It is short enough to read in a minute. Examples: React and Express.js.

Apache 2.0: permissive, with patent protection

Similar to MIT, but it also gives an explicit patent grant: people who contribute code license any patents that cover their contribution, which protects users from patent claims by contributors. It also has extra duties: keep the notices, and mark the files you changed. Examples: Kubernetes, Kotlin and AndroidX.

BSD 2-Clause and 3-Clause: permissive

Very close to MIT. Commercial use and redistribution are allowed with the copyright and license notices. The 3-Clause version also forbids using the contributors’ names to promote a derived product without permission.

GPL 3.0: strong copyleft

You can use, modify and distribute the software, and even sell it. The catch: when you distribute a derivative or a combined work, you generally have to offer the corresponding source code under the GPL as well. That keeps improvements open, and it also makes GPL code hard to use in closed-source products. Examples: GIMP and the Linux kernel (which uses GPL version 2).

A close relative is the AGPL, which treats software offered over a network (a web service, for example) like distributed software.

LGPL 3.0: copyleft for libraries

Designed for libraries. A proprietary application can generally use an LGPL library, with conditions such as allowing users to replace or relink the library. Changes to the library itself have to be shared.

MPL 2.0: file-level copyleft

If you change a file that is covered by the MPL, and you distribute it, that file must stay under the MPL. But you can combine MPL files with your own proprietary code in a larger application. It is a middle path between MIT and GPL. Example: Firefox.

Unlicense and CC0: public-domain dedications

These try to give up copyright restrictions as far as the law allows. How well that works depends on the country, which is why some people prefer a permissive license like MIT instead.

4. Permissive or copyleft: what changes in practice

The practical question is what happens when someone else builds on your code. This table is a simplified summary, so read the real license before relying on it.

5. Which license should you choose?

Start from your goal, not from the license names.

Questions to ask yourself

1. Do I mind if a company uses this in a closed product? If not, pick a permissive license. If yes, look at the GPL family.
2. Could patents be involved? If yes, Apache 2.0 (or MPL, or GPL 3.0) spells out the patent permission. MIT does not mention patents.
3. Is it a library or an application? Libraries that you want widely adopted usually use a permissive license or the LGPL.
4. Are other people contributing? Pick the license before accepting contributions. Changing it later usually needs everybody’s agreement.

6. LICENSE, COPYRIGHT and NOTICE: what each file is for

Also mention the license in your README, with a link to the LICENSE file. People read the README first.

7. Your license and your dependencies

A repository can contain or use third-party code that has different licenses. Putting an MIT license on your repository does not change the license of those libraries. Each dependency stays under its own terms, and you have to follow them.

For an Android app this matters a lot, because a typical project pulls in dozens of libraries, and many of them (AndroidX, Kotlin, OkHttp, for example) use Apache 2.0, which asks you to keep their notices. That is why many apps have an “Open source licenses” screen; Google’s OSS licenses Gradle plugin can generate one for you.

Can I mix code under different licenses?

When in doubt, check the dependency’s license before you ship, and keep a list of what you use.

8. Add a license to your GitHub repository

On the GitHub website

1. Open your repository and choose Add file, then Create new file.
2. Type LICENSE as the file name. GitHub then shows a Choose a license template button.
3. Pick a license, fill in your name and the year, and commit the file.

When you create a new repository, you can also choose a license in the creation form.

From the command line

# Copy the text of the license you chose into a file called LICENSE, then:
git add LICENSE
git commit -m "Add MIT license"
git push

GitHub detects standard license files and shows the license name in the repository sidebar. For a Maven or Gradle library, also declare the license in the build metadata, for example in pom.xml:

<licenses>
  <license>
    <name>MIT License</name>
    <url>https://opensource.org/license/mit</url>
  </license>
</licenses>

9. Common mistakes

10. Takeaways and glossary

• No license means “all rights reserved”, even on a public repository.
• Permissive licenses (MIT, BSD, Apache 2.0) ask for little. Copyleft licenses (GPL, LGPL, MPL) ask for shared changes.
• MIT or Apache 2.0 is a good default for educational and sample projects.
• Add the LICENSE file before you accept contributions, and mention it in the README.
• Your license covers your code, not your dependencies. Check theirs.
• For anything that matters commercially, ask a lawyer.

Links and further reading

• Choose a License (GitHub’s plain-language guide) · What happens with no license
• GitHub Docs: Licensing a repository
• Open Source Initiative: licenses · The Open Source Definition
• SPDX license list (standard identifiers)
• License texts: MIT · Apache 2.0 · GPL 3.0 · MPL 2.0 · Unlicense · CC0