Amazon: Not OK – Why we had to change Elastic licensing • Hacker News Board

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

#171

Post by pas » Tue, Jan 19, 2021, 3:46 PM UTC

hodgesrm wrote: post #112

z77dj3kl wrote: post #38

"And to be clear, this change most likely has zero effect on you, our users. It has no effect on our customers that engage with us either in cloud or on premises." No, that's just not true. So many users, from small hobby side-projects, to large open source projects, and mega-corps care about the licensing of dependencies, each for their own reason, and will not want to build on top of proprietary software that impos…

> It doesn't matter what they say, read the license. I would love to but the terms within the ElasticSearch codebase on Github are quite confusing. Here's the text of the LICENCE.TXT file. Source code in this repository is covered by one of three licenses: (i) the Apache License 2.0 (ii) an Apache License 2.0 compatible license (iii) the Elastic License. The default license throughout the repository is Apache License…

Does this even work? ES was considered 'one work' at some point, right? It's developed together, not file-by-file. How is it possible then to license it file-by-file? Wouldn't most of those files be derivative works of the old 'one work' anyway? (Meaning they have to keep the original license, meaning "the default license, Apache License 2.0"?)

Sure, at some point someone started to create a plugin for ES (let's say the security/ACL thing in x-pack, used to be called Shield or something like that), they used the ES API and they used runtime linking. (I have no idea if that's okay or not, has been tested in court or not. I know the US Supreme Court will say something about that in June.) But when developing any feature in that plugin nobody thinks of just that plugin. Folks think about ES as a whole, indexes, shards, documents, terms, maybe even in terms of low-level Lucene primitives.

I think it's practically impossible to wear the OSS and the proprietary hat at the same time. (Or separately but on the same project.)

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

#172

Post by shawnz » Tue, Jan 19, 2021, 3:46 PM UTC

longhairedhippy wrote: post #105

Could this potentially drive users to the Amazon fork? If I'm a business that may be impacted due to the licensing change, it would seem my safest (legal) option would be to freeze on the last version with a friendly license and then transition to the Amazon fork, since it will probably stay under a more open license. While maybe not the smartest technical decision, from a business standpoint it seems like a reasonab…

Open Distro is not a fork but simply a repackaging of ES with some additional modules.

However there doesn't seem to be many options left now but for Open Distro to become a complete fork of ES.

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

#173

Post by nitrogen » Tue, Jan 19, 2021, 3:47 PM UTC

hodgesrm wrote: post #112

z77dj3kl wrote: post #38

"And to be clear, this change most likely has zero effect on you, our users. It has no effect on our customers that engage with us either in cloud or on premises." No, that's just not true. So many users, from small hobby side-projects, to large open source projects, and mega-corps care about the licensing of dependencies, each for their own reason, and will not want to build on top of proprietary software that impos…

> It doesn't matter what they say, read the license. I would love to but the terms within the ElasticSearch codebase on Github are quite confusing. Here's the text of the LICENCE.TXT file. Source code in this repository is covered by one of three licenses: (i) the Apache License 2.0 (ii) an Apache License 2.0 compatible license (iii) the Elastic License. The default license throughout the repository is Apache License…

It sounds like everything outside of the x-pack directory is Apache or compatible with Apache, so the -oss binaries are Apache

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

#174

Post by [deleted] » Tue, Jan 19, 2021, 3:48 PM UTC

Pet_Ant wrote: post #95

> Our license change is aimed at preventing companies from taking our Elasticsearch and Kibana products and providing them directly as a service without collaborating with us. I feel like I just said this a few days ago: https://news.ycombinator.com/item?id=25796849 The main value of open source to businesses is that support is truly commodified and there is no one with a stranglehold on it. ElasticSearch is trying t…

[deleted]

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

#175

Post by prepend » Tue, Jan 19, 2021, 3:48 PM UTC

tmpxgdqrcKFuG wrote: post #51

I am interested to see how long or if Elastic sticks around after this. If people will just move on to another AWS product or if they'll keep using Elasticsearch.

I think it depends on whether Amazon wants to start funding development of their fork. I think under this new license, Amazon can’t just bring over changes from elastic any more.

If Amazon commits to dev work then their project might be the one that survives since it’s actually OSS and more capable of being used in more products.

But if they don’t then it will drift and not be very useful any longer.

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

#176

