Live data from Hacker News

Amazon: Not OK – Why we had to change Elastic licensing

elastic.co

681–690 of 708 posts

Re: Amazon: Not OK – Why we had to change Elastic licensing

#681
post #45

This is fine. No seriously. Hear me out. If you are a proponent of capitalism then this is how the system works. The little fish grow into big fish. The big fish eat the little fish. The ecosystem suffers. It has always been this way. Many of us remember Microsoft in the nineties. Fewer will remember the phone or oil industry doing the same. Don’t fight this issue. Fight the system that tolerates this pattern. Money…

Meh, I'm not convinced that other systems will be fundamentally better

Humans are flawed, the systems they build will be flawed, flaws will wax and wane with circumstances, possibly waxing to the point of intolerability and then they break and are replaced with something else.

Paradise remains fundamentally always out of reach.

And yet there are good moments, good relationships, little pieces of life that are priceless. So I think it makes sense to carve out little niches in life where things work nicely or to try to make things work better on small issues.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#682
post #639
post #207

Earlier quoted context omitted.

Given that aws just built DocumentDB, I am not sure if the licensing changing anything. I would even say that this choice actually hurts MongoDB because I am less likely to choose it since they have less practical hosting solutions.

If Oracle wins against Google, presumably DocumentDB would be infringing in the same manner, as DocumentDB also is a drop-in replacement adhering to the same API.

I still didn't decide if it would be a good a or bad thing actually.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#683

I don't think you can have an open source product. In this particular case, Elasticsearch is an open source project that Elastic is a custodian of and has been monetising by building products around it: support, consulting, proprietary extensions, hosting and maybe other things. Now an industry behemoth has decided to directly compete with one of their products. That's tough, especially that it's done in a typically…

In the end, what Elastic did is making it so " You can do anything, except selling this product" which imo is fair.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#684

Earlier quoted context omitted.

https://opensource.org/osd See in particular items 5, 6 and 9.

That doesn't parse. The SSPL does not discriminate against a person, a group, or a field of endeavor, any more than the GPL "discriminates" against people who distribute modified versions of a program by requiring them to distribute the source code of the changes. Further, the requirement of the SSPL does not cover "distributing with", so point 9 doesn't seem to make sense either.

"If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License."

This clearly violates point 9, as it impacts "service" source code, not just the program source code. Also as others have pointed out, what exactly is "service" source code is entirely unclear. But it is clear enough to know it isn't Open Source.

Also, it is clear from Elastic's blog post that they are switching to the SSPL in order to discriminant against fields of endeavor.

You can read more about its rejection https://opensource.org/node/1099 and https://www.zdnet.com/article/mongodb-open-source-server-sid...

Re: Amazon: Not OK – Why we had to change Elastic licensing

#685

Apart from the general consternation about an OSS license becoming non-OSS, can we also talk about the problem that companies are formed, invest a whole lot of resources into creating a product, open-source it, and then have Amazon eat into their profits by just installing and maintaining that product as a service? No matter how you slice it, I think Amazon is bad for us end-users, and Elastic is good. Elastic could…

> companies are formed, invest a whole lot of resources into creating a product, open-source it, and then have Amazon eat into their profits by just installing and maintaining that product as a service? Why should we be mad at Amazon for adhering to the terms of the license that the ES developers chose? Software isn't born under the terms of Apache 2/MIT/BSD/a similarly permissive license. The people who developed it…

The main problem is not Amazon using the Elasticsearch product, but using the Elasticsearch trademark without permission, even creating a fork with that trademark in it. That is not OK.

And then doing stuff like this:

> When Amazon announced their Open Distro for Elasticsearch fork, they used code that we believe was copied by a third party from our commercial code and provided it as part of the Open Distro project.

That makes it all the more dodgy. The fact that AWS is also the only cloud provider they complain about, and explicitly name others where they don't have these issues with, paints a pretty clear picture imho...

Re: Amazon: Not OK – Why we had to change Elastic licensing

#686

Apart from the general consternation about an OSS license becoming non-OSS, can we also talk about the problem that companies are formed, invest a whole lot of resources into creating a product, open-source it, and then have Amazon eat into their profits by just installing and maintaining that product as a service? No matter how you slice it, I think Amazon is bad for us end-users, and Elastic is good. Elastic could…

Amazon convinces investors to eschew profits. Unusual. Result: lower cost of capital. Amazon benefits from extended tax holiday. Result: lower cost of doing business. Amazon appropriates FOSS. Result: lower cost of development. Amazon knocks off successful products, competing with their own partners in their own walled garden. Result: lower cost of product development. Amazon allows counterfeit products, fake reviews…

