Elasticsearch going Open Source ? GPL vs AGPL

Introduction

So this thought began from the news article I read about Elasticsearch being open source again. You can read about it here : https://www.elastic.co/blog/elasticsearch-is-open-source-again

Open source software (OSS) is the backbone of modern technology, enabling developers to build upon the work of others without the constraints of proprietary software. Central to this philosophy are the licenses that govern how software can be used, modified, and distributed. Two of the most well-known licenses in the open source world are the GNU General Public License (GPL) and the GNU Affero General Public License (AGPL). While both licenses are part of the GNU family and share similar philosophies, they have important distinctions that can significantly impact the development, distribution, and usage of software.

In recent years, discussions around the AGPL license have intensified, particularly in the case of Elasticsearch, a widely used search engine technology, which switched from an Apache License to a dual-license model that includes the Server Side Public License (SSPL), a license very similar to the AGPL. This shift has raised questions about whether software governed by AGPL or SSPL can truly be considered “open source.” In this blog, we will delve into the key differences between GPL and AGPL licenses and explore why some argue that Elasticsearch’s move to a more restrictive licensing model no longer qualifies as true open source.

Understanding Open Source Licensing

Before diving into the specifics of GPL and AGPL, it’s important to grasp what “open source” means and how licenses fit into the picture.

What is Open Source?

Open source refers to software where the source code is made available to the public. The code can be freely viewed, modified, and distributed, encouraging collaboration and innovation. Open source software licenses typically guarantee certain freedoms:

Freedom to use the software for any purpose.
Freedom to study how the software works.
Freedom to redistribute the software.
Freedom to modify and improve the software.

While all open source licenses provide some degree of these freedoms, they differ in how they impose conditions on the distribution of modified versions, proprietary integration, and commercial use. These differences are particularly apparent in copyleft licenses like GPL and AGPL.

What is a Copyleft License?

Copyleft is a licensing concept in which derivative works of a software project must be distributed under the same license as the original. This ensures that any modifications or improvements to the code remain open source. The GNU General Public License (GPL), created by the Free Software Foundation (FSF), is one of the most famous copyleft licenses.

With copyleft licenses, any derivative works or modifications must also be released under the same open terms, ensuring that the software remains free and open for all users. This prevents others from taking the open source code, modifying it, and then releasing it under a proprietary or more restrictive license.

Overview of GPL and AGPL Licenses

Now, let’s dive into the specifics of the GPL and AGPL licenses.

The GNU General Public License (GPL)

The GNU General Public License (GPL) is one of the most widely used open source licenses in the world. There are several versions of the GPL, with GPLv2 and GPLv3 being the most commonly used. The GPL was created to promote software freedom, ensuring that users of the software have the rights to use, modify, and distribute it, as well as access the source code.

The key provisions of the GPL include:

Copyleft Clause: Any software that incorporates GPL-licensed code must also be licensed under the GPL. This means that if you modify a GPL-licensed project, you must release your modifications under the same GPL license.
No Discrimination: The GPL does not place any restrictions on who can use the software or for what purposes. It cannot be revoked or restricted to prevent use in specific industries or by specific individuals.
Source Code Distribution: If you distribute a compiled version of a GPL-licensed program, you must also provide access to the source code or instructions on how to obtain it.
Patent Clause (GPLv3): Version 3 of the GPL includes provisions that prevent users from applying software patents in ways that would restrict other users’ freedom to use, modify, or share the software.

The GPL aims to ensure that software remains free for all users, including any modifications or derivative works that are built upon the original code. However, the GPL focuses primarily on software distributed in binary or executable form. This means that, in a traditional setting where software is distributed as a product (e.g., on a disk or downloaded), the GPL ensures that the source code is made available.

The GNU Affero General Public License (AGPL)

The GNU Affero General Public License (AGPL) is an extended version of the GPL. The AGPL shares many of the same principles as the GPL, with the significant difference being in how it applies to software that is accessed over a network, such as cloud-based or web applications.

The key difference between the AGPL and GPL is:

Network Interaction Clause: The AGPL requires that any user who interacts with the software over a network (for example, through a web application) must be given access to the source code. This “network use” provision extends the copyleft requirements to cover situations where the software is not distributed in the traditional sense (e.g., as a binary), but is instead offered as a service over the internet.

In other words, if a developer creates a web-based application using AGPL-licensed software, they are required to make the source code available to users who interact with the application over the network. This contrasts with the GPL, which only requires source code to be made available when the software is directly distributed.

This difference is particularly important in the context of modern cloud-based services, where software is often not distributed in the traditional sense but is instead accessed as a service. The AGPL ensures that even in these cases, users maintain the same freedoms to access, modify, and share the source code.

Key Differences Between GPL and AGPL

While both the GPL and AGPL are designed to promote software freedom and protect users’ rights, they differ in how they apply to software used in different contexts. Below are the key differences between the two licenses:

Scope of Copyleft:
- GPL: Copyleft applies only when the software is distributed in binary or source code form. If the software is only used internally or as part of a web service, there is no obligation to release the source code.
- AGPL: Copyleft applies not only when the software is distributed, but also when it is used to provide a service over a network. If users interact with the software via a network, the source code must be made available to them.
Network Use:
- GPL: Does not cover software that is only used internally or provided as a service over a network.
- AGPL: Requires that source code be made available if the software is accessed over a network.
Impact on Cloud Services:
- GPL: Does not impose any additional requirements on cloud service providers who use the software internally without distributing it.
- AGPL: Forces cloud service providers to release the source code if the software is used to provide a service over the network.
Adoption in Commercial Settings:
- GPL: More widely adopted in commercial settings, particularly for software that is distributed in binary form.
- AGPL: Less commonly used, particularly in the context of cloud services, as companies often prefer not to release source code for software that is only used internally or offered as a service.

