When you hear the word “permissive,” you probably think of something without many rules or restrictions. And that isn’t far from the reality when it comes to permissive open source software licenses. Permissive licenses are one of the two major categories of open source licenses; copyleft licenses, which carry more stringent requirements on use of the licensed code, are the other.

Typically, software under a permissive license can be modified, copied, added to, subtracted from, etc. without any obligation to share those updates. Developers can take the permissive-licensed software, make it their own through changes or additions, keep their new version to themselves, or share it if they choose to. This is a major feature if you’re looking to create proprietary software that you can sell and keep secret from competitors — and one of the main reasons why permissive licenses are popular.

These freedoms associated with the use of permissive-licensed code stand in contrast to the stronger requirements of copyleft licenses, which require any derivative work of the licensed software to be distributed only under the same copyleft license. That means that any developer who modifies or adds to the original software is generally required to share the source code of those changes when distributing software that includes copyleft-licensed code.

In this blog, we’ll take a close look at all things permissive licenses, including more on how they compare to copyleft licenses, their use cases, history, and their role in the open source software community.

The History of Permissive Licenses

The first permissive license is generally agreed to be the Prior BSD license, which was the forerunner of the first “official” BSD license (known as the 4-clause BSD license today). This “proto-BSD” license appeared in the late 1980s. About a decade prior, computer scientists at UC Berkeley began working on a Unix-based operating system that came to be known as the BSD (Berkeley Software Distribution) OS. As other institutions began using this OS, some developers began altering and adding to the source code, then requesting that these changes be incorporated into the next release.

In 1989, Berkeley’s Network Release 1 included the earliest precursor of the BSD license, basically stating that the code could be reused or modified. After all, it already was. A year later, the 4-clause BSD license was officially released. Since then, the 3-clause, 2-clause, and 0-clause licenses have joined the BSD family. Today, the 3-clause version is the most popular.

The MIT License, currently the most-used OSS license, was developed around the same time as the first BSD license. However, its origin story is a bit murky. In response to a question on Twitter, two of the computer scientists involved with the creation of the original license, Jim Gettys and Keith Packard, responded with what they remembered about the experience. Both helped develop the X Windows System at MIT.

According to Packard, they added a license to X version 6 when it was released in 1985. It turned out that distributing the software under this license was a big challenge, prompting Gettys to quip that they should simply give it away. However, making it public domain wouldn’t work because then IBM wouldn't use it. So they consulted with MIT's lawyers to craft language that stated the software could be used and modified by anyone.

Subsequent versions contained similar wording, and the license became known as the X Consortium license. In fact, when the Open Source Initiative (OSI) shared its first cohort of approved OSS licenses in 1999, it noted that the MIT License was sometimes called the X Consortium License. However, the X Consortium license and the “official” version of the MIT License, which was released in 1998, aren’t the same license, using different language to convey a similar sentiment.

Still, the precursor to what is now the MIT License seems to have existed nearly a decade before the current version was written. If true, this makes it one of — if not the — earliest permissive OSS licenses.

Permissive vs. Copyleft Licenses

Open source software licenses can be categorized into two groups: permissive and copyleft. The major differences between the two involve the license compliance conditions and how “open” any changes to the code must be.

In general, permissive licenses only require users to include two things in any redistribution of the licensed software: the original copyright notice and a copy of the license text. Copyleft licenses have this condition as well. However, they also require users to offer the source code of any modifications to all recipients of the binary — and place those modifications under the same license. Thus, all reworkings of the code end up exactly as “open” as the original.

One thing to note: Although it's generally relatively easy to comply with the terms of a permissive license, there is a difference between software under a permissive and software in the public domain. While there are public-domain-equivalent OSS licenses (the BSD 0-clause license, or Creative Commons 0, for example), permissive licenses don’t fall into this category. Generally, works in the public domain have no usage requirements while permissive licenses do come with stipulations, however minor.

Permissive License Use Cases

Choosing the right license for a particular software project depends on a number of factors, such as how you want other developers to interact with your code and how open (pun intended) you are to having changes to your code made proprietary/closed-source.

Still, there are some general situations in which a permissive license might be the most appropriate choice. For instance, a permissive license may be the best fit for your project if you:

  • Want to make it simple and appealing for others (including large commercial enterprises) to use your code. After all, a big-name tech company might not want to modify your software if they can’t keep their own version proprietary.
  • Need your project to be compatible with GPL-licensed code. For example, the BSD or MIT License is compatible with every member of the GNU GPL license family.
  • Are creating a project within a community that tends to use a specific permissive license. In this case, peer pressure is a good thing. For instance, If everyone else is using the MIT License, you probably should, too.
  • Don’t want to spend time or resources managing complex license compliance issues. With permissive licenses, open source users don’t need to worry about source code disclosure requirements

If you’re still trying to decide which license to use, this guide can help, as can other OSS contributors.

Types of Permissive Licenses

Unlike copyleft licenses, which come in “strong” and “weak” varieties, permissive licenses don’t fall neatly into categories. However, the most popular options each have their own quirks. The MIT License, for instance, is known for its brevity, flexibility, and ease of use. Basically, it states that a user can do anything they want with the code, including copy it, modify it, add to it, distribute it, and sell it, as long as they include the license text and the original copyright notice.

The Boost Software License (BSL) is quite similar to (albeit far less popular than) the MIT License, except that the BSL doesn't require you to include a copyright notice or license text — if your software is distributed in compiled code form (object libraries, shared libraries, executables).

The BSD 3-Clause license is also functionally very similar to the MIT License. One additional condition is that users of BSD 3-licensed code are prohibited from using the name of the project or its contributors to market or promote their derivative work without express written permission. This caveat makes it an attractive option for OSS developers who don’t want their software used without being given credit. But, arguably, no permissive license grants any such rights in the first place — which would be more like a trademark license than a copyright license.

In the permissive license ecosystem, the Apache License 2.0 stands out a bit. It includes the usual stipulations, but also requires users to state significant changes to the software. Releasing the source code of the modifications is not necessary; simply including notifications of any modifications is sufficient to comply with the license terms. In addition, the Apache License 2.0 includes an explicit grant of patent rights, and a defensive termination provision, which provides some protection against lawsuits to both licensor and licensee.

Permissive Licenses in the OSS Community

Permissive licenses are growing in popularity across the OSS community. More than half of open source projects use either the MIT License or the Apache License 2.0, and in the neighborhood of two-thirds use some type of permissive license.

A number of high-profile OSS projects are using permissive licenses, increasing the attention these licenses receive. The MIT License, for example, is used by Ruby on Rails, jQuery, and Angular.js, while Apache 2.0 is the license of choice for Kubernetes, TensorFlow, and Swift. In fact, all Apache Foundation projects — some of which are widely used — are under the Apache 2.0 License.

With such strong and steady growth in usage, permissive licenses don’t seem to be a passing trend. Most likely, these licenses will only continue to play a bigger and bigger part in the OSS community.