Hacker News Reader

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

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

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.

No, it's fairly inherent; the OSD is very well aligned with the considerations that would support whitelisting licenses that adhere to it.

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

"That's a really extreme way to think about this."

I would argue this is probably how most CTO's think about it unless forced at gunpoint to do otherwise.

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.

That, and if it was going well they wouldn't have relicensed.

Just like parachutists who open their reserve chute suffer more injuries than ones who don't :)

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.

What is less sure is that AWS would come and ask for a license, instead of cooking their own to get customers more locked-in to their platform.

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.

Yep. The warning shot was GCP for these startups, not AWS.

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

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

They should have thought about that before benefitting from it being open source.

> They should have thought about that

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.

I can see where you’re coming from, but the work of the community is still (and forever) under the license that was in place when they contributed.

Someone could fork CoackroachDB and continue working on the open source license.

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

[0] https://news.ycombinator.com/item?id=19936320

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.

Cockroach Labs took $53M in VC: https://www.crunchbase.com/organization/cockroach-labs

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.

They could hire them.

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.

Many authors are still squeezed out on support. RedHat is the breakaway winner there.

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

To realize why licenses like GPL exist, instead of pushing for non-copyleft licenses.

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.

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