Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CockroachDB license change

cockroachlabs.com

Post reply on HN
Print view View original

401–410 of 476 posts

Re: CockroachDB license change

#401

Post by valyala »

999900000999 wrote: post #396
valyala wrote: post #383

Earlier quoted context omitted.

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 o…

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 ta…

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/

Re: CockroachDB license change

#402

Post by franckpachot »

bcantrill wrote: post #206
turtle_heck wrote: post #27

Earlier quoted context omitted.

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…

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.

Re: CockroachDB license change

#403

Post by JackSlateur »

ted_dunning wrote: post #158
ThinkBeat wrote: post #71

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

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.

Re: CockroachDB license change

#404

Post by swiftcoder »

orthoxerox wrote: post #355
swiftcoder wrote: post #323

Earlier quoted context omitted.

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.

Re: CockroachDB license change

#405

Post by remram »

immibis wrote: post #318
ted_dunning wrote: post #147

Earlier quoted context omitted.

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…

[flagged]

If you're trying to say something, say it, and point to proof. I don't know where to even find what you are trying about.

Re: CockroachDB license change

#406

Post by Spivak »

bcantrill wrote: post #206
turtle_heck wrote: post #27

Earlier quoted context omitted.

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…

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.

Re: CockroachDB license change

#407

Post by PeterCorless »

redwood wrote: post #273
bcantrill wrote: post #206

Earlier quoted context omitted.

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…

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?

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.

Re: CockroachDB license change

#408

Post by statusgraph »

leeoniya wrote: post #297
AYBABTME wrote: post #28

I understand the goal, and the perceived abuse of the Core edition. But the problem with the Enterprise edition is that it's quite expensive, "contact us" salesy, and it feels like taking a bite of this edition is possibly getting into bed with a future Oracle/landlord type of relationship where you end up squeezed by your database vendor. The Core offering made this palatable, one could fallback to Core features if…

> 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,…

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

Re: CockroachDB license change

#409

Post by hnarn »

m463 wrote: post #338
hnarn wrote: post #334

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 commun…

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.

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

Re: CockroachDB license change

#410

Post by redwood »

PeterCorless wrote: post #407
redwood wrote: post #273

Earlier quoted context omitted.

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?

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.

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

Post reply on HN