How to use popular open source licenses, explained

Updated November 2, 2023

You are likely already aware that open source software is everywhere. Much has been written about the popularity of open source software, how it is the foundation of technology individuals use every day and the increasing adoption of open source by corporate enterprises. An often overlooked aspect of this narrative is the role of open source software licenses.  The open source license has enabled open source software to thrive. After all, software, like art or music, is subject to copyright, which gives an author the exclusive right to make copies of a work. You need the author’s permission to make copies or do anything else with it. One way you receive permission is in the form of a license.

Traditionally, closed source/proprietary software licenses would permit you to use the software. Open source licenses, by contrast, give you permission to use, modify and redistribute the software. Someone exploring open source software licenses for the first time might be intimidated. There are hundreds of different open source licenses and the sheer volume can be overwhelming. You can find open source software licenses that eschew traditional legal concepts in favor of references to beer, bouncy castles and even profanity.

Since open source software licenses don’t share a common framework,  two licenses may say very different things, but share the same meaning. Additionally, some open source licenses were written by programmers, others by lawyers. For lawyers, like myself, it can be difficult to discern technical references in a license written by a developer. And I am sure it is equally frustrating for developers encountering legalese in a more traditional open source license.

With that said, grasping a basic understanding of open source software licenses does not have to be a challenge. As an attorney at Capital One supporting our Open Source Program Office I help educate our software engineers and developers on the impacts of using code under the various open source licenses. That education leads to a better understanding of company policy and helps developers think strategically about their open source projects and what open source software they use.

The easiest way to understand open source licenses is to take a step back and look at patterns in the licenses. When you do that you see it is possible to group licenses that share common terms into certain categories:

• Permissive licenses

• Weak copyleft licenses

• Strong copyleft licenses

• Network copyleft licenses

This post will compare the different license categories, explaining what they mean, what you need to know about using a license in that category and why you might choose to use code under a license. I will also address the concept of Public Domain as a separate category from open source licenses.

The category of permissive licenses is a great starting point because generally these licenses are the easiest to understand. There are hundreds of variations of permissive licenses, but they all boil down to the same thing. With a permissive open source license you can do whatever you want with the code, just give the original author recognition as required by the license.

The main thing you may want to do, which is not always possible with other categories of open source licenses, is license the code under a different license. The language of a permissive license lets you combine the original code with your own code and then license that combined work with whatever license you want, or even no license at all. Note, the original code may still remain under the original license depending on that license’s terms (this is the case with Apache 2.0 for example), but you are never required to continue using the original license for your modified or derivative work. That is what distinguishes permissive licenses from the different versions of copyleft licenses that will be discussed later.

There are hundreds of variations of permissive licenses, but they all boil down to the same thing. With a permissive open source license you can do whatever you want with the code. Just give the original author recognition as required by the license.

If it sounds simple, it is. Permissive licenses are designed to be appealing to a wide audience of users. Part of that appeal is the additional freedom of relicensing the code in modified/derivative works and part is how easy it is to comply with the requirements of a permissive license--recognizing the original author. Almost always, you are asked to recognize the original author by including a copy of the license with your program. This retains the copyright notice and tells subsequent users that the program contains open source software under a permissive license. The idea being that a person could track down the open source code to review it themselves. That’s it, that notice is normally your only requirement for open source software under a permissive license.

Henry, a developer, wants to use Library A in his project. Library A is under the MIT license, a permissive open source software license. Henry wants to make modifications to Library A and combine it with his own proprietary code.

• Must Henry release his application under the MIT license? No. In fact, his application doesn’t need to be open source at all. He could sell the application as a commercial product as long as he includes the MIT license with “all copies or substantial portions of the Software.”

• MIT

• BSD (many variations)

• Apache License 2.0

If we consider the open source license categories as a spectrum, next to permissive licenses are the slightly more restrictive weak copyleft licenses.

Weak copyleft open source software licenses require the original code and modifications to that code, to remain under the same license. You may combine code under a weak copyleft license with other code under different licenses because the weak copyleft license only applies to the individual component and not the broader program. Often the component must be distinguished from the rest of the application, usually by requiring it to remain in a separate file. The draw of a weak copyleft license is that you get some benefit of the copyleft concept (the ability to see improvements and modifications to your original work), while still appealing to users who may shy away from strong copyleft licenses because of concerns about the need to disclose the source code of their broader program.