Real-World Examples of GPL and AGPL Usage

To further understand the impact of these licenses, it’s helpful to look at real-world examples of how the GPL and AGPL are used in practice.

Example of GPL Usage: Linux Kernel

One of the most famous examples of GPL-licensed software is the Linux kernel. The Linux kernel is licensed under GPLv2, which means that any modifications to the kernel must be released under the same GPLv2 license. This has helped maintain the open nature of Linux, enabling a vast ecosystem of open source tools, distributions, and applications to be built around it.

Companies like Red Hat and Canonical use the Linux kernel as the foundation of their enterprise products (such as Red Hat Enterprise Linux and Ubuntu), while still complying with the GPL by making their kernel modifications available to the public.

Example of AGPL Usage: Nextcloud

Nextcloud, a popular open source file sharing and collaboration platform, is licensed under the AGPL. This means that if a company or individual modifies Nextcloud and offers it as a hosted service, they are required to release the source code for their modified version.

This helps to prevent a common issue with open source software known as the “SaaS loophole,” where companies use open source software to provide a service without ever distributing the software itself, thereby avoiding the copyleft obligations of the GPL. By using the AGPL, Nextcloud ensures that any modifications made to its software in the context of a web service must also be shared with the community.

Elasticsearch and the Move to AGPL-like Licensing: Why It’s Not True Open Source

One of the most prominent cases that have sparked debate in the open source community is the shift in licensing for Elasticsearch. Originally released under the permissive Apache License 2.0, Elasticsearch later adopted a dual-licensing model that includes the Server Side Public License (SSPL), which is very similar to the AGPL. This move has raised concerns about whether Elasticsearch can still be considered true open source software.

Elasticsearch’s License Change

In early 2021, Elastic NV, the company behind Elasticsearch, announced that it would no longer release Elasticsearch and Kibana under the Apache 2.0 license. Instead, the software would be licensed under either the SSPL or the Elastic License, both of which impose more restrictive conditions than the original Apache License.

The SSPL is closely modeled after the AGPL but with an additional clause that targets cloud service providers specifically. Under the SSPL, if a company offers the software as part of a “service,” they must open source not just the code they modified, but the entire infrastructure and tooling they use to deliver the service.

Why the SSPL/AGPL is Not Considered True Open Source

The key reason that Elasticsearch’s shift to SSPL (and by extension, AGPL) is controversial is that many in the open source community do not consider SSPL-compliant software to be true open source. Here are a few reasons for this view:

Violating Open Source Definition: The Open Source Initiative (OSI), which maintains the Open Source Definition (OSD), does not consider the SSPL or AGPL to meet the criteria for being true open source licenses. The OSD requires that a license must not discriminate against fields of endeavor or place additional restrictions on how software can be used. By targeting cloud service providers and requiring them to release all of their supporting infrastructure, the SSPL imposes conditions that go beyond what the OSD allows.
Restricted Commercial Use: By imposing additional obligations on cloud service providers, the SSPL (and, to a lesser extent, the AGPL) creates a situation where certain commercial uses of the software become impractical or undesirable. This can limit the adoption of the software in enterprise environments, particularly for companies that rely on proprietary infrastructure to deliver their services.
Undermining Collaboration: The move to SSPL-like licenses can create friction within the open source community. When large projects like Elasticsearch move to more restrictive licenses, it undermines the collaborative nature of open source, as companies that might otherwise contribute to the project may be discouraged from doing so due to the licensing restrictions.
Not OSI Approved: The Open Source Initiative does not approve the SSPL as an open source license, stating that it discriminates against cloud service providers and imposes additional burdens that are not in line with the principles of open source. This lack of OSI approval is a significant factor in the argument that SSPL and AGPL-licensed software are not true open source.
Confusion Over Licensing: By adopting dual licenses like the SSPL and Elastic License, Elasticsearch creates confusion around what constitutes open source and what obligations users have. This confusion can stifle innovation and adoption, as developers and businesses may be wary of using software with unclear or overly restrictive licensing terms.

Elastic’s Justification and the Open Source Community’s Response

Elastic has argued that the shift to the SSPL was necessary to protect its business from being undermined by large cloud service providers like Amazon Web Services (AWS), which used Elasticsearch to provide their own managed services without contributing back to the development of the software. In this context, Elastic saw the SSPL as a way to level the playing field and ensure that cloud providers who benefited from Elasticsearch’s success were also giving back to the community.

However, this move has been met with significant criticism from the open source community. Many argue that Elastic’s decision represents a shift away from true open source principles and toward a more restrictive, commercially driven model. In response, AWS and others have forked Elasticsearch and Kibana, creating OpenSearch, which remains under the Apache 2.0 license and is considered a more truly open alternative to Elastic’s offerings.

Conclusion

The differences between the GPL and AGPL licenses lie in how they apply to software used in traditional distribution models versus cloud-based or networked environments. While the GPL ensures that software distributed as binaries must be accompanied by source code, the AGPL extends this requirement to software offered as a service over a network. Both licenses promote software freedom, but the AGPL’s network use provision places additional obligations on developers, particularly in the context of web-based applications.

Elasticsearch’s move to an AGPL-like license through the SSPL has sparked debate over whether such licenses can be considered true open source. While Elastic argues that the SSPL is necessary to protect its business interests, many in the open source community believe that the restrictions imposed by the SSPL violate the principles of open source as defined by the Open Source Initiative.

Ultimately, the debate over GPL, AGPL, and SSPL highlights the tension between commercial interests and the ideals of the open source movement. As cloud computing continues to dominate the software landscape, the role of licenses like the AGPL and SSPL will continue to be a contentious issue, shaping the future of open source software development.