Post by pietrovismara » Tue, Jan 19, 2021, 3:49 PM UTC

prepend wrote: post #64

So I guess the options are now to use the “OpenDistro” [0] or the SSPL distro maintained by Elastic. It’s too bad that Elastic is no longer open source, but respect the companies choice to close source their stuff. Will be interesting if Amazon just maintains their fork or abandons it to make something else. I’m not familiar with elastic as a project and not sure how many community contributions they have, but expect…

The source code is freely accessible and you can use it for free.

What's the difference to you as a user? Or are you simply concerned about Amazon?

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

#177

Post by pyb » Tue, Jan 19, 2021, 3:49 PM UTC

pritambaral wrote: post #152

pyb wrote: post #114

This is tangential, but, speaking of intellectual property, was MongoDB entitled to strip the FSF copyright in the SSPL ? (as per https://webassets.mongodb.com/_com_assets/legal/SSPL-compare... line 5)

Given that the text of the SSPL amounts to a minor edit to that of the AGPL (at best): no. The SSPL text is still a derivative of the AGPL text, which is copyrighted and licensed under the following terms (from https://www.gnu.org/licenses/agpl-3.0.en.html ): Copyright © 2007 Free Software Foundation, Inc. https://fsf.org/ > Everyone is permitted to copy and distribute verbatim copies of this license document, but ch…

I thought so. IANAL, but it looks like a blatant copyright violation to me. This indicates that the SSPL may not have been written by a lawyer.

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

#178

Post by brlewis » Tue, Jan 19, 2021, 3:49 PM UTC

DougBTX wrote: post #161

brlewis wrote: post #44

Earlier quoted context omitted.

I'm not a lawyer either, but as I understand it, a trademark is violated if it's likely to confuse people into thinking the product/service is from the trademark holder when it actually isn't. If Amazon's CEO experienced such confusion himself, that does sound like a slam dunk to me. FTA: When the service launched, imagine our surprise when the Amazon CTO tweeted that the service was released in collaboration with us…

It does seem tricky. On on hand, they want to stop AWS using "Elasticsearch" in a product name because it isn't in partnership with Elastic co., but on the other hand AWS's product really does contain Elasticsearch, which is why they are changing their license. If AWS had a product called "Elasticsearch Service" which didn't contain Elasticsearch, then it would be pretty clear cut as that would be very confusing, but…

In general, yes, it can be tricky to determine what will and won't be confusing to people, since different people see things differently.

In this specific case, it doesn't seem tricky to me. When you have concrete examples of people getting confused, no speculation is needed.

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

#179

Post by VoxPelli » Tue, Jan 19, 2021, 3:50 PM UTC

elliekelly wrote: post #65

dhd415 wrote: post #10

Elastic's other blog post with a clarification about their recent license change is also interesting: https://www.elastic.co/blog/license-change-clarification . Apparently, they're considering further license changes such as MariaDB's Business Source License in which code is usable for anything other than offering the product itself as a service but becomes fully open source (including SaaS) after 3-5 years. That mak…

> Then after a period of time, typically 3-4 years, but not more than 5 years, the restrictions lapse, and the source code automatically converts to an Open Source license, in our case Apache 2.0. I’m not familiar with this type of license. Any idea how/when this time frame is decided? Is it 3-5 years from software release? I guess I’m confused by the use of “automatically converts” with a vague timeline. If it’s aut…

Good explanation here: https://perens.com/2017/02/14/bsl-1-1/

It’s from the day that the code is released under the license and the four years is the max under BSL (so that people know roughly what the “worst case scenario” it a BSL licensed software would be) but can be specified to be shorter by the one releasing code under it.

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

#180

Post by throw8932894 » Tue, Jan 19, 2021, 3:50 PM UTC

I run Apache licensed storage library. It is not big, but consulting fees cover my living.

Some time ago I changed development model. Public facing version is still Apache 2 licensed. But now there are no unit tests and no integration tests, those are proprietary now. And I extensively use code generator which is also not public.

It is still possible to fork/modify code. Merging pull request is bit more difficult for me (backport stuff to code generator). But it works great and nobody noticed anything.

Practically any serious use of my library has to go through me now. And I am the hero because my code is virtually without bugs. Magic!!! :)

I become disillusioned long time ago. Also people told me several times unit tests do not matter... but in reality they are most valuable part of know how.