5 ms·

The hole did exist ten years ago, though. The AGPL was released in 2007, three years before Elasticsearch was created, to fix this exact problem. …except Elast

The hole did exist ten years ago, though. The AGPL was released in 2007, three years before Elasticsearch was created, to fix this exact problem. …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.

deleted 6y ago
[deleted]
jeswin 6y ago
> 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.
- bawolff 6y ago
  Not if I am a cloud provider.
  - jasontedor 6y ago
    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 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-application-using-elasticsearch-as-the-backend-how-does-this-affect-me https://www.elastic.co/pricing/faq/licensing#i-build-a-saas-...
    - snikolaev 6y ago
      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".
    - Xylakant 6y ago
      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.
      - indeed30 6y ago
        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.
        cestith 6y ago
        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.
        Xylakant 6y ago
        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.
- jakelazaroff 6y ago
  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.
turminal 6y ago
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.
- jakelazaroff 6y ago
  Is the AGPL not a copyleft license? What are the derivative works you're required to distribute as AGPL?
  - viraptor 6y ago
    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?)
    - deleted 6y ago
      [deleted]
  - tzs 6y ago
    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.
mr_toad 6y ago
This FUD about the AGPL drives its unpopularity more than any reality.
tsimionescu 6y ago
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.

deleted 6y ago

[deleted]

jeswin 6y ago

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

bawolff 6y ago
Not if I am a cloud provider.
- jasontedor 6y ago
  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 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-application-using-elasticsearch-as-the-backend-how-does-this-affect-me https://www.elastic.co/pricing/faq/licensing#i-build-a-saas-...
  - snikolaev 6y ago
    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".
  - Xylakant 6y ago
    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.
    - indeed30 6y ago
      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.
      - cestith 6y ago
        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.
        Xylakant 6y ago
        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.
jakelazaroff 6y ago
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.

turminal 6y ago

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.

jakelazaroff 6y ago
Is the AGPL not a copyleft license? What are the derivative works you're required to distribute as AGPL?
- viraptor 6y ago
  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?)
  - deleted 6y ago
    [deleted]
- tzs 6y ago
  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.

mr_toad 6y ago

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

tsimionescu 6y ago

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.