Relicensing CockroachDB
cockroachlabs.com
cockroachlabs.com
Basically give the open source project a 30% cut if you're going to resell it (or fork and resell it). It might be hard to do now since with AWS since with ES Amazon just forked whatever version was already permissively licensed, but it may be interesting to create a new license to protect against this for new OSS projects.
[1] https://www.gnu.org/philosophy/open-source-misses-the-point....
Open Source and Free Software are, as your link points out from the latter side, divergent ideologies, but they aren't substantively different in terms of concrete meaning when it comes to licensing. It is absolutely not the case that “many things” are Open Source but not Free Software, though many projects producing software which is both Free and Open Source adhere to only one of those ideologies, at least as the projects dominant ideology.
I believe the correct term for those licenses is "shared source" not open source.
Well, you also have to take the game theory of incentives into account.
Let's say you develop a new database called NextGenCockroachDB with a required 30% royalty license. That type of license will alter the behavior of people evaluating it and may very well prevent it from being adopted at all. If there's no critical mass of the market using it, the 30% royalty becomes a moot point.
The whole market of choices available to economic participants has to be analyzed. If potential buyers have an option to substitute a db with 30% fee with another open source db with $0 license, they will be incentivized to avoid paying 30%.
If an open source db requires royalty payments from cloud platforms, it will need to have amazing technology that nobody else can duplicate.
Once your company surpasses $100MM in revenue you have to negotiate licensing terms.
0. If company is profitable and licensing costs > overall salaries + monetary value of controlling roadmap.
No, such a requirement makes it not OSS.
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 now - people only cared what they got from redhat, not from the original author)
One interesting constant is that most of the projects that felt a need to change licensing to react to business model issues over the years are dead ;) . Not all of them, mind you. But the failure rate seems really really high.
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.
No license change will fix that. In that case, AWS actually controls your customer more than you do. Unless something comes along that is "better enough" that people are willing to buck AWS to use it, this approach of relicensing fails.
(and the customers certainly don't care about your licensing scheme)
> No license change will fix that.
Well, perhaps not a licence change, but if it's good enough that it's The One the provider wants, but it can't offer it under the terms of the licence, then paying for it under a separate licence could be a win for both parties.
e.g. AWS creating OpenDistro for Elasticsearch and adding core elastic stack functionality for free (Auth/TLS/Alerting) by integrating and adapting existing OS components.
This would have the benefit of allowing GCP to continue offering all the open source databases, which is great for gaining customers who already use these popular tools.
For the scale of the required exit, they would need a very large support contract, and at that point it would be easier for Google / Amazon to just build their own solution, hire their own people to provide support and development, or just let market forces do their thing.
The fundamental shift now is that a lot of open source software is on shaky ground, having been built by VC money searching a profit. This is the same force plaguing NPM and the JS community. The piper must be paid at any cost, even if it means compromising the open source part of the project
The failure rate for all projects is pretty high, though.
Just like parachutists who open their reserve chute suffer more injuries than ones who don't :)
Something similar was discussed a few weeks ago with respect to procps [0] and the struggles of maintaining Open Source projects.
That's a really extreme way to think about this.
Consider this example: I lose 1 Utility Point for every new provider I need to contract with, set up monitoring for, set up billing etc. This balloons to losing 2 UP if that provider's in a different public cloud, but since many let you choose an AWS region, this is probably not a problem. I gain 5 UP from using Cockroach, because it saves me engineering time. And I gain 1 additional UP from using latest Cockroach because they're making real optimization breakthroughs.
So pre-license-change, AWS Cockroach that tracks the latest release might net 6 UP, and Cockroach Cloud run by the company might only net 5 UP because of that cost of a new provider.
But post-license change, Cockroach Cloud would be tied, because now I'm comparing the cost of a new provider against the cost of latest developments. And every single blog post I see about Cockroach developments pushes me in that direction.
It's a really great move, though kind of a loss to open source. I wish the Cockroach folks the best.
I would argue this is probably how most CTO's think about it unless forced at gunpoint to do otherwise.
It's hard to put a price tag on knowing that an open source project your business depends on is well-funded enough that it's unlikely to disappear or be difficult to support.
They should have thought about that before benefitting from it being open source.
They have thought about it! That's why they are using the BSL.
I note that they are using a time-delayed open source approach (after 3 years it becomes open source) which I understand Stallman has endorsed in the past.
Starting an open source project, taking contributions from the community and getting popularity and traction because you're open source, and then closing it again because you're so popular Amazon might "steal" your revenue? That's just abusing the community.
Someone could fork CoackroachDB and continue working on the open source license.
Clients rarely care what backend is actually running, which is why the clouds can offer the same APIs like Postgres and MongoDB backed by their own custom software.
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 CockroachDB, they can purchase a license, which helps fund development, and would probably be a financial rounding error to an outfit like AWS.
> Unless something comes along that is "better enough" that people are willing to buck AWS to use it, this approach of relicensing fails.
> (and the customers certainly don't care about your licensing scheme)
I think you're misinterpreting how this license works and what it actually restricts, or you've overestimated the number of users this will affect. Most customers don't have to care; for the common use ("I want to install CockroachDB on AWS/GCP/my own server and use it as a data store for my product"), the licensing change is immaterial and they can use the software in the same way as they could when it was Apache-licensed.
The only way this backfires is if Amazon creates a clean-room CockroachDB workalike and offers it as a hosted service. Even then, it's not a slam dunk: for example, I'd very much prefer to run redis myself on bare EC2 instances than use AWS ElastiCache, as the latter just generally doesn't meet my availability requirements. I've also once migrated a service from redis to DynamoDB and had a terrible experience during and after, so switching to a theoretical workalike isn't without its costs and risks.
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 issues.
Or offers a managed service of one of the open source products competing in the same space. Or acquires one of the existing proprietary alternatives and offers it as a managed service. Perhaps even while paying Cockroach’s license fees, offering the most popular hosted Cockroach, and still encouraging customers to shift over time to lower-cost alternatives (Amazon already does this with Windows and SQL Server; no one trick pony first-party SaaS platform is going to be anywhere near what Microsoft has deployed against AWS.)
We are slowly getting back to the shareware and PD days, specially since many kinds of FOSS applications are hard to monetize, e.g. desktop apps.
Elastic is an exception though, I think Lucene would be a better addition to that list.
I trust the creator to run a hosted service better than a generic cloud provider, but most don't which is a failure of their own making. A few companies like Redis Labs and MongoDB have figured this out but most are still stuck writing code when customers are asking for managed services. I don't know why they don't adapt.
The APIs are all public. The company can build whatever integrations they want to offer. For example, many already use EC2, VPCs, S3, Lambda, Kinesis, etc. to extend their databases into a client's architecture, and it's no different than what AWS provides.
If this is a million dollar idea, I'm just going to give it away I guess, so here goes nothing in explaining it!
Imagine an AWS/Google Cloud like company that only sells B2B, so Cockroach for instance, could pay this company to host their own cloud offerings, plus sell through other cloud offerings of the said B2B service but under their marketing umbrella. The B2B service gets a nice chunk for administration et. el plus some fixed percentage of gross (maybe? i dunno what it'd look like).
I think if you contractually obligate yourself as a business to never sell cloud services directly (only via partners like, in this instance of theory, cockroachDB, but it could redis, mongo, whatever), it'd be a fairly stable and comfortable arrangement.
Could also be a way for other SAAS companies to buy into infrastructure without indirectly funding a potential competitor too.
Maybe its too complicated to achieve, though.
There are several companies that do managed services like Aiven, IBM's Compose, ObjectRocket, etc so it's possible for them to get involved like this... and it looks like ObjectRocket just did that for CockroachDB: https://www.objectrocket.com/managed-cockroachdb/
I don't see why a startup would have such a problem with it, especially when they control the software as well.
Disclosure: I build EC2.
Seeing that neither Redis Labs nor Mongo are profitable, they haven’t quite “figured it out.”
Vendor management is a different issue. There's always a risk but if you cant trust any companies smaller than AWS then none of this applies anyway.
Even multiple AWS regions is not that simple, as some other comment mentioned, not all services are in all regions (or are available but at a lower reliability level)
I'm not saying it's trivial, but if they managed to support it across several AWS (and GCP) regions, then I'm not sure what's stopping them for expanding to others. I would imagine it's more of an ROI issue rather than a technical limitation.
In any case, I don't mean to diss Redis Labs. Quite the contrary. I'm keen to see them expand to other regions so I can use their services.
For my OSS project, I include the k8s yaml files in the project repo along with a simple CLI script to make it even easier to deploy. Scaling a service on K8s is very easy if the service is was explicitly designed for K8s.
There simply has been no time where a startup doing SaaS of open source software (whether it's own or someone else's) had a strong route to profitability; this isn't an emergent property of evolving market conditions.
It's perhaps being acutely recognized because there was a particular time when companies started around open source software and, either initially or after a period with no clear business model, adopted “we’ll do SaaS of our core open source offering” as the whole, or a central piece, of their business model, and pretty quickly realized why, despite hosted SaaS being a commercial reality longer than cloud computing has even been an idea, SaaS of a particular open source software product—while sometimes part of the business of a broader SaaS provider—has never been a common successful standalone business model supporting companies centered around the open source offering, and certainly not for company is looking for the kind of growth modern VC-backed startups hope for.
They like to spin stories about AWS being predatory, evolving conditions in the cloud market, and attacking open source, but the real issue isn't with AWS, or cloud computing except insofar as that happens to the modern place where hosted SaaS is found, but that they've adopted a combination of SaaS-centric business model and growth expectations that would never have been realistic with open source software (and which I suspect they will next discover isn't much more realistic with their new relatively liberal proprietary license model either.)
> If you think that the Cockroach Labs, Redis Labs, Mongos, Elastics, etc., of the world provide a net benefit to the software world, I think you have to contend with the fact that there is going to be fewer such companies in the future if AWS keeps eating their lunch.
Software that serves as underlying infrastructure for other software has value to end-users that is with reduced by risks associated with being proprietary, and but also has value to it't is reduced by the non-exclusivity that exists when it is not. That's fairly obvious, and an intrinsic problem for such software being efficiently provided in a basically capitalist system, but unless one’s ideological preconceptions make it difficult to accept that capitalism may not always be as perfectly efficient as it would seem to be in theory under the kind of ideal assumptions sometimes encountered in Econ 101 classes, or unless one has invested in firms without business models which ignore this dilemma, I don't see how that is anything to “contend” lwith.
When I put something out as open source, I’m doing it fully aware that I am leaving money on the table, but it will be worth it if a community of maintainers springs up around the project and ends up making it far better and more useful than I ever could alone. Then I could use that same project perhaps to do other things, which may lead to better money making opportunities.
CockroachDB tried something. It seems to not be working- so they are changing. It's not as if they are doing it retroactively.
You can't do this retroactively.
Perhaps I didn't look at the right comments, but I'm not sensing outrage from the community.
The vibe I'm feeling is, "Bummer, that's another approach to funding OSS development that's having trouble. I hope we can find a good alternative."
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 realistic way to get decent revenue numbers.
I think it’s good that CockroachDB is preemptively doing this, now that it has become more acceptable a practice.
I don't see anything to object to, do you?
The three year change is also a big deal in my mind. Would make me a lot more comfortable to adopt knowing it is absolutely guaranteed to become OSI Open Source later.
Cockroach also have the benefit of hindsight to avoid some of the problems Mongo/Redis et al encountered.
Calling this a "Business Source Licence" avoids the terminology problems so many people complained about with Mongo's perhaps badly chosen "commons clause" rider on top of (and fundamentally changing) a well know open source license.
I think the rolling three year time limit is probably a smart reaction to some of the complaints people have about other companies attempts to tie down some of the rights while providing assurance that there's at least be an option open in the future no matter what happens to the company.
I wish them well with this.
Without having read and fully understood the actual text of their new license and comparing it to the old one, if we take them at their word where they say "The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license." - I find it pretty hard to find anything to "not like" about it... Perhaps the ideological purity of "open source" is being disrupted here (I suspect Stallman isn't a fan of this), but from a pragmatic perspective, it gives me all the rights I need to use it in any way I choose, except to exploit project without contributing back via a license.
So people don't care as much, less impact, less outrage.
Basically they’ve kept collateral damage to a minimum as far as I can tell, where as others haven’t.
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.
Those that genuinely care about the free software movement either have or will stop contributing to these projects and stop signing CLA's[1] so their work can't be abused in the future (turned into a proprietary product).
I personally don't think there is much more to argue about.
If your backup solution is fine with "SELECT * FROM table1; SELECT * FROM table2; ..." you can use the client interface for backups. But usually you want to a snapshot of the entire database at some (self-consistent!) point in time, and back up that.
There is one safe way to make this work: turn off your cluster, back it up with ZFS snapshots, then turn it back on. (Some of Cockroach's production tests do exactly this, in fact, because restoring from ZFS snapshots is so unbelievably fast.) But if you have the flexibility to power cycle your production database off and on in order to back it up... you probably don't need a distributed database, because fault tolerance likely isn't among your requirements.
(I'm a former CockroachDB engineer.)
This is actually super simple to do in Cockroach, as it supports time travel queries - https://www.cockroachlabs.com/blog/time-travel-queries-selec...
So you can run a script at, say, 12:05 AM every morning, saving the table state “AS OF SYSTEM TIME 12:00” (simplifying syntax). And thereby get a fully consistent snapshot of all tables, as long as your backup script takes less time to execute than the configured table TTLs
What I reject is the idea that the only choices are "make this kind of switch" OR "having a dead or hardly-maintained project". Sounds a bit "fallacy of the excluded middle" to me. But they have the right to license their thing however they want, so what right do any of us really have to complain. I just find it frustrating to see people retreating from an Open Source position given my own deeply rooted ideological bias towards F/OSS.
In general, that's of course obviously true. For software like this, that's geared toward use by businesses and SaaS applications, I agree with Cockroach Labs. Their hosted solution doesn't stand a chance if AWS decides to do a hosted version of CockroachDB, and they won't see a penny of that revenue. Since contributions outside of employees of Cockroach Labs are pretty minimal, it's a textbook recipe for eventual project death.
> But they have the right to license their thing however they want, so what right do any of us really have to complain.
Correct. And yet that doesn't seem to stop some people...
> I just find it frustrating to see people retreating from an Open Source position given my own deeply rooted ideological bias towards F/OSS.
I get that, and at some time in the past I probably agreed with you. At this point I'm too cynical to believe that Free Software can succeed solely on its merits. The economics just don't work out, especially when you're in a part of the industry with a lot of competition.
And regardless, the new licensing terms are (in practical terms) identical to Apache for the vast majority of people who already use or might use CockroachDB. All they're restricting is the ability to create a Cockroach DB hosting business, and if you really want to do that, my moral position is that you should be financially contributing back to the DB anyway; otherwise you're taking freeloading to an extreme degree there.
I understand why this is the default assumption that people tend to make, but I'm not sure this analysis goes deep enough. I believe things are more nuanced than "you can't compete with Amazon". There are always a lot of different axes on which you can segment a market, and different attributes on which one can compete. And ironically, the fact that AWS (and other public cloud providers) exist simultaneously makes it easier to run your own cloud based service. And yes, it's possible to have something hosted on AWS while Amazon compete with you at the same time - see Netflix for the obvious example.
Note that I'm not saying it's easy to do any of this, and maybe a thorough enough analysis would reveal that, for CockroachDB it really is the case that "we can't compete in a market where AWS is playing". But I wouldn't necessarily take that as a given without having done a lot more research.
Why? You offer no explanation.
I think it is a good middle ground, it has a very targeted restriction and reverts back to Open Source after 3 years.
Thoughts?
There is a problem though that a DBaaS provider is still at an inherent disadvantage. You aren't in the AWS/GCP cli tool and APIs. And the DBaaS has to setup VPC peering across accounts, which has some inherit limitations (e.g. no DNS resolution on GCP).
actually you do not need DNS resolution on GCP since you can actually have a high available IP way easier (which is way better). in AWS it's also possible to have a highly available IP, but it's way harder to do so.
I’m worried it’d play out where Amazon would vacuum up the “low end” part of the market and the “high end” would further have to be competed for, because Joes Expert RDBMS Service v Amazon.
Companies are much more likely to just go with AWS Aurora than to consider CockroachDB at this point.
I'm still amazed as how promising open source projects continue to undermine themselves with this "commons clause" movement. I hope something good comes out of it but I'm pessimistic.
While they are experts in the technology they've created, offering a managed service is much more than just having awesome developers. Not to mention some companies have other restrictions (on premises, local presence, etc, etc, etc).
For a customer, unless I'm completely sold on their technology and really need it for my company, they just added a restriction on my choices.
I don't think this is the case, a third party can provide hosted CockroachDB provided they license it from Cockroach Labs.
>"The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license."
Again, IANAL.
Right now their sales chat can't say how much that would cost.
It seem an alternative could be to provide something like a cPanel-like thing that would enable other companies to easily offer CockroachDB DBaaS solutions. That's adding value rather than subtracting.
Their new license doesn't forbid others from offering a managed service. It simply requires the managed provider to pay them for a license. AWS, GCP, etc can still create a managed service.
Cockroach Labs is not your only option; you can also use other providers that have a license agreement with us. Our first partner in this area is ObjectRocket: https://www.objectrocket.com/blog/cockroachdb/introducing_co...
Financially, we pay AWS for EC2 instances and other expenses + them on top of that for consulting service, they have root access to the cluster. We do not have any devops/infra guy in the office.
Would they be allowed to install (and manage) CockroachDB on our cluster if we need to ?
Kind of depressing; either one of those projects has that person set for life in the job market, and that jerk has both! How am I supposed to compete with that?
EDIT: Just a note, I say this with all the love in the world, and certainly wish no ill-will towards Fabrice. I hope my dumb joke above didn't come off as hostile...I think it's pretty cool that one person was able to build two apps that I use daily.
What I don't totally understand when I take my developer's hat is why the split between "enterprise" features under CCL and core features under APL/BSL is kept. Without the "enterprise" features, CRDB does not feel like beeing totally open source and open source users are sort of second-zone users.
Are open-source fans supposed to write clean-room implementations of the features (would it even make sense in the licencing model CRDB uses) ?
It would also be nice to have a licencing clause where a change of ownership of CockRoach Labs or the bailout of the company would trigger a licence change for the enterprise features (maybe even after N years).
But as I said congrats on the product and all the best in your commercial endeavour ! may this licence change open new cloud opportunities !
If you want to get paid, then create proprietary software and sell it, if you can. Nothing wrong with doig it.
But if you are developing something you call open source software and you use GNU/Linux for it, then how much money should GNU and Linus get for you doing that?
You could go with Windows insteand and pay the licensing fee.
Here we have people building things on a foundatino of free and open source software, and they feel that they should get paid for the slice that they built, but are they themselves paying every party that was resposible for creating the stack on which they are working? I think usually not.
Everyone is quite happy to accept the free work done by others but they miraculously expect to be the person getting paid.
Now RedHat took GNU/Linux and figured they ought to get paid for creating a packages, a bit of an eco system around their version and sell support and such. Was that fair?
AWS offering some service, are basically doing hosting and support on the product. A lot of people trust AWS/Google/Microsoft to run things in the cloud for them.
Nothing is stopping me from creating ThinkBeat Linux and charge for support. Probably I would do very poorly because people now trust RedHat or Linode, AWS to handle issues around Linux for them.
I dont think if you create a new database managment system that ou think is great, users will flock from Azure/AWS/GCP/Oracle/IBM to pay you for hosting it for them. You are too small and too risky. Obiouvlsy some people will sign up and if you can earn money you need on that then good.
The problem with these discussions is they always set up this false comparison. Then, what's going on looks hypocritical. Here's what actually happened:
1. Linus et al released Linux with a license that says, "Pay us nothing. Just give back any changes in code you distribute." That's their goal. Those with permissive licenses said "Use it and don't share anything unless you want to." That's their goal per the license agreement.
2. Cockroach Labs started with a goal of making a huge pile of profit on a database whose core they keep as free and OSS as possible. The profit takes priority due to VC funding. That's their goals.
Cockroach making profit on Linus et al's work without paying them isn't hypocritical since their license's actual goal was to do that. Whereas, the SaaS vendors are posing a challenge for Cockroach achieving their goals which require making money off their activities. Balancing giving code out as OSS and profit-seeking, they lightly-modified a license that starts as proprietary but goes Apache after 3 years. Personally, I think they're being way, way, too altruistic given what rate of return they're expected to come up with.
If anything, people that wrote their dependencies using freeloader-loving licenses are either achieving their goal of commercial uptake or need to pick a license that incentivizes their goals (or just blocks things they hate). If contributors, probably should contribute to software with strongest copyleft available. AGPL and Parity come to mind. Folks using licenses that don't require payment shouldn't expect payment. If folks want payment, then they should sell the software somehow with licenses worded to bring in revenue.
This change guarantees one of two outcomes: 1) CockroachDB becomes irrelevant, as cloud providers stop providing it, or 2) a FOSS implementation of CockroachDB's API (perhaps based on the last FOSS CockroachDB release) becomes dominant.
Disclosure: I work at AWS on EC2, and sometimes provide my opinion on open source topics to other teams.
IMO the best way forward is for such projects to be run by non-profit foundations, not VC-backed companies.
Aside from purely ideological concerns, what about these changes do you think will kill communities?
The second part of this is that a large number of open source contributions come from employees at large software companies while on company time, and they aren't going to be allowed to do so any longer if the company isn't happy with the licensing terms of the project.
Those are companies with plenty of VC money to pay you a salary. Why would you give your work to them for free?
Maybe I misunderstood what you wrote, but then if I had, why would it bother you that a company like this changed its business model to close an unprofitable loophole?
If Airtable uses cockroachDB then that's fine. The issue is when the cockroachDB is the product that the customer pays for.
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 look like new columns in the UI), it's an application and doesn't need a special license.
Well done.
We at TimescaleDB spent a lot of time thinking about how to best express this dividing line in a manner concretely understandable by engineers. Glad to see others starting to take a similar approach.
I wish you all the luck on this endeavour, I really believe the time has come to move a bit away from strict open-source.
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!)
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.
I've been an OSS user and contributor since the middle 1990s and I very much welcome these moves. SaaS has been getting a free (in the unfair sense) ride without contributing in any way.
Furthermore, the presumption that users of the software are now required to contribute back flies in the face of the agreement.
I'm not against people using a license like this. It does however seems a slap in the face to change the license after benefiting from the fact that you are releasing an open source product.
tl;dr: It's a bait and switch, and dislike it.
[0] https://github.com/cockroachdb/cockroach/graphs/contributors
No, that's exactly what we are talking about. The threat of big cloud players swallowing up the SaaS model that powered opensource to the current highs, is very real. Until Amazon and friends were mostly interested in powering the low-level bits, it wasn't a big deal; but now they are moving up the stack and pulverizing the small businesses that drive the OSS ecosystem. That is a problem.
The AGPL was supposed to protect against this sort of play and it really isn't, for various reasons. Personally, I welcome the attempts at innovating in this area particularly when they are clearly well-intentioned like this one.
> I'd hate to see a project I contributed to change it's license to something that limits how the applications can be used
Unless you've waived your rights, you can exert your copyright and block any such move.
Should have thought about it beforehand.
Leaving aside any license compatibility issues, an open source project with a proprietary dependency will lose users compared to an open source project with entirely open dependencies. This also causes problems for some Linux distributions.
So... :+1:
I think there is so much black and white positioning of this issue - competition from AWS does not eliminate revenue for the project, but reduces it, by a lot. It may not be enough for Open Source company which relies on heavy monetization
I remember distinctly because while I liked BSL, I never understood why I couldn't use AGPL as fallback (which would be much better suited to my use case).
EDIT: It seems I was wrong:
> To specify as the Change License the GPL Version 2.0 or any later version, or a license that is compatible with GPL Version 2.0 or a later version, where “compatible” means that software provided under the Change License can be included in a program with software provided under GPL Version 2.0 or a later version. Licensor may specify additional Change Licenses without limitation.
So Apache is OK, because such software can be incorporated into GPL app. AGPL is not, because it places additional restrictions.
I'm back to Postgres for now but I can't stop thinking about the opportunity CRDB is missing by not releasing the enterprise features as part of the BSL-licensed core, that way I can use them from the very beginning(when I have no money) and when I grow and have traction, money and what not, then I can pay to scale beyond X amount of nodes/capacity a la MemSQL[0].
[0] https://www.memsql.com/blog/announcing-memsql-free-tier/
I read Cockroach Labs’ strategy to be good on single nodes, great on single-datacentre cluster, phenomenal worldwide.
They offer single-DC features open-source, and worldwide enterprise-only.
Apart from SQL features, their open-source cluster offer seems superior to PostgreSQL. Sure, they do not have follower-reads, but neither does PG (which does not even have AS OF SYSTEM TIME, a prerequisite), and it is only beneficial with multi-DC.
Reads are still distributed by range, so there is no particular negative compared to Postgres.
Why was Follower-Reads a dealbreaker?
1) Is CockroachDB actually popular? Like sure they have a couple big users, but is it gaining traction?
2) Would it be as popular as it is if they'd started with this license from the very start?
This is dishonest and deceptive. One other thing you cannot do is use their code and incorporate it in your open source project.
They used to provide an open source parser for postgres' sql syntax. Now it is closed source for 3 years.
I don't mind the license change. Lying however is not a good way to behave with customers or open source communities.
I like the idea and would support initiatives like this. If i really want to use CockroachDB then i'll install and maintain it myself on my own instances. In the long run this would also ensure that if i want to move away from AWS to another provider, i am not locked to an AWS service.
Similarly If you do not believe in open source can you hold anyone else to account by the principles of open source? And if you are committed to open source do bad actors need to be given the same privileges that are extended to everyone else? Do they get to play the 'principle' card that they themselves do not adhere to?
Cloud providers are profitable and the work of these app developers arguably has a role in their growth and profits. AWS, GCE and others are solving all their business problems. Why should it be so difficult for them to build a mutually beneficial relationship with open source projects? Or the pipeline of projects they can use breaks down.
If they just want to take without adhering to the spirit of open source, then playing the open source card whenever confronted seems too self serving.
https://www.google.com/search?q=mongo+db+capitalization&oq=m...
How much a SaaS has to do to not be consider as selling CockroachDB as is?
These questions apart is worth noting that AWS can still copy CockroachDB APIs, rename it AWS Ants, and called it a day.
They have actual managed Postgres with RDS for Postgres, and also a Postgres-compatible (SQL dialect and wire protocol) version of RDS Aurora.
If I understand it correctly, you can get Redis Enterprise Cloud, deployed on AWS. So, it's running on AWS, and it looks like they manage it.
That sounds to me like they are making an effort to meet your needs, of having it running on AWS (their FAQ mentions making sure that the AWS AZs are in sync), but not maintained by you.
For example, with their new license, could I fork cockroachDB, rebrand it, add considerable improvements of my own, and then offer that as a service? Or what if I'm not offering cockroachDB as a service directly, but the service I'm building and offering as a service can still be argued to be some sort of data-store?
If you were to do that, even with current licenses, you probably couldn't call it CockroachDB anyway.
If CockroachDB remained OSS, there would have been a chance of Amazon offering Elastic CockroachDB eventually, and at least make the Cockroach brand more popular. But now it will likely be an Aurora feature.
If you want to compete with Amazon, do something Amazon cannot do.
... run it somewhere other than Amazon?
Just saying there's definitely a market for a database I can run.
If their feature set isn't a good differentiator from other databases, then their company isn't going to succeed in any situation.
This strategy is CockroachDB doing something that Amazon cannot do.
Besides, crdb does worldwide SQL databases now, and the only competitor at that level is not Aurora, it is Google Cloud Spanner, at a much higher price range and with very limited options.
Once every top infra team at MS & Google realized they can be a saas/paaas revenue center, not just saving 1% in internal costs, that made the whole "Google for everyone else" VC funding wave feel like musical chairs.
It does feel like a good ("least bad") move given the environment. We have taken an "embrace" approach to using/contributing to OSS and assuming commoditization of database+compute tech (Apache Arrow, Nvidia RAPIDS, ...). We've wanted to further open most of our code, not just those libs, so we're not the only ones writing funny distributed GPU webapp+etl stuff... but couldn't find a way that made sense so far. So, I've been watching with great interest, and good luck to the teams involved!
That doesn't sound like competing
(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.)
Which lags behind upstream in versioning and has its own quirks.
Or Redshift, which is still stuck in Postgres 8 and absolutely has its own quirks.
No doubt re-implentation will lag and will not be perfect (either buggy, or not buggy enough to match reference). The big question: is it AWS users shopping for DBs, or MySQL/Postgres/CockroachDB users shopping for *aaS services? I suspect the former outnumber the latter, and they will likely tolerate being behind the bleeding edge.
And being behind the bleeding edge is problematic at least these days that databases are incorporating great features, but the bigger problem is incompatibility and subtle differences. Those are the truly annoying issues.
CockroachDB managed service is available today - you can sign up on the website and we'll get in touch with you https://www.cockroachlabs.com/get-cockroachdb/ We will release a self-service offering where you can set up a managed cluster without having to talk to us later in the year. Re: pricing, we have different packages based on # of nodes, and size of node (storage, vpcu etc.) and happy to share that in a call.
Basically, just blacklist certain companies that compete with you directly.
Whether this matters to you or not is another question, of course... :)
> A free program must offer the four freedoms to any user that obtains a copy of the software, provided the user has complied thus far with the conditions of the free license covering the software.
It's unclear what "obtains a copy" means. You could make it that certain companies are not allowed to "obtain a copy", and thus if they do, it is through illegitimate means.
For example, it goes to length to say Free software does not mean gratis. So I'd suspect it would claim that if software is sold, and you pirate the copy instead of paying for it, you have broken the conditions of the free license. But if you paid, and a copy is delivered to you, from that point on, the four set of freedoms are granted to you over the copy that was given.
So, I can see something where, it is gratis, but obtaining the copy is not granted to everyone, but only to some, depending on if you're a potential competitor or not. And that seems like it could still fall under that definition of Free Software.
But truly, I don't think looking for holes in definition of freedom would help anyone. The question if, do these definitions achieve what we have set out to do, and in what way? If yes, great. If not, maybe the time has come to define another set of freedoms, which still protect users better than closed source, but allow developers and maintainers to make money from their creations. And yes, they will not be open source, so we might as well come up with a different term.
I know, it's a choice of two evils, and I don't know what's best.
Most open source projects are not given to the public domain, but encumbered with clauses in the form of their license.
"Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form."
The way I see it this type of company has a short term value that derives from them being first (more or less) to market with whatever it is they do well. In this case, their thing is having a sharded/clustered db that can replicate across datacenters and with serialized transactions.
Awesome, that's a great thing to have and it will take other databases a while to get there. But they will eventually and that matters. This stuff commoditizes quite rapidly. It's based on published research by Google half a decade ago and people can look at the source code and algorithms. It's just a matter of time before somebody else figures out how to replicate what they do in some other product. Somebody like e.g. the postgresql developers: https://tapoueh.org/blog/2018/07/postgresql-concurrency-isol... and https://pgdash.io/blog/postgres-11-sharding.html. It's probably not perfect yet but they are obviously heading the same direction and there's a notion of good enough and diminishing returns.
When it does catch up, it all reverts to which is the best product in the market. Part of that is features but another part of that is a robust developer community and having access to robust support and hosting options from multiple companies. A failing VC backed company that controls the code base and treats it like a walled garden means that community is only as good as that single company behind it, i.e. not very good. It simultaneously repels potential users and contributors thus slowing down adoption and development speed while increasing the R&D burden for the single backing company to not fall behind any further. They can't win that game.
In a nutshell, postgresql does not have that problem and it never will. Mysql doesn't have that problem either. Both developer ecosystems consist of collaborating frenemies that work together because it is better than not doing so. Both provide pretty good database solutions with plenty of hosted solutions (including Amazon and other cloud providers), commercial support via several companies, etc. Also both are pretty much guaranteed to continue to have active development for as long as there are people willing to sell their time doing that and there are so many companies using both that there is just no way that that would change within the next few decades or most likely this century. Essentially all of the current companies behind both could go bankrupt and all that would do is create an opportunity for new companies to step in and take over.
I don't like the drama that seems to surround it.
This post is just one more vote in the "this company has a lot of drama associated with it", and that to me is always a giant blinking warning sign.
Without knowing anything about them (though I do), at this point, I would bet this company flames out eventually, fails to get further funding, and institutes yet another license change to milk the dying cow while the talent flees for greeter pastures. Best case they get acquired by Microsoft, worst case Oracle (I'm sure their users would love that). Or just fade away.
Anyway, my $0.02. I hope I'm wrong.
Call it something high-tech sounding and inoffensive. Now that it has some notoriety it no longer needs a controversial name.
Great so I will write a little shim that loads libcockroach and call it TermiteDB and I'm set.
Downvoters: if you think names for products do not matter you are mistaken.
What would you have picked, master namer? What criteria determines what the mainstream will accept? "Mongo" seems like a bit of a funny name to me, but they seem to be doing alright... What makes Mongo okay but Cockroach not?
Apple is a cute name. Does it pass your test?
Disagreeing with your particular opinions on a particular name doesn't imply a belief that names don't matter.
They've been around for several years and have had millions of dollars in funding. If you're going to argue that their name is holding them back from mainstream acceptance, first you should establish that they don't already have that.