Is “vendor owned open source” an oxymoron?
Update: the post was updated following the relicensing of Redis, CockroachDB, and HashiCorp’s projects (incl. Terraform) off open source.
Open source is eating the world. Companies have realized and embraced that, and ever more companies today are built around a successful open source project.
But there’s also a disturbing counter-movement:
vendors relicensing popular open source projects to restrict usage in a “rights ratchet” play.
The cases when your open source is turning to the dark side.
Last week it was Grafana Labs which announced relicensing Grafana, Loki and Tempo, its popular open source monitoring tools, from Apache2.0 to the more restrictive GNU AGPLv3 license.
This comes at the heel of Elastic’s move a couple of months ago, relicensing Elasticsearch and Kibana, previously Apache2.0 licensed, to a non-open-source dual license based on SSPL (Server Side Public License).
SSPL itself was invented by MongoDB in 2018 for relicensing its popular database away from AGPLv3. Although MongoDB (and now Elastic) tried portraying SSPL as an open source license, the Open Source Initiative (OSI), the body in charge of open source licensing, rejected these attempts then and this time around.
Remember, some of this code was contributed by community members under Apache2.0 license for the good of the community. By close-sourcing or restricting this code use, the vendor used the Contributor License Agreement (CLA) to get rights off the contributors, and essentially then turn their free contribution into its own asset against their intentions.
Besides MongoDB, there are a handful of examples from recent years of other vendors inventing their own non-OSS licenses to restrict open source projects, oftentimes in an open core model where capabilities are not introduced to the open source project but rather are packaged separately under non-OSS licenses. Examples include:
- Timescale, which introduced features under Timescale License (“TSL”) on top of the Apache 2.0 licensed core TimescaleDB.
- Cockroach Labs, which introduced features under Business Source License (BSL) and Cockroach Community License (“CCL”) on top of the Apache 2.0 Licensed core CockroachDB, then relicensed the core to BSL in 2019.
UPDATE, August 2024: CockroachDB was relicensed again to a fully proprietary license. - Redis Labs, which introduced add-on “modules” licensed under Redis Source Available License (RSAL) on top of the BSD licensed core Redis.
UPDATE, April 2024: Redis’ core was relicensed off open source, moving to a dual license, SSPL and RSAL.
Pay back vs. Pay it forward
Why is that? Why are vendors that are deeply vested in open source making such blunt anti-community and anti-OSS moves?
Some claim that these companies weren’t true open source players. I tend to disagree. Knowing the work of these companies and their investment, I believe they start off with great commitment to open source, and they put in many engineering hours to build and maintain.
What these companies don’t have, however, is the business model to support it. They forget the simple rule:
Open source is not a business model.
Commercial vendors are built to maximize profit on their investment (RoI).
Open source, on the other hand, is built to share knowledge and benefit the community, whether individuals, startups or large corporations.
I call it the Pay back vs. Pay it forward paradox.
If you build an open source with the aim of others not being able to profit from it, you’re bound to run into that paradox. The clash typically comes when other vendors start using the open source and building products or services that compete with your business. When that clash happens, commercial companies instinctively close to protect their assets, same as they would with traditional intellectual property.
It’s not that these companies didn’t intend on open source. Rather, they were unable to reconcile it with their commercial model.
Some may argue that it’s good cold business sense: they build a great open source tool, gather a large user base for it, and then restrict the license, betting on the vendor lock-in and the users being deeply vested in their tool and community to keep them hooked.
However, as open source becomes mainstream, companies make open source a selection criterion. For example, following their relicense Red hat dropped MongoDB. Another example is Google, which bans even the OSI-approved (yet restrictive) AGPLv3 usage.
Furthermore, such unilateral changes make many users feel unease, and even flag these as business risks. A strong community may also react to a vendor’s relicensing move by forking the successful project, and keeping it open as an independent project. AWS is leading such an attempt now with forking Elasticsearch and Kibana to a new OpenSearch project and gathering the community behind it.
UPDATE August 2023: another high-profile case in 2023 is HashiCorp which decided to relicense Terraform, Vault, Consul, and other open source projects to non-OSS Business Source License. To date, this has resulted in two forks: OpenTofu fork of Terraform and OpenBao fork of Vault, both of which under the Linux Foundation (the forks aren’t related, despite the common food theme).
Time will tell if these recent moves pay off for these vendors. Perhaps it’s because of the database domain (Elasticsearch, MongoDB, Redis etc.), but I keep getting flashbacks from the Oracle and IBM ruling days.
But there’s another way.
Open source is not a business model
Some companies figured out a business model. Red Hat, SUSE and Canonical are prime examples of that. Some companies haven’t, and ran into the wall. Then their open source started to crack. That’s what happened to MongoDB, Elastic, Grafana and the others above. In their own words, they testify suffering from the competition of giants such as Amazon.
It requires a slightly different thinking from the traditional approach, though principles are the same.
With a services model, a company can build its business around professional services for a successful open source.
With a product model, a company needs to clearly understand its unique value proposition (UVP), build this secret sauce into its IP, and everything else can be considered for open source with full commitment. There’s no half-pregnancy.
As open source projects tend to have a very focused objective, other production-grade concerns are oftentimes left out or not fully covered, whether operational, administrative, security, compliance or other. These unattended concerns are business opportunities for vendors.
This is of course not a static but rather an ever-evolving thing. As the project matures and its usage in production environments grows, the community naturally drives to cover more of these concerns. That requires the vendor to keep innovating and refining its UVP. Unfortunately, too often vendors miss that and instead react defensively, blocking the community from contributing open source code around these concerns. This is an early red flag that may signal the later relicensing move.
Red flags in Open Source Software
A controlling vendor blocking community contributions is one red flag to watch out for, but there are other red flags you can detect, if you look in the project.
The early cracks were there before, if you paid attention.
In Elastic’s example, a review of the Elasticsearch and Kibana source code done recently revealed just how much Elastic tainted the open source with proprietary stuff, such as non-Apache 2.0 licensed code (Elastic’s proprietary ‘x-pack’) entangled in the open source as well as embedded telemetry collection, hooks to proprietary backend services, proprietary technical documentation and other non-open-source stuff, which goes to show how much the vendor treats this project as its asset rather than a community project.
If you truly believe in OSS — Let it go
Companies can start a successful open source project.
But they cannot keep it long term.
Vendor ownership is a suffocating hug.
Companies that have real commitment to OSS need to let the project go, release it to the community with objective governance.
Solid governance helps guarantee that no single vendor gains control over the project. Governance also gives clarity and transparency into how decisions are made, how meetings are held, how community members can influence and get promoted in a meritocratic way.
A good way to employ community-backed governance is with open source foundations, such as Apache Foundation, Linux Foundation and the Cloud Native Computing Foundation (CNCF, under the Linux Foundation). the foundations can also be the legal owners of the brands for safeguard.
A prime example is when Google open-sourced Kubernetes and founded the CNCF to ensure it will be backed by a strong and diverse community, which indeed enabled Kubernetes to flourish and become the de-facto standard for containerization.
And you can add Uber, Facebook and many other tier-1 companies who donated successful projects to the community, which we all use on a daily basis.
An OSI-certified open source license is necessary, but certainly isn’t sufficient.
Real open source needs community-backed governance.
Originally published at http://horovits.wordpress.com on May 1, 2021.