Weak copyleft open source software licenses require the original code and modifications to that code, to remain under the same license. You may combine code under a weak copyleft license with other code under different licenses because the weak copyleft license only applies to the individual component and not the broader program.

One important thing to understand with weak and strong copyleft licenses is that  distribution triggers the conditions in the licenses.

Distribution is a concept from copyright law, is basically giving someone a copy of something. In other contexts, this is very straightforward. With a book, for example, if I make copies of the book available and hand you the book it has been distributed. You received a copy of it. With software it is slightly more complicated. If a user downloads the software to their device or is provided a copy of it on a flash drive it has been distributed. But increasingly software is developed using a SaaS model and in those instances users are accessing the software, but not receiving a copy of it, so distribution has not occurred. More on that subject in the discussion of Network Copyleft licenses, but for now what is important to understand is that if there is no distribution the copyleft requirement for a weak copyleft license does not apply.

Looking back at our earlier example, Henry again uses Library A under the MIT license, but now wants to combine it with Library B, which is under the Eclipse Public License 2.0, a weak copyleft license. Henry has modified Library B to fix a bug. The program will also contain additional proprietary code.

• If Henry distributes the program does he have to disclose the source code for the additional proprietary code within the program? No. He must disclose the source code related to the modifications of Library B, but the copyleft requirement from the EPL 2.0 does not apply to the additional proprietary code in the program.

• Could Henry distribute the combined program under the MIT license? No. The MIT license would not ensure that Library B is “under a license that satisfies the requirements of” EPL 2.0.

• Could Henry distribute the combined program under the EPL 2.0 license? Yes. The MIT license is permissive which allows distributing Library A under a different license and he could choose to open source his proprietary code.

• If Henry does not distribute the program, must he disclose the code for the bug fix he applied to Library B? No. If the code is not distributed this requirement does not apply.

• Eclipse Public License 2.0

• Mozilla Public License 2.0

• Common Development and Distribution License 1.1

This particular license somewhat straddles the line between weak and strong copyleft and does not really fit in perfectly with either category. The important consideration for a library that is licensed under the LGPL is how it is linked within the application. It can generally be treated as a weak copyleft license if it is dynamically linked. If it is statically linked there are other requirements for compliance.

With an understanding of weak copyleft it is easier to grasp what constitutes a strong copyleft open source software license. A strong copyleft open source software license applies the copyleft requirement more broadly to the larger program instead of it being limited to the single component. In other words, if you use code under a strong copyleft license within your program you generally (though not always) would need to apply the terms of the strong copyleft license to the entire program.

A strong copyleft open source software license applies the copyleft requirement more broadly to the larger program instead of it being limited to the single component.

There are two key considerations when working with code under a strong copyleft license:

• What constitutes a single work

• License compatibility

This is an important question because it defines the scope of the copyleft requirement. The most popular strong copyleft license is the GNU General Public License. Version 2 of that license (still widely, if not the most widely, used version) states that:

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Unfortunately, this language does not provide clear guidance on the scope of the copyleft requirement within GPL v 2.0 and established case law on interpretation of this provision is lacking. Version 3 of the GPL helped a bit by introducing a definition of Corresponding Source that clarified, “it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.” The Free Software Foundation has provided some input on its interpretation of what constitutes a single program, which is a helpful starting place but should not be treated as a definitive answer.

Outside of clear aggregation, determining what constitutes a single program versus separate works requires a fact-intensive legal analysis of the work in question, which is beyond the scope of this post. What is helpful for you to know is that if you are considering using code under a strong copyleft license and will be distributing your work you should consider the implications and seek guidance early on in the development cycle.

