You are being too cynical.

Their argument is, more charitably: "We built this, we released it for free. Our business model is professional support and hosted services. In order for us, the creators of this software, to continue building it, we cannot allow megacorporations to freely spin up a loss-leading competitive service and cut us out."

Some observations:

(1) It's interesting how much of the reasoning/argumentation for these restrictive licenses ultimately comes down to a more articulate form of "but that's not fair!". I also wonder how much the implicit beliefs that "unrestrained capitalism is a bad thing", "markets naturally lead towards monopolies", "antitrust law is legitimately necessary", etc are impacting peoples' reasoning here.

(2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault. AWS' managed elasticsearch offering is absolutely terrible, speaking from experience. They block access to important APIs like `reroute`, any minor cluster change results in a whole blue-green deployment which very frequently hits a race condition that prevents the newer cluster from ever coming up healthy, requiring a ticket to be filed that takes multiple days to respond to if you don't have premium support, etc.

So functionally the idea that AWS is going to fleece them because they'll offer a just-as-good service for cheaper has not been the case. Elastic co's managed offering is simply far superior.

---

Ultimately, Elastic has shown that they don't actually want to release FOSS. They want to release proprietary software, and that's why the (in hindsight very easy to foresee) usecase of a cloud provider offering a managed service angers them so much. They don't really breathe the FOSS mindset, because a true non-restrictive license (BSD, Apache 2.0 etc) means that a company can absolutely use your software to make money and that's okay.

Anyway, Elasticsearch is incredible software and the Elastic team has made something truly incredible. I just wish they had a vision for monetization that aligned with their open-source beginnings. It's clear that they don't, and the sooner they stop pretending they're offering a free or open-source solution here, the better.

The problem is that nobody buys AWS ElasticSearch because of quality. They buy it because they already have AWS approved as a vendor and a blank check to spend on it.

Yeah, so they’re not really competing with Elastic right? If I already have an AWS environment I’m never going to use an Elastic hosted service, since it’d be outside my VPC.

I really don’t understand how that business model works.

If you have an AWS env, and they have no comparable alternative, you may be forced to look outside AWS, eg: to Elatic's SaaS offering. But in many cases, if AWS has a comparable offering, you simply don't bother looking outside.

It's similar to bundling tactic of Microsoft, and other big vendors. By bundling MS Teams with other things, no one has to "buy" Teams, they already get it for "free" (well, it's no extra cost beyond what they would be paying for Office or whatever already), so why "buy" Slack when you have a similar chat tool for "free".

But what if the customer needs ElasticSearch, see that AWS provides it and don't look further?

If AWS didn't take the work of Elastic those customers might have used Elastic's services instead.

How can AWS offering the same thing not be competing against Elastic's offering?

> 2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault.

The sad-funny thing is that elastics hosted cloud offering is clearly superior to AWS’ hosted elasticsearch in pretty much all regards.

It’s important to defend the product and the software ecosystem because so many people are confusing AWS’s offering with what the current state of the system is. It’s so bad that some people actually think that AWS _is_ the developer of Elasticsearch in many cases due to the Elastic-X branding similar to the I-Noun convention that Apple tried to defend against but fell short of squashing around the world. It’s also important to note that not defending one’s trademark sufficiently well means bad things in a court precedent where there needs to be reasonable, demonstrable evidence you’re not simply a patent / trademark troll sitting around waiting for someone juicy to sue rather than small fries.

Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)? I don’t really know much about the field, but if AWs’s single contribution were to be “we made it really hard to screw up the configuration and leak all your data”, I’d consider that a very deserving cause.

> Seems like you know a thing or two about this — are all the reports I see about companies leaking tons and tons of data through improperly configured elastic search instances something using the aws’s offering would fix (or even ES’s hosted offering)

The primary issue that leads to that is that the stock open source elasticsearch distribution (APL licenced) does come with no security at all. It even used to be the case that even the most basic security was a plugin that required a paid license. That changed only after AWS released the opendistro set of plugins with a free plugin to add security - after that, elastic offered a basic (free as in beer, but still non-free as in freedom) license that would include security. Additionally, the early ES versions would bind to all IPs by default, so just starting the server would make it available from outside. If you weren't expecting that and no firewall was protecting you, your ES cluster would be available from the outside with not authentication.

Both AWS and elastics hosted offering come with a configured security plugin, so that at least makes it harder to leak data. Obviously, even with authentication you can still leak credential or such.

Hm. So Elastic releases a neutered version of their product that leads to countless PII leaks, AWS provides a FOSS plug-in to fix that, then Elastic turns around and says AWS is leaching off their product and not contributing back to the community and implements a licensing change to prevent them from working together in the future? I can’t help but side with the AWS folks on this one —- I get wanting to make money, but insecure-by-default services are inexcusable, especially when it’s expected that they’ll contain PII.

