Comment by ignoramous | Hacker News Reader

Comment by ignoramous | Hacker News Reader

Parent Full thread

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes:

> Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL.

> It’s not a stretch to interpret the wording of the license as requiring users of the SSPL’d software therefore to release the code for everything straight down to the bare metal. There are those who will point to the FAQ for the SSPL and claim that the license isn’t interpreted in that way because the FAQ says so. Unfortunately, when you agree to a license you are agreeing to the text of that license document and not to a FAQ. If the text of that license document is ambiguous, then so are your rights and responsibilities under that license... This ambiguity puts your organisation at risk.

See also: http://dtrace.org/blogs/bmc/2018/12/14/open-source-confronts...

How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person. And my general sense and understanding is that although an FAQ style clarification is not _perfect_, it _does_ carry non-trivial weight.

Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _clear and well documented intent_ to narrow the scope of the burden they place on another is... well, it doesn't seem all that credible to me.

Of course by the time you get to that point in a legal dispute you're already in some trouble.

But IDK, I'm just a software person speculating. Is there a legal person interested in giving their "not legal advice" perspective on this?

I'd rather stick to the license text (than rely on mental gymnastics to justify any interpretation based on a FAQ) to be upheld in the Court of Law.

Btw, note how MPLv2 FAQ page clearly points out that the FAQ doesn't give anyone a license to freely interpret the license itself:

> ...while this FAQ is intended to be accurate and helpful, it is not the license, and may not cover important issues that affect you and your specific situation. As a result, reading the FAQ should not serve as a substitute for reading the license itself, or for seeking legal advice from a lawyer.

https://www.mozilla.org/en-US/MPL/2.0/FAQ/

In my experience, corporate lawyers don't really understand the distinction and will opt for the route of least risk, which generally entails a commercial relationship with the company. Unfortunately, neither Mongo nor Elastic really offer useful commercial relationships. That is, pay them a sum and be free to use the widely adopted open-source version of their thing.

The overhead to those relationships for what they do offer is significant.

Mongo absolutely offers this. A company I worked for had a contract with them -- these terms are hugely expensive, to the point it was worth switching to the AWS version when we had no AWS services.

Mongo offers what? A license to use their software and have them not harass me or attempt to upsell me or force me to use their management tooling?

Nah.

> and will opt for the route of least risk, which generally entails

Choosing something else - at least if you can do it before getting locked in.

Again, very minor use case. Not worth expending effort on. I attempted to convince the lawyers that we should just yolo it because the product had no actual revenue.

Didn't go well.

I can get at least a couple of person-weeks worth of dev done for the cost of sending the email that results in attempting to convince the lawyers of _anything_.

I wouldn't even ask for a legal review of this new Elastic License, if I thought I could tear it out for less than 2 dev-months of effort.

Well, what, then?

SOLR?

Amazon's Open Distro for ElasticSearch is still an open source fork of Elastic Search, so ironically Amazon may be the saviors of Open Source Elastic Search.

Excellent point.

> Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _clear and well documented intent_ to narrow the scope of the burden they place on another is... well, it doesn't seem all that credible to me.

My (non-lawyer) experience tells me the same, judges don't like people who try to argue one thing to a judge while clearly documenting on their website the opposite isn't going to go well, but as others pointed out that doesn't make it a smart choice to depend on, or that corporate lawyers will agree is worth the risk.

It raises question of how binding is publishing an FAQ? If I sent them an email with that question and they sent me an answer, if they tried to sue me over the issue that email will be a significant piece of evidence in my favor (I imagine).

But what if they only sent me a link to the FAQ or I just silently relied on it to be accurate?

Ambiguities result in increased litigation expense. Each argument over what a term means or how it should be interpreted is very expensive. These kinds of disagreements often need to be resolved early in the case by expensive motion practice.

It is much cheaper if both sides are willing to stipulate that they are in agreement with what the terms mean. Then you can get to fact finding and settlement talks with less upfront cost.

> How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person.

As a business person, I'd prefer to avoid the legal expense and risk to find out the hard way later on. Who knows who'll manage ElasticCo 5 years down the line and whether their motivation may be to milk their IP through litigation. Do you really want to be the guinea pig? The smart business move would be to either license explicitly OR stick to the Apache 2.0 version and plan a migration off ElasticSearch

Remember when Google argued that Oracle shouldn’t be allowed to sue over using the Java API because SUN had said it was fine? That’s the same legal argument as the FAQ issue. It’s called equitable estoppel.

Yeah, that is what happens when one turns down the opportunity to own Java.

Are you saying Google did that? Any links?

When Sun was put on sale, there were eventually two offers, Oracle and IBM (which withdraw theirs shortly thereafter).

Google did zero offers back it was still unclear who would save Sun, most likely hoping that they would just sink away.

