6 ms·

The new license doesn't restrict others from operating Elasticsearch as a service. It restricts others from operating Elasticsearch as a service unless they rel

The new license doesn't restrict others from operating Elasticsearch as a service. It restricts others from operating Elasticsearch as a service unless they release any source code patches, improvements, and/or functionality extensions they make to it. To me, that's exactly what you're saying you expected from liberal licenses, but it's delivered by a restrictive license, using the restrictions popularized by GPL licenses. This makes ElasticSearch more open source, rather than less, because now anyone who uses it has to "open" their source code. That's the premise of GPLv3 in a nutshell, and I'm hard-pressed to understand how it's a drawback here. Have I misunderstood and their new license somehow reduces the openness of their source code to the world?

Conan_Kudo 6y ago
> The new license doesn't restrict others from operating Elasticsearch as a service. It restricts others from operating Elasticsearch as a service unless they release any source code patches, improvements, and/or functionality extensions they make to it. If this was AGPL, I'd agree with you. IANAL, but SSPL is so broad that it could be construed to cover the Linux kernel, which is a no-no. :(
- floatingatoll 6y ago
  What real, non-theoretical, "would stand up in a courtroom" risk is there if the SSPL extends to cover the Linux kernel? SSPL: you have to share your source code to the Linux kernel if you sell Elasticsearch-as-a-service" GPL: you have to share your source code to the Linux kernel if you release binaries SSPL+GPL: you have to share your source code to the Linux kernel if you sell Elasticsearch-as-a-service or if you release binaries As long as the source is duly published under the merged SSPL+GPL conditions above, anyone trying to bring a GPL case against Elasticsearch-SSPL-on-Linux-GPL may discover that their judge refuses to enforce the GPL's hostility clause, because the SSPL strengthens the intent of the GPL without weakening it in any respect. We'll never know until someone gets to a judge, though, but my armchair speculation bet is that the "can't combine this license" clause won't hold up when the combination increases the total amount of Copyleft in play without decreasing it in any regard. I hope someone takes this to court and doesn't settle, or else we'll never find out :) (I'm not your lawyer, this isn't legal advice, etc.)
  - cycloptic 6y ago
    No offense but this advice is rather risky and legally dangerous, please don't tell people to potentially put their products in jeopardy by doing this. The correct thing to do is for MongoDB/Elastic to just clarify the wording in the license.
    - woofie11 6y ago
      No. The correct thing is to adopt a license I understand. AGPL is okay. I'm not hiring a lawyer when I'm selecting a few tools to benchmark. I'm not using EC until I've had the license reviewed by a lawyer. Ergo, redis or similar.
      - cycloptic 6y ago
        If the license is so badly worded that nobody can understand it, it needs to be corrected. I agree you should not hire a lawyer for that, it's not your lawyer's job to fix some other company's license for them. It's a shame that MongoDB appears to have completely lost interest in drafting SSPLv2.
        aries185 6y ago
        Redis is still FOSS under the BSD license. If Redis Labs were to change the Redis license, AWS would fork it in a heartbeat. To help clear up confusion you can read about the Redis, Redis Modules and Redis Enterprise licenses here: https://redislabs.com/legal/licenses/ https://redislabs.com/legal/licenses/
  - Guthur 6y ago
    ElasticSearch know exactly what they are doing here. By leaving it grey and a little open to intrepretation they know that AWS lawyers will have to advice AWS to avoid it because it might open them up to legal attack.
    - bartvk 6y ago
judofyr 6y ago
I think the term "more open" is a bit too vague in this discussion. Sometimes people use it to refer to permissiveness (e.g. BSD) and sometimes people use it to refer to stimulating further open source work (e.g. GPL). (And if we're following the "definitions" then ElasticSearch is no longer "open source" since that has a strict definition, but it's probably not so relevant in this discussion.) I also don't really object to their license choice at all; what I object to is how they're framing the discussion. This license change is all about business: They want to be able to sell their cloud service without competition. That's perfectly okay, but there's no need to hide this. And certainly no need to "shame" Amazon for building a business on top of something Elastic open sourced. > Have I misunderstood and their new license somehow reduces the openness of their source code to the world? I think their new license just shows that it's all about business. If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of. And why are they fine with Facebook/Google doing this? Because it won't jeopardize Elastic's cloud offering. In addition, their new license also makes it harder for other people to build businesses on top of ElasticSearch. Imagine that I invest a ton of time and effort into creating a new management layer which is capable of scaling ElasticSearch drastically better. Something completely novel which looks at current trends of traffic and automatically moves shards around. Non-trivial stuff. Well, sorry, there's no way of building a business on top of this idea.
- sokoloff 6y ago
  > If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of GPL does not require releasing source code or patches except to those whom you give the binaries. If Facebook creates an improved internal fork of GPL code and runs it inside of Facebook, they can keep their sources/patches private and be in compliance with GPL. There is a practical advantage to upstreaming your patches: because it makes maintenance easier if those patches are accepted and merged upstream, but there's no legal/license requirement to release them for code that you keep internal to your company.
