What exactly does `provided it doesn’t expose Elasticsearch functionality` mean? Is exposing KQL via a search field in violation or not? Is exposing the Lucene query language okay or not? Is selling an on-prem monitoring solution that uses ES/Kibana as datastore and visualization interface ok? Is accepting payment from a client to run and maintain that solution in the clients datacenter okay? Is running that solution in a clients private cloud okay?

Can I get that in writing from someone with the power to make binding legal statements?

The problem is never in the clear cases, it’s in the edges. Now, all of a sudden, when thinking about features a legal dimension enters the picture, something that hasn’t been there before.

I agree and find that caveat baffling. "The ability to search a store of information for user-supplied input" is fairly clearly elasticsearch functionality, but it seems that is allowed? They have to be more specific on what this means.

IANAL and I am pretty sure they will need to be involved in a serious way to iron all this out. I have my understanding of the intent, which I would not invest money in at this point trying to prove, and that's as much as I can offer. It seems that you can have users search your data in your Elastic+Kibana instance. What they're precluding is you offering an Elastic instance for your customers to load their data into and then search or offer for search to their users.

I understand the intent, but elastic has proven to create legal confusion despite being warned against it and then sue over it in the past when they mixed the APL source and the x-pack source under two different licenses in the same repo and then sued floragunn over copyright violations. They might be technically correct on that lawsuit, but IMHO they knowingly created that situation.

If they are intentionally causing confusion it seems their right to recover would be seriously limited by their failure to mitigate damages.

I’d not say “intentionally” as I don’t think that this was the motivation behind the change. I’d consider it “knowingly” - they were or at least should have been aware that the change was going to create confusion about the license that individual code parts and changes were under. It was pointed out at that time.

Why didn't Elastic release some SSPL v1.1 or SSPl v2.0 with this kind of clarification? SSPL v1.0 is considered by many kind of vague in terms of p. 13 "Offering the Program as a Service".

> A log search service powered by Elasticsearch is okay (again, provided it doesn’t expose Elasticsearch functionality).

You speak as if Elastic has any say in how people use OSS. Why would anyone use the newly hampered version of ES when they can use and contribute to Amazon's truly open fork? Aside from the bad taste left in everyone's mouth from the whole "Doubling down on open" nonsense, all that reasonable people are going to see now when looking at Elastic's software (ES 7.11+) is unnecessary risk and legal ambiguity.

The disingenous market speak on Elastic's blog post was so thinly veiled that it quickly became insulting. It was gross to watch such a shameful justification form on why everyone should be okay that Elastic will continue using the marketing terms "free" and "open". By forcing a well funded fork by Amazon, Elastic may have just relegated themselves into obsolescence.

This might very well have been your intention, but the license you chose (SSPL) is extremely vague in describing this (section 13, IIRC).

For one data point, my company attorneys interpreted that, even if we present a search box in a web page, allowing visitors to search our own indexed data, it could be understood that we "offer a service" -- and thus forced us to abandon Elasticsearch and figure out alternatives. We might be unique, but I doubt it.