Open source licenses: Everything you need to know

Open source makes the technology world go ’round, forming as much as 90% of the modern software stack via frameworks; libraries; databases; operating systems; and countless standalone applications.

The benefits of open source software are well understood, promising greater control and transparency. However, there’s a perennial struggle between the open source and proprietary realms, leading many companies to retreat from open source to protect their commercial interests. At the heart of all this is the thorny issue of licensing.

There are two broad kinds of licenses that meet the formal open source definition as laid out by the Open Source Initiative (OSI). “Permissive” licenses carry few restrictions in terms of how users can modify and distribute the software, making them popular with companies that wish to use it commercially. And then there are “copyleft” licenses, which offer similar freedoms but with one notable caveat: Any modified version of the software must also be distributed under the same original copyleft license. This isn’t so appealing to businesses wishing to protect their proprietary work.

But there is more to it than that, with various licenses existing within each bucket. Moreover, there are countless licenses that, while not strictly open source, are also worth knowing about.

Permissive

MIT

Originating at the Massachusetts Institute of Technology in the 1980s, the aptly-named MIT license is the most popular open source license by most metrics, sitting in the top spot among the GitHub development community for many years.

Used by projects including React (front-end JavaScript library) and Ruby (general purpose programming language), the MIT license allows developers to use software however they like. As with most such licenses, it’s provided without warranties, meaning authors are absolved from any liability resulting from damages caused by their software (e.g. data loss). All developers need to worry about is including the original copyright notice and MIT license in any derivative work.

But the MIT license has one shortcoming: It doesn’t explicitly grant patent rights. This means that if a given piece of software relies on patented technology, this might create legal uncertainty for developers who deploy the software without securing separate permissions for said patented technology.

However, this underscores one of the key selling points of the MIT license: with just 200 words, the language is simple and concise. Muddying things with ambiguous, word-soup patent spiel would add needless complexity for projects unlikely to be concerned with patents, such as high-level programming languages or web frameworks.

But plenty of open source projects do intersect with patented technologies, such as hardware-centric software like Android.

Apache License 2.0

The Apache Software Foundation published the Apache License 2.0 in 2004, an update to an earlier license with an explicent patent grant to protect users from litigation. So if a developer were, for example, to contribute a unique image processing algorithm to a project licensed under Apache 2.0, any patents that developer holds on that algorithm are automatically licensed to all users of the software.

Most people will be familiar with Google’s brand of Android, replete with app store and suite of home-grown tools and services. But the underlying Android Open Source Project (AOSP) is substantively available under the Apache 2.0 license, a deliberate move by Google in 2008 to combat Apple and encourage phone manufacturers to use Android versus the other proprietary incumbents (e.g. Symbian) of the time. And it worked. Samsung, HTC, LG, and all the rest jumped on Android.

A byproduct of this, though, is that the Apache License 2.0 has around five times the number of words of MIT, owing to the patent grant text, among other additions and clarifications. But that’s the trade-off, and it illustrates the key distinctions between the two most common permissive open source licenses.

Other permissive licenses

The BSD 2-Clause License is similar to MIT, but with key differences in terms of the language used. For instance, it specifies that a copy of the license should be included with both the source code and the compiled binary form. And then there is the BSD 3-Clause License, which has an additional “no endorsement” clause that restricts the use of the names of the copyright holders and contributors for promotional purposes in any derivative project.

There’s also the MIT No Attribution License (MIT-0), which is simpler than the MIT, in that there is no requirement for attribution in derivative software. Using this is close to putting software in the public domain, except the author does retain the copyright and ability to change things in the future.

Copyleft

GNU General Public License (GPL) v. 2.0 and 3.0

The Free Software Foundation (FSF) published the GNU General Public License (GPL) in 1989, and was one of the first copyleft licenses for general use.

Copyleft licenses are often better suited for projects requiring input from the community, versus projects supported by a single corporate entity. By requiring that all modifications remain available under the same open source license, this assures contributors that their hard work won’t be used in proprietary software without also benefiting the wider community — in theory, at least, as it can be difficult to discover every contravention and then enforce the terms of the license.

Launched in 2007, GPL 3.0 is the third most popular license, according to GitHub data. The license ushered in notable updates on GPL 2.0, including patent grant provisions and improved compatibility with other open source licenses. It also prohibits what has come to be known as “Tivoization,” where hardware makers that benefit from GPL-licensed software prevent users from installing modified versions of that software, using digital rights management (DRM) mechanisms.