Exactly! I've used AWS' service, it's awful. Elastic's is better, and price is comparable or better in fact. But the point is they don't even have to compete on price if quality is superior!

If I'm spending $100k/mo on my logging stack, and it's falling over frequently (which in AWS-land means multiple days of back and forth, opening tickets etc), I'd way rather pay $120k/mo for something that actually works.

> If I'm spending $100k/mo on my logging stack, and it's falling over frequently

I do the same and AWS ES works fine. I did try Elastic, performance was bad. They run it in containers internally!

Have you never been burned by those awful blue-green deployments?

Of course, my company was willing to pay $100k/mo to log every SQL query in existence but wasn't willing to pay for AWS support (of course it would have required paying something like 1% of our TOTAL aws spend, not just aws elasticsearch, although we could have probably created a subaccount or something)...so maybe the experience is different if your tickets actually get answered.

What was bad about performance in particular? You were just seeing less throughput per dollar spent or what?

Guys did benchmarks, AWS ES was as fast as hand rolled one, Elastic was few times slower. Searching in Kibana had substantial delay.

Yea, I got bit once by one stuck blu-green. Root cause was zero free disk space, I now keep it at 25%

And we do pay for tech support, im in luck here :)

Wouldn’t getting logs from some AWS service into Elastic’s hosted service (or anything not in AWS) be really expensive at scale though?

I believe they have an option so you can peer your VPC to their hosted offering's VPC, so logs from within your VPC don't have the typical expensive AWS internet egress/ingress costs.

While cheaper, traffic over a VPC peering is still not free.

Special mention for this paragraph: 'we expect that a few of our competitors will attempt to spread all kinds of FUD around this change. Let me be clear to any naysayers. We believe deeply in the principles of free and open products, and of transparency with the community.' Get your offense in early and try not to mention open source!

This.

I feel so much for the hundreds of open source developers who toil everyday only to have AWS make so much money out of it, to make the largest shareholder the richest man on earth, while contributing nothing back to any of the open source projects. This has to be fixed or we will see less and less developers open sourcing quality products

F/OSS exists so that not everyone has to be subject to undifferentiated work, among serving other very high impact purposes. Think brew.sh, vim/Emacs, Eclipse IDE, Postgres, Java, Linux/Linaro etc;

Substitute AWS for "a software developer" and see if you feel the same way.

> I feel so much for the hundreds of open source developers who toil everyday only to have other software developers make so much money out of it... while contributing nothing back to any of the open source projects. This has to be fixed...

As someone who writes open-source, I'm always happy to see other developers use my code to build cool stuff, and I expect nothing in return.

I'm also happy to see small start-ups rise faster by using my software.

But if those theoretical start-ups, whose business wouldn't exist without my software, grew to dozens of employees, made millions of dollars, and still I wouldn't see a nickel.. That's when I would start to wonder, why am I doing this for free?

Incidentally, the bigger the company, the less likely it is to contribute back.

To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting.

I write F/OSS full-time.

AWS does / did contribute patches to Elasticsearch.

The problem Elasticsearch has is, AWS shares none of the gigantic profits it makes from its Elasticsearch Service, which is a double whammy because it cannibalizes Elastic's own SaaS offering.

> To conclude, that sounds like false equivalency to me. It does matter who is using it for free and profiting.

You mean to say, Facebook must share a % of its WhatsApp profits with ejabberd, or ejabberd otherwise is right to SSPL their software?

Or, Google pay Oracle a share of the spoils because it is an "app container layer" on top of Java/JVM? And that Oracle is okay to switch to SSPL otherwise in search of those dollars?

Or, okay if CnFdn SSPLs k8s?

Also, if it matters whoever profits contributes back monetarily, may be the right way to do so would be via a Foundation. Using the Commons Clause or SSPL is not the answer, in my eyes.

See also: http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...

> AWS does / did contribute patches to Elasticsearch.

That's a meaningless statement, since it could just as well mean that they contributed back 2 hours of work.

> * is okay to switch to SSPL ???

Yes, absolutely. Why not?

The article you linked doesn't mention anything about foundations. But let's agree not every open-source project can become one.

I don't think it's reasonable to attribute motive to the contributors in this way. Changes like this protect the elastic enterprise, whether they align with the motives of contributors would have to be evaluated on a per-contributor basis.

I've made several contributions to ELK, and my only motive has been that it's useful open source software, and I want to make it more useful. I personally don't care who profits off the codebase, I think anybody should be free to. I personally would object to anybody trying to lock down how it can be used, and would see any attempt to do so as running completely counter to my personal motivations as a past contributor.

