Why Did License Wars Emerge When Open Source Is Free
When discussing open source, the first word that usually comes to mind is “free.” Many developers download code from GitHub, check the license file, and use it in their projects without paying any cost. As this experience repeats, a natural perception forms: open source is software that anyone can use without paying. In reality, many open source projects have spread in exactly this way. Developers share code, improve each other’s projects, and build collaborative structures that rapidly advance new technologies. This culture has had a significant impact on the entire software industry, and today a large portion of internet infrastructure runs on open source.
However, when we look more closely at this structure, an important question emerges. Who is actually building all this widely used software? And who is covering the cost of its development? In practice, infrastructure software such as complex databases, search engines, and distributed systems is created through long-term work by many developers. Fixing bugs, adding features, addressing security issues, and improving performance are far from trivial tasks. Sustaining this work requires stable development organizations and substantial resources. Ultimately, open source projects cannot avoid the reality that they must exist within a viable economic structure.
At this point, open source companies face a complex problem. The code is open and freely usable, but the economic value created from that code does not always return to the organization that built the project. This issue is particularly pronounced in infrastructure software. Imagine a company that invests years in building a database or search engine. The software is released under an open source license, and developers around the world begin using it. But over time, another company can build a new service on top of that software—and that service may generate even more revenue than the original project.
As this situation repeated, a common question began to emerge among open source companies. Can a project remain open source while still creating a sustainable business? And if another company builds a large service business on top of open source, shouldn’t some of that value return to the organization that created it? This question is not merely technical—it is tied to the structure of the software industry itself. And it is precisely this problem that led to what we now call license wars.
The term “license wars” may sound exaggerated, but in reality, significant changes have taken place in the open source world over the past few years. Many companies have begun modifying existing licenses or creating new ones, and in the process, debates between communities and companies have intensified. Projects such as MongoDB, Elastic, and MariaDB have adopted different licensing strategies, and in some cases, public conflicts with large cloud providers have emerged. These changes are not isolated incidents—they have prompted a broader reconsideration of the direction of the entire open source ecosystem.
At the center of this debate lies a fundamental question: how free should open source be, and who is that freedom for? The interests of individual developers, enterprise users, cloud platforms, and the organizations behind projects do not always align. Open source has long grown by maintaining a balance among these interests. However, in recent years, that balance has begun to shift. And the decisive factor that started to break this balance was the rise of the cloud era.
The Foundations of Open Source Licensing — The Philosophy of GPL and Apache
To understand license wars, it is necessary to first examine the philosophy behind open source licenses. Most open source projects do not simply release code—they define conditions of use through licenses. These licenses specify how the code can be used, how modified code must be distributed, and what obligations arise. Although they may appear to be simple legal documents, they are in fact critical elements that shape the rules of the open source ecosystem.
Open source licenses can broadly be divided into two philosophies: Copyleft and Permissive licenses. A representative example of Copyleft is the GPL. GPL originated from the free software movement and allows code to be used freely, but with one important condition. If someone creates and distributes new software based on that code, the resulting software must also be released under the same license. This requirement prevents software from becoming closed-source and ensures that code continues to be shared within the open source ecosystem.
In contrast, Permissive licenses take a much more flexible approach. Licenses such as MIT, BSD, and Apache impose very few restrictions on the use or modification of code. They even allow inclusion in commercial software, requiring only minimal conditions such as attribution to the original author. This makes such licenses highly attractive to companies. Businesses can build products or services based on open source without being obligated to release their own code. As a result, many infrastructure projects have adopted Apache or MIT licenses.
These two philosophies have coexisted throughout the history of open source, each offering different advantages. Copyleft licenses strengthen community-driven collaboration, while Permissive licenses encourage enterprise adoption. For example, the Linux kernel uses GPL, whereas projects like Kubernetes and Apache Kafka use the Apache License. Each project has chosen its license based on its ecosystem and goals.
However, over time, another characteristic of Permissive licenses has become increasingly significant. Because they impose almost no restrictions on usage, they can be used in very large-scale commercial services. In the past, this was not considered a major issue, as most companies sold software as installable products. But with the rise of cloud platforms, the situation changed. Software released under Permissive licenses could now become a core component of large-scale cloud services, leading to the emergence of unexpected economic structures.
In other words, while Permissive licenses continued to promote enterprise adoption, they also began to produce outcomes that could disadvantage the organizations behind open source projects. This shift did not attract much attention at first. But over time, more and more open source companies began to encounter the same issue. Eventually, this led to a new question: are open source licenses still creating a fair structure in the cloud era?
How the Cloud Disrupted the Open Source Economic Model
The structure of the software industry has undergone significant changes over the past two decades. In the past, most software was sold as installable products. Companies purchased licenses, installed servers in their own data centers, and ran applications on top of them. In this model, software companies generated revenue by selling products and providing support services. Open source projects could also establish relatively stable business models within this structure. For example, Red Hat achieved great success by selling enterprise support services based on Linux.
However, with the emergence of cloud computing, this structure changed dramatically. Companies no longer needed to install software themselves. Instead, they could use services provided by cloud platforms. Infrastructure software such as databases, message queues, search engines, and log analysis systems began to be offered as Managed Services. Users no longer needed to manage servers or install software—they could start using services with just a few clicks.
This model was highly convenient for users. But at the same time, it created new challenges for companies behind open source projects. Cloud platforms could build services based on open source software and generate substantial revenue from them. Yet the organizations that originally created those projects were not guaranteed to share in that revenue. In some cases, cloud services attracted far more users and revenue than the official products.
This situation created a complex dilemma for open source companies. Open source licenses were originally designed to allow anyone to freely use code. But it became clear that this freedom could concentrate economic value in the hands of specific companies. This issue became especially pronounced in infrastructure software, where technologies like databases and search engines play a critical role in cloud platforms.
Ultimately, open source companies found themselves choosing between two options. One was to maintain existing licenses and compete directly with cloud platforms. The other was to change licenses and impose restrictions on certain types of usage. The latter was a highly controversial decision, as one of the core values of open source is freedom of use. At the same time, companies faced the practical pressure of building sustainable economic models to maintain their projects.
It was within this context that new types of licenses emerged. Licenses such as SSPL, Elastic License, and BSL were all created in response to the economic realities of the cloud era. These licenses do not completely abandon the philosophy of traditional open source licenses, but they attempt to restrict specific business models. And it is precisely at this point that a new debate between open source communities and companies begins.
In the next section, we will explore one of the first widely discussed cases of this shift—the story of MongoDB and the SSPL license.
MongoDB and SSPL — The First Experiment to Block Cloud Services
When discussing open source licensing debates in the cloud era, one of the first cases that comes up is MongoDB. MongoDB, a NoSQL database that emerged in the late 2000s, grew rapidly and became a significant part of the developer ecosystem. Thanks to its flexible schema and high scalability, many startups and enterprises began adopting MongoDB, and it gained substantial popularity as an open source project. Initially released under an AGPL-based open source license, MongoDB saw its community grow as developers freely used and contributed to it. At first glance, this seemed like a classic example of how open source projects succeed.
However, the situation began to change with the rise of cloud platforms. Companies like AWS started offering Managed Database services based on MongoDB. From a user’s perspective, this was highly convenient. Instead of managing complex database operations, they could provision infrastructure with just a few clicks. But from the perspective of the MongoDB company, the structure appeared problematic. Other companies were building large-scale service businesses based on an open source project that MongoDB itself had developed and maintained.
To address this issue, MongoDB made a significant decision in 2018. It replaced the AGPL license with a new license called SSPL (Server Side Public License). SSPL was based on GPL-style licensing but introduced a much stronger condition that had not existed in traditional open source licenses. If a company provided a service based on the software, it was required to release the source code of the entire service stack. This meant not only disclosing modifications to MongoDB itself, but also revealing all systems involved in operating the service.
This condition was effectively unacceptable for most cloud platforms, as their internal architectures are core business assets. As a result, SSPL delivered a clear message: if you want to build a service based on MongoDB, you must either collaborate with MongoDB or purchase a commercial license. While this strategy can be seen as an attempt to protect an open source project, it also sparked intense debate. The Open Source Initiative (OSI) did not recognize SSPL as an official open source license, and some in the community criticized MongoDB for undermining the spirit of open source.
Despite this controversy, SSPL marked a significant turning point. It was the first clear example of an open source company strategically modifying its license to compete with cloud platforms. And this event became the beginning of even larger conflicts. MongoDB’s decision was not an isolated case—it set the stage for many other open source companies to confront similar challenges. Among them, the most widely debated case would soon emerge: the licensing changes surrounding Elasticsearch.
Elastic License and OpenSearch — The Largest Fork in Open Source History
If the SSPL case of MongoDB marked the beginning of open source licensing debates, the Elasticsearch case demonstrated how far such conflicts could escalate. Elasticsearch was one of the most widely used open source projects in the fields of log analysis and search infrastructure. The so-called ELK Stack—composed of Logstash, Elasticsearch, and Kibana—played a central role in the data infrastructure of countless companies and held a critical position within the open source ecosystem. Elasticsearch was released under the Apache 2.0 license, allowing anyone to use it freely. This permissive licensing contributed significantly to its widespread adoption.
Over time, however, the company Elastic began to recognize a problem. AWS was offering a managed service called Amazon Elasticsearch Service, and it was growing rapidly. From Elastic’s perspective, its own project had become a core service within a cloud platform, yet the contributions and economic returns did not adequately reflect the effort invested in developing the project. Given the massive infrastructure and customer base of cloud platforms, they were able to capture a much larger market—even when based on the same underlying software.
In 2021, Elastic made a major decision. It changed the license of Elasticsearch and Kibana from Apache 2.0 to a dual licensing model using the Elastic License and SSPL. This decision effectively meant that Elasticsearch was no longer an open source project in the traditional sense. While the source code remained visible, the Elastic License imposed restrictions on certain use cases—particularly offering the software as a competing service. In other words, it was a direct attempt to prevent cloud platforms from using Elasticsearch to build competing services.
AWS responded quickly. It created a new project called OpenSearch, based on the last version of Elasticsearch released under the Apache 2.0 license. This was not just a simple fork—it marked the moment when a major cloud provider began building an alternative open source project directly. OpenSearch grew into an independent project, supported not only by AWS but also by a broader community of companies and contributors.
This event holds deep significance in the history of open source. It was not merely a licensing change, but a public manifestation of the economic conflict between open source companies and cloud platforms. The Elasticsearch case raised critical questions: what rights does a company have over services built on its software, and what role should open source licenses play in such scenarios? While some saw Elastic’s decision as a pragmatic response, others viewed it as a departure from open source principles. What became clear, however, is that open source licensing had evolved from a technical choice into a core element of business strategy.
BSL — A New Strategy That Is Neither Fully Closed nor Fully Open
The approaches taken by MongoDB and Elastic were both strong attempts to restrict cloud platforms. However, not all open source companies chose the same path. Some began exploring more balanced approaches. One such model is the Business Source License (BSL). BSL is neither a traditional open source license nor a fully proprietary software license. Its core idea is to provide software under a restricted license for a certain period, after which it automatically transitions into open source.
This model represents an attempt at balance. The company behind the project can limit competing services during the initial years, allowing it to establish a stable business model. At the same time, the software eventually becomes fully open source, contributing to the broader community and ecosystem in the long term. Projects such as MariaDB, CockroachDB, and Sentry have adopted this model for precisely this reason. It allows them to avoid becoming fully closed while gaining an advantage in early-stage competition.
The BSL model can be seen as a compromise between open source philosophy and business strategy. The community gains access to the code over time, while the company retains a window to build its business. Of course, this model is not free from controversy. Some developers argue that BSL is not truly open source in the strict sense. However, from another perspective, it can be seen as a new experiment at the boundary between open source and commercial software.
All of these licensing strategies stem from a common question: how can organizations that create and maintain open source projects build sustainable economic models? And in that process, how much of the open source philosophy can be preserved? MongoDB’s SSPL, Elastic’s licensing changes, and the BSL model are all different attempts to answer the same question. And these attempts have ultimately led to a broader debate that challenges the very definition of open source itself.
Open Source or Source Available — The Debate Over Definition
With the emergence of new licensing models such as MongoDB’s SSPL, Elastic’s license changes, and BSL, a new debate began in the open source world. This debate went beyond the technical question of “which license is better” and moved toward a more fundamental issue: what can truly be called open source. The term “open source” has long carried a specific meaning. Its core principle has been that anyone can freely use, modify, and redistribute code. This principle has been clearly defined through the Open Source Definition established by the Open Source Initiative (OSI). For decades, this definition has served as the foundation of the open source ecosystem.
However, new licenses that emerged in the cloud era began to subtly conflict with this definition. Licenses such as SSPL or the Elastic License make source code available but impose restrictions on certain types of use. In particular, when software is provided as a cloud service, these licenses often require strict conditions or even prohibit such usage entirely. From a company’s perspective, these restrictions may be a practical necessity. But from the standpoint of OSI’s criteria, they raise concerns. Open source licenses are not supposed to discriminate against specific industries or business models. This is where a new term emerged: Source Available.
Source Available software, as the name suggests, makes the source code accessible. Anyone can read it, learn from it, and modify it. However, not all forms of usage are allowed. In many cases, restrictions apply to competitive service offerings or large-scale commercial use. For companies, this model can be appealing. It allows them to collaborate with the developer community by sharing code while still protecting their core business model. But within parts of the open source community, this approach is viewed critically. The concern is that the meaning of “open source” may gradually become diluted.
This debate is not merely about terminology. For developers participating in open source projects, licenses carry significant meaning. Many contribute to open source because they want the code to remain a shared asset rather than becoming the property of a specific company. If a project transitions to a Source Available license, some contributors may choose to stop participating. On the other hand, companies argue that without a sustainable financial foundation, open source projects themselves cannot survive. Ultimately, this debate comes down to the question of where to draw the balance between philosophy and reality.
This tension demonstrates that open source is no longer just a development culture—it has become part of a large industrial structure. In the past, many projects grew primarily through community-driven collaboration. Today, however, countless companies operate businesses based on open source. In this context, licenses are no longer just technical details—they are key elements that shape the direction of entire ecosystems. And at this point, another question naturally arises: if the definition of open source is changing, what strategies will companies choose moving forward?
Licenses Are No Longer Technology — They Are Business Strategy
In the early history of open source, licenses were primarily understood as legal protection mechanisms. They allowed developers to share code while retaining copyright, and at the same time ensured that code could be freely distributed and reused. However, in the modern software industry, the meaning of licenses has become far more complex. As infrastructure software and cloud platforms have converged, licenses have evolved from simple legal documents into core components of business strategy. The choice of license can directly influence the competitive dynamics of the market.
For example, choosing a permissive license can accelerate developer adoption. Companies can freely use and integrate the code into their products, leading to rapid ecosystem growth. At the same time, however, it also increases the likelihood of competing services emerging. In contrast, a strong copyleft license may limit the free spread of code but makes it easier to retain control over the project. Newer licenses such as SSPL and BSL can be seen as attempts to find a new balance between these two approaches.
These dynamics are especially visible in open source-based startups. Many infrastructure software companies initially use open source to build a developer community and later establish revenue models through enterprise features or services. In this process, the license determines not only whether the code is open, but also how the company can generate revenue. If a cloud platform can build a competing service based on the same software, the business model of the original company can become significantly more difficult.
As a result, license selection has become as important as technical strategy in recent years. Companies now consider factors such as adoption speed, community participation, the risk of competing services, and long-term revenue structures when choosing a license. This involves navigating the tension between traditional open source philosophy and practical business requirements. Some companies continue to adopt fully open licenses, others choose Source Available models, and some create entirely new licensing frameworks.
Ultimately, for modern open source companies, a license is not just a document defining usage conditions. It is a design that combines product strategy, market positioning, and competitive dynamics. And this design is deeply connected to the broader economic structure of the software industry. Without understanding this shift, recent license changes may appear to be isolated corporate decisions. In reality, they reflect a much larger transformation in how the industry operates.
Open Source After the Cloud Era — Searching for a New Balance
The cases examined so far reveal a common pattern. Open source no longer simply means free software. It has become part of a complex economic structure involving developer ecosystems, corporate strategies, and cloud infrastructure. New licensing models such as MongoDB’s SSPL, Elastic’s licensing changes, and BSL all originate from the same question: how can organizations that build open source projects create sustainable economic structures? And this is not a problem limited to a few companies—many infrastructure software projects today face the same challenge.
Before the rise of cloud platforms, the relationship between open source and companies was relatively straightforward. Companies built products or provided support services based on open source, and projects grew through collaboration between communities and organizations. However, as the cloud service model expanded, this structure changed significantly. Economic value began to shift from the software itself to how that software is delivered as a service. This shift introduced a new challenge for open source companies: they needed to find a balance between allowing free use of code and ensuring the long-term sustainability of their projects.
This led to the wave of license changes seen in recent years. SSPL attempted to solve the problem by directly restricting cloud service models. The Elastic License sought to protect economic value by limiting specific forms of usage. BSL proposed a compromise by allowing software to become fully open source after a certain period. While these approaches differ significantly, they all reflect the same reality: as open source projects become more successful, the economic value built on top of them grows—and the way that value is distributed becomes a source of new debate.
These debates can sometimes appear to undermine the philosophy of open source. Some developers criticize Source Available models and new licensing strategies. At the same time, there is a strong argument that sustainable economic structures are necessary to maintain open source projects. Supporting a project over many years, with teams of developers continuously improving and maintaining it, requires stable funding. Ultimately, the debate returns to the question of where to place the balance between philosophy and reality.
One important fact remains: this balance has not yet been fully determined. The open source ecosystem continues to evolve, with new licensing models and business strategies emerging. Some projects maintain fully open licenses, others adopt Source Available approaches, and still others experiment with community-driven governance models. All of these efforts share a common goal—ensuring that open source remains sustainable.
In the end, what we call “license wars” may not simply be a history of conflict, but rather a process of adaptation. As the structure of the software industry changes, the rules that govern it must also evolve. Open source is no exception. Between decades-old traditions of collaboration and new economic realities, the open source ecosystem is still searching for a new equilibrium. And that ongoing process may be the clearest evidence that open source remains a living, evolving system.
