The Enshittification of Open Source: AGPL and Elastic License v2.0
Open Source Software (OSS) has traditionally been a bastion of collaboration, transparency, and freedom. However, the recent adoption of restrictive licenses like the Affero General Public License (AGPL) and the Elastic License v2.0 is leading to the degradation, or "enshittification," of these core principles. This article critically examines these licensing changes and their broader implications for the open-source community.
Understanding AGPL and Elastic License v2.0
AGPL: Extending GPL to Network Use
The AGPL extends the GNU General Public License (GPL) by requiring any service using AGPL-licensed code over a network to make its source code available to users. This aims to prevent companies from leveraging OSS for online services without contributing back to the community.
Elastic License v2.0: Protecting Commercial Interests
The Elastic License v2.0, introduced by Elastic NV, allows free use, modification, and distribution of the software but restricts its use in managed services or as part of a service. This change was aimed at preventing cloud providers from offering Elasticsearch as a service without contributing back to Elastic.
The Enshittification Phenomenon
"Enshittification" describes the process by which something becomes degraded or corrupted. In OSS, this refers to the shift from open and collaborative development to more restrictive, commercially protective practices.
Erosion of Open Source Principles
The primary tenet of open source is freedom: the freedom to use, modify, and share software. AGPL and the Elastic License v2.0 introduce restrictions that challenge these principles.
- AGPL's Network Clause: The requirement to disclose source code for network use can deter businesses from adopting AGPL-licensed software, fearing that proprietary innovations must be open-sourced.
- Elastic License v2.0's Service Restrictions: By restricting the use of software in managed services, Elastic effectively limits its software's flexibility, impacting businesses that rely on versatile deployment options.
Commercialization and Fragmentation
The move towards restrictive licenses is often driven by commercial interests, leading to:
- Dual Licensing: Companies may offer a free version under a restrictive license and a commercial version with more features or fewer restrictions. This creates an uneven playing field where only paying users can access the best version of the software.
- Forks and Compatibility Issues: Restrictive licenses can prompt the community to fork projects to maintain a truly open version. This can lead to compatibility issues, duplicated efforts, and a fractured community.
Trust and Community Backlash
Open source thrives on trust and community engagement. When companies shift towards more restrictive licenses, they risk alienating their user base. The community may perceive these moves as a betrayal of the open-source ethos, leading to:
- Loss of Contributors: Developers who value openness may leave the project, reducing the pool of contributors and potentially slowing down development.
- Negative Publicity: Licensing changes often attract criticism and can damage a company's reputation within the open-source community.
The InvoiceNinja Controversy
Recent issues on GitHub involving InvoiceNinja highlight the complexities and community backlash associated with license changes. Originally licensed under the MIT license, InvoiceNinja's shift to the Elastic License v2.0 prompted significant community outrage.
I myself voiced my views upon it here, and got blocked for it on the repo:
invoiceninjaFurther complicating matters, the discussion around changing the license emphasized the restrictive nature of the new terms. Also other contributors were concerned that the new license isn't Open Source anymore:
invoiceninjaWhats alarming is also the legal misunderstanding of the MIT license as in this comment by one of the main maintainers:
The MIT license clearly states: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. So... how does one conclude that the license can simply be omitted or further restricted?
Changing a Project’s License: Legal Considerations
According to the Open Source Guide, changing the license of a project can be complex and involves several key considerations:
- Compatibility: If the new license is compatible with the old one, you may start using it for new contributions.
- Copyright Holders: You need agreement from all contributors if you’re not the sole copyright holder. This can be a significant hurdle for large projects with many contributors.
- Communication: Clear communication and consultation with stakeholders are crucial to ensure a smooth transition
These guidelines highlight why InvoiceNinja’s approach to changing its license sparked such backlash. The shift was seen as abrupt and inadequately communicated, with insufficient consideration for the contributors' rights and expectations.
The Way Forward
While the concerns driving the adoption of AGPL and the Elastic License v2.0 are valid, it is crucial to find a balance that protects the interests of developers and companies without undermining the fundamental principles of open source. Some potential solutions include:
- Community-Inclusive Licensing: Developing licenses in consultation with the community to ensure that they address the needs of both developers and users.
- Innovative Business Models: Exploring business models that do not rely on restrictive licenses, such as offering premium features, support services, or enterprise solutions.
- Education and Advocacy: Raising awareness about the implications of different licenses and advocating for policies that promote genuine openness and collaboration.
Our take
The enshittification of open source through the adoption of licenses like AGPL and the Elastic License v2.0 is a complex and contentious issue. While these licenses aim to protect the interests of developers and maintainers, they also challenge the core principles of OSS. To preserve the spirit of open source, it is essential to find a balance that supports both innovation and collaboration while addressing the commercial realities of modern software development. By fostering a more inclusive and thoughtful approach to licensing, we can ensure that open source remains a vibrant and dynamic force for good in the tech world.
The InvoiceNinja controversy serves as a stark reminder of the potential pitfalls of restrictive licensing. As open source continues to evolve, it is imperative that we remain vigilant and committed to the principles that have made it such a powerful and transformative movement. Only by doing so can we prevent the enshittification of open source and ensure that it remains a force for good in the world of technology.