To be clear, license compatibility is not only an issue for strong copyleft licenses, however, this category of licenses creates most of the compatibility issues we see with open source software. That is because strong copyleft licenses require conditions that apply outside of the original work to other components within the program. How then, if combining code from two separate packages, can one simultaneously comply with a condition of a weak copyleft license that the code (and modifications to it) from that package remains under the weak copyleft license without further restrictions and a condition from a strong copyleft license that any single work containing the other package needs to be under the strong copyleft license? You cannot, it is not possible, which illustrates the license compatibility issue.

Some licenses (mostly weak copyleft ones) include creative solutions to address the compatibility issue. The Eclipse Public License 2.0, for example, allows anyone wishing to use that license also to designate a “secondary license,” meaning the code would be under both licenses. That would create compatibility with the GPL. Similarly, Mozilla Public License 2.0 permits “a combination of Covered Software with a work governed by one or more Secondary Licenses” when the “Covered Software is not Incompatible With Secondary Licenses.” Secondary Licenses are defined in the MPL 2.0 as GPL 2.0, LGPL 2.1, AGPL 3.0, or any later versions of those licenses.

Discussion of compatibility so far has focused on the compatibility of the copyleft requirement, but other provisions of open source licenses that can create compatibility problems. As an example, the Free Software Foundation, the steward of the GPL licenses, contends that the permissive Apache 2.0 license is incompatible with the GPL 2.0 license because the patent termination provision in Apache 2.0 is an additional requirement not permitted by GPL 2.0. This is just to illustrate that compatibility needs to be analyzed by looking at all of the provisions of the licenses being used, not just the copyleft condition.

Back to our running example. Henry wants to create a business selling a flash drive that contains two separate programs: a computer game licensed under GPL 2.0; and a photo editor licensed under Apache 2.0.

• Is this permissible? Yes. Although GPL 2.0 and Apache 2.0 may not be compatible, Henry doesn’t need to be concerned about that because these are not a single program and GPL 2.0 clearly allows distribution of an aggregate of separate programs under different licenses.

• Henry wants to develop an additional application that will be a combination of Library A licensed under the MIT license and Library B under the GPL 2.0, is this permissible? Yes. The permissive MIT license would allow the entire application to be licensed under GPL 2.0.

• Henry wants to add Library C, which is under the EPL 2.0 to the application, is this permitted? Maybe. It would depend on whether the original author of Library C designated GPL 2.0 as a secondary license.

• GPL 2.0

• GPL 3.0

• Sleepycat

• Creative Commons Share Alike License (many versions, mainly used for documentation)

Network copyleft open source software licenses are an expansion of strong copyleft licenses. Recall that strong copyleft licenses expanded the scope of the copyleft requirement compared to weak copyleft licenses. The scope for network copyleft licenses is the same as strong copyleft licenses (applies to the entire program), but the application is broader. With these licenses the copyleft requirement is triggered anytime the program is run over a computer network.

These licenses are a response to changes in software development and use today. The original GNU General Public License (grandfather of strong copyleft licenses) was written in 1989. It could not contemplate the modern software landscape, so network copyleft licenses were developed to apply the copyleft condition to new use cases/situations common in modern software development. Copyleft proponents were especially concerned with the gap created by software as a service (SaaS). When open source software is used within a SaaS program it is not considered distributed or conveyed so the copyleft condition from strong copyleft licenses does not apply. Network copyleft licenses close that gap by changing the trigger of the copyleft condition to  run the program over a computer network. That puts SaaS programs in scope for these licenses. 

For network copyleft licenses the scope is the same as strong copyleft licenses (applies to the entire program), but the application is broader. With these licenses the copyleft requirement is triggered anytime the program is run over a computer network.

Henry modifies Library A, which is licensed under GPL 2.0 and uses the modified library with other proprietary code in a SaaS program he hosts.

• Must he disclose the source code for the modifications and proprietary code? No. The code in his program is not distributed so the copyleft condition from GPL 2.0 does not apply.

• What if he modifies Library B, which is licensed under AGPL 3.0, and he uses the modified library with other proprietary code in a SaaS program he hosts? Yes. In this case he would have to disclose the source code for the entire program (modifications to Library B and proprietary code) because users of his program would be “interacting with it remotely through a computer network.”

• AGPL 3.0

• Common Public Attribution License 1.0

• European Union Public License 1.2

