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 are full of legal language, usage restrictions and contractual obligations. Make no mistake: open source licenses represent a contractual agreement between you and the author, 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 open source licenses require full publication of all application code versus just pieces of the application code?
  • Which open source licenses are appropriate for “traditional software” but not when it’s run “as a service”?
  • Which open source licenses have implied versus expressed patent clauses?
  • Which open source licenses are appropriate for inclusion in proprietary (ie, commercial) software versus non-commercial software?

Because developers aren’t lawyers most enterprises create 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 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 – applied to code that can be used by anyone, without restriction, but requires that all modified and/or extended versions of the code also be made freely available for use, as well. Be aware that not all copyleft licenses are compatible. Popular examples include GPL, Mozilla and Eclipse.
    • The simplest way to comply with this type of license is to place your code in the public domain, uncopyrighted. As a result, GPL-licensed code is not typically suitable for inclusion in proprietary software, although there are some (such as LGPL licensed code) which may be applicable.
  • Permissive Licenses – applied to any code that can be freely (as in freedom, not $0) used, modified and redistributed. Permissive-licensed code can be included in proprietary, derivative 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 inclusion of the original license or copyright) before they can be redistributed.

Arguably, the third most common type of open source license is “None”. If you randomly check 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. While there are no rules that authors MUST include a license when they publish their software, there are laws about redistributing non-licensed software.

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 licenses:

  • Public Domain – applied to code that can be used by the public without restriction or copyright. Public domain code is intended to be truly “$0 free” and typically has very few (if any) obligations with which you need to comply. Popular examples include Creative Commons (CC-0).
    • While Public Domain code should be the simplest license to deal with, be aware that not all jurisdictions have a common definition of what public domain means. Always check your local regulations.
  • 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 license or remains a series of unique licenses is still under debate.
 

Open Source Licenses 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

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.

AGPLApacheBSDv2BSDv3CC-0EclipseGPLv2GPLv3LGPLMITMozillaMs-PL
Commercial UseYYYYYYYYYYYY
ModifyYYYYYYYYYYYY
DistributeYYYYYYYYYYYY
Sub-licenseXYYXXXYYY
Private UseYYYY
Use Patent ClaimsYXYYY
Place WarrantyYYYYYYY
Include CopyrightYYYYYYYYYYY
Include LicenseYYYYYYYYYYY
Include NoticeYY
Include OriginalYYYYY
Include install instructionsYYY
Compensate for damagesY
Disclose SourceYYYYYY
State ChangesYYYYY
Hold LiableXXXXXXXXXXXX
Use TrademarkXXXXXX


Copyleft style license
Permissive style license
Public Domain license
 

Open Source 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 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).
 

Trends in Open Source Licenses

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

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.

Dana Crane

Dana Crane

Experienced Product Marketer and Product Manager with a demonstrated history of success in the computer software industry. Strong skills in Product Lifecycle Management, Pragmatic Marketing methods, Enterprise Software, Software as a Service (SaaS), Agile Methodologies, Customer Relationship Management (CRM), and Go-to-market Strategy.