Hacker News Reader

Comment by floatingatoll | Hacker News Reader

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?

View on HN

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.

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

Isn’t this the situation AGPL3 was written for? It’d probably kill ES and lead to a fork from the latest pre-AGPL3 version, but it’s still an option.

IANAL but I believe that the AGPL would address the case where AGPL code was used in a user facing setting. If the code was used only internally I believe that it is no different from the GPL in this respect.

Correct: AGPL3 is GPL3 + one requirement – any user who communicates to a program must be able to retrieve its source code.

If ES was under AGPL3, AWS' ES server would absolutely fall in scope.

The Facebook example, however, is tricky. You are technically right: the FSF calls this the Service as a Software Substitute (SaaSS) problem[1]. But Facebook can run an AGPL3 project and, as long as they are careful, will not need to expose any changes they make to it.

In practice, Facebook and other big corporations are extremely unlikely to do this. If they get it wrong, they've inadvertently accepted a license they didn't mean to, which could open them up to liability or worse – relicensing things. To prevent this you get a set of approved permissive licenses that are always kosher. If you want to stray off the path there is a set of massive flaming hoops you have to jump through (VP approval? legal review? just the beginning of your fun!) that are designed to convince you that you should chose a different path that involve more permissively licensed software.

[1]: https://www.gnu.org/philosophy/who-does-that-server-really-s...

AWS elasticsearch is user-facing: the users are AWS’s clients.

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

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

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.

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.

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.

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/

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.

You write as though the AWS lawyers' advice is binding. However the article starts with a trademark violation and apparently in that case, the AWS lawyers didn't have the upper hand internally.

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?

If it's AGPL your application would have to be open source. With SSPL only the management plane has to.

Dual license.

Reply on news.ycombinator.com