Slightly off topic but...

> …except Elastic doesn't want to use the AGPL because anyone using Elasticsearch would have to open-source their whole codebase — a non-starter for most companies.

They wouldn't have to. This is a common misconception about AGPL.

Is the AGPL not a copyleft license? What are the derivative works you're required to distribute as AGPL?

AGPL is meant to address the situation where someone takes GPL code, such as a database server, runs it on their systems (possibly with proprietary modifications), and provides network access to it to users, and does not provide those users with the source code. That is perfectly acceptable under GPL, GPL doesn't trigger if you aren't distributing the program.

What AGPL changed is that they made it trigger on distribution (like GPL) and on interactive access of modified versions over a network.

If Amazon's plan had been to make money by hosting a proprietary fork of the server, which would give them some sort of advantage over other clouds like Azure or Google that only have the non-proprietary version, AGPL would thwart them.

But that doesn't seem to be the case. They don't appear to trying to make it proprietary. They seem happy to run the same code that everyone else does. They are making money from it by selling management and support services for it.

AGPL doesn't impede doing that at all.

If you're using a database that's not tightly integrated into your project and distributed with it, I don't believe you'd have to open your project. The API is the boundary:

- your project running on Linux kernel doesn't become GPL

- your project talking to MySQL doesn't become GPL and one talking to mongodb pre-2018 doesn't become AGPL

- your project talking to elasticsearch wouldn't become AGPL

(However AWS search offering... could?)

If you modified the software and then sold a hosted solution using the modified software you would need to release the source code for your modifications. Or if you built a plugin that was directly linked to the software you might have to release the source for that plugin. But if you had other software that made network calls to the software I'm pretty sure you wouldn't have to open source that as well.

This FUD about the AGPL drives its unpopularity more than any reality.

Amazon is in compliance with the terms of the AGPL already for their managed ES. Switching ES to from Apache to AGPL would only affect other users of ES, not Amazon.

> Elastic wants to have their cake and eat it too.

That doesn't follow from your preceding statement. Elastic doesn't want to constrain all users of their software by using AGPL; and instead they adopted a license which imposes restrictions only on cloud providers. That's better compared to AGPL for general consumers, if you ask me.

The "have their cake" is enjoying widescale adoption of a liberal open source license. The "eat it too" is thereafter making that license restrictive to shut down competition.

Not if I am a cloud provider.

Jason from Elastic here.

I want to clarify this. Building a SaaS product with Elasticsearch or Kibana on the backend is okay and not prohibited, as long the service is not “managed” Elasticsearch nor Kibana. For example, a music service that uses Elasticsearch on the backend to provide music catalog search is okay. A service that offers site search powered by Elasticsearch is okay. A log search service powered by Elasticsearch is okay (again, provided it doesn’t expose Elasticsearch functionality). We welcome applications built with Elasticsearch or Kibana in the backend, even those that would be seen as competitors, as long as they are not managed Elasticsearch nor Kibana services. The Elastic License allows this, and you can do it for free. See this [item][0] in our FAQ. If you have any doubt, reach out to [email protected] and we would be happy to clarify.

Disclaimer: I am on the Elasticsearch team and work for Elastic; I welcome any and all feedback.

[0]: https://www.elastic.co/pricing/faq/licensing#i-build-a-saas-...

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.