How to Use Popular Open Source Licenses, Explained
An open source lawyer explains code use under the permissive, weak copyleft, strong copyleft & network copyleft licenses
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. It is the open source license that 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, licenses for closed source/proprietary software would give you permission 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, it is possible two licenses will 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 what open source software they use in their projects.
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 in the category. I will also address the concept of Public Domain as a separate category from open source licenses.
What are permissive 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, that 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.
Recognizing the original author under permissive open source licenses
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.
Example of the permissive open source software license at work
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.”
Popular examples of permissive open source software licenses
What are weak copyleft open source software licenses?
If we think of the open source license categories as a spectrum, next to permissive licenses are the slightly more restrictive weak copyleft licenses.
Before getting into what makes a license weak versus strong copyleft it is important to understand the concept of copyleft itself. Copyright has traditionally been used to exclude others from your original work and copyleft is essentially the inverse of that concept. Copyleft uses copyright to dictate downstream usage rights. With a copyleft license you grant others rights associated with the work and require that they too will grant those same rights if they turn around and convey the work to someone else. You are not excluding others from the work so much as inviting others to use, modify, and redistribute the work with the requirement that those permissions remain intact. The mechanism to keep those permissions intact is the requirement that the license stays the same. Whether the license must apply to just that particular open source component (and any modifications to it), or to any code linked to the open source component, is the difference between weak copyleft and strong copyleft.
Weak copyleft open source software licenses are those that 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 that 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 are those that 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.
Distribution under weak copyleft open source software licenses
One important thing to understand with weak and strong copyleft licenses is that the trigger for the conditions in the licenses is distribution.
Distribution is a concept from copyright law, which is basically the act of 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.
Example of the weak copyleft open source software license at work
Looking back at our earlier example, Henry is again using 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.
Popular examples of weak copyleft open source software licenses
- Eclipse Public License 2.0
- Mozilla Public License 2.0
- Common Development and Distribution License 1.1
A note on the GNU Lesser General Public License (LGPL)
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. If it is dynamically linked it can generally be treated as a weak copyleft license. If it is statically linked there are other requirements for compliance.
What are strong copyleft open source software licenses?
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
What constitutes a single work for strong copyleft open source software licenses
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 itself 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 instances of clear aggregation, a determination of 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.
License compatibility for strong copyleft open source software licenses
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 to also designate a “secondary license,” meaning the code would be under both licenses. That would create compatibility with the GPL. Similarly, the 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 compatibility of the copyleft requirement, but it is possible for other provisions of open source licenses to 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.
Example of the strong copyleft open source software license at work
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 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.
Popular examples of strong copyleft open source software licenses
What are network copyleft open source software licenses?
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. 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.
These licenses are essentially a response to changes in how software is developed and used today. The original GNU General Public License (grandfather of strong copyleft licenses) was written in 1989. Obviously, it could not contemplate the software landscape in 2021 and so network copyleft licenses were developed to apply the copyleft condition to new use cases/situations that are 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 running 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.
Example of the network copyleft open source software license at work
Henry makes modifications to Library A, which is licensed under GPL 2.0 and uses the modified library with other proprietary code in a SaaS program he hosts himself.
- 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 makes modifications to 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 himself? 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.”
Popular examples of network copyleft open source software licenses
What does it mean for something to be in the Public Domain?
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 code is in the public domain that means it is free from copyright. You don’t need a license giving you permission to use it and there are no restrictions for how you use it. While that sounds simple in theory, there are two major problems with public domain software.
- 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.
- Second, is that 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 at all. It is easy to see the problems this can present when you have software being developed by contributors from all over the world. A contributor from a country that does not recognize public domain would retain copyright over their work.
If code is in the public domain that means it is free from copyright. You don’t need a license giving you permission to use it and there are no restrictions for how you use it.
Example of public domain software at work
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 and he does not need to give any notice or attribution. It is perfectly acceptable to use the code in closed source, commercial software.
What to watch for in open source software licensing in 2021
Something to watch in open source software licensing in 2021 is the continuation of the trend of new licenses for narrow/specific use cases. This is nothing new--companies, organizations, and individuals continue to find situations they feel cannot be adequately addressed with an existing open source software license.
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 which targeted that use case. Already in 2021 we have seen 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), which is essentially a governing body for open source software licenses.
The OSI has approved four new open source software licenses so far this year. 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 will be 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 too early to tell if there will be a lasting effect and it will be something to keep an eye on this year.
My hope is that after reading this post you will have a better understanding of 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 to use than a license in another. There is no correct answer and it will really depend on how you are using 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.
The information provided in this article does not, and is not intended to, constitute legal advice and is for general informational purposes only. Information in this article may not constitute the most up-to-date legal or other information. This article contains links to other third-party websites. Such links are only for the convenience of the reader, user or browser; Capital One does not recommend or endorse the contents of the third-party sites.