Live data from Hacker News

Licensing changes to Elasticsearch and Kibana

elastic.co

261–270 of 378 posts

Re: Licensing changes to Elasticsearch and Kibana

#261

Earlier quoted context omitted.

How true is this, in practice? I hear software folks say this sort of thing somewhat frequently, but I haven't heard it from a _legal_ person. And my general sense and understanding is that although an FAQ style clarification is not _perfect_, it _does_ carry non-trivial weight. Judges are not totally capricious people making arbitrary decisions: the notion that in a dispute they would just cast aside one party's _cl…

In my experience, corporate lawyers don't really understand the distinction and will opt for the route of least risk, which generally entails a commercial relationship with the company. Unfortunately, neither Mongo nor Elastic really offer useful commercial relationships. That is, pay them a sum and be free to use the widely adopted open-source version of their thing. The overhead to those relationships for what they…

> and will opt for the route of least risk, which generally entails

Choosing something else - at least if you can do it before getting locked in.

Re: Licensing changes to Elasticsearch and Kibana

#262

Earlier quoted context omitted.

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not…

Isn’t it a dual license, and the existing license isn’t going away?

It used to be Apache 2.0. You now get to choose between SSPL and "Elastic License".

Re: Licensing changes to Elasticsearch and Kibana

#263

This is an alarmist headline. The SSPL license to which they are switching only requires your code to be open sourced if you are providing Elasticsearch itself as a service. This change is directed at cloud providers who take open source software and then provide them as a service for payment without contributing to the project. If you are using Elasticsearch on your backend to build search-enabled products or websit…

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not…

Here's the actual language from SSPL

> If you make the functionality of the Program or a modified version available to third parties as a service... (license conditions apply)

> “The Program” refers to any copyrightable work licensed under this License.

IANAL, but that seems pretty cut and dry referring to making an Elasticsearch or Kibana service

Re: Licensing changes to Elasticsearch and Kibana

#264

Earlier quoted context omitted.

TFA explains why Elasticsearch switching to SSPL is indeed a cause for concern. Money quotes: > Basically, it’s a hostile proprietary license masquerading in open source clothing. By using an SSPL project in your code, you are agreeing that if you provide an online service using that code then you will release not only that code but also the code for every supporting piece of software, all under the SSPL. > It’s not…

Isn’t it a dual license, and the existing license isn’t going away?

The current open-source Apache 2 license is being replaced by two proprietary, source-available licenses. Of course this only applies to future releases.

Re: Licensing changes to Elasticsearch and Kibana

#265
> The SSPL allows free and unrestricted use and modification, with the simple requirement that if you provide the product as a service to others, you must also publicly release any modifications as well as the source code of your management layers under SSPL.

That doesn't sound like something incompatible with Open Source Initiative standards for "open source". And it sounds like something existing OSI-approved licenses could do?

And yet, SSPL is not OSI-approved, and they did not choose an existing OSI-approved license, instead the SSPL which they say "embodies the principles of open source", but isn't actually an open source license by accepted standards.

So... why? What's going on? What is this really about?

The press release of course doesn't answer the question "why not use an actual OSI-approved license"?

What they describe seems pretty similar to AGPL, which is a pretty inconvenient license for use in commercial products, but is OSI approved. What does SSPL do that AGPL doesn't, and what about it makes OSI approval challenging?

Re: Licensing changes to Elasticsearch and Kibana

#266

Earlier quoted context omitted.

Some observations: (1) It's interesting how much of the reasoning/argumentation for these restrictive licenses ultimately comes down to a more articulate form of "but that's not fair!". I also wonder how much the implicit beliefs that "unrestrained capitalism is a bad thing", "markets naturally lead towards monopolies", "antitrust law is legitimately necessary", etc are impacting peoples' reasoning here. (2) If they…

> 2) If they can't actually compete and provide superior value to whatever managed offering Amazon can scrounge together, that's actually their fault. The sad-funny thing is that elastics hosted cloud offering is clearly superior to AWS’ hosted elasticsearch in pretty much all regards.

