Live data from Hacker News

Relicensing CockroachDB

cockroachlabs.com

191–200 of 290 posts

Re: Relicensing CockroachDB

#191

It’s interesting to see the mindset over here at HN change over the year. I recall when MongoDB introduced their “commons clause”, RedisLabs did the relicensing and ElasticSearch doing the dual license open source code, there was quite some outrage over here. I guess everyone is accepting that these clouds are in fact major threats to these projects, as providing these databases as a service is pretty much the only r…

They get a lot of credit in my book for keeping it open and not hiding anything behind enterprise / non free components. I think Elasticsearch for example left a bad taste in people’s mouths by adding enterprise only features for something as crucial as security features and mixed their OSS core with it.

Basically they’ve kept collateral damage to a minimum as far as I can tell, where as others haven’t.

Re: Relicensing CockroachDB

#192
I'm curious about the legal process of relicensing. Did they have significant open source contributors from outsiders? If so, did they have copyright assignment? And if not, then how valuable is it to them to be open source in the first place?

(Not trying to cause trouble; I admire Cockroach DB and its founders greatly! But I've watched open source struggle with this kind of thing for 20+ years and am increasingly curious about why businesses choose to open source their core technology.)

Re: Relicensing CockroachDB

#194
post #42

Earlier quoted context omitted.

How does this move disqualify CRDB as a dependency of other open source projects?

The majority of open source projects need to be usable without installing proprietary dependencies. Whatever you might think of CockroachDB's choice, this means that any other project depending on them makes their users deal with that license too, and while CockroachDB might be willing to push that on their users, that doesn't mean other projects want to follow them down that path and lose their users in the process.…

Presumably the open source package in question would just support the Postgres protocol, with cockroach being one option? What else are you envisioning there?

Re: Relicensing CockroachDB

#195
post #181

Earlier quoted context omitted.

> The underlying issue here in this one is that people (apparently so far!) want to use AWS/GCP/etc more than they want to use mongo, redis, cockroach, or any particular technology. There's nothing stopping people from using BSL-licensed software on AWS/GCP/etc., as long as they aren't running it for the purposes of offering a hosted version of that software. And Amazon/Google/etc. still really wants to offer hosted…

> There's nothing stopping people from using BSL-licensed software on AWS/GCP/etc., as long as they aren't running it for the purposes of offering a hosted version of that software. There is. This is no longer an OSI license, which means it's no longer on the automatic whitelist. Using CockroachDB now requires running through legal, which really makes me reconsider just using the hosted whatever offering, despite the…

that's kind of a "for now" issue. eventually these will become common enough that things will shake out, but it will take years.

Re: Relicensing CockroachDB

#196
The biggest thing that keeps me from even trying CockroachDB is that there's no clear licensing or managed server pricing on the website. It's all a sales funnel.

Of course, I don't mind and understand the license change. I just wish they were more upfront about pricing without being subjected to sales.

Re: Relicensing CockroachDB

#197

It’s interesting to see the mindset over here at HN change over the year. I recall when MongoDB introduced their “commons clause”, RedisLabs did the relicensing and ElasticSearch doing the dual license open source code, there was quite some outrage over here. I guess everyone is accepting that these clouds are in fact major threats to these projects, as providing these databases as a service is pretty much the only r…

> I recall when MongoDB introduced their “commons clause”, RedisLabs did the relicensing and ElasticSearch doing the dual license open source code, there was quite some outrage over here.

My problem with "Commons Clause" was never with the terms of the license, it was with the naming. If a company is finding open source licensing is posing an obstacle to the success and survival of their business, that's regrettable, but at the end of the day, they have a broad legal right to adopt whatever licensing terms they wish, and they have a legal duty to do whatever they believe to be in the best interest of their shareholders and employees.

Calling such a license "Existing Open Source License name with Commons Clause", however, is in my view deceptive naming. It makes it sound like it is the same thing as the existing open source license, possibly with some extra rights added; in reality, the "with" is taking rights away. (Also, when the existing license is Apache, it causes confusion with the Apache Commons project, and makes it sound like the overall license is approved by the Apache Software Foundation, which isn't true.)

CockroachDB isn't doing this. They aren't using any deceptive or confusing naming for their new license. And, they are committing to revert each version to an open source license three years after its release. I think it's regrettable the business climate forces them to do this, but (unlike the whole "Commons Clause" business), I'm not complaining about it; and I think that given they've decided to do this, they should be commended for the way they've gone about it.

Re: Relicensing CockroachDB

#198

Earlier quoted context omitted.

The problem with this argument is that there has always been a before and after. IE This is not the first business model issue OSS has dealt with. For example: It seems ridiculous now, but at one point authors were significantly squeezed by commercial distros offering support and feature work directly to customers for their packages. (And this was even a similar kind of disintermediation applied to authors as you see…

You're completely missing the point. The point isn't to stop AWS from integrating. The point is to get a slice of the pie if AWS does decide to do an integration because now, with the new license, AWS needs to come to them first and ask for a license, which I'm sure they would give with reasonable terms.

This fantasy of getting the VCs their money from Amazon rather than non-existent customers is not going to play out as they want. If we assume Amazon are evil, they won't hand over a slice of the pie they'll just write a replacement. So no integration, no money, and no users. But at least it's not the fault of "Open Source" I guess.

Re: Relicensing CockroachDB

#199

Earlier quoted context omitted.

The problem with this argument is that there has always been a before and after. IE This is not the first business model issue OSS has dealt with. For example: It seems ridiculous now, but at one point authors were significantly squeezed by commercial distros offering support and feature work directly to customers for their packages. (And this was even a similar kind of disintermediation applied to authors as you see…

You're completely missing the point. The point isn't to stop AWS from integrating. The point is to get a slice of the pie if AWS does decide to do an integration because now, with the new license, AWS needs to come to them first and ask for a license, which I'm sure they would give with reasonable terms.

Indeed. If AWS makes a load of money out of Cockroach's hard work, why shouldn't Cockroach get a slice of it?

Re: Relicensing CockroachDB

#200

This is pretty interesting, I'm thinking about how edge cases will be handled. Consider a product like Airtable: at present I think most people would classify it as a consumer productivity tool. Firebase on the other end would be a platform as a service. Airtable is adding features that make it more of a platform as a service. I wonder where the line will be drawn for the new BSL.

(Cockroach Labs founder) The details are in the "additional usage grant" clause: https://github.com/cockroachdb/cockroach/blob/8acfe8ffd0028c... We decided to draw the line at whether the end user has direct control over table schemas. If users can specify the schema to be used, it's a database service and needs a license. If you're fitting everything into a generic schema (even if the user can specify things that lo…

I'm surprised everyone is saying it's clear, because I think it's sort of vague, so maybe someone can talk me out of it. :)

If I build a service that lets customers define object types by dragging form widgets, and I turn that into a CRUD app backed by CockroachDB, and they just get to pick a CSS template and occasionally get Excel dumps, are they controlling the schema? They don't write any SQL, they certainly don't ever type or see the words CREATE TABLE, but internally I create a table for each of their types with a schema generated from their input, does that count?

Someone else asked about hiring a sysadmin consulting service. If I go to them and say, "Hey, my consulting firm will install and maintain your production servers, pay us $N/hour for routine changes and $kN/hour to page us," but they have their own developers who write code and can cobble together dev infra if needed, can they choose to use CockroachDB? In my reading of the license, they have the right to make it available to us as their contractor, but we don't have the right to download and install it and make it available to them for them (or us!) to run their CREATE TABLE statements on.

(I appreciate that edge cases are hard, and that while "just leave it open source" provides easy answers to these questions, it obviously brings other difficulties that you care about avoiding!)

Post reply on HN