The Developer’s Guide: Open Source Software License Comparison

Open source licenses come in different types (i.e., copyleft vs permissive), flavors (i.e., industry standard vs specific to a single vendor), and versions that contain legal language, usage restrictions and contractual obligations. Make no mistake: open source licenses represent a contractual agreement between you and the copyright holder of an open source work, whether an actual contract has been signed or not. If you’re not a lawyer, all this legalese can be intimidating, making it difficult to compare open source software licenses to discover the best ones for your use case. For example:

• Which copyleft licenses require full publication of all application code versus just pieces of the application code?
• Which open source licenses are incompatible with running a proprietary service?
• Which open source licenses have implied versus expressed patent clauses?
• Which open source licenses are appropriate for inclusion in proprietary software versus non-commercial software?
• Which open source licenses require that contributors to the licensed software grant a patent license to users of the open source software?

Because developers aren’t lawyers most enterprises create a policy that defines which licenses can be used to develop software, and which must be avoided. If you’ve been tasked with crafting such a policy, this guide can help, but first a disclaimer:

This blog post provides guidelines, not legal advice. Use your own judgement, or better yet, involve a lawyer to help draft and review your policy. Alternatively, ActiveState has a 20-year track record of helping our enterprise and OEM customers review and understand their open source license obligations. Connect with us to review any of your open source needs.

Open Source Software License Types

Generally, there are two widely accepted and recognized categories into which the majority of open source licenses fall, as well as a few minor ones.

Major types of open source licenses:

• Copyleft Licenses – permit anyone to use, study, modify and share the licensed software and its source code, but on the condition that modified versions of the software are shared under the same license. Be aware that not all copyleft licenses are compatible. Popular examples include the GNU GPL, Mozilla Public License and Eclipse Public License.
  • Placing a work into the public domain isn’t as straightforward as one might think. The simplest way to comply with a copyleft license is to either a) apply the same license to your own code that forms a combined work with the code in question or b) apply a permissive open source license to your code. As a result, code licensed under a strong copyleft license is not typically suitable for inclusion in proprietary software

• Permissive Licenses – applied to any code that can be freely used, modified and redistributed. Permissive-licensed code can be included in proprietary software. Popular examples include MIT, BSD, and Microsoft Public License (Ms-PL).
  • Remember that while permissive licenses are not as restrictive as copyleft licenses, they still require compliance with a number of obligations (such as the inclusion of the original license or copyright notice) before they can be redistributed.

Arguably, the third most common type of license is “None”. If you randomly check Github for popular, publicly-available repos, it won’t take long before you find one that doesn’t have a license associated with it. The same can be said for packages located in CPAN, PyPI, npm, etc. This doesn’t mean that anyone is free to use the software though. When software is created, the creator (or their employer) usually gains copyright on the software – giving them the exclusive right to reproduce the work. While there are no laws that authors MUST include a license when they distribute their software, there are laws about redistributing copyrighted software without a license.

If you are utilizing software with no license you are at risk of take-down notices, demands for compensation, or litigation. Ensure that you obtain the author’s permission before you start working with their unlicensed code.

Minor types of open source software licenses:

• Public Domain – A work in the public domain is not copyrighted and has no license. It can be used by anyone for any purpose at no charge. However, putting software into the public domain is a complex endeavor. The closest equivalent is use of waivers or licenses like the  Creative Commons “CC0” waiver.
  • Be cautious of software labelled as being in the public domain. If it’s not relatively old (pre-1976) or placed under a specific waiver, it may not be what it claims to be.

• Source Available – an emerging type of license that is meant to be applied to code that cannot be deployed “as a service”. This type of license is being defined in response to cloud providers like AWS packaging, rebranding and profiting from open source projects  deployed on their cloud platform. Popular examples include Redis’ Source Available License (RSAL), MongoDB’s Server Side Public License (SSPL), the Cockroach Community License (CCL), or licenses that have had the Commons Clause added.
  • “Source Available” is a contentious license type that some say contravenes the spirit of open source. Whether it becomes a standard, accepted type of Free or Open Source license is still under debate at the time of this writing.

Open Source Software License Compared

There are literally hundreds of “standard” open source licenses (i.e., licenses that are generally accepted, and included in multiple open source projects) and “specific” licenses, which may have been created solely for use in one specific vendor’s offering. Rather than trying to boil the ocean, this blog post focuses on the most commonly used licenses. For example:

Top 10 Open Source Licenses in 2018 (source: WhiteSource Software)

The following table provides a comparison of the most popular open source licenses, denoting how they can be used and enumerating the obligations they impose on the user.

