Open Source Licenses: MIT vs. Apache vs. GPL Explained

1. What is an open source license?

An open source license is a document in which the author gives others permission to use, change and share the code. Without one, default copyright applies: according to GitHub's docs, other GitHub users can view and fork code in a public repository, but nobody may reproduce it, distribute it or create derivative works from it. A public repository isn't automatically open source.

The OSI (Open Source Initiative) reviews licenses against the Open Source Definition and keeps a public list of the approved ones. The definition also bans restricting fields of use, so you can use open source software commercially.

2. Types of open source licenses

Open source licenses are either permissive or copyleft and copyleft can be weak or strong. Copyleft means a derivative work has to be released under the same or a compatible license, so the code stays open in later versions too.

3. MIT license

The MIT license lets you do almost anything with the code, including using it in a closed-source commercial product. The only condition is to keep the copyright notice and license text in all copies. It's a few paragraphs long and disclaims any warranty.

The license doesn't address patents; the word doesn't appear in its text at all. React and Vue both use it.

4. Apache License 2.0

The Apache License 2.0 is permissive like MIT, but it also grants an explicit patent license from every contributor. If you sue someone claiming the code infringes a patent, you lose that patent license. Kubernetes, for example, ships under Apache 2.0.

The license has a few more conditions than MIT: you have to mark changed files and if the project has a `NOTICE` file, you have to pass its contents on. It doesn't give you the right to use the author's trademarks. Watch out for compatibility too: you can include Apache 2.0 code in a GPL v3 project but, according to the Free Software Foundation, not in a project that's GPL v2 only.

5. GPL license: what copyleft means

The GPL license (GNU General Public License) requires anyone who distributes the program or a work based on it to pass on the source code under the same license. It doesn't ban commercial use: you can sell GPL software, but buyers get the same rights you have and can share it further.

According to the GNU licenses FAQ, you can change GPL code and use it inside your company without publishing anything and the same goes for a modified program you run on your website. Programs a website sends to its visitors, often written in JavaScript, are different: users have to get their source code under the terms of the GPL. GPL v3 treats any transfer of a copy as distribution, so delivering a desktop or mobile app to a customer counts too.

The GPL is in use today in versions 2 and 3. GPL v3 requires anyone who distributes the program to give recipients the patent licenses they need and it stops devices from blocking users from running a modified version. The Linux kernel is under GPL v2, while GIMP and Ansible are under GPL v3.

6. AGPL license: copyleft for web apps

The AGPL license (GNU Affero General Public License) builds on GPL v3 and also covers running software over a network. If you give users access to a modified version over the internet, you have to offer them its source code. That's the difference from the GPL and it mostly matters for web apps and services.

The Free Software Foundation recommends considering it for software that commonly runs over a network. Grafana and Mastodon both use it. Some companies don't allow it, though: under Google's policy, AGPL code must not be used at Google because the network terms are hard for the company to comply with. That can limit how widely a library gets adopted.

7. MIT vs. Apache vs. GPL: comparison

The comparison shows that MIT and Apache 2.0 differ mainly on patents, while MIT and GPL differ on whether derivative code has to stay open.

8. How to choose an open source license

Choosing an open source license comes down to what you want to happen to the code: maximum adoption or changes that stay open. The table below will help, as will Choose a License, which GitHub created.

9. How to add a license to your project

You add a license to a project with a file in the repository and a field in the package manifest. Once you've picked one, check that the libraries your app uses don't conflict with it.

1. 1

   Add a LICENSE file

   Put the full license text in the repository root and, for MIT, fill in the year and the copyright holder. GitHub detects the file and shows the license in the repository overview.

2. 2

   State the license in your manifest

   Use an identifier from the SPDX list, such as `MIT`, `Apache-2.0` or `GPL-3.0-or-later`, as the npm docs recommend. For a package you don't want to grant anyone rights to, use `UNLICENSED`.

3. 3

   Check your dependencies' licenses

   When your app uses a GPL library, the GNU licenses FAQ says the GPL's terms apply to the entire combination of app and library. A list of libraries with their licenses also belongs on your about screen and in your handover checklist.

{
  "name": "room-booking",
  "version": "1.8.2",
  "license": "MIT"
}

10. Where your app's license should be visible

Your app's license should be visible outside the repository, because customers, support and new maintainers may not have access to it.

In AboutTheApp, you fill in the app's license (pick one from the list or type your own) and a link to its text. The About page and About box then show it next to the author, version and links. You can attach related documents, such as a license agreement or terms of use, as links under Legal & Compliance. AboutTheApp doesn't choose a license for you or check that it's correct; it just keeps the details and links in one place.

11. How to track third-party licenses and show them on your About page

In AboutTheApp, you track third-party licenses for each app in the Components & Licenses window, which you open from the app's card. For each library, framework or font, you fill in the name, version, license, link, category and optionally a description. You pick the license from the same list as for the app or type your own.

The About page then shows the list publicly in the Components & Licenses tab, where visitors see the name, license and link and can filter by category. To show it inside your app, use the About box variant Credits & Licenses, which also lists the version and description.

Frequently asked questions