4 ms·

I think the term "more open" is a bit too vague in this discussion. Sometimes people use it to refer to permissiveness (e.g. BSD) and sometimes people use it to

I think the term "more open" is a bit too vague in this discussion. Sometimes people use it to refer to permissiveness (e.g. BSD) and sometimes people use it to refer to stimulating further open source work (e.g. GPL). (And if we're following the "definitions" then ElasticSearch is no longer "open source" since that has a strict definition, but it's probably not so relevant in this discussion.) I also don't really object to their license choice at all; what I object to is how they're framing the discussion. This license change is all about business: They want to be able to sell their cloud service without competition. That's perfectly okay, but there's no need to hide this. And certainly no need to "shame" Amazon for building a business on top of something Elastic open sourced. > Have I misunderstood and their new license somehow reduces the openness of their source code to the world? I think their new license just shows that it's all about business. If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of. And why are they fine with Facebook/Google doing this? Because it won't jeopardize Elastic's cloud offering. In addition, their new license also makes it harder for other people to build businesses on top of ElasticSearch. Imagine that I invest a ton of time and effort into creating a new management layer which is capable of scaling ElasticSearch drastically better. Something completely novel which looks at current trends of traffic and automatically moves shards around. Non-trivial stuff. Well, sorry, there's no way of building a business on top of this idea.

sokoloff 6y ago
> If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of GPL does not require releasing source code or patches except to those whom you give the binaries. If Facebook creates an improved internal fork of GPL code and runs it inside of Facebook, they can keep their sources/patches private and be in compliance with GPL. There is a practical advantage to upstreaming your patches: because it makes maintenance easier if those patches are accepted and merged upstream, but there's no legal/license requirement to release them for code that you keep internal to your company.
- fiddlerwoaroof 6y ago
  Isn’t this the situation AGPL3 was written for? It’d probably kill ES and lead to a fork from the latest pre-AGPL3 version, but it’s still an option.
  - metiscus 6y ago
    IANAL but I believe that the AGPL would address the case where AGPL code was used in a user facing setting. If the code was used only internally I believe that it is no different from the GPL in this respect.
    - fiddlerwoaroof 6y ago
      AWS elasticsearch is user-facing: the users are AWS’s clients.
    - 35fbe7d3d5b9 6y ago
      Correct: AGPL3 is GPL3 + one requirement – any user who communicates to a program must be able to retrieve its source code. If ES was under AGPL3, AWS' ES server would absolutely fall in scope. The Facebook example, however, is tricky. You are technically right: the FSF calls this the Service as a Software Substitute (SaaSS) problem[1]. But Facebook can run an AGPL3 project and, as long as they are careful, will not need to expose any changes they make to it. In practice, Facebook and other big corporations are extremely unlikely to do this. If they get it wrong, they've inadvertently accepted a license they didn't mean to, which could open them up to liability or worse – relicensing things. To prevent this you get a set of approved permissive licenses that are always kosher. If you want to stray off the path there is a set of massive flaming hoops you have to jump through (VP approval? legal review? just the beginning of your fun!) that are designed to convince you that you should chose a different path that involve more permissively licensed software. [1]: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s...

sokoloff 6y ago

> If they really wanted an open source license which stimulates anyone to share improvements to ElasticSearch they could have picked GPL. As of now, any big company (Facebook, Google, etc) can create an improved internal fork of ElasticSearch which none of the community will ever be able to take advantage of GPL does not require releasing source code or patches except to those whom you give the binaries. If Facebook creates an improved internal fork of GPL code and runs it inside of Facebook, they can keep their sources/patches private and be in compliance with GPL. There is a practical advantage to upstreaming your patches: because it makes maintenance easier if those patches are accepted and merged upstream, but there's no legal/license requirement to release them for code that you keep internal to your company.

fiddlerwoaroof 6y ago
Isn’t this the situation AGPL3 was written for? It’d probably kill ES and lead to a fork from the latest pre-AGPL3 version, but it’s still an option.
- metiscus 6y ago
  IANAL but I believe that the AGPL would address the case where AGPL code was used in a user facing setting. If the code was used only internally I believe that it is no different from the GPL in this respect.
  - fiddlerwoaroof 6y ago
    AWS elasticsearch is user-facing: the users are AWS’s clients.
  - 35fbe7d3d5b9 6y ago
    Correct: AGPL3 is GPL3 + one requirement – any user who communicates to a program must be able to retrieve its source code. If ES was under AGPL3, AWS' ES server would absolutely fall in scope. The Facebook example, however, is tricky. You are technically right: the FSF calls this the Service as a Software Substitute (SaaSS) problem[1]. But Facebook can run an AGPL3 project and, as long as they are careful, will not need to expose any changes they make to it. In practice, Facebook and other big corporations are extremely unlikely to do this. If they get it wrong, they've inadvertently accepted a license they didn't mean to, which could open them up to liability or worse – relicensing things. To prevent this you get a set of approved permissive licenses that are always kosher. If you want to stray off the path there is a set of massive flaming hoops you have to jump through (VP approval? legal review? just the beginning of your fun!) that are designed to convince you that you should chose a different path that involve more permissively licensed software. [1]: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s...