Notable GPL adopters include WordPress, which is available under a GPL 2.0 “or later” license, leaving it to the developer to decide which license they distribute any modification under.

Linux, for its part, is among the most successful open source projects of all time, used in servers, cloud infrastructure, embedded systems, and even Android. However, the underpinning Linux kernel is only available under a GPL 2.0 license, given that Linux creator Linus Torvalds is against some of the provisions added in version 3.0 of the license — including the Tivoization clause.

GNU Affero General Public License (AGPL) 3.0

The Affero General Public License (AGPL) is similar to GPL 3.0, insofar it’s a “strong” copyleft license that promotes software freedoms and ensures modified versions remain open source. However, a key distinction with AGPL is that it’s focused on web-based services and applications, where the software is run from servers rather than distributed as executable files.

Under a GPL 3.0 license, developers aren’t required to release the source code for modified software if it’s run across a network, as SaaS applications are. The AGPL license closes this loophole, requiring third-parties to make the source code available even if the modified software is only running from a server.

Published in 2007 by the Free Software Foundation, the AGPL 3.0 license has grown in popularity due in large part to the rise of cloud computing and SaaS, and today it’s the fifth most popular open source license.

GNU Lesser General Public License (LGPL)

Also a product of the Free Software Foundation, the GNU Lesser General Public License (LGPL) is a “weak” copyleft license, insofar as it’s more business friendly with less stringent stipulations on what is shared. LGPL is normally used for software libraries where project authors want to encourage contributions from the community, but it allows proprietary software to link to the libraries without having to open source their entire proprietary code. If someone modifies the open source library itself, then they need only release those modifications under the LGPL license.

Mozilla Public License 2.0

Published by the Mozilla Foundation in 2012, the Mozilla Public License (MPL) 2.0 is the tenth most popular open source license today as per GitHub’s licenses metric. MPL is also a weak copyleft license designed to protect proprietary code while enabling developers to benefit from open source software.

However, while LGPL is focused at the library level, and GPL at the project level, MPL operates at an individual file level requiring the user to share a narrower set of code.

Public domain and creative commons

While an “open source license” grants specific rights, there’s always stipulations attached. Those who want to place their software entirely in the public domain without any caveats, however, can do so through other means.

It’s not enough to simply publish software without a license; copyright law applies by default to most creative works, including software. This is where a “public domain dedication” can help.

Designed specifically for software, the Unlicense is the ninth most popular license on GitHub (though whether it can actually be called a “license” is debatable). Even though the OSI approved it as a license in 2020, it noted that the document is “poorly drafted” and questioned its legal efficacy in jurisdictions (e.g. Germany) where it’s not possible to donate work to the public domain.

Like the Unlicense, Creative Commons’ CC0-1.0 is also a public domain dedication tool, though its focused more broadly on creative works. It uses clearer, more professional legal language that might be more in tune with international law. It’s worth noting that Creative Commons applied to have CC0-1.0 approved as an open source compliant license in 2012, but withdrew the application after the OSI raised concerns that it explicitly excluded patent grants.

There are other public dedication tools, such as Zero-Clause BSD, which might appeal as it has even simpler language. However, there’s no consensus on the best mechanism for giving away all rights to a given piece of software.

“Faux-pen” source

There are countless other licensing paradigms across the software spectrum.

In some cases, businesses will release software under a dual-license model, with the user able to choose between a recognized open source license and a commercial license, depending on their intentions. Then there is “open core,” which offers the software under an open source license, but with key features paywalled. In other instances, a company might add a Commons Clause addendum to an otherwise permissive open source licence, putting commercial restrictions in place.

There are also plenty of licenses that look and smell like open source, but are ultimately incompatible with the open source definition.

In 2018, database giant MongoDB transitioned from a copyleft AGPL license to the server side public license (SSPL), a license of MongoDB’s own creation. While the SSPL is still fairly “open,” it’s what is known as “source available,” in that the code is accessible but has significant commercial restrictions, which is a big no-no as far as the OSI is concerned.

The folks at MariaDB forged a similar path with the business source license (BUSL), which imposes commercial restrictions before transitioning to a true open source license after a set number of years. There is another similar movement under way that’s looking to make “fair source” licensing a thing. This includes the Functional Source License, which is touted as a simpler alternative to BUSL.

You may also come across so-called “ethical source” licenses from time to time, such as the Hippocratic License, which prohibits the use of software in violation of internationally recognized human rights. Similarly, the open standard JSON file format has an extremely permissive license, barring one hilarious clause at the end: “The Software shall be used for Good, not Evil.”