CockroachDB license change(cockroachlabs.com)
cockroachlabs.com
CockroachDB license change
https://www.cockroachlabs.com/enterprise-license-update/
469 comments
It seems that whenever an open source project is run by a VC-backed company, it sooner or later ends up like this. Increasingly it seems that "open source" is just the teaser to get people interested and then when investors want revenue growth, the rug gets pulled.
IMO, it's not really open source if its run by a company that will eventually use its position to squeeze its users for cash.
IMO, it's not really open source if its run by a company that will eventually use its position to squeeze its users for cash.
> IMO, it's not really open source if its run by a company that will eventually use its position to squeeze its users for cash.
I know it's not as popular or sexy as it used to be, but the whole point of a foundation like Apache was to avoid these situations, even more than the way the Linux Foundation is setup. Apache _explicitly_ manages projects to avoid these downsides.
- Single corporation ownership. Projects cannot get out of the Incubator unless they demonstrate a diverse and healthy community. That doesn't mean popular, it doesn't necessarily mean best-in-class, but it means that there shouldn't be just one entity backing a project.
- Membership in Apache is _personal_ not a seat for a given company. If you're a committer on an Apache project and you move jobs, you're _still_ a committer on that project
- The Foundation owns the trademarks. There have been fights about this in the past, but the whole idea is that the _community_ owns the name, so some corporation can't claim to be the sole or official owner by naming their company or product after the open source product.
The core premise of the Apache Software Foundation is community over code, that healthy, diverse communities have a better chance of standing the test of time than open source projects backed by a single individual or company. That's the thesis at least.
The is starkly different from several other foundations, notably the Linux Foundation or Eclipse Foundation which are modeled more around industry consortiums.
Both models have their place, but I believe Apache better models the core values many of us feel strongly about when it comes to free and open source software.
I know it's not as popular or sexy as it used to be, but the whole point of a foundation like Apache was to avoid these situations, even more than the way the Linux Foundation is setup. Apache _explicitly_ manages projects to avoid these downsides.
- Single corporation ownership. Projects cannot get out of the Incubator unless they demonstrate a diverse and healthy community. That doesn't mean popular, it doesn't necessarily mean best-in-class, but it means that there shouldn't be just one entity backing a project.
- Membership in Apache is _personal_ not a seat for a given company. If you're a committer on an Apache project and you move jobs, you're _still_ a committer on that project
- The Foundation owns the trademarks. There have been fights about this in the past, but the whole idea is that the _community_ owns the name, so some corporation can't claim to be the sole or official owner by naming their company or product after the open source product.
The core premise of the Apache Software Foundation is community over code, that healthy, diverse communities have a better chance of standing the test of time than open source projects backed by a single individual or company. That's the thesis at least.
The is starkly different from several other foundations, notably the Linux Foundation or Eclipse Foundation which are modeled more around industry consortiums.
Both models have their place, but I believe Apache better models the core values many of us feel strongly about when it comes to free and open source software.
Apache isn't a silver bullet... there are plenty of Apache projects where the individuals are compromised mostly from one company and hide behind the veneer of the ASF... where they are working on the projects per their employment. Gerrymandering is definitely possible and has happened in the past, that's why you have to look at governance and ownership of the marks/build systems etc: https://www.aniszczyk.org/2019/10/08/open-source-gerrymander...
I actually prefer the approach of LF, EF or CNCF where it's transparent where folks work for and your affiliation is disclosed upfront. In the CNCF for example, we separate out technical project decisions (maintainers) from funding decisions (members). That is healthier than blending it all in one at the ASF imho and having no idea where person is working for imho.
I actually prefer the approach of LF, EF or CNCF where it's transparent where folks work for and your affiliation is disclosed upfront. In the CNCF for example, we separate out technical project decisions (maintainers) from funding decisions (members). That is healthier than blending it all in one at the ASF imho and having no idea where person is working for imho.
Agreed. Red Hat isn't perfect, but when I worked there we had a few products that were CNCF under my umbrella, including a few incubator projects. Even though we had several developers working full or part time on those projects, it was always something I was meaningful of, not stacking the project board Red Hat-heavy, to not make it a defacto RH project.
After the RedHat/Hyprland fiasco, it feels like RedHat is corrupt with SJW that are focused more on polics than on actual code
What is more popular than the Apache Foundation? I thought Apache was top... Is there a cooler/better Apache? If so, please let me know.
And when was Apache more popular? I thought it was the uncool place where stuff was written in Java, that became popular because people's conception of Java (and the language/ecosystem itself) changed.
And when was Apache more popular? I thought it was the uncool place where stuff was written in Java, that became popular because people's conception of Java (and the language/ecosystem itself) changed.
Apache is both popular and “the place where projects go to die”. They have many, many projects that see limited development activity and aren’t well-known (how many projects in https://projects.apache.org/projects.html?name do you even vaguely know of what they’re about?)
I also think the popularity of the Apache license is part of what makes Apache popular.
> I thought it was the uncool place where stuff was written in Java
They have lots of projects running on the JVM, but “written in Java” isn’t a requirement, nor is “running on the JVM”. See https://projects.apache.org/projects.html?language
I also think the popularity of the Apache license is part of what makes Apache popular.
> I thought it was the uncool place where stuff was written in Java
They have lots of projects running on the JVM, but “written in Java” isn’t a requirement, nor is “running on the JVM”. See https://projects.apache.org/projects.html?language
EDIT: wrote something stupid here before my morning coffee
This is an Eclipse foundation project, not an Apache Software Foundation (ASF) project?
it's all volunteers/open source, but this isn't an ASF project.
it's all volunteers/open source, but this isn't an ASF project.
I'm sorry, I hadn't finished my coffee yet.
I'm gonna go embarrasingly delete this thread tail between my legs...
I'm gonna go embarrasingly delete this thread tail between my legs...
I think CNCF is home to most of the big projects I’ve been contributing to or using lately.
CNCF is a project of the Linux Foundation - which has become absolutely massive: https://www.linuxfoundation.org/projects
Ah yes, thank you! But would you say they more about infra/platform while Apache is more about application?
immibis(1)
Old(?) school open source with GPL licenses doesn't seem to suffer from this, on a first glance. Maybe Stallman was right. Would love to hear from someone more knowledgeable on this. I'm not trying to troll.
Maybe? Every day it seems clearer that Stallman is right. Mouse subscription? Windows displaying ads in start menu and recording everything you do? How many devices have become useless when the servers shot down, or games became unplayable? How many times books or songs or movies have disappeared from "online collections" after being paid for? "The right to read" seems more and more realistic as time passes.
In my opinion, Stallman has been proven right many times over.
In my opinion, Stallman has been proven right many times over.
Well what do you expect to maintain the mouse’s cloud servers, if not subscription revenue? The greed here!
if the server was integral to the running of the service then yes, it makes sense to discontinue it when there's no more profit to be made.
However, increasingly more and more services which could've been an on-premises deployment become SAAS. This includes games (live services they call it). It is _designed_ to end, and designed to not be able to run locally.
Tell me who's the greedy one.
However, increasingly more and more services which could've been an on-premises deployment become SAAS. This includes games (live services they call it). It is _designed_ to end, and designed to not be able to run locally.
Tell me who's the greedy one.
I don't think it's designed to end, they're just trying to:
- Prevent piracy
- Extract more money per user (subscriptions, repeated purchases in-game)
Look, you can live perfectly fine without all of those services, there are indie games and there are old games and, according to some, they're much better than any online crapware from today.
Make it a point not to buy Free to play online crap, forbid your kids from playing that crap. Absolutely don't give them any money for this crap.
If enough people stop buying the we'll see a shift to the DRM & no hassle approach of indie games. I'd also prefer giving my money to a small team of devs than some corporate ladder who happend to purchase the latest AAA game built by a studio of overworked and underpaid devs.
- Prevent piracy
- Extract more money per user (subscriptions, repeated purchases in-game)
Look, you can live perfectly fine without all of those services, there are indie games and there are old games and, according to some, they're much better than any online crapware from today.
Make it a point not to buy Free to play online crap, forbid your kids from playing that crap. Absolutely don't give them any money for this crap.
If enough people stop buying the we'll see a shift to the DRM & no hassle approach of indie games. I'd also prefer giving my money to a small team of devs than some corporate ladder who happend to purchase the latest AAA game built by a studio of overworked and underpaid devs.
1. Create a mouse that needs Cloud services.
2. Need revenue to pay for the Cloud services.
3, Charge mouse users for the Cloud services.
It's the (stupid) circle of life.
2. Need revenue to pay for the Cloud services.
3, Charge mouse users for the Cloud services.
It's the (stupid) circle of life.
It's scary to have you say that when logitech recently looked a computer mouse that needs a subscription:
https://arstechnica.com/gadgets/2024/07/logitech-has-an-idea...
https://arstechnica.com/gadgets/2024/07/logitech-has-an-idea...
Was he though? If we didn't have GPL perhaps at least our software and data would've still been on our computers instead of a privately owned cloud...
GPL is actually a great license for this scenario. The software advances to a particular level of development, inertia, market penetration - then the company that owns the software dual licenses with GPLv3 - which no company can risk to have on their premise, distribute, or use/touch, etc... - ergo you then have to pay for a commercial license to avoid the GPLv3 taint.
Why can companies not use GPL3 software? I cannot see how its so different from GPL 2 for companies that are users.
I can see it has some disadvantages for companies incorporating GPL software in their products, but none for companies merely using GPL 3 software.
I can see it has some disadvantages for companies incorporating GPL software in their products, but none for companies merely using GPL 3 software.
I can't say for certain why they can't use GPLv3 - just that no company I've ever worked for (n=4 since GPLv3 came out) - will allow it on premise. It's probably why Apple stopped updating all their GNU binaries, and you have to sideload stuff with brew to use anything released in the last 10 years.
If I had to guess - The patent rights clause weirds out a lot of lawyers. Obviously anyone who works with hardware doesn't like the anti-tivoization clause. Another possibility is the AGPL (which IS lethal for obvious reasons) is often conflated with GPLv3.
All I know is GPLv2 is fine, GPLv3 is usually not, and AGPL is never possible in corporations that I've worked for.
If I had to guess - The patent rights clause weirds out a lot of lawyers. Obviously anyone who works with hardware doesn't like the anti-tivoization clause. Another possibility is the AGPL (which IS lethal for obvious reasons) is often conflated with GPLv3.
All I know is GPLv2 is fine, GPLv3 is usually not, and AGPL is never possible in corporations that I've worked for.
A small refinement here, your statements are largely my experience dealing with people linking against gpl3 software because of the vitality and the patent exemptions. Most places run gpl3 stuff just fine. The one organizations won’t touch with a ten foot pole, even to run it, is AGPL.
I remember that Neo4j Enterprise used to be available under AGPL. They pulled it and now it's available only under a commercial license.
AGPL is not a problem for server-side software if you don't need to modify it. Your application (talking to the server) doesn't become infected by AGPL.
AGPL is not a problem for server-side software if you don't need to modify it. Your application (talking to the server) doesn't become infected by AGPL.
> A small refinement here, your statements are largely my experience dealing with people linking against gpl3 software because of the vitality and the patent exemptions
In the context of the thread (the claim GPL 3 provides more of a motive for people to by paid licences for dual licensed software) I think that "small refinement" covers most of what we are talking about though.
In the context of the thread (the claim GPL 3 provides more of a motive for people to by paid licences for dual licensed software) I think that "small refinement" covers most of what we are talking about though.
> won’t touch with a ten foot pole, even to run it, is AGPL.
I feel out of touch
Why?>
I feel out of touch
Why?>
The AGPL has a significantly stronger viral clause than the plain GPL. You must offer the source code to anyone who connects to the AGPL-covered code via a network connection (i.e. must open source the entire server if it is using any AGPL code)
Releasing the whole server sounds more like the Commons Clause or the SSPL. AGPL requires you only to provide the source code of your fork to its users.
> AGPL requires you only to provide the source code of your fork to its users
The AGPLv3 is exactly the same as the GPLv3, except with the added clause that connecting to a server counts as distribution for the purposes of triggering the right to obtain source code.
That means all the usual GPL copyleft rules apply: if you include an AGPL library in your server binary, the entire binary becomes subject to the AGPL. And being subject to the AGPL, you are obligated to provide access to the source code for your entire server binary to anyone who connects to and interacts with your service across a network.
Quoting from https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... :
> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program...
> These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient...
> The AGPLv3 does not adjust or expand the definition of conveying. Instead, it includes an additional right that if the program is expressly designed to accept user requests and send responses over a network, the user is entitled to receive the source code of the version being used.
The AGPLv3 is exactly the same as the GPLv3, except with the added clause that connecting to a server counts as distribution for the purposes of triggering the right to obtain source code.
That means all the usual GPL copyleft rules apply: if you include an AGPL library in your server binary, the entire binary becomes subject to the AGPL. And being subject to the AGPL, you are obligated to provide access to the source code for your entire server binary to anyone who connects to and interacts with your service across a network.
Quoting from https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... :
> Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program...
> These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient...
> The AGPLv3 does not adjust or expand the definition of conveying. Instead, it includes an additional right that if the program is expressly designed to accept user requests and send responses over a network, the user is entitled to receive the source code of the version being used.
Yes, but are there any AGPL-licensed libraries? I've only seen runnable binaries licensed under AGPL. I can theoretically imagine one, "if you want to build a server application using my binary, I don't want you hiding my source code from your users", but even GPL-licensed libraries are rare, LGPL is more common.
Ah but what if you bundle both your application binary and some (unmodified) AGPL software into a single Docker container? Do you then need to provide source code for your entire application?
> I can't say for certain why they can't use GPLv3 - just that no company I've ever worked for (n=4 since GPLv3 came out) - will allow it on premise
My limited experience with IP lawyers at big software companies is that they have zero understanding of software licensing and patent law. They just seem to parrot some line they learned in college 10 years ago, even when the plain text of the license or law sitting in front of them proves them wrong. It's honestly baffling how they get these jobs.
My limited experience with IP lawyers at big software companies is that they have zero understanding of software licensing and patent law. They just seem to parrot some line they learned in college 10 years ago, even when the plain text of the license or law sitting in front of them proves them wrong. It's honestly baffling how they get these jobs.
I can see it makes sense for Apple (anti-tivoization is something they do not want).
> I can't say for certain why they can't use GPLv3 - just that no company I've ever worked for (n=4 since GPLv3 came out) - will allow it on premise
So they do not allow the use of things like Bash or GNU coreutils? That seems quite restrictive and difficult.
> I can't say for certain why they can't use GPLv3 - just that no company I've ever worked for (n=4 since GPLv3 came out) - will allow it on premise
So they do not allow the use of things like Bash or GNU coreutils? That seems quite restrictive and difficult.
They often use older version of things like Bash and Coreutils, or equivalents from other ecosystems (i.e. Apple ships the BSD versions thereof)
So, for example, if they use RHEL version 6 or later they will install it without the default shell?
Apple is different as they produce their own OS. I am asking about non-software companies avoiding GPL3 which would be necessary for (as the comment I responded to earlier in the tread claims) the use of GPL3 providing a motive to pay for licenses for dual licensed software in a way GPL2 does not.
Apple is different as they produce their own OS. I am asking about non-software companies avoiding GPL3 which would be necessary for (as the comment I responded to earlier in the tread claims) the use of GPL3 providing a motive to pay for licenses for dual licensed software in a way GPL2 does not.
I used to work for a company that used AGPL. For databases, in particular, it's not as noxious as people make it seem, other than if you are a hyperscalar trying to commercialize someone else's hard work and run them out of business, or a bottom feeding hosted service company also trying to commercialize someone else's hard work and coattail on their success.
Otherwise it works great for end-user adoption.
Otherwise it works great for end-user adoption.
Old school open source projects don't seem particularly profitable. The projects themselves might thrive, but that seem to rely on altruistic developers with other sources of income.
Richard Stallman himself doesn't seem to make money from any software he made directly, but from various grants and such, for example:
https://web.archive.org/web/20220123032418/http://tech.mit.e...
I thought he was on the payroll for FSF, but his reportable compensation has been zero from 2002 to 2022 according to:
https://www.fsf.org/about/financial
Richard Stallman himself doesn't seem to make money from any software he made directly, but from various grants and such, for example:
https://web.archive.org/web/20220123032418/http://tech.mit.e...
I thought he was on the payroll for FSF, but his reportable compensation has been zero from 2002 to 2022 according to:
https://www.fsf.org/about/financial
You're kinda saying the same thing there.
As a developer, I don't want to rely on code from a project that "seems particularly profitable", because one day it's 100% certain they're going to start making their profit off me.
I'm _extremely_ wary of any "open source" projects that're VC funded, because the entire VC industry exists to make rich people richer at everybody else's expense, throwing a few bones at a few of the founders and a vanishingly small portion of the startup employees. As soon as they think that can get away with it because they have enough "free" open source users locked, they're gonna turn all the screws to chase the "100x or bust" exit strategy the VCs rely on. At the expense of everybody who foolishly built something on to of that project without an easy way to replace it.
As a developer, I don't want to rely on code from a project that "seems particularly profitable", because one day it's 100% certain they're going to start making their profit off me.
I'm _extremely_ wary of any "open source" projects that're VC funded, because the entire VC industry exists to make rich people richer at everybody else's expense, throwing a few bones at a few of the founders and a vanishingly small portion of the startup employees. As soon as they think that can get away with it because they have enough "free" open source users locked, they're gonna turn all the screws to chase the "100x or bust" exit strategy the VCs rely on. At the expense of everybody who foolishly built something on to of that project without an easy way to replace it.
I am saying that old school projects aren't paying the developers' bills because they aren't profitable. The developers realize this too, there is only so much altruism to go around but you got mouths to feed and rents to pay.
As an alternative to working on a second job to fund their passion, we are seeing developers trying various things to make their one passion job pay, such as licensing tweaks or VC funding. These don't seem to work out very well, I think it's best explained here:
https://apenwarr.ca/log/20211229
As an alternative to working on a second job to fund their passion, we are seeing developers trying various things to make their one passion job pay, such as licensing tweaks or VC funding. These don't seem to work out very well, I think it's best explained here:
https://apenwarr.ca/log/20211229
"So it is with free software. You literally cannot pay for it. If you do, it becomes something else."You are correct, but there is also an interesting phenomenon going on here: old school open source projects last longer. They end up being more reliable in the long term. It's kind of weird that the unprofitable option is the stable one.
> They end up being more reliable in the long term.
you're just seeing survivorship bias.
Plenty of them would've also disappeared, because their core contributor no longer wanted to give out free labour and moved on.
you're just seeing survivorship bias.
Plenty of them would've also disappeared, because their core contributor no longer wanted to give out free labour and moved on.
It's almost like capitalism is a destructive force and a poor way to organise a society.
Capitalism works fine under certain conditions: free markets, which implies competition.
The problem is that these conditions do not always prevail.
I used to think this was fixable: https://pietersz.co.uk/2009/11/fix-capitalism
I now think it is more complex and we need a mixed economy.
The problem is that these conditions do not always prevail.
I used to think this was fixable: https://pietersz.co.uk/2009/11/fix-capitalism
I now think it is more complex and we need a mixed economy.
> Capitalism works fine under certain conditions: free markets, which implies competition. The problem is that these conditions do not always prevail.
Eventually, on the free market there are winners, and these winners form a monopoly. See Nestle, Tyson foods, Apple. The big corps, having cornered the market, then squeeze the hapless users (and the ecosystem, in Apple's case) into exorbitant prices, because there is no competition. You started with your beloved "free market", ended up with a monstrous monopoly. Surprise, this is how any "free market" story ends.
If you want to avoid the trash situations that we are in today, you need to regulate the shit out of companies with antitrust, breaking them down when they become too big, not allowing them to acquire others under certain conditions and forcing them to treat their workers and customers well. This is the opposite of "free markets", and is the only way if you want a stable society.
Eventually, on the free market there are winners, and these winners form a monopoly. See Nestle, Tyson foods, Apple. The big corps, having cornered the market, then squeeze the hapless users (and the ecosystem, in Apple's case) into exorbitant prices, because there is no competition. You started with your beloved "free market", ended up with a monstrous monopoly. Surprise, this is how any "free market" story ends.
If you want to avoid the trash situations that we are in today, you need to regulate the shit out of companies with antitrust, breaking them down when they become too big, not allowing them to acquire others under certain conditions and forcing them to treat their workers and customers well. This is the opposite of "free markets", and is the only way if you want a stable society.
Yes, which is also what Milton Friedman said. I am not sure anyone notable in capitalistic thought actually professed full unbridled capitalism.
> Old school open source projects don't seem particularly profitable.
And is also subject to survivorship bias. For every OSS project that makes it, tens of thousands do not.
And is also subject to survivorship bias. For every OSS project that makes it, tens of thousands do not.
> I thought he was on the payroll for FSF, but his reportable compensation has been zero from 2002 to 2022 according to:
He resigned in 2019 following allegations of inappropriate behavior towards women (https://news.ycombinator.com/item?id=20990583).
He resigned in 2019 following allegations of inappropriate behavior towards women (https://news.ycombinator.com/item?id=20990583).
FSF requires signing of a CLA. A CLA would let them change the license to whatever they want, just like these companies. Some people were not happy with GPL3 yet that didn't stop the FSF from changing the licenses on their software.
They explain that without it, they can't effectively enforce the copyrights on their projects: https://www.gnu.org/licenses/why-assign.html.en
I highly doubt that the FSF, who developed the GPL licenses and values free software above anything else, would change the licensing of their projects like "these companies" do.
I highly doubt that the FSF, who developed the GPL licenses and values free software above anything else, would change the licensing of their projects like "these companies" do.
[deleted]
The FSF does not require a CLA.
If they don't that is something new. Do you know when that started (or rather, stopped)?
This stopped a long time ago. Many older GNU projects still have them, but newer ones are not required to have them. Some have even made their usage optional.
An example of a project making it optional is GCC itself: https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
An example of a project making it optional is GCC itself: https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html
That's great news! I've always been a big supporter of the FSF and that they stopped this toxic practice it awesome!
MongoDB switched from AGPL to their own license when they couldn't compete with others offering their software as SaaS, so I don't think the GPL is any kind of protection from this. It's just that the GPL is less popular than alternatives for this type of business model.
That's a very good counter example. Although, I'd imagine, the latest AGPL version will be useful for a long time and any further progress in the code base would also be under AGPL, which would not be under risk of becoming an open core project.
Which is exactly why we are back into Public Domain/Shareware kind of models, and GPL is an endangered license model, only some old school projects keep it around.
It will be even worse after the GPL developer generation is gone.
It will be even worse after the GPL developer generation is gone.
What is the GPL-licensed product that is comparable in functionality and scalability to CockroachDB? If there is one, you're free to use it.
Yep! I actually far prefer closed source software, made by non-VC funded companies, where there business is to create good software that actually adds value for the license I'm paying for. Something like Sublime Text or JetBrains.
Sure <VC funded editor company> can have people spend years of their life working on something, but release it as open source because VCs are paying for it, and that leads to more mindshare, but it leaves a bad taste in my mouth. Similar reasons to not use VSCode (commoditizing the complement by using billions of dollars from other products).
The "must be open source (I think they actually mean free as in $$) at all costs" crowd baffles me because the money to support the humans creating the software in the real world doesn't just magically appear.
Sure <VC funded editor company> can have people spend years of their life working on something, but release it as open source because VCs are paying for it, and that leads to more mindshare, but it leaves a bad taste in my mouth. Similar reasons to not use VSCode (commoditizing the complement by using billions of dollars from other products).
The "must be open source (I think they actually mean free as in $$) at all costs" crowd baffles me because the money to support the humans creating the software in the real world doesn't just magically appear.
I'm imagining that those closed source softwares wouldn't be possible without open source libraries and tools...
Correct. This is what makes me feel guilty about releasing a closed-source product, or even one with a non-OSI license. It’s irrational, but I feel like I’ve benefited so massively from FOSS that I owe it to the community to contribute back.
EDIT: as another commenter wrote below, OSI is driven by massive cloud vendors, who have a vested interest in having their freedoms to take projects and monetize them. Perhaps a somewhat restrictive license isn’t a bad thing.
EDIT: as another commenter wrote below, OSI is driven by massive cloud vendors, who have a vested interest in having their freedoms to take projects and monetize them. Perhaps a somewhat restrictive license isn’t a bad thing.
Open source as a byproduct of a company absolutely works - it's been proven by tons of tech companies.
But if you open source your revenue-generating parts, and only charge for support/managed version/enterprisey features you'll end up with quite weird incentives, particularly with infrastructure tools, in which the big cloud providers will happily compete with you, using the version you open sourced and providing and ecosystem to their customers that one simply cannot compete with
But if you open source your revenue-generating parts, and only charge for support/managed version/enterprisey features you'll end up with quite weird incentives, particularly with infrastructure tools, in which the big cloud providers will happily compete with you, using the version you open sourced and providing and ecosystem to their customers that one simply cannot compete with
In the sense that most modern programming languages and compilers are open-source, sure, nothing outside the embedded world can truly be built without relying on open source.
There are still native shops that rely on very little open source, though at this point probably only in niches like gamedev or defence.
There are still native shops that rely on very little open source, though at this point probably only in niches like gamedev or defence.
This is not true even in those spaces anymore. Games these days require libraries like SDL, or (increasingly) use engines like Godot.
Defense is a weird place, but open source is used quite a lot there, it's often required to do so and to record the open source consumed to produce a product. And often times, it must be commercial open source where you can get engineering support for the lifetime of the product's existence.
Defense is a weird place, but open source is used quite a lot there, it's often required to do so and to record the open source consumed to produce a product. And often times, it must be commercial open source where you can get engineering support for the lifetime of the product's existence.
Not at all, when talking about game consoles.
They were possible for quite some time, I guess people born after Linus created Linux have no idea how we used to pay for everything, or pirate.
I would imagine there is a lot on Windows possibly macOS.
Many c/C++ libraries are not open source - even more .Net ones
Many c/C++ libraries are not open source - even more .Net ones
Like other folks have said, anytime you see a CLA, you see the true intentions of the project. A project that will always be FOSS won't have a need for a CLA.
The ASF requires a CLA for all regular contributors or large contributions, so I don’t think this is a particularly good barometer.
That's a good point. The ASF's FAQ [1] states that "All software developed by all projects of The Apache Software Foundation is freely available without charge" and that it "is specified in the Foundation's Articles of Incorporation [2]", however I see no such specification in the linked incorporation. Is there some actual legal guarantee there?
[1]: https://www.apache.org/foundation/license-faq.html#IsItFree
[2]: https://www.apache.org/foundation/records/incorporator.html
[1]: https://www.apache.org/foundation/license-faq.html#IsItFree
[2]: https://www.apache.org/foundation/records/incorporator.html
I think it's mentioned in this document: https://www.apache.org/foundation/records/certificate.html
Thanks!
It seems a little short of the claim in their FAQ though, but it's something:
> The purpose of the Corporation is to engage in any lawful act or activity [...] including the creation and maintenance of "open source" software distributed by the Corporation to the public at no charge
It seems a little short of the claim in their FAQ though, but it's something:
> The purpose of the Corporation is to engage in any lawful act or activity [...] including the creation and maintenance of "open source" software distributed by the Corporation to the public at no charge
I don't think that falls short.
The reason for the "any lawful act" language is to allow the ASF to do things like run a conference, accept donations, sell t-shirts and other activities. If the statement was only "develop open-source software" there are all kinds of important activities that support open source development that would be impossible.
The fact is, however, that certificates can be changed by the people who can vote. IN the case of the ASF, the members are the ones who vote. Getting those ~800 members to radically trash the traditional goal of the foundation is not going to be possible as long as the current membership is active.
The reason for the "any lawful act" language is to allow the ASF to do things like run a conference, accept donations, sell t-shirts and other activities. If the statement was only "develop open-source software" there are all kinds of important activities that support open source development that would be impossible.
The fact is, however, that certificates can be changed by the people who can vote. IN the case of the ASF, the members are the ones who vote. Getting those ~800 members to radically trash the traditional goal of the foundation is not going to be possible as long as the current membership is active.
What I mean is that, if they made some software non-free alongside some free ones (to make money to finance the free ones, for example), that still seems valid as to the current certificate of incorporation.
Their FAQ says "all software free no exception" and this document says something weaker.
Their FAQ says "all software free no exception" and this document says something weaker.
immibis(1)
The difference with the ASF/FSF is that they are non-profits with a mission statement (and, if we don't trust that enough--due to OpenAI, as I don't entirely understand what happened there--with clearly-mission-aligned board leadership) that prevent them from pulling the rug out from under their license. (...and, right as I pushed this comment, I see that someone else looked into it, and maybe the ASF fails to have such a clause anywhere ;P but hopefully it is there and just a bit hidden.)
Sure, but that contradicts the statement made in the comment they are replying to:
> anytime you see a CLA, you see the true intentions of the project. A project that will always be FOSS won't have a need for a CLA.
If there are conditions to the statement, it isn't "anytime you see a CLA".
> anytime you see a CLA, you see the true intentions of the project. A project that will always be FOSS won't have a need for a CLA.
If there are conditions to the statement, it isn't "anytime you see a CLA".
Sure, but now we would need to find another epicycle for why giving a for-profit corporation this dangerous power over its licensees is safe/benign. There is, at times, some logic to "the exception that proves the rule".
It depends on the CLA. In some countries, you cannot not have a CLA because there's always an implied contract.
Many CLAs are just a hassle (basically, DCO that has to be reviewed by the legal department). But a lot are asymmetrical in a substantial way and the original developer gets to play by different rules than the rest. CLAs in the second category tend to be problematic.
Even that is not a completely clear indicator because in some cases, the asymmetry is only intended to help with potential future relicensing in alignment with the project's goals, and not to enable commercialization (either today or at some point in the future). Some organizations have resisted direct commercialization of the code they have been entrusted with for decades, so that can happen even with an asymmetrical CLA.
Many CLAs are just a hassle (basically, DCO that has to be reviewed by the legal department). But a lot are asymmetrical in a substantial way and the original developer gets to play by different rules than the rest. CLAs in the second category tend to be problematic.
Even that is not a completely clear indicator because in some cases, the asymmetry is only intended to help with potential future relicensing in alignment with the project's goals, and not to enable commercialization (either today or at some point in the future). Some organizations have resisted direct commercialization of the code they have been entrusted with for decades, so that can happen even with an asymmetrical CLA.
This is not necessarily true. Sometimes it's needed to pivot to a better/different open source license without going through the pain of contacting every contributor ever. I have seen that pain in some projects that want to go from LGPL to MIT or something.
For many contributors, they're ok giving full ownership of their contributions to a project owner on the owner's terms. Some contributors may not be ok with that of course, but it doesn't mean that every project owner has nefarious plans with said code ownership.
For many contributors, they're ok giving full ownership of their contributions to a project owner on the owner's terms. Some contributors may not be ok with that of course, but it doesn't mean that every project owner has nefarious plans with said code ownership.
> better/different open source license
And that's why "open source" is a really bad term that no one should use unironically, unless they want to confuse the hell out of people.
There are protective (copyleft) licenses, and there are permissive licenses - and they're very different beasts. And it's, like, software licensing 101.
> that want to go from LGPL to MIT or something
I find this extremely weird.
In a sane world, picking a copyleft license must mean that you care about user freedoms and want to make sure they're respected no matter what happens. Because that's the whole point of picking a copyleft license - not about letting people peek or tweak some code, not about social brownie points, and most certainly not about marketing campaigns - but about granting users their freedoms.
Either people get confused about "open source" and pick... I don't know, whatever looks cool, without even understanding what they're doing; or they're giving up on their principles when they smell the money.
I can understand wanting to go from, say, GPL to AGPL, or GPLv2 to GPLv3[+] - it would make sense, as it all goes in line of protecting freedoms. But LGPL to MIT is truly a weird one.
And that's why "open source" is a really bad term that no one should use unironically, unless they want to confuse the hell out of people.
There are protective (copyleft) licenses, and there are permissive licenses - and they're very different beasts. And it's, like, software licensing 101.
> that want to go from LGPL to MIT or something
I find this extremely weird.
In a sane world, picking a copyleft license must mean that you care about user freedoms and want to make sure they're respected no matter what happens. Because that's the whole point of picking a copyleft license - not about letting people peek or tweak some code, not about social brownie points, and most certainly not about marketing campaigns - but about granting users their freedoms.
Either people get confused about "open source" and pick... I don't know, whatever looks cool, without even understanding what they're doing; or they're giving up on their principles when they smell the money.
I can understand wanting to go from, say, GPL to AGPL, or GPLv2 to GPLv3[+] - it would make sense, as it all goes in line of protecting freedoms. But LGPL to MIT is truly a weird one.
(L)GPL to MIT is a choice many projects made when they decided they cared more about their code being used than about it staying free.
Copyleft licenses were the default choice at some point in time, but then in the '10s most big projects seemed to pick a permissive license, and many switched.
Copyleft licenses were the default choice at some point in time, but then in the '10s most big projects seemed to pick a permissive license, and many switched.
Yea, and the point is that they really should not have picked LGPL in the first place. If you pick a copyleft license, please don't do it because it's cool - do it if and because you care for what it stands for.
However, I thought about it and I think I can get the cases where monetary opportunities started to outweigh what's essentially are political ideals. Happens all the time, heh. I guess I can imagine person not being honest with themselves until the temptation really comes. Especially if it's about casual developers trying to have some money to live comfortably (as opposed to lowering their standards of living), rather than getting rich.
I can only hope it's that and not a simple ignorance.
However, I thought about it and I think I can get the cases where monetary opportunities started to outweigh what's essentially are political ideals. Happens all the time, heh. I guess I can imagine person not being honest with themselves until the temptation really comes. Especially if it's about casual developers trying to have some money to live comfortably (as opposed to lowering their standards of living), rather than getting rich.
I can only hope it's that and not a simple ignorance.
> picking a copyleft license must mean that you care about user freedoms [...] they're giving up on their principles
This is a personal bias and disregards others' definition of true do-whatever-you-want freedom. Different project owners may think differently on what free means and alter the license to respect their principles (and may consider copyleft to be the restrictive/anti-free mistake made early on based on these same kinds of personal biases).
And many contributors don't really care what the project owner does with their code and the CLA lets them delegate responsibility.
This is a personal bias and disregards others' definition of true do-whatever-you-want freedom. Different project owners may think differently on what free means and alter the license to respect their principles (and may consider copyleft to be the restrictive/anti-free mistake made early on based on these same kinds of personal biases).
And many contributors don't really care what the project owner does with their code and the CLA lets them delegate responsibility.
It's been popular in the last decade and a half to think that freedom is when everyone, including massive corporations, can do anything they want with your software, including closing it and taking away everyone else's freedom. Don't people think it would be better if they couldn't do that?
People who value attention over principles are known as "pick mes" apparently.
People who value attention over principles are known as "pick mes" apparently.
> including closing it and taking away everyone else's freedom.
unless the corp owns the rights, they cannot "close it", nor take away everyone else's freedom. The old version that was open source licensed is always going to be available.
Unless you're talking about the additions these corporations made, which they keep closed, and charge you for it. But if they are able to charge for it, they deserve it.
unless the corp owns the rights, they cannot "close it", nor take away everyone else's freedom. The old version that was open source licensed is always going to be available.
Unless you're talking about the additions these corporations made, which they keep closed, and charge you for it. But if they are able to charge for it, they deserve it.
> But if they are able to charge for it, they deserve it.
This is an extremely black-and-white view. If I make a competing product to you and it’s superior to yours, then yes, I deserve profits (though of course consumers may still choose yours for a litany of other reasons). If a trillion-dollar corporation becomes a competitor, that’s not exactly fair. They can, if they want, spin up an entire team dedicated to the product, and by sheer numbers, they will win. Is it legal? Yes. Is it ethical? That’s subjective.
This is an extremely black-and-white view. If I make a competing product to you and it’s superior to yours, then yes, I deserve profits (though of course consumers may still choose yours for a litany of other reasons). If a trillion-dollar corporation becomes a competitor, that’s not exactly fair. They can, if they want, spin up an entire team dedicated to the product, and by sheer numbers, they will win. Is it legal? Yes. Is it ethical? That’s subjective.
Embrace, extend, extinguish - AGPL makes it harder and SSPL even harder still.
That example is exactly why many people will not want to sign a CLA.
Someone who is has a strong preference for copyleft licences may not want to contribute to a project with a permissive license.
The intent may not be for the project owners to use the code in proprietary software, but it would be to allow someone to do so.
Someone who is has a strong preference for copyleft licences may not want to contribute to a project with a permissive license.
The intent may not be for the project owners to use the code in proprietary software, but it would be to allow someone to do so.
Sure, and I think the CLA is a good signal to those that care about how their contribution is used to stay away. But for everyone else that's not concerned with that, the CLA is not inherently evil.
I wonder... if you do something with AGPL that requires releasing the changes back ... you don't need to sign a CLA to do that.
However that would also mean that the core project couldn't accept your changes without the CLA since that would also bind them to never switching the license or relicensing your contributions for an enterprise license.
... I think. My head hurts when trying to consider the implications for CLAs and AGPL and the endless debates that lawyers could have over this.
However that would also mean that the core project couldn't accept your changes without the CLA since that would also bind them to never switching the license or relicensing your contributions for an enterprise license.
... I think. My head hurts when trying to consider the implications for CLAs and AGPL and the endless debates that lawyers could have over this.
That's the core project's own fault and problem, not yours.
For those of us not in-the-know about licensing acronyms.
CLA = Contributor License Agreement
CLA = Contributor License Agreement
Imagine a world where GPLv2 was found to be unenforceable in a major jurisdiction such as the US. It has been a serious worry in the past. A CLA lets a project survive that situation. But I don't know if it is possible to have a CLA that also cannot be used to fork a project into a commercial license. So the trick would seem to be a CLA that assigns copyright to some sort of non-profit that is legally bound to be unable to take that path.
This is not true. Many companies want a CLA because their lawyers are worried about unclear patent law. They don't want someone to contribute some code, and then later claim the contributed code violates their patents.
Good examples are React from Facebook, and TypeScript from Microsoft. Both require a CLA. But these projects are never going to go closed-source. They are complements to the companies' core business strategies.
Good examples are React from Facebook, and TypeScript from Microsoft. Both require a CLA. But these projects are never going to go closed-source. They are complements to the companies' core business strategies.
Even if a project/company doesn't have a CLA, I don't think that is any sort of guarantee that their license won't change in the future.
I think that's a bit reductive. It's possible to have a CLA because you want to sell a non-GPL version of your app to some corporation that's worried about the legalities of the license. This is an additional revenue stream that open-source projects make use of, and it's not fair to say "any project with a CLA is selling out."
There's this balance between being a project forever run out of someone's garage and actually growing into a larger and more used system. I'd say the line is dilineated by many factors: who is the project's primary user? Enterprise? Devs? How much money is changing hands? What's the business model? Is there investment involved? How restrictive is the primary license? How restrictive is the CLA?
I think any open-source project that has aspirations to actually make money for the creators is shooting themselves in the foot without a CLA. And it's fine to judge them for this, but we live in a system where people have to extract value out of this shit even if it's against their ethos.
If people truly and ultimately believe in open-source, then the most logical conclusion is that capitalism does not allow for open source and that must be changed. Fighting things at the license level can only delay the inevitable. But people want to have their cake and eat it too: "I want the system to stay the same AND I want open-source creators to keep pumping out stuff for free forever."
There's this balance between being a project forever run out of someone's garage and actually growing into a larger and more used system. I'd say the line is dilineated by many factors: who is the project's primary user? Enterprise? Devs? How much money is changing hands? What's the business model? Is there investment involved? How restrictive is the primary license? How restrictive is the CLA?
I think any open-source project that has aspirations to actually make money for the creators is shooting themselves in the foot without a CLA. And it's fine to judge them for this, but we live in a system where people have to extract value out of this shit even if it's against their ethos.
If people truly and ultimately believe in open-source, then the most logical conclusion is that capitalism does not allow for open source and that must be changed. Fighting things at the license level can only delay the inevitable. But people want to have their cake and eat it too: "I want the system to stay the same AND I want open-source creators to keep pumping out stuff for free forever."
Opensource is opensource: CockroachDB Core up until Nov 24, 2024 is, and not afterward. Anyone who wants to fork it can do so. Mind you this will be a hard fork as there's no way to keep in sync with their enterprise product.
What you say is true in that you shouldn't view a VC backed opensource offering as 'permanently' opensource by the same group.
What you say is true in that you shouldn't view a VC backed opensource offering as 'permanently' opensource by the same group.
CockroachDB Core has not been offered under an OSI (i.e. Open Source) license since 2019 - everything subsequently has either been under Business Source License or the Cockroach Community License.
I searched github and thought this[0] was it.
> Source code in this repository is variously licensed under the Business Source License 1.1 (BSL), the CockroachDB Community License (CCL), the MIT license, BSD-style licenses, and other licenses specified in the source code. Source code in a given file is licensed under the BSL and the copyright belongs to The Cockroach Authors unless otherwise noted at the beginning of the file.
Is the caveat in this part (that I didn't catch before)? "Source code in a given file is licensed under the BSL and ..." That is sucky.
[0] https://github.com/cockroachdb/cockroach?tab=License-1-ov-fi...
> Source code in this repository is variously licensed under the Business Source License 1.1 (BSL), the CockroachDB Community License (CCL), the MIT license, BSD-style licenses, and other licenses specified in the source code. Source code in a given file is licensed under the BSL and the copyright belongs to The Cockroach Authors unless otherwise noted at the beginning of the file.
Is the caveat in this part (that I didn't catch before)? "Source code in a given file is licensed under the BSL and ..." That is sucky.
[0] https://github.com/cockroachdb/cockroach?tab=License-1-ov-fi...
Kind of... Certain extensions such as basic backups are closed source and have never been in the OSS version.
Many things would have to be re-added from scratch in a fork.
Many things would have to be re-added from scratch in a fork.
"Basic" (i.e. full) backups have been included in the OSS version since its November 2020 release (20.2): https://www.cockroachlabs.com/blog/backup-restore/
They are still pretty limited compared to what's in the enterprise version, but it's not right to say basic backups are closed source and have never been there.
They are still pretty limited compared to what's in the enterprise version, but it's not right to say basic backups are closed source and have never been there.
CockroachDB Core uses 3 licenses: CCL, BSL, Apache
CCL, BSL = "source available"
Apache = open source
Parts of CockroachDB under CCL that do NOT transition to Apache OSS: https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl
CCL, BSL = "source available"
Apache = open source
Parts of CockroachDB under CCL that do NOT transition to Apache OSS: https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl
> the sub-tree under pkg/ccl is under a different license (CCL) that does not transition to APL2 after a set duration.
I'm having trouble parsing/making sense of this. Was basic backup in Core? If you were running anything more than Core you weren't running an OSS version and had already crossed that line before this announcement. If you were running an OSS version there's nothing to add, just fork, no?
Core only has the "full backup". Incremental and other types are available to enterprise. I run the Core edition (with full backups) for my personal projects.
CockroachDB Core uses 3 licenses: CCL, BSL, Apache
CCL, BSL = "source available"
Apache = open source
Parts of CockroachDB under CCL that do NOT transition to Apache OSS: https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl
CCL, BSL = "source available"
Apache = open source
Parts of CockroachDB under CCL that do NOT transition to Apache OSS: https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl
> the sub-tree under pkg/ccl is under a different license (CCL) that does not transition to APL2 after a set duration.
What happens the day where the only way to fork it realistically is to pay people. And I mean good people to even keep up? And what if on top of that the bests in the game are already in the corporations that you want to fork from?
This is one reason to avoid any company run software that requires a CLA to contribute. No CLA makes it a lot harder to do this, at least if they have very much in the way of community contributions. Distributed ownership would keep them honest.
start open/source available has become a trend among yc-backed startups lately. one wonders how long before a “well, actually, we need a business-y license.”
Lately? This was cool like 12 years ago. Then you turn commercial once you get enough users. It’s the open source chameleon model.
Maybe we will have to replace "open source" with "spec driven". As you point out, open source can be just as bad as closed source, given future changes in direction by the project team. But "spec driven" means that anybody can come along and compete, and you can switch to them, regardless of how the original developers feel about it.
Is it not more about who does the development?
If cone entity does the development, they can change direction or licensing and it is hard for anyone to fork.
If you have more of a bazaar form of development with many contributors neither is as easy (even less so if you do not have a CLA). Even if you have a small core team of developers, a really bad direction is likely to lead to a split.
If cone entity does the development, they can change direction or licensing and it is hard for anyone to fork.
If you have more of a bazaar form of development with many contributors neither is as easy (even less so if you do not have a CLA). Even if you have a small core team of developers, a really bad direction is likely to lead to a split.
I think you are right to think of it in terms of who is doing development. The plus of a non open-source license is well-funded development. The downside is fewer outside contributions. In this specific instance, I think Cockroach was BSL? So, it can be forked into a community project where new contributions are open-source. Another corporation just wouldn't be able to profiteer off the fork directly until the changeover date.
EEE all over again.
This is one of the reasons people should hold the line for open source licensing for any infrastructure software: Any licensing scheme that forces a relationship with a single entity / doesn't allow for forking is open to abuse of users and customers at some point.
Very much this sentiment. While these sort of licenses and business relationships might make sense for high-margin industries that have specific needs, as somebody who has been doing consultancy for the last x years, I tend to advise most companies against the use of software with vendor or data lock-in, and I'm always sad and weary when this happens to interesting long-term projects where such business decisions get made which erode the trust in a healthy future [for smaller companies and more general purposes].
I'm not criticising a company's business decisions here, it might make sense for CockroachDB's business and profit goals; but such decisions also impact the decisions of dependent users, and I've been too long in this to recommend products and services with increasingly restrictive licensing or technical features that create unhealthy dependencies.
Since the AWSification of software licenses, I'm seeing more and more projects where a company is trying to get out of product/service X or license Y because they're unhappy or pivoting and the license or tech just doesn't fit the purpose any more, at high cost, occasionally even taking down the company.
I guess it's not trivial to balance abusive practices from big players that don't contribute much back with necessary freedom for smaller customers to experiment and freely move between technical solutions.
I'm not criticising a company's business decisions here, it might make sense for CockroachDB's business and profit goals; but such decisions also impact the decisions of dependent users, and I've been too long in this to recommend products and services with increasingly restrictive licensing or technical features that create unhealthy dependencies.
Since the AWSification of software licenses, I'm seeing more and more projects where a company is trying to get out of product/service X or license Y because they're unhappy or pivoting and the license or tech just doesn't fit the purpose any more, at high cost, occasionally even taking down the company.
I guess it's not trivial to balance abusive practices from big players that don't contribute much back with necessary freedom for smaller customers to experiment and freely move between technical solutions.
> It took at least 17y for Amazon to get rid of its last Oracle database:
this is from CockroachDB license, pretty much straight out of Oracle's playbook:
> You will not perform Benchmarks against any products or services provided under terms that restrict performing and disclosing the results of benchmarks of such products or services, unless You have the lawful right to waive such terms. If You perform or disclose, or direct or permit any third party to perform or disclose, any Benchmark, You will include in any disclosure and will disclose to Licensor all information necessary to replicate such Benchmark, and You agree that Licensor may perform and disclose the results of benchmarks of Your products or services, irrespective of any restrictions on benchmarks in the terms governing Your products or services.
this is from CockroachDB license, pretty much straight out of Oracle's playbook:
> You will not perform Benchmarks against any products or services provided under terms that restrict performing and disclosing the results of benchmarks of such products or services, unless You have the lawful right to waive such terms. If You perform or disclose, or direct or permit any third party to perform or disclose, any Benchmark, You will include in any disclosure and will disclose to Licensor all information necessary to replicate such Benchmark, and You agree that Licensor may perform and disclose the results of benchmarks of Your products or services, irrespective of any restrictions on benchmarks in the terms governing Your products or services.
That seems... fine? The terms basically imply that if you publish a benchmark you need to let CRDB reproduce your benchmark and discuss it publicly
Slightly off-topic but:
> a future Oracle/landlord
I don't think I've ever heard Oracle's business model described so accurately.
> a future Oracle/landlord
I don't think I've ever heard Oracle's business model described so accurately.
it's the classic vendor lock-in, it's the feudal serfdom model.
https://www.reddit.com/r/AskHistorians/comments/weva2v/did_p...
we can see that as long as there were "expoitable resources" competition led to "good times".
as long as "software lordships" are competing for users, users tend to enjoy "lots of rights".
https://www.reddit.com/r/AskHistorians/comments/weva2v/did_p...
we can see that as long as there were "expoitable resources" competition led to "good times".
as long as "software lordships" are competing for users, users tend to enjoy "lots of rights".
Well named! It is like a roach motel - once in, you can never leave.
You have nailed their issues - packaging and their revenue model. If you align this well with your target audience the license would have not been a problem for them. Wrote about this a bit here: https://cra.mr/open-source-is-not-a-business-model/
> They may be nice folks today, but who knows who will run the place in 5y when the next round of squeeze comes?
The same idea applies to political questions. A politician I like is proposing a policy I approve of. Great! Now what happens in the next election cycle, when a politician I don't like gets to use that same power to do something I don't approve of? Woops.
The same idea applies to political questions. A politician I like is proposing a policy I approve of. Great! Now what happens in the next election cycle, when a politician I don't like gets to use that same power to do something I don't approve of? Woops.
We can vote for different politicians after a few years. The politicians can vote to remove laws that were problems. There’s a straight-forward solution to that.
Building critical features on a single, closed-standard database means you can’t leave unless you rewrite all code that relied on it. The new code must integrate in the system well. The change must also happen without taking down the business.
For these reasons, politicians and laws change regularly but companies rarely escape database lockin.
Building critical features on a single, closed-standard database means you can’t leave unless you rewrite all code that relied on it. The new code must integrate in the system well. The change must also happen without taking down the business.
For these reasons, politicians and laws change regularly but companies rarely escape database lockin.
> the problem with the Enterprise edition is that it's quite expensive
Seems to me that it's still free for development, and small business use. If you're over $10M in revenue, with a business or product built on CockroachDB, they want a share of what they made possible. That seems totally reasonable to me.
Seems to me that it's still free for development, and small business use. If you're over $10M in revenue, with a business or product built on CockroachDB, they want a share of what they made possible. That seems totally reasonable to me.
You'd be a fool to put all your eggs in this basket:
> Annual term. Can be renewed subject to meeting the then-current eligibility requirements
> Annual term. Can be renewed subject to meeting the then-current eligibility requirements
OK, use a different database then if you don't like the terms.
Like the original commenter, everyone at my company really likes all the folks at Cockroach Labs. It's been a pleasure working with them.
We're currently in discussion with them to see if we can resolve this licensing change to our satisfaction. If not, we'll do the obvious (use a different database) as you said.
We're currently in discussion with them to see if we can resolve this licensing change to our satisfaction. If not, we'll do the obvious (use a different database) as you said.
[deleted]
There is no abuse here. They released software under a specific license (BSL at that, plenty of opportunities to restrict).
It can be construed as "abuse" if another commercial entity is deriving value from the core license while Cockroach Labs doesn't get to enjoy a "fair" share of this created value, while pouring its own resources into a product that enables this value creation.
I think CR Labs needs to make money from their activities. However they do it, should be in a way that incentivizes a win-win for them and their customers. Right now I think they attempted to "correct" for the uncaptured value, but the game theory switched toward discouraging adoption (in my perspective). I may be wrong, probably am.
I think CR Labs needs to make money from their activities. However they do it, should be in a way that incentivizes a win-win for them and their customers. Right now I think they attempted to "correct" for the uncaptured value, but the game theory switched toward discouraging adoption (in my perspective). I may be wrong, probably am.
> perceived abuse of the Core edition
They don't say that this was the reason for the change. What makes you presume it was "perceived" if they had said it was a reason for the change? I think it's the opposite: Too few used the open core edition, as it is quite limited. They want to increase the overall usage. They want to get growing companies using it. I think it's a fair move: Use it for free as long as you grow. You benefit. When you're large, pay us back. We benefit.
> 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
That's about the strongest negative allegation one could come up with. Unobjective content and wording. There're thousands of software vendors or service providers out there (DB and not) that are competitive (they all are) but fair. Every of our much liked startups like Supabase, Neon, Vercel makes the entry very cheap or free and compensates for that with larger fees from the larger customers. There's nothing shady about it.
As I said, your post has to much negative bias in content and esp. wording. I don't see that. Factually, there's not risk at all. Every company (see Redis) can change their license of their future work. So you never have any guarantees. With or without a core edition.
If you want "true" open source, you can't choose a software developed by a company. The goal of a company is to make money. That should not be surprising.
They don't say that this was the reason for the change. What makes you presume it was "perceived" if they had said it was a reason for the change? I think it's the opposite: Too few used the open core edition, as it is quite limited. They want to increase the overall usage. They want to get growing companies using it. I think it's a fair move: Use it for free as long as you grow. You benefit. When you're large, pay us back. We benefit.
> 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
That's about the strongest negative allegation one could come up with. Unobjective content and wording. There're thousands of software vendors or service providers out there (DB and not) that are competitive (they all are) but fair. Every of our much liked startups like Supabase, Neon, Vercel makes the entry very cheap or free and compensates for that with larger fees from the larger customers. There's nothing shady about it.
As I said, your post has to much negative bias in content and esp. wording. I don't see that. Factually, there's not risk at all. Every company (see Redis) can change their license of their future work. So you never have any guarantees. With or without a core edition.
If you want "true" open source, you can't choose a software developed by a company. The goal of a company is to make money. That should not be surprising.
That's another company that feels like they don't want to be an OSS company after all. After Elastic, I pay more attention to contributor agreements. Basically I consider any project that requires transfer of copyright for OSS contributions as likely to change their license at some point. It's fine; I'm not against that sort of thing and I sometimes pay for software. But I like to know what I'm getting into before and I don't appreciate the bait and switch. It also guides decisions as to what I contribute to actively.
I do a simple sanity check with any OSS software before using it:
- Make sure there is no contributor agreement requirements. This is a gigantic red flag that the license can and probably will be changed at some point.
- Make sure the license is not overly restrictive (like AGPL). I appreciate people have good reasons for picking this license; but it comes with some serious restrictions in a commercial environment. And like it or not, a lot of companies have active policies against this. Either way, I avoid anything with this license.
- Make sure the project is actively maintained. You don't want to get stuck with unmaintained software. Replacing dependencies is a PITA.
- Make sure the project is not overly dependent on VC funding. Startups fail all the time at which point anything they worked on turns into abandon ware.
- Ideally, make sure the project has a healthy diverse group of committers. Healthy here means more than one company is involved. Most projects that fail one or more of the above tests usually aren't very healthy in this sense.
I do a simple sanity check with any OSS software before using it:
- Make sure there is no contributor agreement requirements. This is a gigantic red flag that the license can and probably will be changed at some point.
- Make sure the license is not overly restrictive (like AGPL). I appreciate people have good reasons for picking this license; but it comes with some serious restrictions in a commercial environment. And like it or not, a lot of companies have active policies against this. Either way, I avoid anything with this license.
- Make sure the project is actively maintained. You don't want to get stuck with unmaintained software. Replacing dependencies is a PITA.
- Make sure the project is not overly dependent on VC funding. Startups fail all the time at which point anything they worked on turns into abandon ware.
- Ideally, make sure the project has a healthy diverse group of committers. Healthy here means more than one company is involved. Most projects that fail one or more of the above tests usually aren't very healthy in this sense.
CockroachDB hasn't been an open source project in more than 5 years.
They took down the blog post (I'd be curious to know why), but here is the announcement: https://web.archive.org/web/20190604173131/https://www.cockr...
What started as a neat project with a vibrant and enthusiastic community is now just another dull beige enterprise vendor.
They took down the blog post (I'd be curious to know why), but here is the announcement: https://web.archive.org/web/20190604173131/https://www.cockr...
What started as a neat project with a vibrant and enthusiastic community is now just another dull beige enterprise vendor.
The BSL doesn't make it closed source, it prevents a competitor from running their own DBaaS business using Cockroach as the backend. This has happened to various open source projects, AWS started selling their technology and ate their lunch.
BSL is a totally fair compromise for commercial open source licensing imho.
If you see BSL as the first step to an announcement like today's, that's a fair criticism. Not sure how often that happens. But BSL doesn't disqualify software from being open source.
BSL is a totally fair compromise for commercial open source licensing imho.
If you see BSL as the first step to an announcement like today's, that's a fair criticism. Not sure how often that happens. But BSL doesn't disqualify software from being open source.
> The BSL doesn't make it closed source […]
Yes, that’s right!
> But BSL doesn't disqualify software from being open source.
No, that’s wrong: https://spdx.org/licenses/BUSL-1.1.html
> The Business Source License […] is not an Open Source license.
Yes, that’s right!
> But BSL doesn't disqualify software from being open source.
No, that’s wrong: https://spdx.org/licenses/BUSL-1.1.html
> The Business Source License […] is not an Open Source license.
Any license that prevents others from selling your code and eating your lunch is, by definition, not an open source license.
One good way of looking at the goals of open source licenses is to force companies to compete on offering services related to the code. Whether this is a sustainable idea is a different question, but this is one of the bedrock ideas about OSS (and FLOSS as well). The other is of course that the rights of those running the software are absolute and trump any rights that the original creators have, except where the users would try to prevent other users from gaining the same rights.
One good way of looking at the goals of open source licenses is to force companies to compete on offering services related to the code. Whether this is a sustainable idea is a different question, but this is one of the bedrock ideas about OSS (and FLOSS as well). The other is of course that the rights of those running the software are absolute and trump any rights that the original creators have, except where the users would try to prevent other users from gaining the same rights.
The BSL is not an OSI-approved license, so it’s certainly not “open source” by the commonly used definition.
I agree it’s a reasonable license. But it’s not an open source license.
I agree it’s a reasonable license. But it’s not an open source license.
The OSI is a consortium of cloud platform vendors (really - check for yourself). Of course they'll define open source in a way that excludes licenses that restrict them from turning your work into closed-source cloud platforms. The good news is that we're not beholden to their definition as they have no official status whatsoever. We don't have to believe them just because they put the words Open Source in their company name.
The BSL is clearly not open source since it requires approval from the licensor in certain applications, but the OSI also rejected the SSPL, which is just an extended AGPL that requires source code publication in even more cases, and is clearly open source because of that.
The BSL is clearly not open source since it requires approval from the licensor in certain applications, but the OSI also rejected the SSPL, which is just an extended AGPL that requires source code publication in even more cases, and is clearly open source because of that.
OSI, and the open source definition they produced, predate the very notion of public cloud by close to a decade. While you don’t have to accept the definition, you are out of step with the industry at large, who broadly use “open source” to refer to things which meet the OSI definition. There’s no need for a competing definition: it’s fine for software to not be open source.
As to the specifics of SSPL, I personally don’t see the rationale for accepting AGPL but not SSPL.
As to the specifics of SSPL, I personally don’t see the rationale for accepting AGPL but not SSPL.
At large? As you can see, there is room for a community with a different view on that. My personal definition of an "open source license" is that, as the name implies, I can access the code, preferably without much gatekeeping (e.g., creating a free account in a private GitLab instance). And, to be honest, I prefer the BSL with an Additional Use Grant over any other license, because this is the most reliable option to ensure that the project has a future and won’t be abandoned because no one wants to invest their time for free.
You are welcome to choose that, but in my opinion, it isn't open source. I think open source should means anyone can contribute or take, and contributions are shared, without undue discrimination. Nobody is forced to work on the project, but if they are then they have to give the results of their work back to the common pool they took from. You have just as much power to keep the project going as anyone else does, including the current "maintainer".
You cannot redefine words because they don't fit with your personal definition. Open source has meant in accordance with the OSI, for quite a while.
I hadn’t considered this angle, stupidly. Now I have to rethink a minor belief system.
> but the OSI also rejected the SSPL
So did Debian and Red Hat. Do you think AWS leads them both?
So did Debian and Red Hat. Do you think AWS leads them both?
It even says it is not an open source license right in the license
> The Business Source License (this document, or the “License”) is not an Open Source license. However, the Licensed Work will eventually be made available under an Open Source License, as stated in this License.
— The Business Source License
https://mariadb.com/bsl11/
— The Business Source License
https://mariadb.com/bsl11/
It sounds like they intended to open-source their code after 3 years. Did that actually happen? Are cockroachdb versions from 2021 open?
> That's another company that feels like they don't want to be an OSS company after all
TBH that's nothing new for Cockroach. Even back when they were open core, the core was so restricted it didn't include backup & restore.
I think that may have changed, but only when they changed the license of the core to BSL, that is making the core non open source for three years.
TBH that's nothing new for Cockroach. Even back when they were open core, the core was so restricted it didn't include backup & restore.
I think that may have changed, but only when they changed the license of the core to BSL, that is making the core non open source for three years.
Correction - backup and restore was there, just not incremental backups. Which, yes, on very large DBs = no backup.
AGPL + commercial license is a solution for keeping a project open while avoiding the situation where profit goes to cloud hosting.
Is there a better solution?
Is there a better solution?
This one is not a solution.
The first of these open source companies to switch to a closed source license because the big bad cloud was eating their lunch was MongoDB, which was already AGPL. The AGPL, by design, doesn't stop anyone from offering your code: it merely makes sure that they provide the source code and installation instructions to anyone who is using the service. Amazon is only to happy to provide this, and they always have for all of the services they offer (that require it). They even contribute to some of these projects.
Also, from the perspective of the free software movement at least, there is nothing to solve here. The whole point of the GPLs is that you don't get to have any special power over the code that you create: everyone who gets a copy has the exact same rights to it that you do, including the right to run your company under the ground if they can outcompete you.
The first of these open source companies to switch to a closed source license because the big bad cloud was eating their lunch was MongoDB, which was already AGPL. The AGPL, by design, doesn't stop anyone from offering your code: it merely makes sure that they provide the source code and installation instructions to anyone who is using the service. Amazon is only to happy to provide this, and they always have for all of the services they offer (that require it). They even contribute to some of these projects.
Also, from the perspective of the free software movement at least, there is nothing to solve here. The whole point of the GPLs is that you don't get to have any special power over the code that you create: everyone who gets a copy has the exact same rights to it that you do, including the right to run your company under the ground if they can outcompete you.
Unfortunately you can't do commercial licenses unless you take full ownership of each and every source contribution. So, it means there is zero guarantees the project stays open. AGPL without that is a non starter for commercial usage.
Some of the most popular database and database related projects & products have been or are AGPL. MongoDB became massively successful as AGPL from the start. Grafana has been AGPL for 3+ years.
The AGPL is absolutely viable in commercial contexts. There are a handful of companies that have hangups about it, but the industry overall has long since realized that it is almost identical to the GPL for most practical purposes.
The AGPL is absolutely viable in commercial contexts. There are a handful of companies that have hangups about it, but the industry overall has long since realized that it is almost identical to the GPL for most practical purposes.
Mi d that those companies do dual licensing. All companies which worry about AGPL got to buy the commercial license to be on the safe side. While only the original vendor is able to do that, creating an imbalance between what they can do and an external contributor can do. (While external contributions are of limited interest for vendors who want to control a roadmap etc. and treat open source as marketing vehicle anyways)
LGPL is friendlier for commercial use. Keep the core LGPL, and the enterprise version proprietary.
tbf I think both GNU and Linux require copyright assignment, and I don't think that either of those are likely to swap licenses any time soon
Neither of those licenses require copyright ownership transfer. It's what makes Linux completely bullet proof against license changes. You'd have to track down every copyright holder (everyone that contributed, even if it's just a 1 line change) to get their permission for re-licensing their contribution. Which in the case of Linux is literally tens of thousands of individuals and companies, if not more.
Most GNU projects require a copyright assignment. For example, GNU coreutils: "note that non trivial changes require copyright assignment to the FSF as detailed in the “Copyright Assignment” section of the Coreutils HACKING notes." (from: https://www.gnu.org/software/coreutils/coreutils).
As far as I know, this is case for most GNU projects.
Linux only requires a confirmation that you wrote the patch; previous poster was mistaken about that, but they were correct about GNU.
As far as I know, this is case for most GNU projects.
Linux only requires a confirmation that you wrote the patch; previous poster was mistaken about that, but they were correct about GNU.
This is a trust point, though: assigning copyright to the free software foundation allows code to be relicensed under new versions of the gpl.
https://www.gnu.org/licenses/gpl-3.0.en.html - section 14
And so when you see things like https://directory.fsf.org/wiki/Coreutils
Note also the "if you used the GPL without a version number, you can relicense it under any version"
---
The "why they require a CLA" is for enforcement.
https://www.gnu.org/licenses/why-assign.en.html
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
And so when you see things like https://directory.fsf.org/wiki/Coreutils
Note also the "if you used the GPL without a version number, you can relicense it under any version"
---
The "why they require a CLA" is for enforcement.
https://www.gnu.org/licenses/why-assign.en.html
In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer.> The "why they require a CLA" is for enforcement.
None of that seems like a "why" to me; to cynically paraphrase it, "our policies require our polices." Why does your record-keeping require a CLA? Why is a CLA required to enforce the GPL?
None of that seems like a "why" to me; to cynically paraphrase it, "our policies require our polices." Why does your record-keeping require a CLA? Why is a CLA required to enforce the GPL?
A CLA is required to be able to sue someone infringing the GPL and represent yourself as the legal owner of the entirety of that code. If you have a hugely fractured ownership like Linux, it may be very expensive to bring a suit against an infringer.
That might be true for the GNU foundation. But they don't actually control/host the vast majority of software licensed under the many GPL variants. None of the GPL licenses actually cover any form of copyright transfers. Including the AGPL. That's done via separate contributor agreements typically. The GNU foundation doesn't control the licenses either. That's a job done by the free software foundation. Which doesn't host any projects as far as I know.
At this point the GNU foundation mostly just runs relatively small, older projects and that definitely does not include the linux kernel. That one has its own foundation called the Linux foundation. The Linux foundation runs many hundreds of projects and they operate mostly without contributor licenses as far as I know. And in so far they do those agreements are not about transferring ownership of the copyright but asserting ownership to ensure that the contributions people make are actually legal.
Big corporations moving code bases under their control seems to be a regular thing and that includes some pretty high profile projects recently. And of course there are many more projects on Github that use one of the GPL licenses. The vast majority of which don't have any contributor license.
So, I don't think I'm that wrong here at all that this is not that common. The previous poster seems to confuse the license with the GNU foundation which is a tiny subset of the overall GPL licensed software ecosystem.
At this point the GNU foundation mostly just runs relatively small, older projects and that definitely does not include the linux kernel. That one has its own foundation called the Linux foundation. The Linux foundation runs many hundreds of projects and they operate mostly without contributor licenses as far as I know. And in so far they do those agreements are not about transferring ownership of the copyright but asserting ownership to ensure that the contributions people make are actually legal.
Big corporations moving code bases under their control seems to be a regular thing and that includes some pretty high profile projects recently. And of course there are many more projects on Github that use one of the GPL licenses. The vast majority of which don't have any contributor license.
So, I don't think I'm that wrong here at all that this is not that common. The previous poster seems to confuse the license with the GNU foundation which is a tiny subset of the overall GPL licensed software ecosystem.
> But they don't actually control/host the vast majority of software licensed under the many GPL variants. None of the GPL licenses actually cover any form of copyright transfers.
No one claimed this is the case. The only person conflating "GNU" with "GPL" is you.
You said projects with copyright assignments should be distrusted. Someone pointed out that GNU projects require this, which you promptly denied, and I just wanted to correct the record on that. Nothing more, nothing less.
No one claimed this is the case. The only person conflating "GNU" with "GPL" is you.
You said projects with copyright assignments should be distrusted. Someone pointed out that GNU projects require this, which you promptly denied, and I just wanted to correct the record on that. Nothing more, nothing less.
There is a Gnu Foundation, but it has nothing to do with computing: http://www.gnufoundation.org/who-we-are
You mean the GNU Project.
You mean the GNU Project.
I don't think either of the comments you replied to has stated the opposite. They both spoke of GNU, not the overall GPL licensed software ecosystem.
No, the FSF specifically requires ownership transfer for GNU projects, so that they can do things like go after infringements in court, or relicense GNU projects to newer versions of the GPL unconditionally, e.g. when GPLv3 was released.
Ironically, CLAs like the one Google and Meta use for their projects on GitHub do not require ownership transfer -- only the rights to redistribute, because the prevailing Lawyer-brain belief is (roughly, to my understanding) that just assuming that right from the license itself isn't necessarily sound.
For licenses like Apache 2.0, assignment/ownership is a kind of irrelevant practical distinction because entities can just distribute proprietary versions anyway (and because it's not clear if you really agree to much more than e.g. Apache 2.0 implies), which is the prevailing worry people have. Most of the people here actually want GPL-style copyleft licenses along with some vague idea of a "communal project", even if they don't know it. Because that's the only way to achieve the practical desired outcome, where your code and contributions stay open and are difficult to "rework" in this way. The talk about CLAs and all the other stuff is irrelevant; it's a matter of the politics and composition of the project, not the exact legal words in the license.
> everyone that contributed, even if it's just a 1 line change
That depends on the jurisdiction. There is a concept called the "threshold of originality" in the US which states roughly that some obvious, trivial things just can't be copyrighted. Typofix patches that change "form" to "from" aren't meaningful enough to be given copyright, so you literally do not need to be consulted on the matter at all. It is not clear that simple bugfixes fit under this definition either for example, because they may be obvious. Realistically, I'd say there are very few contributions that are going to fit in 1 line while being original enough for copyright to apply. They could also just not include your patch too or rewrite it, in that case, so the "1 line" case is pretty much meaningless in practice.
Ironically, CLAs like the one Google and Meta use for their projects on GitHub do not require ownership transfer -- only the rights to redistribute, because the prevailing Lawyer-brain belief is (roughly, to my understanding) that just assuming that right from the license itself isn't necessarily sound.
For licenses like Apache 2.0, assignment/ownership is a kind of irrelevant practical distinction because entities can just distribute proprietary versions anyway (and because it's not clear if you really agree to much more than e.g. Apache 2.0 implies), which is the prevailing worry people have. Most of the people here actually want GPL-style copyleft licenses along with some vague idea of a "communal project", even if they don't know it. Because that's the only way to achieve the practical desired outcome, where your code and contributions stay open and are difficult to "rework" in this way. The talk about CLAs and all the other stuff is irrelevant; it's a matter of the politics and composition of the project, not the exact legal words in the license.
> everyone that contributed, even if it's just a 1 line change
That depends on the jurisdiction. There is a concept called the "threshold of originality" in the US which states roughly that some obvious, trivial things just can't be copyrighted. Typofix patches that change "form" to "from" aren't meaningful enough to be given copyright, so you literally do not need to be consulted on the matter at all. It is not clear that simple bugfixes fit under this definition either for example, because they may be obvious. Realistically, I'd say there are very few contributions that are going to fit in 1 line while being original enough for copyright to apply. They could also just not include your patch too or rewrite it, in that case, so the "1 line" case is pretty much meaningless in practice.
> No, the FSF specifically requires ownership transfer for GNU projects
No they do not. Individual GNU software projects might require it, but this choice is up to the project, not the FSF.
No they do not. Individual GNU software projects might require it, but this choice is up to the project, not the FSF.
FYI, you're right about GNU (by and large), but mistaken about Linux.
Whoops, you're right! I thought there was some kind of sign off in there. My mistake.
GNU has contributor agreements?
Absolutely! They want to have standing in court so they can defend infringers, and that's materially easier to establish with copyright assignment agreements.
https://www.gnu.org/licenses/why-assign.en.html
So while I agree with other commenters that a CLA is a clear indication that the entity seeking to have copyright assigned wants to reserve the right to take some kind of legal action at some point (like changing the license), it also applies in cases where the legal action is benevolent rather than malevolent (like defending the copyright).
https://www.gnu.org/licenses/why-assign.en.html
So while I agree with other commenters that a CLA is a clear indication that the entity seeking to have copyright assigned wants to reserve the right to take some kind of legal action at some point (like changing the license), it also applies in cases where the legal action is benevolent rather than malevolent (like defending the copyright).
> Does this mean that CockroachDB is no longer open source?
> CockroachDB will remain source available under a new license. While the new license is a proprietary enterprise license, the source code will still be available for viewing and contributions.
The word you're looking for is "yes".
> CockroachDB will remain source available under a new license. While the new license is a proprietary enterprise license, the source code will still be available for viewing and contributions.
The word you're looking for is "yes".
It was already not open source, hence the weasel language. "It will remain source available" is the second-most straightforward way to say "it already wasn't, but it's awkward to admit that given that we allowed you to misunderstand the license for five years".
Discussion from five years ago:
Relicensing CockroachDB June 4, 2019 (487 points, 282 comments) https://news.ycombinator.com/item?id=20097077
The blog post is a 404, here's the archive: https://web.archive.org/web/20190604173131/https://www.cockr...
Discussion from five years ago:
Relicensing CockroachDB June 4, 2019 (487 points, 282 comments) https://news.ycombinator.com/item?id=20097077
The blog post is a 404, here's the archive: https://web.archive.org/web/20190604173131/https://www.cockr...
Coming next decade: companies marketing their product as "open source" because they have an empty GitHub repo for issues.
Or a repository with some source code under a free license, and then some .so and executables in a subdirectory. I'm looking at you Sciter.
It's always obvious when they need multiple sentences to answer a simple yes or no question.
I'm just so shocked that VC is following the open source for a while then fuck you business playbook. If only there was prior art to warn people that this was a risk, like all the other VC backed software projects.
I said it somewhere else, but this FAQ is likely because most people think "source available on GitHub" = "open source", so they're just answering the low-hanging-fruit even if the question is technically incorrect. Not everybody is aware of the differences between "on GitHub" vs OSS, the OSI, the FSF, etc.
We will probably end up removing CockroachDB from our infra due to this change. It also makes me a bit worried about their long term viability. How much ARR does CockroachDB have and what was their last round valuation...?
CockroachDB is easier to manage and more cost effective than Postgress due to that. But now I suspect the balance tips back to Postgres
Citus would be great if the HA story was better: https://github.com/citusdata/citus/issues/7602
What issue do you have with the changes? Sounds like it's mostly focused on making it more affordable for small operations.
Not me, but two issues I could see: Revenue over $10 million, but not profitable, or the license cost would be to high. We had that issue with support contracts Elastic tried selling us, way back, compared to our revenue and profit, the license/support contract made zero sense.
Other issue: Telemetry is mandatory on the free tier and cost to avoid it is to high. Some industries cannot have telemetry enable, or at least not without a heavy amount of reviews, think finance or healthcare.
Other issue: Telemetry is mandatory on the free tier and cost to avoid it is to high. Some industries cannot have telemetry enable, or at least not without a heavy amount of reviews, think finance or healthcare.
What will you switch to? I feel like there isn’t a good alternative.
YugabyteDB is a commonly used alternative.
According to Wikipedia, Yugabyte (the company) has taken 290 million dollars of VC money. It's probably a safe assumption that they will follow the same path soon enough.
While the future is unwritten, FWIW in 2019 Yugabyte moved to Apache 2.0, open-sourcing features that were previously paywalled.
They wrote up their rationale here: https://www.yugabyte.com/blog/why-we-changed-yugabyte-db-lic...
They wrote up their rationale here: https://www.yugabyte.com/blog/why-we-changed-yugabyte-db-lic...
Also has a CLA: https://cla-assistant.io/yugabyte/yugabyte-db
Were you paying for it?
Probably a good move. I'd looked at Cockroach before for a project - they basically disqualified themselves from the start by nerfing the "core" version so bad it was useless, while Enterprise was some absolutely insane figure for a cash-strapped startup. While it was possible to hotfix the code to get around their restrictions - we eventually just used something else.
This at least gets the full-fledged product in the door at startups. Say what you want about the timing or the BSL but I think this makes sense business-wise.
This at least gets the full-fledged product in the door at startups. Say what you want about the timing or the BSL but I think this makes sense business-wise.
The enterprise per core is still an insane figure, based on last time I interacted with sales- would be amazing if this was revised, too, to be more competitive with Planetscale, etc.
Would be far easier to recommend CockroachDB if it were more competitive with Planetscale.
Would be far easier to recommend CockroachDB if it were more competitive with Planetscale.
The last time I priced out CockroachDB it was more than 10x what multi region SpannerDB would cost.
That is very interesting. As CRDB user, I priced Spanner (had to do some estimates during load testing), and Spanner came 3 times more expensive includign our eng salary to run CRDB
I'm long gone and never signed anything so have no problem mentioning that we were quoted USD$150/m per vCPU core with a 12-month commitment (from memory).
The project called for a minimum of 4 replicas and likely 8 vCPUs per, so right off the bat that's close to $60k/year before you even do anything. Plus the unwelcome addition of "license anxiety" to the whole development experience, and being forced to make a big decision up front.. it's not how I like to work or what a startup needs.
The project called for a minimum of 4 replicas and likely 8 vCPUs per, so right off the bat that's close to $60k/year before you even do anything. Plus the unwelcome addition of "license anxiety" to the whole development experience, and being forced to make a big decision up front.. it's not how I like to work or what a startup needs.
Oh the joys of "Contact Sales" pricing strategy, where made up rates are no more consistent than "whatever the sales rep thinks they can extract from the business".
From what I remember, the cost per server per year was about 5x to 6x (annually) the hardware cost of a new server, and these were dual 32 core EPYCs. 64 cores per box at per core licensing gets really expensive.
Re: CockroachDB vs Planetscale. It's all about the price per core of the CockroachDB license.
In my understanding, last time I talked to sales it's approximately 3x worse (because Planetscale offers 1 primary + 2 replicas) with CockroachDB you'd have to triple the CockroachDB license fees to even be competitive to achieve the same HA .... on hardware you purchase and run yourself.
In my understanding, last time I talked to sales it's approximately 3x worse (because Planetscale offers 1 primary + 2 replicas) with CockroachDB you'd have to triple the CockroachDB license fees to even be competitive to achieve the same HA .... on hardware you purchase and run yourself.
Last time I checked, the cockroach serverless pricing model and free tier were cheaper than planet scale for small projects. IIRC, the dedicated cloud product was also cheaper if you kept it utilized. What’s your evidence that planetscale is cheaper?
For example, planetscale charges 3x as much per gb of storage if I read the pricing correctly.
For example, planetscale charges 3x as much per gb of storage if I read the pricing correctly.
we charge per node and you get 3 nodes by default so it’s not 3x it’s just that you have more nodes.
Cockroach is also doing 3x replication of the data, so I don’t think that’s particularly relevant here. Cockroach serverless will dynamically scale up sql serving processes based on load. The storage and compute are separated in the cockroach architecture. My point is that if your query load is relatively low, cockroach serverless is definitely cheaper because the storage costs dominate. I think there’s ambiguity on which product is cheaper for a real-world application with meaningful load and data size.
I remain curious about the perception that cockroach is a meaningfully more expensive product. Where does that idea come from?
I remain curious about the perception that cockroach is a meaningfully more expensive product. Where does that idea come from?
It’s interesting to hear that CockroachDB is so much more expensive than Planetscale, since I thought planetscale was already prohibitively expensive.
through cash strapped startups can now use the "free" enterprise version until they reach 10M$ annual revenue
weather it's a good idea to commit to it if you might not want to afford it once your revenue went up is another matter
and 10M$ annually is not little but also no absurdly huge, I mean a ~80 person company probably will struggle to be profitable with that revenue (if it's 80 good paying jobs like software developer).
weather it's a good idea to commit to it if you might not want to afford it once your revenue went up is another matter
and 10M$ annually is not little but also no absurdly huge, I mean a ~80 person company probably will struggle to be profitable with that revenue (if it's 80 good paying jobs like software developer).
For a US startup I would divide annual revenue by aprox 200k for reasonable bootstrapped employee max size. So maybe 50 max? This is assuming standard software startup with most cost being employees.
It's not that much different in the EU. Through due to higher sales/revenue tax etc. a bit less employees. Also the additional cost above neto salary for epmploying someone is higher, but AFIK (especially as a startup) you can get away with a paying a bit less. Through in general it's less viable to scam your employees by doing stuff like goading them with non voting shares and then diluting them massively before selling. Like it's still possible but with much more limits. So this is comparison is limited to ethical company operation.
> they basically disqualified themselves from the start by nerfing the "core" version so bad it was useless
Ran the core version for around 3 years in production for a smart city project. The company I worked for has been running it for around 6 years. Not sure what you are talking about. Of course, we would love to use features like stale replicas for exports. But this isn't something we absolutely need.
Ran the core version for around 3 years in production for a smart city project. The company I worked for has been running it for around 6 years. Not sure what you are talking about. Of course, we would love to use features like stale replicas for exports. But this isn't something we absolutely need.
Overall I feel like this is a step in the right direction.
I do love Cockroach, but the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup).
For reference, some other data stores doing "horizontal scale of writes" ..any others I'm missing ?
* MySQL: Vitess, Planetscale, TiDB, MariaDB Spider
* Postgres: Citus, YugabyteDB, YDB, Neon
* SQLite: mvsqlite, marmot
* Document: ScyllaDB, Cassandra, DynamoDB
I do love Cockroach, but the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup).
For reference, some other data stores doing "horizontal scale of writes" ..any others I'm missing ?
* MySQL: Vitess, Planetscale, TiDB, MariaDB Spider
* Postgres: Citus, YugabyteDB, YDB, Neon
* SQLite: mvsqlite, marmot
* Document: ScyllaDB, Cassandra, DynamoDB
If what you mean by "horizontal scale of writes" is a distributed database, then there is FoundationDB, which is one of the very few databases that offers strict serializability (see https://jepsen.io/consistency). But it isn't quite comparable, because it isn't an easy-to-use shiny tool, rather a database-building toolkit (hence the name).
Not a distributed systems guy, but Spanner also offers that right? Or at least I'd assume they do considering they coordinate with actual clocks so you're naturally tied with real-time.
Most of the others listed are relational SQL databases, FoundationDB is a key-value store.
What? FoundationDB disappeared down the memory hole whenever Apple acquired them.
It's still open source and actively maintained by Apple, they use it internally.
https://github.com/apple/foundationdb
https://github.com/apple/foundationdb
It is now. There were a few years where it had basically disappeared (2015-2018). When Apple eventually put it back in the open-source world, it was done with little fanfare so it could be easy to miss.
> put it back in the open-source world
Just to clarify - FoundationDB was never open source before 2018. Binaries were available under certain conditions, but no source.
Just to clarify - FoundationDB was never open source before 2018. Binaries were available under certain conditions, but no source.
Deno KV uses FoundationDB, for example:
https://deno.com/blog/building-deno-kv
https://deno.com/blog/building-deno-kv
same guy who wrote mvsqlite btw
It re-appeared after 10 or so years though.
Really, what is the reason why?
Apple thought it would be in their best interest to release it.
Apple acquired the company in 2015 and 3 years later open-sourced the database.
(so much misinformation in this thread, this isn't hard to check)
(so much misinformation in this thread, this isn't hard to check)
Neon doesn't horizontal scale of writes. Just like Aurora doesn't.
Also, not all alternatives listed are ACID compliant with serializable transactions like CockroachDB is.
Also, not all alternatives listed are ACID compliant with serializable transactions like CockroachDB is.
Most of those solutions are not on part with Cockroach, Cockroach is basically Spanner usable outside of Google. So global transaction with cluster world wide.
Spanner is cheap in comparison depending on your storage requirements. I've seen CockroachDB quoted as 10x more, and for a product that is harder to sell to stake holders.
There are some contenders in that list: TiDB, YugabyteDB, YDB.
spanner != cockroach. Spanner has specialized hardware with atomic clocks. It's better.
https://www.cockroachlabs.com/blog/living-without-atomic-clo...
https://www.cockroachlabs.com/blog/living-without-atomic-clo...
> if you required any enterprise features
For me it was the multiple regions. It's like.. with that disabled why are we even here? Data residency is the whole point...
For me it was the multiple regions. It's like.. with that disabled why are we even here? Data residency is the whole point...
I don’t believe Neon supports multiple write nodes.
It currently does not, but it's something we would like to eventually support.
- employee
- employee
Odd to see the market leader in this space not listed. It's "web scale"
Ah you must be referring to /dev/nullDB?
Right which has been come along way in 15 yrs
> On November 18, 2024, we will eliminate our Core offering and consolidate on a single, robust CockroachDB Enterprise license
That is incredibly short notice.
That is incredibly short notice.
only a problem if you need to update
This hasn't been my experience. After another VC-backed software switched licenses, we continued using an older, open source version licensed Apache 2. But that didn't stop their lawyers from trying to shake us down, claiming we were using the latest, enterprise version. We just showed up in their telemetry as using their product and they came a knockin. I imagine that their telemetry failed to distinguish who was running old FOSS from the latest proprietary one.
We showed our lawyers that we were using the FOSS version. But, they didn't care and demanded we remove their product (despite being FOSS) immediately on all our systems.
That was a crazy crazy week.
You can say that's a problem with our lawyers. But still, who wants to go to court even if you know that you'll win eventually? It's expensive and incredibly annoying as an engineer to have to deal with lawyers.
We showed our lawyers that we were using the FOSS version. But, they didn't care and demanded we remove their product (despite being FOSS) immediately on all our systems.
That was a crazy crazy week.
You can say that's a problem with our lawyers. But still, who wants to go to court even if you know that you'll win eventually? It's expensive and incredibly annoying as an engineer to have to deal with lawyers.
even then you've had five years notice that enshittification was coming: https://en.wikipedia.org/wiki/CockroachDB#History
Making $10M ARR companies pay for the software that they use is not enshittification.
$10M ARR doesn't mean anything. You could still be a tiny company with terrible financials by selling your product at a loss (a startup)
It's just an arbitrary number
It's just an arbitrary number
[deleted]
i mean, yes? it is? software you can't use without someone else's permission is obviously shittier than open-source software you can fork, even if you're a big company. perhaps especially if you're a big company. and software that sends telemetry to the vendor is obviously shittier than software that doesn't
Well if the company can build a business then you can get great software to use... while in theory it would be great if a bunch of incredible software were done purely in the spirit of community open source, in practice that's pretty limited
i mean, no? it isn't? changing the license doesn't change the software? the software still works the same way?
In this case, they cancelled a product (core) and replaced it with a different product that has an additional new license (enterprise edition with a free tier)
So not just a license change
So not just a license change
I posted it on Twitter, but I feel like revenue-based licensing models unnecessarily push the compliance burden onto the user. It's an honor system, and even they admit it [0]; even Unity, who also uses a revenue-based model, admits it [1]. I'd prefer licensing models that are able to automatically segment users into customers at the software-level, such as a feature-based or usage-based model. For example, they could segment on CPU count or disk size, requiring an Enterprise offering for databases or clusters over a certain threshold.
But completely doing away with Core and requiring license keys even for free users [2] (which I assume is for revenue auditing purposes) ... I feel like that's a big step backwards. All of this because their Enterprise offering seemingly wasn't valuable enough (or from the comments -- it was too expensive).
I'd of focused there, on making Enterprise more valuable or more accessible, instead of doing something this drastic.
AFAICT, they're also doing away with BUSL and DOSP [3], which is a big bummer.
[0]: https://techcrunch.com/2024/08/15/cockroach-labs-shakes-up-i...
[1]: https://www.reddit.com/r/Unity3D/comments/82mfwh/how_could_u...
[2]: https://www.cockroachlabs.com/blog/enterprise-license-announ...
[3]: https://opensource.org/dosp
But completely doing away with Core and requiring license keys even for free users [2] (which I assume is for revenue auditing purposes) ... I feel like that's a big step backwards. All of this because their Enterprise offering seemingly wasn't valuable enough (or from the comments -- it was too expensive).
I'd of focused there, on making Enterprise more valuable or more accessible, instead of doing something this drastic.
AFAICT, they're also doing away with BUSL and DOSP [3], which is a big bummer.
[0]: https://techcrunch.com/2024/08/15/cockroach-labs-shakes-up-i...
[1]: https://www.reddit.com/r/Unity3D/comments/82mfwh/how_could_u...
[2]: https://www.cockroachlabs.com/blog/enterprise-license-announ...
[3]: https://opensource.org/dosp
VictoriaMetrics CTO here.
I don't understand why pure open-source license such as Apache2, MIT or BSD should be replaced with some source available license in order to increase profits from enterprise support contracts:
- The license change won't force cloud companies signing the enterprise agreement with you in most cases. If they didn't want paying you before the license change, why they will change their mind after the licence change? It is better from costs and freedom perspective forking open-source version of your product and using it for free like Amazon did with Elasticsearch.
- The license change leads to user base fragmentation - some of your users switch to forks run by cloud companies. Others start searching for alternative open-source products. So, you start losing users and market share after the license change.
- The license change doesn't bring you new beefy enterprise contracts, since it doesn't include any incentives for your users to sign such contracts.
That's why we at VictoriaMetrics aren't going to change the Apache2 license for our products. Our main goal is to provide good products to users, and to help users use these products in the most efficient way. https://docs.victoriametrics.com/goals/
I don't understand why pure open-source license such as Apache2, MIT or BSD should be replaced with some source available license in order to increase profits from enterprise support contracts:
- The license change won't force cloud companies signing the enterprise agreement with you in most cases. If they didn't want paying you before the license change, why they will change their mind after the licence change? It is better from costs and freedom perspective forking open-source version of your product and using it for free like Amazon did with Elasticsearch.
- The license change leads to user base fragmentation - some of your users switch to forks run by cloud companies. Others start searching for alternative open-source products. So, you start losing users and market share after the license change.
- The license change doesn't bring you new beefy enterprise contracts, since it doesn't include any incentives for your users to sign such contracts.
That's why we at VictoriaMetrics aren't going to change the Apache2 license for our products. Our main goal is to provide good products to users, and to help users use these products in the most efficient way. https://docs.victoriametrics.com/goals/
What if AWS launches AWS Metrics which just takes your code and hosts it.
You can't out compete Amazon here. I vastly prefer to use MIT or Apache code for my projects. It just makes things easier, but I also respect companies like yours have a right to seek a profit.
You can't out compete Amazon here. I vastly prefer to use MIT or Apache code for my projects. It just makes things easier, but I also respect companies like yours have a right to seek a profit.
If Amazon will make a product on top of open-source VictoriaMetrics, then we'll say thanks to Amazon, since this is great marketing - more people will be aware of great products provided by VictoriaMetrics!
There is close to zero probability that Amazon will pay us for this product, so there is no any sense in changing the license from Apache2 to some BSL-like license, since they never sign long-term contracts with open-source product vendors.
There is close to zero probability that Amazon will pay us for this product, so there is no any sense in changing the license from Apache2 to some BSL-like license, since they never sign long-term contracts with open-source product vendors.
But if I could just go to Amazon directly,presumably they'd offer support, how do I give you money.
I just don't understand how for-profit company can develop true open source software. You can have a non profit foundation and a for profit support studio. Godot effectively does this.
Plus if you've taken VC money you can always get voted out in a few years. Or just have a nice exit. I wouldn't be mad at anyone for taking a large payday and retiring. But then the for profit company is free to change the license.
It feels more straightforward to use a proprietary or copy left license from the start. Your company exists to make money, and I think most of us can respect that. We just don't want to start building our projects off of open source software, that converts to some other license years down the road.
I just don't understand how for-profit company can develop true open source software. You can have a non profit foundation and a for profit support studio. Godot effectively does this.
Plus if you've taken VC money you can always get voted out in a few years. Or just have a nice exit. I wouldn't be mad at anyone for taking a large payday and retiring. But then the for profit company is free to change the license.
It feels more straightforward to use a proprietary or copy left license from the start. Your company exists to make money, and I think most of us can respect that. We just don't want to start building our projects off of open source software, that converts to some other license years down the road.
If you go to Amazon directly, this is great - you continue using our products and recommending them to your friends. Probably, next time you'll become our customer. For example, if you aren't satisfied with the support from Amazon, or there are some missing features at Amazon, or if you just switch department or company.
We develop open source products, we are profitable and we have good revenue growth rate. We make money mostly on high-quality enterprise technical support for our open-source products. Some of our products have enterprise-only features [1], but most of our paid customers continue using open-source versions of VictoriaMetrics products.
[1] https://docs.victoriametrics.com/enterprise/
We develop open source products, we are profitable and we have good revenue growth rate. We make money mostly on high-quality enterprise technical support for our open-source products. Some of our products have enterprise-only features [1], but most of our paid customers continue using open-source versions of VictoriaMetrics products.
[1] https://docs.victoriametrics.com/enterprise/
Thanks for taking the time to respond.
If I ever have a need for a metrics solution I'll consider your products.
If I ever have a need for a metrics solution I'll consider your products.
Not everyone is able to or wants to use other peoples' computers.
I hope you can appreciate that the problem here is that the proposition that you "aren't going to change" is entirely unfalsifiable, reliant on trust, and that the individuals making the proposition are in a position to enforce it ad infinitum.
Consider me skeptical.
Consider me skeptical.
I tried providing good reasons why changing the license from truly open source to some source-available license has little sense from business perspective. Of course, something may change in the future, which could force us reconsider the decision on sticking with Apache2 license. But currently I don't see any reasons to change the license. And I'm sure there will no be such reasons in the next 10 years.
P.S. IMHO, the main reason to change the license at CocroachDB, Redis, Elasticsearch, MongoDB, TimescaleDB, Grafana and other products is weak revenue growth rate. Shareholders falsely think that the license change may help increasing the revenue growth rate, but I don't understand why...
P.S. IMHO, the main reason to change the license at CocroachDB, Redis, Elasticsearch, MongoDB, TimescaleDB, Grafana and other products is weak revenue growth rate. Shareholders falsely think that the license change may help increasing the revenue growth rate, but I don't understand why...
I'm really not a big fan of holding backups and DR behind licensing. That's base level functionality. That and row level security, but at least with row level, I get that there has been a lot of time and energy expended on that feature.
Cluster optimization, and enhanced security sure. And responsive support, absolutely.
Cluster optimization, and enhanced security sure. And responsive support, absolutely.
The ability to turn off telemetry collection is missing from the free version as well. No thanks.
It's the same with SSO, and I think it hurts some companies more than it helps. SSO too often is an arbitrary selection for "Enterprise/$Call Us".
Then you're two or three founders, you set up G Suite, and think oh, let's use SSO for this service, and then you're paying $$$.
Then you're two or three founders, you set up G Suite, and think oh, let's use SSO for this service, and then you're paying $$$.
So the obvious question is, which big shops were using the Core version that ended up prompting this change? I know of one or two but I'm curious if there are some obvious big fish.
Weren't Oxide using CockroachDB?
Yes, we are -- and it's worked well for us! (The most acute issue we hit was actually a gnarly OS issue[0][1].) That said, we are not currently a Cockroach Labs customer and we will not be becoming one for purposes of licensing CockroachDB. We are abiding by the terms of the BSL, and the version that we are on (22.1) will be Apache licensed in May 2025; by that point, we will maintain our own Apache-licensed fork for purposes of being the database for the control plane included in the Oxide rack.
We will be outlining our current direction in an RFD[2] that we will make public -- and we will also make public our RFDs that pertain to our selection of CockroachDB and the other alternatives that we evaluated; stay tuned!
[0] https://www.illumos.org/issues/15254
[1] https://oxide-and-friends.transistor.fm/episodes/a-debugging...
[2] https://rfd.shared.oxide.computer/rfd/0001
We will be outlining our current direction in an RFD[2] that we will make public -- and we will also make public our RFDs that pertain to our selection of CockroachDB and the other alternatives that we evaluated; stay tuned!
[0] https://www.illumos.org/issues/15254
[1] https://oxide-and-friends.transistor.fm/episodes/a-debugging...
[2] https://rfd.shared.oxide.computer/rfd/0001
And like clockwork too.
1. Company builds cool OSS and releases it to the world.
2. The product becomes stable, mature, and users are happy with its feature set. Development slows down.
3. Company starts having to make money so they relicense future code.
4. A few large users of the software (that company was hoping for $$$ from) realize that since it's mature and stable it's massively lower cost to just maintain the last OSS version.
5. At the time of the license chance the new OSS fork is identical to what everyone is already using and so it's the the least resistance migration.
6. The consortium of actual users of the software drive its future direction instead of the company.
I'm not mad about the cycle, it's the moment VC backed software gets turned over to the community. But I always wonder how it turns out for the companies in the long run.
1. Company builds cool OSS and releases it to the world.
2. The product becomes stable, mature, and users are happy with its feature set. Development slows down.
3. Company starts having to make money so they relicense future code.
4. A few large users of the software (that company was hoping for $$$ from) realize that since it's mature and stable it's massively lower cost to just maintain the last OSS version.
5. At the time of the license chance the new OSS fork is identical to what everyone is already using and so it's the the least resistance migration.
6. The consortium of actual users of the software drive its future direction instead of the company.
I'm not mad about the cycle, it's the moment VC backed software gets turned over to the community. But I always wonder how it turns out for the companies in the long run.
Any real world example for this?
Search keyword is "relicense", and especially "BSL" or "Cloud license".
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Redis, rhymes with this. Redis Labs, which captures the smallest sliver of the value OSS Redis provides, is valued at $2 B, with 2023 revenue of $151 M.
MongoDB, aka AWS "DocumentDB" (Microsoft/Azure Cosmos DB seems to have a different lineage). Mongo had $458 M in revenue Q4 2023 [1].
[1]: https://www.businessinsider.com/redis-labs-ceo-ipo-2-billion...
[2]: https://investors.mongodb.com/news-releases/news-release-det...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Redis, rhymes with this. Redis Labs, which captures the smallest sliver of the value OSS Redis provides, is valued at $2 B, with 2023 revenue of $151 M.
MongoDB, aka AWS "DocumentDB" (Microsoft/Azure Cosmos DB seems to have a different lineage). Mongo had $458 M in revenue Q4 2023 [1].
[1]: https://www.businessinsider.com/redis-labs-ceo-ipo-2-billion...
[2]: https://investors.mongodb.com/news-releases/news-release-det...
> aka AWS “DocumentDB”
Nope, just the same API, completely unrelated codebase.
Nope, just the same API, completely unrelated codebase.
Outside Olobserver here... isn't it a huge distraction from your core mission to be maintaining a fork of a database engine? Why not just use something like MongoDB Community if you're trying to avoid paying for database and need a horizontally scalable distributed transactional system?
No -- but I will leave it to the RFD that I'm currently writing (and to the others that we will make public) to explain the rationale.
Look forward to reading it
As promised, I have made RFD 508 ("Whither CockroachDB?")[0] public -- along with RFD 53[1] and RFD 110[2], which explain the problem we are trying to solve and our rationale for CockroachDB, respectively.
[0] https://rfd.shared.oxide.computer/rfd/0508
[1] https://rfd.shared.oxide.computer/rfd/0053
[2] https://rfd.shared.oxide.computer/rfd/0110
[0] https://rfd.shared.oxide.computer/rfd/0508
[1] https://rfd.shared.oxide.computer/rfd/0053
[2] https://rfd.shared.oxide.computer/rfd/0110
Not Jepsen tested but rqlite [0] could be in the running and meet the requirements and is open source (MIT).
0. https://rqlite.io/
0. https://rqlite.io/
Thanks: I think there's a category you're missing, which is transactional document oriented databases with strongly consistent secondary indexes.
Hi,
Does multi-region replication also go under the apache license?
MongoDB is not a drop-in replacement for a CockroachDB.
It's not SQL.
While MongoDB has come a long way in terms of ACID compliance, etc., you still would need to map everything you've done to MongoDB.
That's more work than forking code you're familiar with that already is working.
It's not SQL.
While MongoDB has come a long way in terms of ACID compliance, etc., you still would need to map everything you've done to MongoDB.
That's more work than forking code you're familiar with that already is working.
That makes sense it's more that from first principles when exploring the options it looked like and I see below based on the public page, it wasn't even contemplated.. instead various key value stores without transactionality, and with eventual consistency and limited secondary indexing capabilities were looked at that are not widely used.
I guess my deeper point is there's sort of the illusion of a comprehensive analysis in the post when actually engines that haven't been widely used in 5-10 years were analyzed when more widely deployed engines weren't even analyzd that's what was odd
I guess my deeper point is there's sort of the illusion of a comprehensive analysis in the post when actually engines that haven't been widely used in 5-10 years were analyzed when more widely deployed engines weren't even analyzd that's what was odd
RFD 53 addressed why they avoided NoSQL in general:
"NoSQL systems (e.g., Cassandra, Riak). The challenges of building relational, transactional applications atop these systems is well known. These systems also generally predate the modern emphasis on hands-off operation, which is critical for supporting a system that we will not be operating directly."
https://rfd.shared.oxide.computer/rfd/0053#rfd48
"NoSQL systems (e.g., Cassandra, Riak). The challenges of building relational, transactional applications atop these systems is well known. These systems also generally predate the modern emphasis on hands-off operation, which is critical for supporting a system that we will not be operating directly."
https://rfd.shared.oxide.computer/rfd/0053#rfd48
My point is to conflate the entire non-relational category into this bucket when one of the two items referenced peaked >10 years ago and the other isn't generally strongly consistent at write time, transactional, or with strongly consistent secondary indexes, is a limited and misleading POV https://db-engines.com/en/ranking
YugabyteDB is and will always be Apache2. It is PostgreSQL compatible (the query layer is a fork of PostgreSQL) so the migration from CockroachDB, which implements a subset of PostgreSQL features, is easy.
Seems like. There are 5.2k hits in their codebase for "cockroach" (https://github.com/search?q=owner%3Aoxidecomputer+cockroach&...)
Looks like those hits are because they forked it https://github.com/oxidecomputer/cockroach (no changes since then though)
Doesn't this only affect companies with more than $10M in revenue? This change should only affect companies that are a going concern and are apt to remain in business.
Finally all Open Source pretense is dropped. CockroachDB becomes Enterprise+Cloud database company with a free tier, not dissimilar from Oracle.
The revenue driver as a driver for freemium tier is interesting as it seems like it would require company to regularly disclose their revenue to CockroachDB which looks intrusive.
The revenue driver as a driver for freemium tier is interesting as it seems like it would require company to regularly disclose their revenue to CockroachDB which looks intrusive.
Props for calling it source available and not hiding behind "you can't police the meaning of open source", though.
I actually think source available software is great. Not every piece of software can survive as OSS but source available eliminates most the downsides of closed-source software from a technical perspective.
In my daily life I use a lot of essentially source-available software that I pay for. I spend like 4+ hours a day every day in IntelliJ IDEA etc. I don't have a problem paying for software, I have huge problems paying for software that I don't sufficiently control and/or it's closed-source nature affects it's ability to get it's job done - i.e anything mission critical where uptime and security are paramount.
In my daily life I use a lot of essentially source-available software that I pay for. I spend like 4+ hours a day every day in IntelliJ IDEA etc. I don't have a problem paying for software, I have huge problems paying for software that I don't sufficiently control and/or it's closed-source nature affects it's ability to get it's job done - i.e anything mission critical where uptime and security are paramount.
I certainly agree.
And it makes sense (for Enterprise "tech stack" software). A license violator would just crack your software anyway and legitimate paying users pay for it and want less hassle.
You probably will save on some support calls if their engineers can take a quick look themselves.
Same goes for any "secret Sauce" in the Code. Most Software of that Type isn't algorithmically novel enough to warrant drm and obfuscation.
And again a serious criminal comoetitor would spend the money to reverse it
And it makes sense (for Enterprise "tech stack" software). A license violator would just crack your software anyway and legitimate paying users pay for it and want less hassle.
You probably will save on some support calls if their engineers can take a quick look themselves.
Same goes for any "secret Sauce" in the Code. Most Software of that Type isn't algorithmically novel enough to warrant drm and obfuscation.
And again a serious criminal comoetitor would spend the money to reverse it
Enforced telemetry for free users? That's gross.
Not only that, but according to the licence agreement, there are "technical countermeasures" to stop you from using the product if you were to block telemetry with a firewall (presumably it stops working if the telemetry server doesn't send back an acknowledgement), and "You understand and agree that Licensor may use and disclose personal information collected as part of Telemetry in accordance with Licensor's Privacy Policy" ... wait, what?
In the closed source world it's common enough that free trials will be something along the lines of "we give you a license key tied to your name, and every time you start the software it calls into our license server to validate the license key"
It's bad, but it's not unusual if you use closed-source software.
It's bad, but it's not unusual if you use closed-source software.
I really hope they’re more lenient than that. Having a database go offline because their telemetry servers are down, slow, or unreachable seems inconvenient.
I can't find it now but I think I read words to the effect that performance is degraded if one isn't using the correct license or something, even for v23.x versions.
I guess this is fine for a free _trial_, if you can host it in some separate firewalled-off subnet where it doesn't touch your real customer data.
The issue here is that if you're an org with less than $10M turnover, you're currently on the Core plan and don't want to negotiate the full "Enterprise" licence (which is presumably priced towards larger users than you anyway), then you can't use the thing at all anymore unless you agree to telemetry and some vague disclosure of personal data thing that will get your lawyers in a spin (especially if you serve states in which GDPR applies).
EDIT: oh, and PCI-DSS requirements if you want to take credit cards? That's going to be fun.
The issue here is that if you're an org with less than $10M turnover, you're currently on the Core plan and don't want to negotiate the full "Enterprise" licence (which is presumably priced towards larger users than you anyway), then you can't use the thing at all anymore unless you agree to telemetry and some vague disclosure of personal data thing that will get your lawyers in a spin (especially if you serve states in which GDPR applies).
EDIT: oh, and PCI-DSS requirements if you want to take credit cards? That's going to be fun.
Sure, but I'm not sure why they wouldn't just use a signed license file with a start- and stop-date in this case. Lots of companies, especially enterprises, run air-gaps and telemetry just won't work there. And they should know that... it's their target market after all...
They have indicated that they will continue to make the source available.
Assuming you pay for a license, does the license prevent you from building your own fork, and patching out the telemetry code?
Assuming you pay for a license, does the license prevent you from building your own fork, and patching out the telemetry code?
As much as this has the vibes of a classic OSS rug pull, as a Cockroach user, I don’t really take it that way. First of all, it was already not open source and secondly, the free to use version was missing key features like follower reads and incremental backups.
Someone creating free software and changing the license on software they created isn't a "rug pull" in any sense of the word. You paid $0 and contributed nothing. What rug is being pulled?
A rug pull is when you buy into something and then it's taken away, like when a cryptocurrency token is busted out or you spend money on something and then it's cancelled or nerfed.
Don't like it? Write your own distributed fault tolerant database, or contribute an extension for Raft replication to the Postgres open source code base.
A rug pull is when you buy into something and then it's taken away, like when a cryptocurrency token is busted out or you spend money on something and then it's cancelled or nerfed.
Don't like it? Write your own distributed fault tolerant database, or contribute an extension for Raft replication to the Postgres open source code base.
I see the issue with these more as if you are paying for it, one of the decision factors to buy it might have been that you have the opportunity to go to an open source version if the relationship gets bad.
Sole source vendors are really risky, so open source gives a little control back to the buyer that the vendor won't lock them in then screw them later (oracle).
So now if you're paying for Cockroach, you're effectively on proprietary technology with no negotiating levers.
Sole source vendors are really risky, so open source gives a little control back to the buyer that the vendor won't lock them in then screw them later (oracle).
So now if you're paying for Cockroach, you're effectively on proprietary technology with no negotiating levers.
It’s Postgres compatible. If you only use standard features your negotiating lever is to bail for another Postgres compatible database. There are tons of managed offerings that are quick to stand up.
This is why standard APIs, protocols, and languages are a more important thing than specific pieces of software. If there is compatibility you have choice.
This is why standard APIs, protocols, and languages are a more important thing than specific pieces of software. If there is compatibility you have choice.
> You paid $0 and contributed nothing
I think investing into integrating a tool into your infrastructure is not exactly "paying $0".
I think investing into integrating a tool into your infrastructure is not exactly "paying $0".
From the standpoint of the people paying the developers of said software, it is exactly like paying $0.
No, it's not. If they're planning a rug pull, they very much care that you took effort to integrate their free offering into your infrastructure, because they care that you're sitting firmly on the rug before they can pull it.
If you make software and I start using it, I’ve created an obligation for you to keep making it?
CockroachDB raised >$500M in funding, and a big reason for this was it's high number of users. That high number would be a lot lower if it wasn't a free software.
[deleted]
The rug where my contributions sit on. That rug.
And as you're surely aware, competent OSS contribution is worth thousands
And as you're surely aware, competent OSS contribution is worth thousands
It is described as a rugpull because of the marketing around it being open source. Coackroach however was never open source, it was BSL licensed. This change does appear to mean that old versions will no longer eventually convert to open source, though.
Thus it would be up to the the BSL promoters and marketers to decide whether or not this is a rugpull. As an open source user and proponent, I don't really care.
Thus it would be up to the the BSL promoters and marketers to decide whether or not this is a rugpull. As an open source user and proponent, I don't really care.
> Coackroach however was never open source, it was BSL licensed.
It used to be Apache2. :)
Their blog post announcing this in 2019 happens to now 404:
https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...
But see also: https://news.ycombinator.com/item?id=40058332.
It used to be Apache2. :)
Their blog post announcing this in 2019 happens to now 404:
https://www.cockroachlabs.com/blog/oss-relicensing-cockroach...
But see also: https://news.ycombinator.com/item?id=40058332.
My bad, I was wrong then. They even still falsely claim on github that it is open source, too (thanks to another commenter for pointing that out.).
Really does appear to be memory-holed, rather than just having moved. Not a good look. https://www.google.com/search?q=site%3Acockroachlabs.com+"Co...."
Cockroach hasn’t marketed itself as open source for years
> CockroachDB - the open source, cloud-native distributed SQL database.
https://github.com/cockroachdb/cockroach
https://github.com/cockroachdb/cockroach
They seem to have fixed it.
Free license:
> Telemetry Required (excluding ephemeral clusters of 7 days or less)
So not free, then.
Is there already a popular fork?
> Telemetry Required (excluding ephemeral clusters of 7 days or less)
So not free, then.
Is there already a popular fork?
Yes, the popular fork is called Postgres. You can find many vendors who will let you run it on one node cheaply. It’s also free to self-host.
In what way is postgres similar to cockroachdb? Except for being a database. Going by that standard you might as well say that Access is an alternative to postgres. Which it technically is but...
Cockroach marketed themselves as largely Postgres-compatible, so I guess there's that.
I guess that's true, I didn't think about that. But i think that you'd probably not be using cockroachdb if you were fine with what postgres offers. Cockroach might be compatible, but it really isn't "comparable" in terms of use cases and deployment imo. I might be totally wrong though, I have not been following it and Postgres closely since some time around 2021?
It's useful to use a Postgres-compatible syntax. The point of Cockroach was always to compete with globe-spanning DBs like Spanner, not with (possibly) sharded PG.
Citus gets close for many usecases but the HA story sucks: https://github.com/citusdata/citus/issues/7602
PG is nowhere close of What Cockroach does and probably never will.
CockroachDB was already under the BSL. It's interesting that they're further restricting it... Perhaps the BSL isn't the panacea folks are making it out to be.
it hasn't been open-source since 02019 according to https://en.wikipedia.org/wiki/CockroachDB#History so if there are popular forks they'd have to be five years old
BSL code automatically converts to open source at a specified date. So probably several releases since then are now as open source as anything else in the world. And if not, then they will be soon - BSL allows a maximum 5 year delay.
that may be (i haven't read the license) but i'm not persuaded it's relevant
if nobody forked it five years ago, they probably aren't going to fork it now
if somebody did fork it five years ago, they probably aren't going to try to merge in new source code drops as they convert to open source
if nobody forked it five years ago, they probably aren't going to fork it now
if somebody did fork it five years ago, they probably aren't going to try to merge in new source code drops as they convert to open source
Then why do you care? If nobody is going to fork it anyway, what’s the benefit of being open source from the beginning?
i don't care that much because i don't use it, and evidently not much of anybody else does either, or there would have been a popular fork. i'm just saying that this is probably not a good time to expect one to pop up
> 02019
Why not 002019? 6 digits. That would be valid a lot longer.
Why not 002019? 6 digits. That would be valid a lot longer.
i wholeheartedly support your choice to henceforth format your years with six digits
I'm waiting for python support first. Not sure what the eta is or why it's taking so long. Every day we get closer to the eventual deadline.
> Extended date representations are not currently supported (±YYYYYY-MM-DD).
https://docs.python.org/3/library/datetime.html#datetime.dat...
> MAXYEAR is 9999.
https://docs.python.org/3/library/datetime.html#datetime.MAX...
I'm also waiting for longnow.org to start using long dates behind the scenes, like image urls, html metadata, http headers, etc. They need to eat their own dog food as far as software goes.
> Extended date representations are not currently supported (±YYYYYY-MM-DD).
https://docs.python.org/3/library/datetime.html#datetime.dat...
> MAXYEAR is 9999.
https://docs.python.org/3/library/datetime.html#datetime.MAX...
I'm also waiting for longnow.org to start using long dates behind the scenes, like image urls, html metadata, http headers, etc. They need to eat their own dog food as far as software goes.
<link rel="icon" href="https://static.longnow.org/2022/06/favicon.png" type="image/png">
<meta property="og:image" content="https://static.longnow.org/2021/10/header-talks.jpg">
<meta property="article:modified_time" content="2024-06-11T17:21:23.000Z">This is really painful, I don't want this pattern of data collection being common, Telemetry included.
Yup - another "Contact Us" for pricing. God forbid if your business grows more than 10 Million ARR and now you owe them undisclosed amount of money.
At this point I'm convinced "Contact Us" is worse for business/sales than just disclosing any outrageous fees upfront
I am with you! I stop looking when it says contact us for pricing.
I think the reality is, only exceeding common codebases (Linux and Postgres for example), can survive with an open source model. If the value created by the product is 1M times greater than the costs, fine, a way to support it will materialize. Otherwise, economics take over and people need to get paid. The fact that source is publicly available is largely irrelevant.
I don't think the point is how common it is, it's about a organizational model.
Linux and Postgres are not reliant on any one commercial entity being successful for their continued existence. Even many of the maintainers are not reliant: if the company/foundation Linus Torvalds is working for at the moment has to close down, someone else will pay him to keep working on Linux. And even if he couldn't personally work on Linux anymore, there are enough other people in a similar position that Linux won't die.
I'm sure there are many much smaller and more obscure projects in a similar boat, especially in academia. If the code is not dependent on a single entity for maintenance, both in terms of someone knowing it and in terms of someone paying for it, then it will naturally thrive for a very long time.
Linux and Postgres are not reliant on any one commercial entity being successful for their continued existence. Even many of the maintainers are not reliant: if the company/foundation Linus Torvalds is working for at the moment has to close down, someone else will pay him to keep working on Linux. And even if he couldn't personally work on Linux anymore, there are enough other people in a similar position that Linux won't die.
I'm sure there are many much smaller and more obscure projects in a similar boat, especially in academia. If the code is not dependent on a single entity for maintenance, both in terms of someone knowing it and in terms of someone paying for it, then it will naturally thrive for a very long time.
You need an enterprise that's already decided to use CockroachDB if your trial offer is only 30 days long. We've barely walked around the car & kicked the tires before that trial runs out; it's not respectful of the time it takes enterprises to move at all.
I guess I don't get it. CockroachDB is decidedly an enterprise product. There's no need for even a medium sized company to require distributed database the likes of CockroachDB. If you're a small company using it, you're just using it for fun, and you're probably not paying.
If you're using it and paying for it, then this doesn't seem like a problem. If you're not using it, then it shouldn't matter. If you're using it but not paying for it, then maybe it's okay that you have to start paying for it.
If you're using it and paying for it, then this doesn't seem like a problem. If you're not using it, then it shouldn't matter. If you're using it but not paying for it, then maybe it's okay that you have to start paying for it.
There are quite a few situations where running the (previously) open source core was a good fit for business problems which would become unprofitable if the enterprise license was used.
It seems a shame that to grow, companies are backing away from the vector that got them there: open source.
I agree that current cloud providers are gaining more benefit from open source than they're putting in. So, it seems logical that the main developers want to recapture some of that.
On the other hand, open source is supposed to help build a bigger pie. If the pie gets bigger faster (i.e. more people using CockroachDB) then is the recapture worth it?
It seems the smaller companies think so. But, I don't know of a solid analysis that shows this to be true.
I agree that current cloud providers are gaining more benefit from open source than they're putting in. So, it seems logical that the main developers want to recapture some of that.
On the other hand, open source is supposed to help build a bigger pie. If the pie gets bigger faster (i.e. more people using CockroachDB) then is the recapture worth it?
It seems the smaller companies think so. But, I don't know of a solid analysis that shows this to be true.
Wow, what a rug-pull! Good luck to Cockroach Labs, but I doubt their product is entrenched-enough to make this strategy sustainable - it's going to _kill_ growth.
It's a surprising and very welcome change. Most will benefit.
If you have more than $10M revenue, why on earth would you run the limited open core version of CochroachDB just to save some $1K-$10K (which is about the enterprise license cost). The open core version has limitations you don't want to miss esp. reg. backup and restore, encryption, follower reads. Now all those features are available for free if you're small.
If you have more than $10M revenue, why on earth would you run the limited open core version of CochroachDB just to save some $1K-$10K (which is about the enterprise license cost). The open core version has limitations you don't want to miss esp. reg. backup and restore, encryption, follower reads. Now all those features are available for free if you're small.
That's _not_ what the enterprise license costs for reasonably large deployments.
That is not what the license costs even for relatively small deployments.
Anyone here migrated to TiDB from cockroach and can share experience? Asking for a friend…
It's a lot more moving parts unfortunately and the TiDB team has historically little interest in fixing that.
TiDB CTO here, I think that a clear boundary between components is beneficial for the maintainability of a distributed systems like TiDB, and automated deployment tools like `tiup`(https://tiup.io) and the Operator of Kubernetes shield end-users from this complexity in order to maintain best practices in deployment. While still providing enough debugging details for advanced users.
That’s one of worst part of TiDB to be honest.
Single boundary with simple flag listing peers (or DNS SRV address) would bring you a lot of smaller companies and/or hobbyists who will contribute.
Having different parts written in different languages is awful too, because it brings some micro improvements (if any) but makes project look complex and scary for many new-comers :(
Having different parts written in different languages is awful too, because it brings some micro improvements (if any) but makes project look complex and scary for many new-comers :(
Single binary is for sure preferable but given that they have k8s operator shouldn't be too bad? CRDB also had its faults - their CDC to kafka had terrible reliability even on enterprise versions.
I'm guessing the Required Telemetry thing is gonna cause a technical/security problem too. Most production databases would be running in private isolated networks with no inbound or outbound internet access on the VMs, and because of this requirement, they'll have to open outbound access to at least Cockroach's IPs.
I worked with the cockroachdb founders at a previous company.
They’re clowns.
They’re clowns.
I am a great fan of scaling vertically as far sa possible on DB servers.
These days that is pretty damn high.
It avoids a lot of prickly edge cases.
It is definitively not one solution for all. There are many cases where it just won't work.
I would like to see more IBM Z servers being used. $$$$$$$$ though
It is definitively not one solution for all. There are many cases where it just won't work.
I would like to see more IBM Z servers being used. $$$$$$$$ though
It doesn't solve for required multi-region data storage. Nor for data center failure resilience.
Scaling up is fine for a few things, but hopeless for many others.
Scaling up is fine for a few things, but hopeless for many others.
For data-center failure, it does: the underlying storage can be resilient.
For multi-region, indeed, that will not be possible. Master-slave would be the way.
For multi-region, indeed, that will not be possible. Master-slave would be the way.
If you prefer mysql sql flavour, pingcap has titanium db(tidb) alternative.
I'm trying to figure out how this is better than Postgress ?
Does it perform significantly better to justify the cost? Back in the day I worked heavily with databases and we always tilted towards open source.
Does it perform significantly better to justify the cost? Back in the day I worked heavily with databases and we always tilted towards open source.
For most databases (like Postgres), you typically run a single database (per shard, possibly), and replicate changes to a live read-only backup as fast as possible. If the live R/W database fails, you quickly switch the backup to R/W, and point traffic there instead.
Then, there's a class of databases that tries to actively commit across multiple geographies. You pay a cost (in terms of latency, and typically also $$$), but when a commit succeeds, it has been written durably and reliably, using some consensus protocol, across multiple geographies.
The exemplar is probably Spanner, which uses atomic clocks to get very specific about time to narrow the latency gap as much as possible. Cockroach is broadly in the same class, although without atomic clocks I believe it's using network roundtrip measurements and/or some kind of mathematical time abstraction (like counters of come kind) to do the same thing. Can't ever be quite as fast, but you don't need atomic clocks!
What's _really_ funny is when people start out choosing Spanner because of its global replication, then decide it's too expensive, and settle on regional non-replicated Spanner DBs to save cost. Like, that's just a database, man. (Or maybe something slightly above a single database, like Aurora replicated across Availability Zones in the same Region).
Other folks can chime in, but there are a growing number of databases in this class. TiDB I believe is one. I _thought_ PlanetScale was just sharded mysql (Vitess+MySQL = clever auto-(re-)sharding), but perhaps it does replicated writes too - I see it getting mentioned here a bunch.
Then, there's a class of databases that tries to actively commit across multiple geographies. You pay a cost (in terms of latency, and typically also $$$), but when a commit succeeds, it has been written durably and reliably, using some consensus protocol, across multiple geographies.
The exemplar is probably Spanner, which uses atomic clocks to get very specific about time to narrow the latency gap as much as possible. Cockroach is broadly in the same class, although without atomic clocks I believe it's using network roundtrip measurements and/or some kind of mathematical time abstraction (like counters of come kind) to do the same thing. Can't ever be quite as fast, but you don't need atomic clocks!
What's _really_ funny is when people start out choosing Spanner because of its global replication, then decide it's too expensive, and settle on regional non-replicated Spanner DBs to save cost. Like, that's just a database, man. (Or maybe something slightly above a single database, like Aurora replicated across Availability Zones in the same Region).
Other folks can chime in, but there are a growing number of databases in this class. TiDB I believe is one. I _thought_ PlanetScale was just sharded mysql (Vitess+MySQL = clever auto-(re-)sharding), but perhaps it does replicated writes too - I see it getting mentioned here a bunch.
Assuming I need to host on prem, do any fully open source solutions exist for this .
It really looks like every database company is trying to become Oracle. You want your clients to be trapped and unable to leave, so if you hypothetically just up the price by 30 or 40% upon renewal they either have to rewrite their entire stack, or pay the piper.
It really looks like every database company is trying to become Oracle. You want your clients to be trapped and unable to leave, so if you hypothetically just up the price by 30 or 40% upon renewal they either have to rewrite their entire stack, or pay the piper.
CockroachDB is basically "run postgres on a cluster with more fault tolerance" - you can have machines (or entire datacenters) going down, netsplits etc. and as long as there's enough infra up to keep going, it will.
Presumably only a small subset of postgres users really need this feature - and those that do, are big enough to need an enterprise licence.
Presumably only a small subset of postgres users really need this feature - and those that do, are big enough to need an enterprise licence.
I'll admit I haven't worked directly in this space in a good while, but the whole mystery terms really rubs me the wrong way .
For example if I have a company that provisions databases on behalf of my clients, is this 10 million revenue cap for my company, or for the clients themselves .
The pricing isn't even on the website for self hosting, I presume it's one of those if you need to ask you can't afford it type situations.
Plus you're locking yourself into a vendor that has no worries about changing its terms again later on.
>Required only during the trial period. Businesses that cannot accommodate telemetry may contact sales to request an exception. Paid use does not require telemetry.
From some of the industries I've worked in, this is a massive red flag. We don't want to give you telemetry at any point in our process.
For example if I have a company that provisions databases on behalf of my clients, is this 10 million revenue cap for my company, or for the clients themselves .
The pricing isn't even on the website for self hosting, I presume it's one of those if you need to ask you can't afford it type situations.
Plus you're locking yourself into a vendor that has no worries about changing its terms again later on.
>Required only during the trial period. Businesses that cannot accommodate telemetry may contact sales to request an exception. Paid use does not require telemetry.
From some of the industries I've worked in, this is a massive red flag. We don't want to give you telemetry at any point in our process.
The 8.19.2024 Oxide.Computer podcast talks about this.
https://www.youtube.com/watch?v=DNHMYp8M40k
Of special interest is that they are maintaining a completely free pre-rugpull version of CockroachDB that was forked before Cockroach's retroactively relicensed security fixes.
I would look seriously at using that instead of starting down Cockroach's free with telemetry offering.
https://www.youtube.com/watch?v=DNHMYp8M40k
Of special interest is that they are maintaining a completely free pre-rugpull version of CockroachDB that was forked before Cockroach's retroactively relicensed security fixes.
I would look seriously at using that instead of starting down Cockroach's free with telemetry offering.
Sharding (huge data and local distribution, even worldwide) and HA by retaining serializable transactions. Possibly easier to operate.
The downsides are:
- slower - Postgres (if it can handle the amount of data, which is very much on proper hardware and partitioning of > 1B row tables) is much faster, esp. for joins
- features
- ecosystem (see the countless extensions)
- cost of course
The downsides are:
- slower - Postgres (if it can handle the amount of data, which is very much on proper hardware and partitioning of > 1B row tables) is much faster, esp. for joins
- features
- ecosystem (see the countless extensions)
- cost of course
> Even by conservative estimates, the vast majority of the world’s businesses will meet the eligibility requirements for the Enterprise Free Tier license
This feels dishonest. What percentage of the world’s business need a system like CockroachDB? Of those, what percentage are under 10 million in revenue?
This feels dishonest. What percentage of the world’s business need a system like CockroachDB? Of those, what percentage are under 10 million in revenue?
if it were really the case that the vast majority of businesses doesn't need to pay then they'll just adjust it down to 1 million in revenue
Amidst the frequent noise - its hard to notice that even the most stringent of OSS licenses like AGPL was written way back in 2002! Cloud was not even in the picture. Since then, ever growing cloud players have been playing the 'state' role and misusing OSS as 'religion' heavily affecting infra OSS products or companies.
I spotted this company in their seed stage and wanted to invest. The founders asked us to provide names for reference checks, etc - a bit unusual, but we were almost done with the commitment, so why not?
After quite a lot of work, introductions, and back and forth, they told us: sorry, Google Ventures is investing and we're kicking everyone else out, despite we expected an allocation at that point (50k, not very large). Not nice by them, and not nice by GV, but... Just another lesson learned in the epicenter of startup investing which is San Francisco. This was Feb 2015. Wow, almost 10 years ago. Time flies.
I am still happy to see they've been successful at building the company. I loved the product from the very beginning.
After quite a lot of work, introductions, and back and forth, they told us: sorry, Google Ventures is investing and we're kicking everyone else out, despite we expected an allocation at that point (50k, not very large). Not nice by them, and not nice by GV, but... Just another lesson learned in the epicenter of startup investing which is San Francisco. This was Feb 2015. Wow, almost 10 years ago. Time flies.
I am still happy to see they've been successful at building the company. I loved the product from the very beginning.
The FAQ that asks "What telemetry data will be collected, and how will it be used?" never answers the first half of the question in its marketese blurb. You failed the "ask yourself a question and answer it" part of the exam.
Dancing around the "so it's not open source" by not clearly saying "correct, it's no longer open source".
"CockroachDB will remain source available under a new license" sounds correct but it's still sidestepping the question. And "the source code will still be available for viewing and contributions" is completely shit. Why would anyone contribute to a commercial product unless they're getting paid to do so.
Also, the use of this kind of "evolving our" and "advancing our" phrasing is so incredibly gross. No one speaks like this except in corporate announcements.
"CockroachDB will remain source available under a new license" sounds correct but it's still sidestepping the question. And "the source code will still be available for viewing and contributions" is completely shit. Why would anyone contribute to a commercial product unless they're getting paid to do so.
Also, the use of this kind of "evolving our" and "advancing our" phrasing is so incredibly gross. No one speaks like this except in corporate announcements.
> Why would anyone contribute to a commercial product unless they're getting paid to do so.
Because they'd be getting paid to do it for their company? I know of a few customers who, if they could, would have their employees contribute minor features to AWS services to solve issues.
Because they'd be getting paid to do it for their company? I know of a few customers who, if they could, would have their employees contribute minor features to AWS services to solve issues.
[deleted]
> Dancing around the "so it's not open source" by not clearly saying "correct, it's no longer open source".
CockroachDB hasn't been open source for over 5 years: https://web.archive.org/web/20190604173131/https://www.cockr...
CockroachDB hasn't been open source for over 5 years: https://web.archive.org/web/20190604173131/https://www.cockr...
Yet it's one of the top questions on their announcement page and they won't clearly answer it.
Likely because most people think "source available on GitHub" = "open source", so they're just answering the low-hanging-fruit even if the question is technically incorrect. They don't claim to be open source anywhere, and I haven't seen them claiming to be open source since they relicensed to the BUSL over 5 years ago. I don't think there's malice here.
> Why would anyone contribute to a commercial product unless they're getting paid to do so.
Because they need a bug fix in the code as soon as possible without waiting for the vendor's priorities to match their own?
Because they need a bug fix in the code as soon as possible without waiting for the vendor's priorities to match their own?
> Why would anyone contribute to a commercial product unless they're getting paid to do so.
Because they get to use it for free?
Because they get to use it for free?
I like the technology here, but at the same time I feel like they've been on this trajectory since the beginning. It's just another VC-backed company using open source for marketing, without any legitimate desire to actually be open source. At least now they've pulled the wool off of it.
[deleted]
This made me wonder about postgres. Is Postgres at risk of being taken over by some corporate? What can we learn from all these free open-source databases that has gone enterprise commercial.
That is a valid concern, see what happened with Redis or MySQL. But I think (while valid) it's very unlikely. Postgres can't be "bought". A company would need to start building an own version and make it better than the still existing open source version. Then they would need to convince people to pay for it. Not a good business idea.
PostgreSQL's global, decentralized community, including companies like PostgreSQL Professional in Russia, makes a corporate takeover unlikely.
Even if the name is taken, the community and independent providers would carry on.
Even if the name is taken, the community and independent providers would carry on.
I just don't understand why they didn't go with a copyleft license like SSPL; is it because they're worried too many people will self-manage in the Enterprise and not pay them?
Ensure your data is secure with our mandatory telemetry. No deal.
WRT CockroachDB Enterprise Free's telemetry requirement:
> Required (excluding ephemeral clusters of 7 days or less)
Does that mean the cluster will stop working when it can no longer report?
> Required (excluding ephemeral clusters of 7 days or less)
Does that mean the cluster will stop working when it can no longer report?
I understood it as "it pings the HQ once a week".
I get wanting large companies and cloud providers to pay, but mandatory telemetry collection in the self-hosted version of the product is an absolute non starter.
What are the remaining use cases for CockroachDB where there isn't a better/open-source alternative?
multi-master writes with serializable transactions
TiDB
Are any of the databases certain (as certain as one can be) to stay open?
MySQL/Perconna/MariaDB has a pretty community with three different, large entities supporting it. At least there's some redundancy if one decides to change course
Postgres also has some separate large entities supporting it but it rolls up to the same codebase
Postgres also has some separate large entities supporting it but it rolls up to the same codebase
I've never seen this database used by anyone in real life.
Is Netflix[0] real life enough?
[0] - https://www.cockroachlabs.com/blog/netflix-at-cockroachdb/
[0] - https://www.cockroachlabs.com/blog/netflix-at-cockroachdb/
That's impressive. I'm genuinely surprised they have users at this scale. Are there others?
I heard that doordash ran a cluster serving >1M qps, there maybe still a setup at square/block where the team originated from
I guess most of the larger deployments are self-managed rather than their SaaS offering... Do you think this is mostly running on top of hyperscaler infrastructure? Or in traditional enterprise data centers? I'm just surprised because I never see it
It looks like[0] DoorDash is running theirs self-hosted and just on their cloud, not in the DC. At former gig we ran our much smaller clusters (largest one was ~10T and 20k qps) on kubernetes on cloud. Deployment/updates and what not wasn't difficult - the biggest difficulty was not accidentally overloading the DB from the application layer as always.
[0] - https://www.youtube.com/watch?time_continue=97&v=jCjrfpF64Kc
[0] - https://www.youtube.com/watch?time_continue=97&v=jCjrfpF64Kc
I'm skeptical of this kind of multi-master horizontal DBMS to begin with. Never used Cockroach but have used Spanner, and even besides the $, you pay with complexity, slowness, and limitations. Even the in-betweens like Citus have their issues. As far as I can tell, the world runs on traditional DBMSes like Postgres, maybe with HA. If you're big, you run multiple and shard at the application level. I don't think there's a better option yet.
Btw, Spanner and Cockroach both have fully serializable transactions. Even single-node Postgres doesn't do that by default (though it can) because they didn't think the performance tradeoff was worthwhile. Read-committed is good enough.
Btw, Spanner and Cockroach both have fully serializable transactions. Even single-node Postgres doesn't do that by default (though it can) because they didn't think the performance tradeoff was worthwhile. Read-committed is good enough.
predictable and pretty good business move.
these things are easy to evaluate - 1. what's your appetite in running infra ? low - then use the SAAS offering 2. doable - then use a db that has good scalable solutions in this case mysql -> vitess since those products don't come from a database vendor. mongo might qualify too
these things are easy to evaluate - 1. what's your appetite in running infra ? low - then use the SAAS offering 2. doable - then use a db that has good scalable solutions in this case mysql -> vitess since those products don't come from a database vendor. mongo might qualify too
Whats your appetite for a SaaS vendor unpredictably and without enough warning changing the price they are charging you, or pushing updates to the SaaS that break your business? Better get it put into the contract.
Their target customers for self-hosting are Enterprises with a capital E who are used to signing multi-year software contracts.
I don't know much about CockroachDB's business, so I was just speaking in general about SaaS products and licensing non-open source software.
It seems cockroach was aptly named
It's honestly getting tiresome reading about yet another company that rides on the wave of open source for popularity and growth, but only for as long as it suits their own bottom line. Just like every other example, the page is filled to the brim with borderline unparsable marketing speak and, excuse my french, pure bullshit. Here's an example:
> we are updating our licensing model to better serve our diverse community of users
One could hope that whoever wrote this at least had the decency to blush while doing so. So here's what's actually happening, as I understand it at least:
CockroachDB used to be split into "Core" and "Enterprise". Core was Apache 2.0 licensed (open source), Enterprise was BSL (fake open source, "source available", bullshit). After three years, BSL code becomes real open source. This setup that they are sunsetting is already pretty restrictive, and is by no means uncontroversially "open source".
The New And Improved(tm) idea they have to "better serve" their "diverse community of users" is even worse: it's free as in beer to use, but other than that it's completely proprietary, and it also includes *mandatory telemetry* for non-paying users. Any reference to "open" in regards to this product is a complete lie, because being able to read the source code does not make a product open source -- Microsoft allows you to read their code too, if you sign a piece of paper with them.
I've never used CockroachDB, but I'm glad I saw this, because now I know there's a 0% chance I will ever consider using it.
> we are updating our licensing model to better serve our diverse community of users
One could hope that whoever wrote this at least had the decency to blush while doing so. So here's what's actually happening, as I understand it at least:
CockroachDB used to be split into "Core" and "Enterprise". Core was Apache 2.0 licensed (open source), Enterprise was BSL (fake open source, "source available", bullshit). After three years, BSL code becomes real open source. This setup that they are sunsetting is already pretty restrictive, and is by no means uncontroversially "open source".
The New And Improved(tm) idea they have to "better serve" their "diverse community of users" is even worse: it's free as in beer to use, but other than that it's completely proprietary, and it also includes *mandatory telemetry* for non-paying users. Any reference to "open" in regards to this product is a complete lie, because being able to read the source code does not make a product open source -- Microsoft allows you to read their code too, if you sign a piece of paper with them.
I've never used CockroachDB, but I'm glad I saw this, because now I know there's a 0% chance I will ever consider using it.
That's the problem with the term "open source". It is ambiguous and can mean anything from public domain to source available. If you just allow people to look at the source, you can call it "open source" and nobody can really argue.
If you did that and called it GPL, things would be different.
If you did that and called it GPL, things would be different.
It's certainly not ambiguous, but the reason why companies like CockroachDB and others would like to make it appear so certainly is obvious. Anyone confused can just be referred to "The Open Source Definition"[1] by the OSI.
[1]: https://opensource.org/osd
[1]: https://opensource.org/osd
that is one definition.
It's like saying "freedom".
reading this:
https://en.wikipedia.org/wiki/The_Open_Source_Definition
"the definition is the most common standard for open-source software."
It is not exclusive.
saying "open source" does not describe a license. It is a generic term.
And the point is that unless someone points to a standard or a license, they can call their software open source, just show you the source with restrictions and use ambiguity to do different things than expected.
It's like saying "freedom".
reading this:
https://en.wikipedia.org/wiki/The_Open_Source_Definition
"the definition is the most common standard for open-source software."
It is not exclusive.
saying "open source" does not describe a license. It is a generic term.
And the point is that unless someone points to a standard or a license, they can call their software open source, just show you the source with restrictions and use ambiguity to do different things than expected.
It’s not like “freedom” because open source software was a term invented only a few decades ago. Definitions that stray from this definition do so for a very obvious reason in every case I’ve ever seen, and that reason is profit.
You can’t just take a well established term and say “well actually I don’t agree” and don’t expect to annoy people. If you don’t agree with the ideas of FLOSS then use something else and call it something else.
As for your last part, the top answer of this SE question answers it nicely: https://opensource.stackexchange.com/questions/8367/is-the-t...
You can’t just take a well established term and say “well actually I don’t agree” and don’t expect to annoy people. If you don’t agree with the ideas of FLOSS then use something else and call it something else.
As for your last part, the top answer of this SE question answers it nicely: https://opensource.stackexchange.com/questions/8367/is-the-t...
I like this part:
"4. Does this mean CockroachDB is no longer open source?
CockroachDB will remain source available under a new license. While the new license is a proprietary enterprise license, the source code will still be available for viewing and contributions."
I mean... "The answer is kinda sorta 'No', but we really would prefer not to phrase it like that."
"4. Does this mean CockroachDB is no longer open source?
CockroachDB will remain source available under a new license. While the new license is a proprietary enterprise license, the source code will still be available for viewing and contributions."
I mean... "The answer is kinda sorta 'No', but we really would prefer not to phrase it like that."
Good on them for not mincing words and being upfront about this
Mandatory telemetry?
Friendly reminder that if you contributed code but signed a contribution agreement (which assigns copyright on the code contribution to cockroachlabs) you’ve got nothing to complain about.
Never sign contributions agreement: it will be used against you when the license inevitably get changed.
Never sign contributions agreement: it will be used against you when the license inevitably get changed.
at least should still cover a lot of businesses under the free tier
> Individuals and businesses, under $10M in annual revenue, can use CockroachDB Enterprise for free
> Individuals and businesses, under $10M in annual revenue, can use CockroachDB Enterprise for free
You just can't build anything new based on CockroachDB now, because the pricing for self-hosted is "Contact us". So if you build a product you'd need to contact them first and kinda guess how successful you'll be. Maybe it's fine and the license cost isn't a big deal, or it will completely ruin your business case.
Plenty of us have had to deal with this scenarios before with Oracle. Cheap or free to get started, then your product takes off and Oracle shows up and starts to demand their cut. I'm not suggesting that Cockroach is the new Oracle, but this type of licensing introduces a significant uncertainty into your future plans.
Plenty of us have had to deal with this scenarios before with Oracle. Cheap or free to get started, then your product takes off and Oracle shows up and starts to demand their cut. I'm not suggesting that Cockroach is the new Oracle, but this type of licensing introduces a significant uncertainty into your future plans.
They're following the Mongo playbook
Yeah no thanks, I'll stick with Postgres
Thank God I stuck with Postgres lol
another open source project has died. At least we will always have Postgres.
I'm not even going to read this, we all know what it is and we all know it's just the first step in a long series of very shitty changes, expect all new development to be in the "contact us" tier.
Ignorance was maybe excusable the first 15 times, but if you keep falling for corporate owned rug-pull OSS packages in 2024, you deserve what's coming for you.
Weird databases are NFTs for startup founders. You're not too cool for Postgres. Use it.
Ignorance was maybe excusable the first 15 times, but if you keep falling for corporate owned rug-pull OSS packages in 2024, you deserve what's coming for you.
Weird databases are NFTs for startup founders. You're not too cool for Postgres. Use it.
Can you please not post in the flamewar style here? It's not what this site is for, and destroys what it is for.
You can make your substantive points without it, so please do that instead.
https://news.ycombinator.com/newsguidelines.html
You can make your substantive points without it, so please do that instead.
https://news.ycombinator.com/newsguidelines.html
Sometimes it's a reasonable choice to pay for software, especially if you're a large company that can easily afford it. It's not like "just using postgres" in a manner similar to Cockroach's capabilities is trivial, building your own solution also has a whole set of risks.
If you're absolutely opposed to ever paying for a software solution, then sure, avoid commercial projects. I'm happy to spend my (company's) money on useful software.
If you're absolutely opposed to ever paying for a software solution, then sure, avoid commercial projects. I'm happy to spend my (company's) money on useful software.
Without marketing bs, what's something that can be done only with Cockroach and not postgres or other truly-OSS alternatives? I'm curios because I've been reading news about it forever but never had the chance to work with it
Maybe not cool, but you can, in fact, be both too big and too geographically distributed for Postgres.
This actually moves stuff out of the "contact us" tier, where it used to be, and makes everything available to all.
There are new hooks, but paywalling capabilities was not the point here.
There are new hooks, but paywalling capabilities was not the point here.
New hooks like disabling my database if the telemetry API call fails?
Per their announcement, it sounds like a free user will have to get an annual Enterprise Free license key to use it.
I'd hope that'd be automated, but could also be a "contact us" tier to audit revenue. Time will tell.
I'd hope that'd be automated, but could also be a "contact us" tier to audit revenue. Time will tell.
Another database fails to be better and ends up worse. This is why we use DAL agnosticism.
I always use good ol’ MySQL. If anything happens can hop to Maria
"Open-source" in 2024 is a synonym for "ransomware."
It's still nice that I can audit the code and contribute (unpaid) changes, but I no longer assume anyone is acting in good faith.
It's still nice that I can audit the code and contribute (unpaid) changes, but I no longer assume anyone is acting in good faith.
This is why you should look for software that calls itself "FOSS" or "Free Software" instead. Avoid CLAs at all costs as well. If the software is licensed under a GPL-like license without a CLA and has had significant contributions from multiple people, this relicensing rugpull is nearly impossible.
The Core offering made this palatable, one could fallback to Core features if the relationship with Cockroach Labs degraded, which made it possible to entertain the Enterprise license since there's was a way to walk back from it. But now there's no such mitigation available. By using non-PG native features, users of the Enterprise edition are accepting to get in bed with Cockroach Labs for effectively forever (databases), a single provider that has no competition.
I think this may backfire, as it now seems imprudent to go all in on Cockroach Labs. They may be nice folks today, but who knows who will run the place in 5y when the next round of squeeze comes?
I wish them the best, they're a great team and I always liked the project and toyed with it for years, and currently am involved with a paid Enterprise license. But this change in the dynamics is really giving me pause.
Getting in bed with a single vendor for an incredibly sticky tool comes with a _lot_ of risk. It took at least 17y for Amazon to get rid of its last Oracle database: https://aws.amazon.com/blogs/aws/migration-complete-amazons-...