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?

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

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.

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

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

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.

> In my opinion it seems like Elastic wants ElasticSearch to still be perceived as the fully open source project (with all of its good connotations) it once was.

That’s my attitude towards most of these license changes or “open core” pivots. These companies want all the good will and community contributions of “open source” while still being able to wield intellectual property protection laws against other companies who dare compete against them on unrelated, commoditized services like hosting.

It's somewhere between bait and switch & dumping. It's very hard to compete against free. And it's very hard to make money when you give away your product for free. Cloud hosting was a way out of that conundrum. But that window is now closing as the big cloud operators move in + the rise of Docker making hosting much easier.

> And it's very hard to make money when you give away your product for free. Cloud hosting was a way out of that conundrum.

But surely it's only a conundrum if the primary goal of a software project is for a single company that has the same name as the software project to exclusively make money by selling hosting and/or support for that software while still using an open source license to attract a community of developers to work for you for free. I'd argue that this conundrum is easily resolvable: either have an open source software project for which anyone can sell support and hosting, or have a software company that develops proprietary software and sells it and related services.

The only mistake Elastic seems to have made here is not releasing ElasticSearch under something like the SSPL in the first place. Of course, it didn't exist then.

Almost every user would have been free to use it exactly as they do today.

I think AWS is a case of someone ruining it for the rest. Yes, they’re allowed to do that and there’s nothing wrong legally, but in the end everyone will be worse off.

I would be much more hesitant choosing an storage solution if I knew the parent company has problems monetizing upon it.

> more hesitant choosing an storage solution if I knew the parent company has problems monetizing

You should be hesitant about choosing any mission critical product where you don't know how the vendor will make money. This is even the case with stable vendors. How many products has Google killed over the years because they could figure out how to make them profitable (enough)?

> How many products has Google killed over the years because they could figure out how to make them profitable (enough)?

HN never ceases to amaze me. This is a post on pattern of exploitative and anti-competitive behavior of AWS. Somehow HN crowd found a way to whine about Google. Every single day multiple anti-Google posts on HN front page was not enough.

It is simply the effect of Google spending their reputation as if it is a never ending fountain of free cash.

How many products has Google not killed?

It's quite a long list.

"Just because you CAN, doesn't mean you SHOULD."

> In my opinion it seems like Elastic wants ElasticSearch to still be perceived as the fully open source project (with all of its good connotations) it once was.

This. It is too bad they couldn't have satisfactory financial success building on open source and it is their right and perfectly fine to switch to a different model, but their justification as well as the SSPL dual licensing muddle the water unnecessarily.

At least the blogpost clearly states it is no longer open source, but then it goes "it's just definition, we're actually totally free and open, just, you know, not OSI free and open". SSPL software is not free software, it is not FOSS. Calling it "free and open software" is misleading at best.

I don't have any problem calling SSPL software "open source". Or AGPL software, for that matter. What's not free or open about applying copyleft to network services?

The license discriminates based on field of endeavor, invoking additional constraints on the basis of what you use the software for.

The legal team for Fedora expressed this well, I think:

> It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk.

https://lists.fedoraproject.org/archives/list/devel@lists.fe...

I think it is this discrimination that makes in not as free or as open as AGPL and GPL.

The field-of-endeavor and persons-or-groups discrimination arguments don't stand up. They just sound nice if you want to knock the license.

If SSPL discriminates against a "field of endeavor" that is making proprietary software, or against "persons or groups" that are proprietary software developers, all copyleft licenses do. That was the point. Here's Richard Stallman on the GPL:

> I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well. I figure that since proprietary software developers use copyright to stop us from sharing, we cooperators can use copyright to give other cooperators an advantage of their own: they can use our code.

https://www.gnu.org/philosophy/pragmatic.html

The quote from Fedora perfectly encapsulates the difference between the OSI review process as people perceive it and the OSI review process as it really was. Are we judging license terms, or what we believe to have been in the secret heart of the company that wrote them? What happens when someone else uses the license, as when independent hackers choose GPL, or startups choose AGPL?

Commercial software makers have plenty to fear from GPL, AGPL, and other open source copyleft licenses, because so many of their business models entail slurping up other people's open code, but not sharing their own. Those licenses prohibit building proprietary software with open code, just not if you happen to "compose" a service with network API calls, rather than build a program by copying code snippets, using frameworks, and linking libraries.

Basically shareware with source available, we have come full circle.