Which is exactly what I see Elastic doing here.

> I've made several contributions to ELK, and my only motive has been that it's useful open source software, and I want to make it more useful. I personally don't care who profits off the codebase, I think anybody should be free to. I personally would object to anybody trying to lock down how it can be used, and would see any attempt to do so as running completely counter to my personal motivations as a past contributor.

This x 10000. I couldn't agree more, thanks for putting that so clearly.

Frankly, I think a number of people in the Open Core movement have a psychological hangup around profit. They feel that if a company - particularly a large corporation - is making money using their software without "contributing back", that that should not be allowed. Well, if you don't want to allow it, fine, but don't pretend you're in the business of releasing free software - you're not. You want to be in the business of proprietary software, since only proprietary software lets you say "hey I don't want Jeff to profit off of my work without paying my for a proprietary license".

I very strongly agree. It's always seemed like a quintessential tragedy of the commons to me. Everybody benefits from open source software, no matter what they're doing. Proportionally, very few people/organisations contribute to open source, and I would guess that nobody contributes to every open source project that they consume. I've always seen one of the core aspects of the value of open source being the common utility they provide. The idea that an open source consumer should contribute back value in some way proportional to the value they derive runs counter to that. The moment you start to restrict access to open source software based on some model of deservedness, you start to undermine the principles of common good that a lot of open source values are based on.

that's one of the things that bugs me, old contributions like yours have the apache license, can they modify without your approval?

Legally, I’m sure their contributor license agreement gives them the full rights to do that. Which was my understanding at the time. I’ve contributed to lots of projects that have them, and I likely will again in the future.

It's not open source though.

Yes, it is not. But who cares? What I care about as a user is repairability:

* can I inspect source and build it myself?

* can I fix it?

* can I share modifications with others?

Many of the new "cloud protection licenses" offer this, yet they are (by definition) not opensource.

I think this is the right way to look at things, after all, these were the orignal "why" arguments in favour of open source. If we can get the same benefits while also protecting open products from megacorps like AWS, that's a better licence than a true open source licence

> If we can get the same benefits while also protecting open products from megacorps like AWS, that's a better licence than a true open source licence

That's your opinion, of course. IMO, there's a type of magic that happens when software is under a truly non-restrictive license. You get a level of quality and reliability in the software that is unmatched by what you get with any proprietary equivalent.

Unfortunately, most people don't really believe in FOSS. And that's okay. But boy am I getting frustrated with these companies that are happy to preach about how "open source" is amazing, until someone else is making some profit with their software and then suddenly the (extremely vague) restrictive licenses start rolling out.

The only entity who says it's not "open source" is the OSI, which is mostly funded by corporations, who are in the business of cloud computing.

Both the Debian Free Software Guidelines[1] and the GNU Free Software Definition proscribe limiting fields of endeavor. The OSD[3] borrows heavily from the DFSG.

I remember reading (alas, I can't find my source) a spokesperson for the OSI admitting to the existence of licenses that meet the OSD that they don't want to be OSI-approved because they don't add enough value versus the cost of proliferation of licenses that are substantially similar.

[1] https://www.debian.org/intro/free

[2] https://www.gnu.org/philosophy/free-sw

[3] https://opensource.org/osd

These definitions were written a long ago, in a time when cloud computing wasn't even a buzzword yet.

But I read them and couldn't find anything addressing fields of endeavor. GNU's "four essential freedoms", which imho are a little naive in retrospect, don't say anything about this. They say anyone should be able to "sell copies", but SSPL doesn't disallow this either.

Debian obviously didn't address it either. They clarify: " They can even try to sell it. In practice, it costs essentially no money to make electronic copies of software. Supply and demand will keep the cost down."

I.e. they only allowed it because they thought the free market will take care of it, and didn't imagine how cloud provides will become monopolies of access.

"As a result, you can buy a Debian release on several CDs for just a few USD." - Lol.. that's like trying to apply lessons from the bible to modern life.

Just to broaden the discussion, "fields of endeavor" doesn't just mean cloud services, but also whether you can prevent your software from being used in weapons, or other such morally objectionable applications.

> GNU's "four essential freedoms", which imho are a little naive in retrospect, don't say anything about this.

"The freedom to run the program as you wish, for any purpose."

That clearly includes purpose of running the progam as a cloud service and profiting from selling it SaaS-style to third parties.

We support these principles just not enough to actually support them......

Yep. It may totally make a "business sense" but positioning as great for Open Source community and "Doubling Down on Open" stinks

Imagine if the only way to use Linux or Kafka is to use a specific hosting company. The title should've been "Doubling Down on our Revenue Model by changing our Licensing"