AGPL

Apache

BSDv2

BSDv3

CC-0

Eclipse

GPLv2

GPLv3

LGPL

MIT

Mozilla

Ms-PL

Proprietary Use

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Modify

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Distribute

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Sub-license

X

Y

Y

X

X

X

Y

Y

Y

Private Use

Y

Y

Y

Y

Grants Patent License

Y

X

Y

Y

Y

Place Warranty

Y

Y

Y

Y

Y

Y

Y

Requires Copyright Notice

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Must Include License

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

Include Notice

Y

Y

Include Original

Y

Y

Y

Y

Y

Include install instructions

Y

Y

Y

Compensate for damages

Y

Disclose Source

Y

Y

Y

Y

Y

Y

State Changes

Y

Y

Y

Y

Y

Hold Liable

X

X

X

X

X

X

X

X

X

X

X

X

Use Trademark

X

X

X

X

X

X

	Copyleft style license
	Permissive style license
	Public Domain license

Open Source Software License Compliance

As the above table shows, there are a number of obligations that organizations must comply with in order to be able to legally use the code, from simple rules like including the open source code’s existing copyright notice and license in your application to the more stringent requirement to disclose all modified and derived code. To ensure compliance, enterprises typically take one or more of the following approaches:

• License Governance Policy
  • A structured document that expressly allows or forbids the usage of specific open source licenses by software development teams. Policy management tools like Keylight, CentralPoint and others can help here.

• Third-party Enforcement Tools
  • Enforcement tools are typically implemented in the software development process in order to help ensure an organization’s policies are enforced at time of code use. These tools may warn or even prevent developers from importing non-compliant code into their project. Examples include WhiteSource, Veracode, Fortify, etc.

• Annual Audits
  • Despite policies and enforcement tools, code with non-compliant licenses can slip through. And despite best efforts, not all of a license’s obligations may have been met. To mitigate risk, many enterprises will conduct a yearly audit of all distributed code. Again, there are a number of software tools that can help here, including Software Composition Analysis tools (like BlackDuck) and Binary Repositories (like JFrog Artifactory).

Open Source Software License Trends

Open source software has been around for more than 30 years. During that time, the way we write, license and use open source software has changed. For example:

• There has been a steady shift away from copyleft licenses toward permissive licenses in the enterprise as commercial organizations have chafed at the restrictions imposed by copyleft.

Permissive vs Copyleft License Usage (source: WhiteSource Software)

• More and more large enterprises are becoming integral to the open source community, either by purchasing open source organizations directly (i.e., IBM’s acquisition of Red Hat and Microsoft’s acquisition of GitHub), or else encouraging employees to contribute to open source on company time. This kind of sponsorship and management of open source software for corporate users by corporate users is gaining ground with enterprises like Microsoft and Google leading the charge.
• Litigation has been steadily on the rise, both as a result of the ubiquity of open source software nowadays, as well as the rise of copyright trolls.
• As more and more open source software gets re-packaged and run as proprietary cloud-based services, there has been a backlash from some creators that never intended cloud providers to profit from their code. The result has been the creation of a number of new “source available” licenses, such as:
  • MongoDB’s Server Side Public License (SSPL), which is a copyleft license that requires you to open-source all programs used to make the software available as a service.
  • Redis Source Available License (RSAL), which is a permissive license in most respects, but forbids usage in databases, caching engines, stream processing engines, search engines, indexing engines or ML/DL/AI serving engines.

Open Source Indemnification

One of the best ways to continue to gain the benefits of open source while mitigating the risk of lawsuits due to improper implementation or interpretation of a license is through indemnification. Indemnification is essentially insurance offered by some third-party, commercial vendors of open source. It’s designed to defray lawsuit damages that can result when busy developers ignore or click through license agreements without reading or understanding the obligations those licenses impose.

Sometimes these oversights are caught during resource-intensive, manual audits. More often, however, licenses buried deep in the code base get overlooked. And in some cases, the various licenses incorporated in an application are actually incompatible, and cannot be deployed within the same code base. Any and all of these scenarios can result in expensive lawsuits and damaged reputations.

More importantly, for some organizations is the legal review that gets imposed whenever a new open source package is added to a project. This is especially true for regulated industries like finance and banking, but can also be generally true for any organization that fears legal reprisal. Essentially, all new packages required by a development team are subjected to scrutiny by a legal team before they can be incorporated into any distributed code. Depending on the length of the review and the outcome, this process can significantly delay time to market.

ActiveState offers indemnification for its Python, Perl and Tcl offerings. To find out more, read our Indemnification datasheet.