When “Open Source” Stops Being Open
Single-source software companies—businesses built around a single, widely adopted project—are increasingly abandoning OSI-approved open source licenses in favor of “source available” alternatives. The rationale is straightforward: cloud providers are using those licenses to compete directly against the very companies that created the software.
Why the License Shift Is Happening
These companies typically rely on one of two business models. In the open-core model, a vendor sells proprietary add-ons or services around a free and open source project. In dual-licensing, the same software is offered both under a FOSS license with obligations that are cumbersome for enterprises and under a commercial license that removes those burdens. Both models depend on viral adoption: today’s developer who grabs the free version is tomorrow’s paying customer.
The rise of cloud infrastructure has put both models under strain. With workloads moving from on-premises servers to hyperscale data centers, cloud vendors can take a project’s open source license and stand up a managed offering—often pushed by customers who prefer consolidating their compute spend with a single provider. The cloud vendor, not the original vendor, ends up with the first relationship with the user. That makes it far harder for the open-core or dual-licensing company to convert users into paying customers.
From Broad Restrictions to Surgical Ones
Several prominent vendors have responded by moving off OSI-approved licenses entirely. Confluent, MongoDB, Cockroach Labs, Redis Labs, Timescale, and Graylog have all shifted to source-available licenses that impose restrictions aimed squarely at cloud infrastructure providers.
The first wave of these efforts was broad. The Commons Clause, for example, limited “commercial use” generally. But users found the wording “created some confusion and uncertainty,” and Redis Labs eventually dropped it in favor of more targeted language. Newer licenses, such as Elastic’s Elastic License v2, take a narrower approach: they permit nearly everything except standing up the software itself as a hosted service. The intent is to keep benefiting from widespread source availability and community growth while preventing competitors from offering the same code as a SaaS product.
What Developers Should Watch For
The lesson for developers choosing dependencies is to evaluate who actually controls the project. A project with a non-profit home, neutral trademark ownership, and multiple significant contributors is far less likely to face relicensing pressure. A project that serves as the primary revenue engine for a single for-profit company exists under a different set of constraints. Any for-profit business must protect its bottom line, and that may mean relicensing the project if its current license enables competitors to erode its revenue.
Understanding the structure behind your dependencies is now as important as evaluating the code itself.