h_anna_h 6y ago
The license does not seem any different to AGPLv3 as you are describing it, in that case why did they not just use AGPLv3 which is FOSS?
- whs 6y ago
  If it's AGPL your application would have to be open source. With SSPL only the management plane has to.
  - woofie11 6y ago
    Dual license.
deleted 6y ago
[deleted]

Conan_Kudo 6y ago

> The new license doesn't restrict others from operating Elasticsearch as a service. It restricts others from operating Elasticsearch as a service unless they release any source code patches, improvements, and/or functionality extensions they make to it. If this was AGPL, I'd agree with you. IANAL, but SSPL is so broad that it could be construed to cover the Linux kernel, which is a no-no. :(

floatingatoll 6y ago
What real, non-theoretical, "would stand up in a courtroom" risk is there if the SSPL extends to cover the Linux kernel? SSPL: you have to share your source code to the Linux kernel if you sell Elasticsearch-as-a-service" GPL: you have to share your source code to the Linux kernel if you release binaries SSPL+GPL: you have to share your source code to the Linux kernel if you sell Elasticsearch-as-a-service or if you release binaries As long as the source is duly published under the merged SSPL+GPL conditions above, anyone trying to bring a GPL case against Elasticsearch-SSPL-on-Linux-GPL may discover that their judge refuses to enforce the GPL's hostility clause, because the SSPL strengthens the intent of the GPL without weakening it in any respect. We'll never know until someone gets to a judge, though, but my armchair speculation bet is that the "can't combine this license" clause won't hold up when the combination increases the total amount of Copyleft in play without decreasing it in any regard. I hope someone takes this to court and doesn't settle, or else we'll never find out :) (I'm not your lawyer, this isn't legal advice, etc.)
- cycloptic 6y ago
  No offense but this advice is rather risky and legally dangerous, please don't tell people to potentially put their products in jeopardy by doing this. The correct thing to do is for MongoDB/Elastic to just clarify the wording in the license.
  - woofie11 6y ago
    No. The correct thing is to adopt a license I understand. AGPL is okay. I'm not hiring a lawyer when I'm selecting a few tools to benchmark. I'm not using EC until I've had the license reviewed by a lawyer. Ergo, redis or similar.
    - cycloptic 6y ago
      If the license is so badly worded that nobody can understand it, it needs to be corrected. I agree you should not hire a lawyer for that, it's not your lawyer's job to fix some other company's license for them. It's a shame that MongoDB appears to have completely lost interest in drafting SSPLv2.
      - aries185 6y ago
        Redis is still FOSS under the BSD license. If Redis Labs were to change the Redis license, AWS would fork it in a heartbeat. To help clear up confusion you can read about the Redis, Redis Modules and Redis Enterprise licenses here: https://redislabs.com/legal/licenses/ https://redislabs.com/legal/licenses/
- Guthur 6y ago
  ElasticSearch know exactly what they are doing here. By leaving it grey and a little open to intrepretation they know that AWS lawyers will have to advice AWS to avoid it because it might open them up to legal attack.
  - bartvk 6y ago

judofyr 6y ago

I think the term "more open" is a bit too vague in this discussion. Sometimes people use it to refer to permissiveness (e.g. BSD) and sometimes people use it to refer to stimulating further open source work (e.g. GPL). (And if we're following the "definitions" then ElasticSearch is no longer "open source" since that has a strict definition, but it's probably not so relevant in this discussion.) I also don't really object to their license choice at all; what I object to is how they're framing the discussion. This license change is all about business: They want to be able to sell their cloud service without competition. That's perfectly okay, but there's no need to hide this. And certainly no need to "shame" Amazon for building a business on top of something Elastic open sourced. > Have I misunderstood and their new license somehow reduces the openness of their source code to the world? I think their new license just shows that it's all about business. If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of. And why are they fine with Facebook/Google doing this? Because it won't jeopardize Elastic's cloud offering. In addition, their new license also makes it harder for other people to build businesses on top of ElasticSearch. Imagine that I invest a ton of time and effort into creating a new management layer which is capable of scaling ElasticSearch drastically better. Something completely novel which looks at current trends of traffic and automatically moves shards around. Non-trivial stuff. Well, sorry, there's no way of building a business on top of this idea.

sokoloff 6y ago
> If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of GPL does not require releasing source code or patches except to those whom you give the binaries. If Facebook creates an improved internal fork of GPL code and runs it inside of Facebook, they can keep their sources/patches private and be in compliance with GPL. There is a practical advantage to upstreaming your patches: because it makes maintenance easier if those patches are accepted and merged upstream, but there's no legal/license requirement to release them for code that you keep internal to your company.

h_anna_h 6y ago

The license does not seem any different to AGPLv3 as you are describing it, in that case why did they not just use AGPLv3 which is FOSS?

whs 6y ago
If it's AGPL your application would have to be open source. With SSPL only the management plane has to.
- woofie11 6y ago
  Dual license.

deleted 6y ago

[deleted]