Live data from Hacker News

Amazon: Not OK – Why we had to change Elastic licensing

elastic.co

581–590 of 708 posts

Re: Amazon: Not OK – Why we had to change Elastic licensing

#582

Earlier quoted context omitted.

Frankly I don't get why OSI proponents are so angry about the use of the term Open Source, when they can just unambiguously use "OSI Approved License" instead. It's borderline gatekeeping and it irks me to no end.

> It's borderline gatekeeping No, it's a term-of-art. When people muddy the waters and try to undermine the standard terminology of a field, it's not some righteous struggle to liberate a term, it's just an obstacle to clear communication. In aviation, flap is a precise term-of-art, and is never used interchangeably with aileron , despite that an aileron is plainly a kind of flap (in the colloquial sense). If you ado…

But it’s not a term of art, when it was first used it had a broad scope for more or less anything where source was made available to users of software.

The OSI definition is a newer more narrow definition adopted long after the term was in broad use.

And fundamentally, the literal meaning of the words open and source do not have connotations beyond the source being available for viewing.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#583
If your organisation uses the Apache v2 licensed Elasticsearch or Kibana in its projects or products, it must now assume that it is at risk one way or another. It can upgrade to version 7.11 of these projects, thereby accepting the terms of SSPL and potentially also being required to release the code for its entire stack (a great deal of which it will not have the copyright over and will be unable to release, thereby potentially being in violation of SSPL). It can remain on version 7.10, but then it will no longer receive future updates, including important security fixes, thereby taking on another sort of risk.

https://anonymoushash.vmbrasseur.com/2021/01/14/elasticsearc...

Re: Amazon: Not OK – Why we had to change Elastic licensing

#585

Earlier quoted context omitted.

That doesn't parse. The SSPL does not discriminate against a person, a group, or a field of endeavor, any more than the GPL "discriminates" against people who distribute modified versions of a program by requiring them to distribute the source code of the changes. Further, the requirement of the SSPL does not cover "distributing with", so point 9 doesn't seem to make sense either.

The main problem is that the license is bad, in the sense that it's vague.

AGPL is GPL with some changes. SSPL is AGPL with some more changes.

There is plenty of vagueness in open licenses. Familiarity over time doesn't make that vagueness go away.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#586

Earlier quoted context omitted.

> I read that article [...] If they had actual proof, they would take legal action against the author of that plugin. The first sentence of that article: > Back on September 4th, we filed a lawsuit against floragunn GmbH, the makers of Search Guard, a security plugin for Elasticsearch

Yeah? SCO sued a bunch of people too. They haven't won, though.

Elastic and Floragunn are unrelated to SCO.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#587

Earlier quoted context omitted.

The new license doesn't restrict others from operating Elasticsearch as a service. It restricts others from operating Elasticsearch as a service unless they release any source code patches, improvements, and/or functionality extensions they make to it. To me, that's exactly what you're saying you expected from liberal licenses, but it's delivered by a restrictive license, using the restrictions popularized by GPL lic…

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 ob…

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

Re: Amazon: Not OK – Why we had to change Elastic licensing

#588
It's pretty clear from the post that Amazon is not acting in good faith and very short-sighted. If they destroy ElasticSearch as a company, their foundation will erode: no more updates, no more improvements, no more bug fixes.

All for another cool billion.

NOT OK

Re: Amazon: Not OK – Why we had to change Elastic licensing

#589
post #562

What gets often never discussed in these debates is below : The sheer inability of OSI to provide a new-age license that can counter AWS. Can anybody knowledgeable shed some light on this topic ? Like what OSI license can counter AWS & if there are none why aren't OSI doing anything.

I'd argue this is pretty much what SSPL was supposed to be: https://writing.kemitchell.com/2019/06/13/SSPL-Not-Commons-C...

It's no secret AGPL was written to solve "the Google problem". SSPL tried to solve "the AWS problem" with copyleft, rather than just banning the use case, which is what Commons Clause did.

Re: Amazon: Not OK – Why we had to change Elastic licensing

#590

Earlier quoted context omitted.

The main problem is that the license is bad, in the sense that it's vague.

AGPL is GPL with some changes. SSPL is AGPL with some more changes. There is plenty of vagueness in open licenses. Familiarity over time doesn't make that vagueness go away.

The argument that it's vague indeed makes sense, but I can't make heads or tails of the one that claims it's not an open source license at the end of the day. If anything, it's more open source than the AGPL.
Post reply on HN