Eventually Oracle and IBM came into the picture, and still radio silence from Mountain View.

So yeah, they get what they deserve.

As for links, the press of the day.

Here's the actual language from SSPL

> If you make the functionality of the Program or a modified version available to third parties as a service... (license conditions apply)

> “The Program” refers to any copyrightable work licensed under this License.

IANAL, but that seems pretty cut and dry referring to making an Elasticsearch or Kibana service

Next sentence is

> Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version.

and IMO (IANAL) that would put some of the services that offer log ingestion / indexing / querying in legal gray area.

There's quite a cottage industry of SIEMS that wrap ELK, so I'm curious how this'll shake out...

I do empathize with the desire to safely open their code for all/most users and their attempt to use SSPL to do it. For Graphistry, we ended up going proprietary for our core GPU visual analytics and went open for more generic infra and client codes, e.g., launched one of the Apache Arrow languages and our popular Python/Jupyter lib. I'm still looking forward to the day we can open our core as well (all our $B/$T partners ask us to, and yet ;-)). Encouragingly, our users are increasingly preferring the marketplace + saas versions, so I remain optimistic about an SSPL-ish license. That 90%+ of ES users go with SSPL is promising!

But there is also

> Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Program or modified version.

From what I understand the big question is, where is the line on if value is derived primarily from "the Program", and what exactly constitutes modifying the program.

Wait? Would even my devops pipeline fall under it?

Or my monitoring? Deployment and management in kubernetes for example?

SSPL is a malicious source-available license, if there ever was one: https://news.ycombinator.com/item?id=18301116

I reserve special hate for Commons Clause [0] too but SSPL is downright offensive.

A reminder that F/OSS works very well for a lot of reasons [1]. The number one of which is if you want to commodize your product's complement [2][3]. Don't be a knob and F/OSS your core product if you plan to make billions or whatever.

[0] https://news.ycombinator.com/item?id=17814386

[1] http://dtrace.org/blogs/bmc/2004/12/16/the-economics-of-soft...

[2] https://www.gwern.net/Complement

[3] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

HN: "Hey, you're not using an FLOSS license!"

Also HN: Don't be a knob and F/OSS your core product if you plan to make billions or whatever.

They're doing exactly you want: picking a non-free license for their core product, and you're still mad at them.

Not upset because they choose SSPL but because:

1. Avarice: They rode the FOSS wave and gained industry mindshare for a conveniently long time. Now, after making (well deserved) millions on the back of it, they turn to an absurd license to basically say, fuck you, looser, I need my billions.

2. Hypocrisy: Spinning the whole thing as "doubling down on Open" with a source-available license. One must be so delusional to call out "naysayers" as spreading FUD about SSPL when the fact remains that SSPL is a landmine.

3. Short-termism: It is all fun and games till Elasticsearch is wealthy and healthy. Once some PE firm takes over when they get pushed into a corner, I can see them doing Oracle-esque law suites even if it isn't their current intention.

If their core product was Elasticsearch, they could have SSPLd it from the start. I'd be curious to see where they'd have ended up then. I'd absolutely not have been upset in this scenario.

The current scenario is what we are in, lets see how it pans out.

Yes. That's the intent, that if you have some code (such as your devops pipeline) which is used to provide some service to an end user, the end user is able to use/modify/redistribute that code to provide the same service without you being able to obstruct what they do.

No. None of the things you describe involve both providing service to third-parties and modifying SSPL-licensed ElasticSearch code. You are operating the code purely for your own benefit, and you are not patching SSPL-licensed code, and therefore nothing from this discussion is applicable to your described use case. (I'm not your lawyer, etc.)

This change only applies if you are offering Elasticsearch and Kibana _directly_ as a service.

It doesn't impact your devops pipeline or your monitoring workload(s).

Link to FAQ: https://www.elastic.co/pricing/faq/licensing

I would like to point out to anyone else perusing these comments the issue a lot of people are raising in the comments can be summed up in the two responses to the parent:

https://news.ycombinator.com/item?id=25782849

https://news.ycombinator.com/item?id=25784581

The ambiguity is the problem. Yes, the FAQ/A Developer/A Company has said they really mean (A), but the license text, which is the legally binding part, is ambiguous. Even if a judge supports the freest reading of the license, you have to go through the time and resources to get in front of a judge.

For FOSS, this means the majority of projects that run on a scattering of donations + developer free time are dead in the water the first time someone tries to hit them with a Cease and Desist or similar.

Isn’t it a dual license, and the existing license isn’t going away?

It used to be Apache 2.0. You now get to choose between SSPL and "Elastic License".

The current open-source Apache 2 license is being replaced by two proprietary, source-available licenses. Of course this only applies to future releases.

Reply on news.ycombinator.com