This is more validation of the threat that cloud providers (mainly AWS) are to businesses built around open source products. Yes, AWS and others are legally permitted by existing open source licenses to create SaaS versions of these open source products, but with cloud computing becoming an increasingly winner-take-all market, it leaves little room for the software's authors to generate revenue via hosted offerings of their software. 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.
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 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)
> 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 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'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 issues.
Hasn’t happened for GPL3, and I would bet it won’t happen for these either. More importantly, the one-click solutions offered by amazon, GCP, etc. will always be the GPL2/MIT/etc licensed products, while the others will require you to either install and manage on your own, or sign up separately outside your main cloud provider. This will be an additional point of friction (potentially more so than the licensing woes).
I wouldn't be so sure of that. For AWS it is risky to not support popular platforms, because it gives their customers a reason to move elsewhere. AWS is not the only cloud provider around (and certainly not the cheapest). There is a reason they developed an alternative to MongoDB instead of just saying "sorry, we don't support MongoDB because of license". They couldn't buy a license from them because that would set a bad example (they are not really fond of these alternative licenses) and they probably didn't want to maintain MongoDB codebase (before relicensing), so this was the only solution left.
> The only way this backfires is if Amazon creates a clean-room CockroachDB workalike and offers it as a hosted service.
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.)
> 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.
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.
There's another angle to it post-license-change: AWS Cockroach continues tracking the latest release and pays a licensing fee for the privilege of doing so. Your costs to use it might go up a tiny amount, but AWS would likely eat most of it, and, bonus: CockroachDB's development gets more funding.
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.
> 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 failure rate for all projects is pretty high, though.
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.
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.
They're using the BSL now. If they cared about revenue protection, they shouldn't have opened it in the first place.
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.
> 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.
Something similar was discussed a few weeks ago with respect to procps [0] and the struggles of maintaining Open Source projects.
Is there a way to encourage AWS/GCP to contract major project maintainers for support? For example, could GCP set up a platform where maintainers of Postgres, Redis, ..., could sign up to be paid monthly, and perhaps to prioritize GCP issues when doing maintenance?
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
I agree with that and it is one of the main reasons why I personally don't care for Open Source and make a huge distinction between it and Free Software.
Free software has the exact same problem here. You can be 100% free software and still have VC funding you. For the context of this discussion, they're the same.
There is essentially no difference between Open Source and Free Software, though people who prefer one label over the other tend to have different ideologies. In practice essentially everything that is recognized as Free Software by the FSF and the broader Free Software community is likewise recognized as Open Source by OSI and the broader Open Source community, and vice versa.
The difference is the focus, the one is focused on developers (and businesses) the other one on users. Which to me makes a huge difference to where the licenses used evolve, like we see in this article.
Exactly, customers want services that solve problems, not software that they have to operate.
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.
I mean what the heck are they going to do when one of these tech giants pulls a Oracle and buys the whole project out? I'd much rather see Microsoft have taken MySQL over than Oracle. It's sad that I trust Microsoft with OSS projects more than I would most tech giants, well not sad because it's Microsoft, but sad because somebody like Google used to be seen as a good tech giant that worked on OSS, but then they extended and extinguished (Android, Chrome, Email, AMP so on).
> 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.
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.
Depending on the licensing cost and the effort required to integrate the project with their infrastructure, it might be cheaper for the provider to fork the last version before the relicense and support it going forward. Maintaining API/wire-protocol compatibility isn't that hard for large tech companies these licenses are trying to battle. I don't think these open source companies are not aware of the risk of forking, but they are between a rock (AWS/GCP) and a hard place (VC returns demands).
> Depending on the licensing cost and the effort required to integrate the project with their infrastructure, it might be cheaper for the provider to fork the last version before the relicense and support it going forward
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.
I disagree. Services are worth far more than software. That's what cloud/SaaS is all about. AWS is rising to meet the demand by customers paying lots of money to have their problems solved, not worry about software licenses and operations.
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 article specifically mentioned that the integrations AWS can offer between services simply cannot be competed with by any single company, no matter how good that company makes their own hosted product.
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.
One difference is that AWS etc. can run software on bare metal if they want. (I suspect they are doing just that with their hosted Kafka offering.) Even with the new EC2 bare metal instances, I don’t think you could roll your own for a competitive price (IME packet.net is much cheaper than EC2 for on-demand bare metal, with a much better UX).
But you're essentially saying if you want to compete with AWS, you have to offer every feature and integration they offer. Good luck to any startup attempting that.
I wonder if a startup opportunity exists to be a B2B only provider that has all the infrastructure trappings of an AWS or Google Cloud, but never selling directly your services on the open market, but instead selling your services contractually to other businesses (in a sense, not sure if my terms are lining up here).
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.
It doesn't make sense for the DB vendors to pay someone else to run a white-labeled managed service for them. It's a source of revenue so they would actually want to be paid for the license and get revenue share from the operator running the managed service.
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/
AWS doesn't really offer that much between all their products and those integrations are all done over public APIs anyway. Many of the new features they release are just automating away things that people previous hooked up themselves.
I don't see why a startup would have such a problem with it, especially when they control the software as well.
Is the hosted service going to have the global network of data centers that the generic cloud provider has? What are the chances that the unprofitable maintainer is going to stay in business? If they are acquired, what are the chances that the acquirer is going to run the service well and not just kill it?
Seeing that neither Redis Labs nor Mongo are profitable, they haven’t quite “figured it out.”
They're offerings run on the same clouds, often within your own cloud account or peered to it. They're providing a managed version of their software product, not building a cloud from scratch.
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.
Redis labs doesn’t run on all regions / cloud providers sadly. I’ve asked (begged) them to support GCE in Europe for a while now... even not all AWS regions are supported as far as I’m aware.
Supporting multiple cloud providers is much less trivial than it looks like
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.
Now with Kubernetes, deploying to and maintaining self-hosted services to your own baremetal instances/servers is very easy but OSS solution providers need to provide the Kubernetes .yaml files.
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.
It'd be interesting if there was a way to specifically require AWS, Azure, Google Cloud (or more generally any cloud hosting reseller) to pay if they use the open source software or any derivative of it (or if they create any company which then uses it) for the purposes of reselling it to others.
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.
>, but it may be interesting to create a new license to protect against this for new OSS projects.
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.
And even if you have some tech advantage, it still needs to compete with 0 cost license + increased infrastructure (since licensing dollars can now be spent on more hardware; 30% more hardware is hard to beat).
I understand what you mean and totally agree with you, I just feel the need to remind (not to you) the term free software, as many things are open source but not free software [1]
> I understand what you mean and totally agree with you, I just feel the need to remind (not to you) the term free software, as many things are open source but not free software [
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.
How many engineers can be paid from $100MM revenue?[0] The *aaS company might be better served by employing engineering team to maintain their fork/API-compatible clean-room implementation a-la Amazon Aurora.
0. If company is profitable and licensing costs > overall salaries + monetary value of controlling roadmap.
> It'd be interesting if there was a way to specifically require AWS, Azure, Google Cloud (or more generally any cloud hosting reseller) to pay if they use the open source software or any derivative of it
I think from a practical perspective this makes sense but having to change their licenses makes me sad. I don't want to see licenses change from "you can do whatever you want with this" to "you can do whatever you want with this unless you are competing with us".
> but with cloud computing becoming an increasingly winner-take-all market, it leaves little room for the software's authors to generate revenue via hosted offerings of their software.
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.
I’m still not sure why people open source great products then get outraged that someone else would simply resell the product and make money off of it, possibly even more than them.
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.
Doesn't seem reasonable to compare how you feel about open sourcing personal projects to open source software that a company builds and relies on for revenue. Open source is amazing because it allows all of us to share knowledge and build things better than any of us could build individually, and I LOVE that. When a goliath like AWS comes along as abuses OSS to make money off of someone else's work without contributing back (either with money or code) they're not operating in the spirit of open source and they're potentially making it more difficult to successfully run that company (which IS contributing software to our community). That's not cool.
Does everyone who has contributed to this project over the years have a say in this decision? My code itself will also be relicensed, whether I like it or not.
You actually have the right to appeal that decision, because you own your contributed code. (unless you already agreed in advance through a Contributor License Agreementt.)
> I’m still not sure why people open source great products then get outraged that someone else would simply resell the product and make money off of it, possibly even more than them.
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."
The outrage is mostly driven by companies that took millions in VC money. VC-fueled open source would always need to find a way to monetize, and "bait and switch" by changing licenses is a tried and true strategy.
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 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 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.
Imo the key difference here is that they're owning the decision and not trying to paper over the fact that it is no longer OSI Open Source.
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.
My point is that they are able to own the decision only because the public opinion has accepted it as a new reality. If CockroachDB was the first OSS database company to do this, they would have a much harder time explaining their rationale. MongoDB et al have paved the way for them.
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.
Could you expand of what it is you don't like about this change?
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.
I disagree with your assessment that people are more acceptable. I think it's just more along the lines of the people that care are "over it" and have learned their lesson now.
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.
Part of it is that companies are getting better at it. There is no attempt at confusion over what "open source" means in this announcement, and automatically converting to open source in three years is clever.
GCP just started offering Postgres v11 in beta in April and it was released on 2018-10-18. They skipped v10 (released October 5, 2017). Comparing to Postgres, three years feels like the right balance (i.e. in the zone a cloud provider would want to offer it).
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.
They're still having enterprise features. The formerly open source core is now using this new non-free (in the sense of FSF or Debian free software guidelines) license, but they are not dropping their enterprise add-on.
I don't think people think it's a good idea, it's just that:
1. CockroachDB isn't nearly a prolific as Elastic/Redis/Mongo
2. There's not much new to say that hasn't already been said
So people don't care as much, less impact, less outrage.
Agreed. I disagree with the change and have made my comments in the other situations about taking the good with the bad when you give something away. Just no need to keep harping on it, doesn't mean mindset has shifted.
It's a good move and I even welcome it. However, I would have loved to see the removal of their enterprise version of the product at the same time.
I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore feature, which is currently locked behind their enterprise version. I also would love to use CDC and table partitioning.
Nevertheless, great product.
Never used CRDB so this question may make no sense, but given it builds upon Postgres (AFAIU), couldn't you use any of the many backup solutions Pg offers?
CRDB is compatible with the PostgreSQL wire protocol, so you can use existing database drivers (in C#, Golang, whatever) to talk to a CRDB instance. The SQL itself is slightly different (no two databases are the same these days), so that would have to be adjusted.
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.
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
Not unless you like pain. CockroachDB is distributed and uses Raft consensus under the hood, so you can't take a snapshot of just one node; you need to take a snapshot of all the nodes in your cluster, and you need to take those snapshots at the same logical instant. If the snapshots are from slightly different moments, when you boot the cluster up from the backup, the nodes will panic because you'll have corrupted the Raft state or otherwise caused the multiple replicas of the data to become inconsistent with one another.
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.
CockroachDB is a proprietary database built in Go using RocksDB for the storage layer. It just uses the PostgreSQL protocol so it's compatible with existing drivers and applications but the underlying tech is entirely different.
Making a project that was Open Source, not Open Source anymore, is hardly a "good move". I mean, it might be a good financial move for Cockroach and their VC's, but I have a hard time seeing it as good for the world in general.
If it helps with increasing resource allocation to the project it can be a good move for the world as well. Currently resource allocation is sponsored by VCs, but this can't continue forever.
For the world in general, indeed, it is better than having a dead or hardly-maintained project (which needs financial incentives from project owners). Don't you agree?
I don't really think increasing the world's stock of proprietary software is something to laud. Still, with their "switch to Apache after 3 years", I guess that this is still, on balance, better than nothing.
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.
> 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.
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.
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.
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.
Recently discussed with somebody at a major cloud provider and IIRC their response was in essence “I think we’re doing them a favor: ask Neo4j about our release of [hosted graph database service]. We’ve taken a share of their business, but the overall market is much bigger, and they’re doing great. Our hosted products are not even the most polished in the market, and companies like Elastic can easily be compete with us.”
Yes, some cloud providers readily suggest competing with them by making something better. In the end, the DB is still running on their infrastructure (required to keep the customer's latency low) and they are still capturing profit even if it is not as much as their DBaaS profit.
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.
Years ago I heard the same from a Postgres-contractor friend who said amazons ready-to-go (now RDS, but iirc, back then just MySQL; I don’t recall the service brand name - maybe also RDS) SQL service was welcome, because it sucked. Its not clear to me though that 1) it would stay “sucky” 2) users would make the distinction my friend did.
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.
Sure. Amazon Neptune is garbage, but that's not the issue. They are competing fair and square here. The problem is when they fork <insert liberally licensed open source project> completely.
CockroachDB is an excellent project but it doesn't have the massive adoption that would prompt AWS/Azure/GCP to implement it as a managed service.
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.
Why would this undermine their efforts? It seems totally reasonable to say "You can't just sell a hosted version of this yourself". Anyone who was planning to use Cockroach still can, it even seems that you could be a CockroachDB shop that provides consulting services, so long as you don't manage and host it.
Simply because if I'm using CockroachDB and don't want to manage it myself, my only option is Cockroach Labs.
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.
Quick question : my company uses a "devops as a service" partner. Basically we pay a monthly fee to have their guys on call 24/7 in case something starts to go wrong. Additionally they update and manage our kubernetes cluster, installing and setuping any dependency we require. From our point of view, we have a fully managed kubernetes cluster.
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 ?
I'm not a lawyer or in any way speaking for Cockroach Labs, but the Additional License Grant in their license looks to allow "contractors" to do that kind of thing. It's you or your lawyer's call as to whether you're safe in your scenario, but it seems to me that the answer is yes.
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.
It is a high risk business model to be entirely dependent on negotiating a license with a single vendor that you are competing against.
For MongoDB there are vendors that will keep offering managed MongoDB. I talked with one that is open-sourcing their deployment as required by the MongoDB license. I suspect that no companies will start a new hosted MongoDB offering based on purchasing a commercial license from MongoDB and we already saw the biggest alternative MongoDB provider merge with MongoDB.
Good point. We shall wait and see how that turns out.
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.
Companies don't relicense on a whim. It is plausible that they might have got wind of a big player readying to offer their service, and proactively tried to defuse the threat.
Over in PostgreSQLand ... Tom Lane is an important member of the PostgreSQL core team and also was involved in the PNG image format (and other graphics related efforts).
Something that came as a surprise to me was the fact that QEMU and FFMpeg are made by the same guy as well.
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.
It is nice to see that CockroachDB's team keep their original vision of creating a long term open source "commons" of their database.
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.
"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."
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.
So they're taking their product proprietary. They're not the first to try this move. They won't be the last. It never works.
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.
3) The cloud provider forks at the version under the previous license, continues to iterate on it by adding valuable features that are exposed to users, which the OSS version won't have, and now the OSS vendor is playing both marketplace & technical catch-up at the same time and with each reinforcing the downside of the other. Effectively forcing original innovator into the position of being a fast-follower.
No. In that case, AWS built and released new Apache licensed, 100% open source extensions for Elasticache to make essential functionality like TLS encryption and authentication available to anyone. It did not fork Elasticsearch, it released a collection of software that works with the OSS core version of Elasticsearch.
Disclosure: I work at AWS on EC2, and sometimes provide my opinion on open source topics to other teams.
While I understand the move (similar to what Redis Labs, MongoDB, Confluent and many others have done recently), as one of the many contributors to these projects not affiliated with any company, it feels like a slap in the face. If such licenses gain prominence then having a healthy open source community for large-scale projects will be a thing of the past. As an outsider, it makes zero sense to be involved in the project if my code isn't really going to be open source until 3 years from now, and that can be delayed further or indefinitely if the company wants.
IMO the best way forward is for such projects to be run by non-profit foundations, not VC-backed companies.
I'm curious about this take. If I'm reading the article correctly it appears if you did not have plans to turn the software into a managed service this has no practical impact on you. Personally, for every open source project I've contributed to if this license has been in place rather than an open source one no one would have been impacted at a practical level (including those doing it professionally).
Aside from purely ideological concerns, what about these changes do you think will kill communities?
I think it's a combination of ideological and practical (and in some sense they aren't all that different). If they changed the license once, they can do it again. As a for-profit company they are obligated to their investors and shareholders, and at some point it is inevitable that they will find ways to start charging those who want to self-host as well.
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.
Hang on. Are you saying that you make a practice of contributing to open source software products of for-profit companies?
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?
Wait, Cockroach Labs accepts external code contributions? How are they able to pull the rug out from under you and relicense the code without your consent? Did you sign a CLA giving away your rights?
Well played cockroachlabs. I find it awkward being an AWS user and knowing there products are something else under the hud, even when they do use the product name. It leads to user lock in, which is what they want. These addendum to licenses are what the world needs. Not sure it would work for certain products, like BSDs though, although they seem to get a lot more back from those who use them in products (Netflix is a good example)
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.
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.
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!)
Here's another one: if I run some website that's backed by Cockroach and has its own source code available publicly for pull requests (think Reddit until a few years ago, etc.), and one of my customer sends me a pull request that changes a schema in order to implement a feature they care about, does that count?
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.
As a startup founder and CTO who has had to deal with getting (or not getting) such licenses through legal, I really appreciate the clarity of definition here. Typically the language tends to be vague around "derivative works as a service" which conservative lawyers treat as a risk.
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.
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.
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.
As far as I can tell as part of POC downloads for open projects they always use either MySQL or Postgres if they are going to use a relational database. Cockroach seems to be in a good place here as you can just substitute Postgres for Cockroach.
Presumably the open source package in question would just support the Postgres protocol, with cockroach being one option? What else are you envisioning there?
Among other reasons, most open source projects expect their dependencies to be things they can interact with like they're open source. It's one of the reasons OSS support for Windows is poorer than support for OSS platforms, despite Windows as a whole being far more popular. This might be close enough, in that developers can install it on their own, you can put it in CI, etc. But it's a barrier.
So the open source community is about giving free labor to Amazon?
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.
No, the open source community is not about giving free labor to Amazon. But that's not what we are talking about. We are talking about members of the open source community taking free labor from the community and then pulling back on the open source promise. As someone in the same boat, I'd hate to see a project I contributed to change it's license to something that limits how the applications can be used. If something is licensed as MIT, I expect it to stay MIT.
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.
That is a valid point. Of course the question is, how big the contributions from the random people were. Judging by the list of contributors [0] a relatively small core contributed most, but I wasn't involved at any point so this is not a reliable assessment.
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.
Not really. The limit is clearly defined (if you are using it as DB, there is no change). If you allow users to create schemas, then it's a different thing, but I'm guessing there is no such project.
Open source is great, open everything is great. But if 99.9% of companies can't make any money on open source because someone big swoops in ... then open source isn't of much use to anyone. It'll drive everyone who tries, out of business or into forced acquisition by said big player. Then people will give up on OSS for anything but hobbies and software they don't care about... and the world as a whole loses out.
CockroachDB has raised over $50M of Venture capital which obviously pushes them on the "grow revenue fast" track, which is much easier if you do not have competition from the cloud vendors.
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
Can outside contributors to CockroachDB get a cut of the licensing revenue? I mean, if cockroachlabs is upset that people are taking their open source code and making money without giving them a cut, should they also be upset that they are taking people's open source contributions to that code and not giving them a cut?
Hm, wasn't one of the conditions to use BSL (the name of the license) that one of the "Change licenses" must be GPL?
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.
Good for CockroachDB, they need to make money. I understand I'm not their target user though, I stopped using them when they released Follower-Reads as an enterprise feature.
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].
> I stopped using them when they released Follower-Reads as an enterprise feature.
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.
I'm not necessarily exhausting the physical capacity of a single datacenter to expand to another datacenter, I may expand early or from day one to run queries closer to the user even if the workload is a few seconds behind. I don't think Follow-the-workload works well for that scenario.
this seems like an excellent licence, clearly spelling out the intent of the copyright, rather than trying to fashion a one-size-fits-all set of rules. it reminds me of cory doctorow's point that, intuitively, if some community theatre wanted to dramatise one of his works, they should be able to just do so, but if a major hollywood studio wanted to film it they should require a licence, and it is hard to draft a copyright law that does this properly.
As the link says:
The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service without buying a license
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.
Do bad actors get to hold good actors to the good actors principles? This seems unsustainable and a recipe for disaster, ie tolerating the intolerant whose objective is to gain power and stamp down on dissent and impose their own values.
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.
The "API" you are referring to is known as SQL, transmitted over the wire using the pgsql protocol. There's nothing to copy. The magic of Cockroach is in the implementation.
Yes, it is indeed a little puzzling. CrB's biggest benefit is to people not interested in engineering their own scaling/sharing solutions for existing RDBMS options or if they care about optimal resource utilization (under a certain subset of conditions), neither of which are particularly draws for the AWS team. Perhaps they are more worried about other vendors.
Smart move and I really hope the BSL can be used by others outside of Cockroach DB either in its current form or as a template for a similar license. This is badly needed in our industry to protect innovators from rent seekers.
This is really tough. I really want the redis and cockroachdbs to make money, but on the other hand I don't want to give my customer data to everyone. I give them reluctantly to AWS because, well, I guess at least one company has to have them, and while they are probably not perfect, I reasonably trust them to keep the data safe, but I'd really rather keep this to one. We could run the software on ec2 and pay a licence (we occasionally do that) but when we don't want to maintain things ourselves, we always turn to AWS, which saddens me a lot
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.
I'm all for businesses coming up with whatever licensing terms they want. That said, as a user, it'll be a harder sell if I can't easily understand or validate what the license permits and doesn't.
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?
The way I understand it, the whole idea of this relicensing is that you can no longer take someone else's work and build your business competing with them. So no, you can't do that. Seems fair enough to me.
Right, but now there's this ambiguity about what counts as competing. And that ambiguity sounds like a risk to business, which opens a door to potential liabilities if CockroachLabs were ever to believe you are competing. That in turn makes CockroachDB a harder sell to management.
True. Though in this case it's very admirable how cleanly they have specified the exception case. But yes, it is a harder sell, and this is the main issue that these licenses must solve if they want to be successful.
This is not the best way to compete with Amazon. The believe that their feature set is enough of a differentiator is probably delusional. CockroachDB does "massive scale SQL without manual shading". BSL won't hinder Amazon offering those features too.
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.
I estimate the odds that AWS Aurora will offer "massive scale SQL without manual shading" in the next 3 years to be >95%. Then why would anyone want to to use Cockroach? They need to differentiate on something else. Ideally something that Amazon is unwilling to do, or would find very hard to do.
Amazon may be unwilling or unable to be multi-cloud. Companies worried about being stuck in a silo may think twice if they have a more convenient option.
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.
The #2+ cloud vendors are hungry for marketshare, so they're showing signs of multi-cloud already (and already global). A bit reductive, but CRDB is now in an arbitrage game: will Google/MS/IBM/Oracle/Baidu/... pay $200M-$1B to buy them ($50M is a lot on the cap table), or they somehow pull off a rev share similar to "Azure Databricks" that they can bail before it goes to zero / find something more differentiating long-term.
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!
Amazon is generally averse to multi-region integration for reasons of fault-tolerance, so I doubt they are going to offer a fully geo-distributed DB any time soon.
lol. True, but not much to differentiate on that unfortunately, unless they're able to point out something fundamentally wrong with the Amazon platform.
Sure is. I didn't mean a product that Amazon can't do, but other factors that Amazon would likely be unwilling to do or find very hard to do. For example, offering high-touch support, or having a great UI... Or being an open source champion! Lots of things that Amazon is likely incapable of doing in the near future.
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.)
If community patches are licensed under MIT or BSD, all CockroachDB has to do is include those license texts in their proprietary distribution, which is the only requirement by both licenses. Proprietary derivative works are allowed under MIT and BSD.
That's not how it works. Each commit is a "derivative work" of the last. If today a codebase is licensed under MIT, tomorrow you can change a single line of code, and this produces a brand new work under US and international copyright law. You can license this work under any license, provided you comply with the MIT license of the work that has been derived.
They already have - Amazon has Aurora, which has MySQL and Postgres compatibility. I'm sure if there's enough demand, Amazon will add CockroadDB compatibility to Aurora in the not-too-distant future.
> Which lags behind upstream in versioning and 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.
I think it's still the majority of developers that first deal with databases outside a cloud environment and then want a managed version of it in their environment (which btw, Amazon does offer in RDS Postgres/MySQl, but it's their forks that have these problems).
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.
Could someone say just take a normal open source license, like MIT, and just add a provision saying, if you are Amazon, Google, Microsoft, this license doesn't apply to you and you are not permitted to use the code in any way?
Basically, just blacklist certain companies that compete with you directly.
It's still not free/open/libre source anymore, because you are discriminating against someone, so it's not in-line with the set of freedoms as defined by both OSI and FSF.
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.
Sure - except that under their definition of freedoms you are allowed to share software with anyone, so while you can sell it to the first person, they can freely share it with anyone.
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.
But the other option is that the license is made more restrictive for everybody. So at least that way, it is still open source for me, and a lot of other people, but not for direct mega competitor with too much leverage.
I know, it's a choice of two evils, and I don't know what's best.
A blacklist would not be very effective. The companies you list could contract out the running of the database to someone who isn't blacklisted, or even just another company that they own.
Yes, but it would be a stupid thing to do because you have cut off a major chunk of contributors to your project, especially if they were interested in using it in the first place.
Even if cloud providers give back more than they take, there nothing legally stopping them from stealing an open source project as their own. The Business Source License (BSL) seems like a good reaction. What Amazon did to confluent.io and so many others seems pretty cold hearted.
Quicksort is an algorithm, a copyright on it would not hold up, but a creative use of it may hold up. Kafka is not part of the public domain, but available through an open source license, that AWS is arguably exploiting to make some money off the back of open source contributors.
True, but for all intents and purposes, it's basically public domain with some attribution clauses and litigation indemnity:
"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."
Since "Redis" and "Redis Labs" are mentioned multiple times among the comments, here is my gentle reminder that Redis is BSD licensed, and only additional modules provided by Redis Labs have a different license.
I wish them well but fear this won't work out for them. This sounds like a smart move until you realize that they are just one of many players in a crowded market and that this actually decreases their value proposition for end users and external contributors. Having less of both is bad news for an OSS project, no matter how you spin it.
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 really like this company, and their developers. Solid tech vision and the actual tech chops to pull it off.
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.
TBH, I think _renaming_ CockroachDB would do it more good than relicensing. All other things being equal, I think it is safe to say that nobody wants any cockroaches in their infrastructure. I think it's also safe to say that few people know in detail what CockroachDB is, and its name creates additional friction to more people figuring it out. If you disagree, call your next database project TurdDB or something and see how it does in the marketplace. Names matter.
Call it something high-tech sounding and inoffensive. Now that it has some notoriety it no longer needs a controversial name.
> or embed it in their applications (whether they ship those applications to customers or run them as a service). They can even run it as a service internally. The one and only thing that you cannot do is offer a commercial version of CockroachDB as a service
Great so I will write a little shim that loads libcockroach and call it TermiteDB and I'm set.
Intent matters in the law, and judges see right through transparent attempts to evade the spirit of agreements on a frequent basis. They aren't stupid.
Maybe a good time to change the name as well? Funny names are cute and all but if you want to gain mainstream acceptance for your database product CockroachDB is not the one I would have picked.
Downvoters: if you think names for products do not matter you are mistaken.
> if you want to gain mainstream acceptance for your database product
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.
The belief that names are particularly important to corporate software adoption and that CockroachDB is a good name for such a purpose is probably pretty rare.
I don't care one way or the other about the name. But if you're marketing directly to engineers who want a resilient solution, there's probably an argument to be made.
I think it would be a bad name for a consumer product but this isn’t a consumer product. CockroachDB invokes a feeling of resilience which is perfect for marketing to engineers.
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?
I think this needs to be added to the guidelines as a flame-bait topic. Every single CockroachDB post devolves into bickering about whether it is a good or bad name, and I can't stop thinking about that one episode of the Dilbert TV cartoon[1]
