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-...

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 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.

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.

it's all volunteers/open source, but this isn't an ASF project.

Yuk.

It is a trap to condem the foundation because of some people who are nasty outside the foundation

If they were enabled to stand in the way of Mahdi Islam, or their mates participating then there would be a problem

We have a problem in tech with naive fascists and fascist enablers. We must deal with it, but condemning the person, not the behavior, is not the way

Mahdi Islam is made up

A similar but opposite problem is pushing back too much on things that don't matter. E.g. a core python developer and inventor of Timsort just got a 3 month suspension for liking a comedy skit that used the word "slut", and for thinking that it's possible to discriminate against white people.

At first the behaviour should be condemned. If the person refuses to change the behaviour, the person is now at fault for choosing the behaviour which they know to be condemned.

In my opinion, Stallman has been proven right many times over.

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 can see it has some disadvantages for companies incorporating GPL software in their products, but none for companies merely using GPL 3 software.

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.

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.

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.

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.

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'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.

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.

Otherwise it works great for end-user adoption.

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 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'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.

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.

And is also subject to survivorship bias. For every OSS project that makes it, tens of thousands do not.

It will be even worse after the GPL developer generation is gone.

Sure 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.

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.

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

There are still native shops that rely on very little open source, though at this point probably only in niches like gamedev or defence.

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.

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

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.

Their FAQ says "all software free no exception" and this document says something weaker.

> 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".

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.

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.

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.

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.

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.

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.

People who value attention over principles are known as "pick mes" apparently.

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.

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.

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.

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.

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.

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."

What you say is true in that you shouldn't view a VC backed opensource offering as 'permanently' opensource by the same group.

Many things would have to be re-added from scratch in a fork.

> 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...

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.

As always: “If you have to ask, you can’t afford it.”

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.

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.

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.

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.

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.

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.

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.

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.

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.

I agree it’s a reasonable license. But it’s not an open source license.

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.

As to the specifics of SSPL, I personally don’t see the rationale for accepting AGPL but not SSPL.

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.

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.

    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.

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?

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.

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.

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 they do not. Individual GNU software projects might require it, but this choice is up to the project, not the FSF.

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).

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 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.

> 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".

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.

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.

Would be far easier to recommend CockroachDB if it were more competitive with Planetscale.

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.

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.

For example, planetscale charges 3x as much per gb of storage if I read the pricing correctly.

I remain curious about the perception that cockroach is a meaningfully more expensive product. Where does that idea come from?

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).

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.

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

Just to clarify - FoundationDB was never open source before 2018. Binaries were available under certain conditions, but no source.

(so much misinformation in this thread, this isn't hard to check)

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 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/

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.

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.

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.

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/

Consider me skeptical.

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...

That is incredibly short notice.

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.

It's just an arbitrary number

So not just a license change