…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. Elastic wants to have their cake and eat it too. They want the wide adoption of open source software, while also preventing people from competing with them. That's not how open source works.
> …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.
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.
- 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?)
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.
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 elastic_license@elastic.co 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-...
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.
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.
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.