It’s important to defend the product and the software ecosystem because so many people are confusing AWS’s offering with what the current state of the system is. It’s so bad that some people actually think that AWS _is_ the developer of Elasticsearch in many cases due to the Elastic-X branding similar to the I-Noun convention that Apple tried to defend against but fell short of squashing around the world. It’s also important to note that not defending one’s trademark sufficiently well means bad things in a court precedent where there needs to be reasonable, demonstrable evidence you’re not simply a patent / trademark troll sitting around waiting for someone juicy to sue rather than small fries.

Re: Licensing changes to Elasticsearch and Kibana

#267

Earlier quoted context omitted.

In my experience, corporate lawyers don't really understand the distinction and will opt for the route of least risk, which generally entails a commercial relationship with the company. Unfortunately, neither Mongo nor Elastic really offer useful commercial relationships. That is, pay them a sum and be free to use the widely adopted open-source version of their thing. The overhead to those relationships for what they…

Mongo absolutely offers this. A company I worked for had a contract with them -- these terms are hugely expensive, to the point it was worth switching to the AWS version when we had no AWS services.

Mongo offers what? A license to use their software and have them not harass me or attempt to upsell me or force me to use their management tooling?

Nah.

Re: Licensing changes to Elasticsearch and Kibana

#268

Earlier quoted context omitted.

In my experience, corporate lawyers don't really understand the distinction and will opt for the route of least risk, which generally entails a commercial relationship with the company. Unfortunately, neither Mongo nor Elastic really offer useful commercial relationships. That is, pay them a sum and be free to use the widely adopted open-source version of their thing. The overhead to those relationships for what they…

> and will opt for the route of least risk, which generally entails Choosing something else - at least if you can do it before getting locked in.

Again, very minor use case. Not worth expending effort on. I attempted to convince the lawyers that we should just yolo it because the product had no actual revenue.

Didn't go well.

Re: Licensing changes to Elasticsearch and Kibana

#269
post #244

Earlier quoted context omitted.

I highly doubt anybody chooses an explicitly free and open source license without intending to offer their software to users under the terms of that license.

I wouldn't be so sure about that. Thinking "is this software going to be resold by Amazon" is not high up on the priority list for someone who is just working on a hobby project/releasing that project under a permissive license. Sure, this is a non problem for 99.99+% of the population and it's a relatively new "problem", but it's fair to retroactively change the license because it's within their rights.

It's only a "problem" for the 0.001-% who choose to view it that way. There's decades worth of large/serious/complex open source projects that have totally been monetised by other companies without the founders/maintainers feeling ripped off and butthurt about it.

Linux, GNU, Apache, Perl, Python, PHP, Rails, WordPress, and many many more projects at least as important and complex as Elasticsearch. We don't hear Linus or Stallman, or Larry or Guido or Rasmus or DHH or Mullenweg complaining about hosting companies profiting off their work.

I get that newer projects are structured differently, and that companies like Redis Labs and Mongo and Elastic are paying salaries to engineers to develop their software - which is _way_ different to the examples I cited above. But just because they've chosen that, doesn't mean they're "right" or entitled to succeed working that way. The optimist in me hopes some of them will, and perhaps this will be a route to the world getting "open source" software written that the old Apache project's model perhaps could never have achieved. I certainly don't think that's a given though.

The pessimist in me feels bait-n-switched, and is wondering how to plan on staying on 7.10 safely and keeping an eye out to see who's gonna fork it and at least keep up security work on it under Apache 2.0 moving forward. We don't "sell Elasticsearch as a service", but we use it enough that I don't want to ask for legal budget to mitigate the risk of upgrading away from the Apache 2.0 licensed version. I don't trust SSPL enough to want use anything licensed that way, and I doubt I'll be very happy with Elastic License either if I spend enough time to read/understand it properly...

Re: Licensing changes to Elasticsearch and Kibana

#270

Earlier quoted context omitted.

> and will opt for the route of least risk, which generally entails Choosing something else - at least if you can do it before getting locked in.

Again, very minor use case. Not worth expending effort on. I attempted to convince the lawyers that we should just yolo it because the product had no actual revenue. Didn't go well.

I can get at least a couple of person-weeks worth of dev done for the cost of sending the email that results in attempting to convince the lawyers of _anything_.

I wouldn't even ask for a legal review of this new Elastic License, if I thought I could tear it out for less than 2 dev-months of effort.

Post reply on HN