> And figuring out how to sell excess capacity was cool

If you're referring to how Amazon Web Services was born out of the excess server capacity in their eCommerce service, this has been debunked as a myth [1]

Bezos knew what he was doing.

[1] https://www.networkworld.com/article/2891297/the-myth-about-...

Re: Amazon: Not OK – Why we had to change Elastic licensing

#687
post #597

Earlier quoted context omitted.

We're in the era of big platforms that can pick and choose the winners, and the winners have to play with those rules. see: GPLv3 ban on Tivoization. It makes anything v3 radioactive to any company seeking to make $$$.

The argument is that those people were never going to pay you money anyway so don't cater to them. All you can do is try to make it seem like it is cheaper to pay you for a license exception than it is to reimplement, but some places will reimplement anyway.

SaaS in big cloud is the way most people prefer to consume services. Few people enjoy setting and maintaining a large elastic cache cluster.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#688

Earlier quoted context omitted.

That doesn't parse. The SSPL does not discriminate against a person, a group, or a field of endeavor, any more than the GPL "discriminates" against people who distribute modified versions of a program by requiring them to distribute the source code of the changes. Further, the requirement of the SSPL does not cover "distributing with", so point 9 doesn't seem to make sense either.

"If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License." This clearly violates point 9, as it impacts "service" source code, not just the program source code. Also as others have pointed out, what exactly is "service" source code is entire…

Those posts are a mere re-statement of the conclusion, not the reasoning that led to it.

1. The OSI definition applies to the license itself, not the company's motivations for its use, so that point is irrelevant.

2. I do not see how point 9 amounts to a restriction, for four reasons:

a. The "other software" is packaged together as a service by the company offering the service, not by the SSPL. The SSPL, in other words, recognizes what already exists. It does not create a new thing.

b. The example given by OSI relates to other unrelated programs simply sharing the same media. The SSPL targets programs that are bound together to provide a service. GPLs already recognize linking, for instance, so how does this not apply as a different kind of linking? It's merely happening at the next layer up.

c. Open source is not a restriction - it is the opposite of a restriction. The entire point of free software licenses is to, as the preamble of the GPLs say, "guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users". It beggars belief that integration of a program into a packaged product, modified for and made available over the network, should override that protection. If the SSPL is not "open source" for this reason, then neither is the AGPL.

d. Legal ambiguity is not a reflection on the open-source-ness of the license. All FOSS licenses are "ambiguous" until tested in court multiple times.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#689

Earlier quoted context omitted.

I don’t see these as comparable. If Microsoft packaged up Linux and started selling Linux licenses, maybe? Elastic search being used in a product seems different from elastic search being the product. It’s not black and white, but there are real differences.

I can’t imagine anything closer to “selling THE product” when it comes to Linux than AWS EC2. It’s Linux as a service on different virtual hardware options. It’s directly comparable to the AWS Elastic search service, which is Elastic search as a service on different virtual hardware options. The fact that this isn’t immediately obvious shows how much we take Linux for granted. Perhaps you mean when comparing to the “…

Ah yeah, I meant the comment about “literally every single company in Silicon Valley,” but now I see that was entirely ambiguous. I thought you meant like Facebook, google (minus GCP), Uber, Airbnb, etc profiting off of linux (and pandas and gcc and pytorch and Cpython and ...).

Re: Amazon: Not OK – Why we had to change Elastic licensing

#690

Earlier quoted context omitted.

spot on. The lesson for would-be companies formed around open source is pretty stark: if your stuff is any good, then assume the clould vendors will offer it. If they do, it's going to be really hard for you to compete with a separate commercial offering. Not only has the cloud vendor already gone through the hoops of getting an enterprise agreement in place. They're also big, and recognised, and know how to deal wit…

The whole reason I would choose an open-source tech against closed source is so that I can go to whoever I want for support and future enhancement, that I'm not dependent on this tiny company for my business continuity. Sometimes that tiny founding company may not be the best to offer the kind of support and enhancements I need. A real personal example I experienced: at one time, the founding team behind a project I…

> In that situation, if my cloud vendor were to say they would solve that problem for me as they would be willing to invest whatever engineering bandwidth required to make it happen, then I would go with them.

Aren't cloud vendors generally less willing then smaller SAAS companies to do custom engineering work for their customers?

Post reply on HN