Regrettably, it's becoming a common occurrence to see well-performing open-source projects shifting towards a more closed-door approach, with weird vanity licenses being deployed that make the code less open.
Many usually opt for a “source available” policy, where the code is publicly accessible, available for anyone to view, while restricting any form of commercial usage. The debate on open-source vs. source available is a never-ending one, but one that divides the community of software developers as a whole.
In a similar type of situation, CockroachDB, a popular distributed SQL database management system developed by Cockroach Labs, recently announced that they were changing their licensing terms.
CockroachDB: The Same Old Story?
Come November 2024, the free CockroachDB Core offering will be no more, and a new enterprise licensing system will take its place to cater to users. Cockroach Labs asserts that they have taken this measure to encourage established organizations to utilize the full capabilities of the platform without any compromises by opting for one of the new plans.
There are two enterprise plans individuals/organizations can choose from:
- The first is the free CockroachDB Enterprise Free plan, meant for individuals, organizations, researchers, etc. with an annual revenue below $10 million. They will be provided with annual renewal (subject to eligibility check) and community support.
- The second one is the paid CockroachDB Enterprise plan with all the features as Free, but with dedicated support, and the flexibility to opt for a 30-day self-service trial (with only community support).
The second plan is meant for large-scale commercial businesses with more than $10 million in revenue, and government use.
Following this change, the code for CockroachDB will just be source available, with restrictions on commercial use or redistribution without a license by Cockroach Labs.
CockroachDB was originally offered under the Apache License 2.0, with a subsequent switch to the Business Source License (BSL), and finally, settling on their in-house Cockroach Community License (CCL) for their enterprise offerings.
However, there's another concerning aspect with this situation. In the licensing comparison table below, do you see the section about Telemetry? The bit around the end of the table. 👇
On the free trial of the paid enterprise plan, and on the free enterprise plan of CockroachDB, users cannot opt out of Telemetry, which makes the latter a mandatory requirement to deploy CockroachDB on non-paid self-hosted plans.
I am sure many of the people reading this won't like that, but, it is what it is. You can check out what kind of telemetry system is in use by going through their blog on it.
When announcing these changes, CEO at Cockroach Labs, Spencer Kimball added that:
With the introduction of version 24.3 in November, we are retiring our Core offering and introducing a new Enterprise licensing structure for self-hosted users, also applied to new patch releases of versions 23.1 and later.
This new structure will provide all users with the robust database capabilities found previously only in the self-hosted Enterprise license. CockroachDB will remain entirely source code available.
You can take a closer look at the updated licensing of CockroachDB on the official website.
The Community Sees What's Going On
As expected, the conversation over this move has gained traction on Hacker News, with one of the community members, saying that:
I understand the goal, and the perceived abuse of the Core edition. But the problem with the Enterprise edition is that it's quite expensive, "contact us" salesy, and it feels like taking a bite of this edition is possibly getting into bed with a future Oracle/landlord type of relationship where you end up squeezed by your database vendor.
I agree with what they have said, this change has created the perfect stage for vendor lock-in. Organizations and individuals who are drawn towards CockroachDB for its features and scalability, will inevitably end up paying increasing amounts of money as they grow.
This begs the question, should anyone integrate such restrictive options into core parts of their IT infrastructure? I leave you to answer that question, feel free to add your thoughts in the comments below.
Suggested Read 📖
Ankush Das
More from It's FOSS...
- Support us by opting for It's FOSS Plus membership.
- Join our community forum.
- 📩 Stay updated with the latest on Linux and Open Source. Get our weekly Newsletter.
