Open-source software has been one of the most transformative forces in the technology sector. Operating systems, databases, web servers, and encryption libraries that we now consider essential exist thanks to thousands of developers who chose to release their code so that anyone could study it, modify it, and improve it.
This model has enabled companies and organizations to build advanced solutions without relying exclusively on proprietary software. However, this openness also introduces a recurring challenge: how to ensure the sustainability of open-source software in a world where software is no longer distributed, but consumed as a service.
In this context, recent discussions around well-known projects have brought renewed attention to licenses such as AGPL (Affero General Public License), specifically designed to respond to this shift in how software is delivered and consumed. Beyond individual cases, the underlying message is clear: open-source software requires a balance between those who contribute and those who use it.
What Do We Mean by “Open Source” in 2025?
When people talk about open-source software, it is often confused with “free software” in the sense of cost. In reality, the term refers to a set of fundamental freedoms:
- The freedom to run the program for any purpose
- The freedom to study how it works
- The freedom to modify it
- The freedom to redistribute it, with or without changes
These freedoms are defined and enforced through licenses. Some licenses prioritize maximum adoption, while others aim to ensure that the ecosystem remains collaborative and sustainable.
During the 1990s and early 2000s, the dominant model was traditional software distribution: installers, CDs, and packaged binaries. In that context, licenses such as GPL ensured that if you redistributed the software, you were required to release your modifications.
Today, this landscape has changed completely, most software is delivered as a service. Companies can benefit from open-source software without ever distributing it; they simply run it on their own infrastructure. This shift is precisely where modern licensing models come into play.
2. MIT, Apache, GPL, AGPL: What Actually Sets Them Apart
When discussing open-source licenses, we are not just talking about legal text, but about different collaboration models.
Broadly speaking, there are two major families of licenses:
A) Permissive Software licenses (MIT, BSD, Apache 2.0)
Permissive licenses such as MIT, BSD, or Apache 2.0 allow organizations to take the code, modify it, integrate it into proprietary products, and redistribute it without any obligation to return improvements to the community. They are attractive to companies that want minimal legal constraints and maximum flexibility.
Their primary goal is typically to encourage widespread adoption, leaving the decision to contribute entirely up to each organization.
B) Copyleft Software licenses (GPL, LGPL, AGPL)
Copyleft licenses such as GPL, LGPL, and AGPL follow a different logic. If a project benefits from community-driven development, the improvements made on top of that code should remain accessible to the community. The intent is not to restrict commercial use, but to prevent open-source code from being absorbed into closed solutions without any return to the original project.
AGPL (Affero GPL) emerged to address a specific change in context: the transition from distributed software to software offered as a service. Traditional GPL licenses focused on redistribution—if you shipped a binary to a third party, you were required to provide the source code and your modifications.
What was the problem?
In the SaaS model, many companies began using open-source software internally or as part of web services without ever “distributing” it. They simply ran it on their own servers and exposed functionality through APIs or web interfaces. In these cases, modifications could be made without being shared.
AGPL extends the scope of reciprocity: if you offer the software to users over a network, your modifications must be made accessible.
When Open Source Forces a Change in Licensing Models
As open-source software has become deeply embedded in enterprise infrastructures, many projects have reached a point where usage grows faster than contributions. This is a natural outcome of how technology is consumed today, particularly in SaaS and cloud environments.
In recent years, several mature projects have adopted AGPL or dual-licensing models after observing recurring patterns:
- The software becomes a critical component in enterprise environments
- Internal or commercial forks evolve independently
- Improvements remain isolated and never reach the core project
- The cost of ongoing development falls almost entirely on the original maintainers
The result is that, despite widespread adoption, the project lacks the resources required for long-term sustainability.
In this context, adopting reciprocal licenses such as AGPL is not a restrictive move, but a mechanism to preserve the continuity of the project.
The Role of AGPL in Cloud and SaaS Ecosystems
The shift toward cloud and SaaS models has fundamentally transformed the software lifecycle. Many historical licenses were not designed for environments where software operates exclusively as a remote service.
Licenses such as AGPL introduce mechanisms intended to protect the integrity of open-source ecosystems in this new context. Their purpose is not to limit commercial use, but to ensure that significant improvements do not remain locked inside private implementations—especially when the software underpins critical infrastructure.
From a technical and organizational perspective, this approach provides several benefits:
- Project cohesion, by preventing parallel versions from diverging into incompatible branches
- Greater transparency and security, as shared improvements can be audited and reviewed collectively
- Reduced duplication of effort, allowing innovation to build on a common foundation
- A more balanced ecosystem, where the cost of evolution is not borne by a single actor
As a result, more projects are adopting hybrid models that combine open foundations, reciprocity mechanisms, and commercial offerings that fund ongoing development. This is not an exception, but a natural response to how software is built and maintained today.
5. Open Source and Long-Term Sustainability
Open-source software remains a fundamental driver of innovation. Its sustainability, however, depends on maintaining a fair balance between those who create and those who rely on it.
As SaaS models continue to redefine software consumption, licensing frameworks evolve alongside them. AGPL and other reciprocal licenses do not aim to restrict adoption, but to ensure that critical projects can continue to grow, improve, and remain viable over time.
Ultimately, the goal is to protect the continuity of the open-source ecosystem in a technical landscape that is changing rapidly.
At SKUDONET, we work closely with open-source technologies in security and application delivery. Understanding how licensing models evolve is a key part of building sustainable infrastructure.