Public Domain is often mistaken as the name of an open source license, but Public Domain is really a concept, not a license and should be thought of differently. I’ve saved the discussion of Public Domain for last because I think it is easier to understand once you have a grasp of what licenses do (grant permissions and require conditions), but if you are thinking of these categories as being on a spectrum of compliance difficulty, code placed in the Public Domain is even easier to use than permissively licensed open source software.

If the code is in the public domain, it is free from copyright. You don’t need a license permitting you to use it and there are no restrictions for how you use it. While that sounds simple in theory, public domain software has two major problems. 

1. First, placing something in the public domain is not straightforward. Works created by the United States federal government are free from copyright and in the public domain. Works that reach a certain age can have their copyright expire at which point they are in the public domain. But when something is created by a private citizen in 2021 that work is copyrighted automatically without any action required. It then must be explicitly dedicated to the public domain. There are no magic words to do that so evaluating whether something has been truly placed in the public domain requires an analysis of the author’s expression.

2. Second, the public domain is not a universally recognized international concept. Different countries have different requirements for placing something in the public domain and some countries do not recognize the concept. It is easy to see the problems this can present when you have software being developed by contributors worldwide. A contributor from a country that does not recognize the public domain would retain copyright over their work.

If code is in the public domain, it is free from copyright. You don’t need a license permitting you to use it and there are no restrictions on how you use it.

Henry modifies Library A, which is in the public domain (assume it has been properly placed in the public domain), and combines it with proprietary code to make a mobile application he plans to sell to the public.

• Is this permissible? Yes. Henry can use the public domain code for any purpose, he does not need to disclose the source code or to give any notice or attribution. Using the code in closed source, commercial software is perfectly acceptable.

An ongoing development in the realm of open source software licensing is the emergence of new licenses tailored for specific, niche use cases. This trend is not limited to a particular year, as companies, organizations and individuals consistently encounter scenarios where existing open source licenses may not fully cater to their unique needs.

A recent example is the Server Side Public License (SSPL) introduced by MongoDB in late 2018. MongoDB did not believe the AGPL sufficiently covered the situation of a cloud vendor offering their databases as a service, and so they drafted a license that targeted that use case. In 2021 we saw a similar situation with Elastic transitioning to a dual licensing model with the SSPL and Elastic License 2.0. 

Elastic was concerned about their product being offered as a managed service and the circumvention of license keys for their commercial offerings. The Elastic license addresses these situations with specificity not found in commonly used open source software licenses. It is important to note that neither the SSPL nor the Elastic License have been approved by the Open Source Initiative (OSI), essentially a governing body for open source software licenses.

The OSI has approved four new open source software licenses in 2021. Notably the Cryptographic Autonomy License is a new license intended for cryptographic applications. This is an area to watch because the need for new licenses must be balanced with the consequences of license proliferation. License proliferation is a major problem in open source licensing and the volume of licenses can create compliance problems.

Another topic of interest in 2021 was the impact of the United States Supreme Court’s decision in Google v. Oracle. The Court issued its decision on April 5, 2021.  This case was about the copyrightability of Oracle’s Java SE API. Ultimately the Court determined that Google’s copying of the API was a fair use of the material.  A decision on whether the API could be copyrighted in the first place likely would have had greater repercussions, but the Court declined to address that issue and instead for argument’s sake assumed it could be.  The narrow holding might limit its impact, but because case law in this area is sparse and immature, it is uncertain if there will be a lasting effect and it will be something to continue to keep an eye on.

My hope is that after reading this post you will better understand the basic categories of open source software licenses and why a particular open source license falls into one category versus another. Hopefully you can also start thinking about why a license in one category might be more appealing than another. There is no correct answer and it will depend on how you use the code and the objective of what you are working on.

If you are interested in learning more about open source software licenses the next step on your journey would be looking closer at the specific terms of individual licenses. Many open source software licenses contain provisions related to warranty disclaimers or patent licenses among others. These provisions can be important and might influence you to choose one permissive license over another for instance. Categorizing licenses as I’ve done in this post can be helpful for a basic understanding, but it is not a substitute for analyzing a specific license’s terms.