BLOG »

nexB on GPL 3.0 and Related License Compliance Issues

by Michael Herzog
on February 4, 2021
| 8 minute read

by Michael Herzog
February 4, 2021
8 minute read

This post provides some background on license compliance Issues related to Copyleft licenses with a focus on the GPL 3.0 and its derivatives: LGPL 3.0, AGPL 3.0 and SSPL 1.0. The document is based on our decade of Software Composition Analysis experience, but we are not providing any form of legal advice. For the purposes of this document, we do not distinguish between the “only this version” and “this version or any later version” variants of the AGPL, GPL, LGPL and SSPL.

Open Source Software Policies

The severity of many Copyleft license-related Issues depends on the context of the relevant open source license policies because there are different perspectives on many of these Issues across the FOSS community, companies and legal services providers. It is important for companies that use Linux in a proprietary product that they distribute or deploy on the Cloud to define license policies for:

L/GPL 3.0
AGPL 3.0
SSPL 1.0

L/GPL 3.0

Many companies prohibit any use of software licensed under GPL 3.0 or LGPL 3.0 in a distributed or deployed proprietary product because they are concerned about:

GPL 3.0 Section 3. Protecting Users’ Legal Rights From Anti-Circumvention Law.
GPL 3.0 Section 11. Patents
And other license conditions.

Other companies permit the use of L/GPL 3.0-licensed software on an exception basis. Such exceptions may be available only on a case-by-case basis or they may be based on broader concepts.

For example, most companies will allow the use of current GCC compiler components because the commonly distributed GCC libraries (e.g.libgcc or libstdc++) are licensed under GPL 3.0 with the “GCC exception to GPL 3.0 or later”.

Other relatively common exception criteria are:

Use of LGPL 3.0-licensed software is acceptable if linked dynamically and without any modifications because of a perception that there is less risk from using libraries.
Use of GPL 3.0-licensed software is acceptable if used without any modifications and the code runs in processes separated from processes running proprietary code.
Use of either GPL 3.0- or LGPL 3.0-licensed software is acceptable (with the same linking and process separation requirements) if the software is provided as part of a Linux distribution (“Distro”) or similar third-party larger packages set that is conveyed to a customer without any modification. A policy that permits the distribution or deployment of L/GPL 3.0-licensed code in a proprietary product is often related to the “System Libraries” definition in Section 1 of the GPL 3.0.

Linux Distro Exception for L/GPL 3.0

Since many common Linux userspace software packages have some GPL 3.0- or LGPL 3.0-licensed code, it would be very difficult to build and distribute a product based on a current version of Linux without some provision for allowing the distribution of some L/GPL 3.0-licensed packages.

The goal of most companies in this area is to ensure that there is clear distinction between Copyleft-licensed code and Proprietary-licensed code and one of the primary techniques here is to avoid any modification of the Copyleft-licensed code. This can generally be accomplished by only allowing distribution of unmodified Linux userspace software.

This can, however, become more complicated by a requirement to remove unneeded packages or to add additional packages or update installed packages, especially for security-related patches. One practical solution to this type of customization is to allow updates to the base Distro only from standard packages from that same Distro.

AGPL 3.0 and SSPL 1.0

The AGPL 3.0 (Affero GNU Public License) is an important variant of the GPL 3.0 license published in 2007 by the Free Software Foundation – see the GNU Affero General Public License wiki for additional history. The SSPL 1.0 (Server Side Public License) is a MongoDB-created license derived from the AGPL 3.0 with additional restrictions and conditions.

The key difference between GPL 3.0 on the one hand AGPL 3.0 or SSPL 1.0 on other hand is Section 13 where these licenses effectively define network deployment of software as a form of distribution that invokes Copyleft license conditions including Redistribution of source code that interacts with Copyleft-licensed software.

Both licenses were designed to address the perception that companies who deploy L/GPL-licensed software on a network or the Cloud are not subject to L/GPL license conditions because those licenses do not treat this type of deployment as a form of distribution. These licenses are commonly used in a “dual licensing” scheme with a Commercial license alternative where the apparent goal is to encourage most companies to acquire a Commercial license.

AGPL 3.0

The first paragraph of Section 13 of the AGPL 3.0 says:

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

“Remote Network Interaction” is usually interpreted in the open source domain to mean any use of software on a network including SaaS and other Cloud deployments. There is, however, less clarity about what “modify the Program” and “your modified version” mean in the AGPL 3.0 context.

What does “modify” mean in the AGPL 3.0 context?

Some key terminology from Definitions (section 0) in the GPL 3.0, AGPL 3.0 and SSPL 1.0 license texts is:

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
A “covered work” means either the unmodified Program or a work based on the Program.

The interpretation of section 13 of AGPL 3.0 is clearly a matter for legal counsel, but we can characterize two contrasting views as follows:

Most permissive: Modification means changing the source code and creating new binaries or other executable programs from that source code.
Most restrictive: Modification includes any combination of the Program with other software.

The latter interpretation is favored by many companies with a “dual licensing” model where you choose between a commercial license or AGPL 3.0. Some prominent examples are MongoDB (prior to their switch to the SSPL), iText and BerkeleyDB (Oracle).

Many of these companies assert that AGPL 3.0 means that you must obtain a commercial license to use their product or make the source code for any software that interacts with their AGPL 3.0-licensed available under an AGPL 3.0-compatible license.

Many large companies, including Google, have policies that prohibit any use of software licensed under AGPL 3.0 due to concerns about the restrictive interpretation of the license conditions.

SSPL 1.0

Section 13 of the SSPL 1.0 says:

13. Offering the Program as a Service.

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

This text appears to be much more direct than the corresponding Section 13 of AGPL 3.0 in two ways:

It expands the definition of distribution to encompass almost any type of Cloud-based deployment including SaaS.
It defines the scope of the Corresponding Source Code very broadly to encompass any software used to deliver the “service”.

Since the SSPL 1.0 is a relatively new license (published in 2018) that was until recently only used by MongoDB, there is not much public information about enforcement, but most commentators agree that the practical impact will be that you need a Commercial license to deploy software offered under a choice of SSPL 1.0 or a Commercial license on any network.

It is important to note that some companies that previously offered software under a choice of AGPL 3.0 or a Commercial license have replaced the AGPL 3.0 with the SSPL 1.0. The most recent example is Elastic that switched from an Apache 2.0 license to the SSPL 1.0.