"And to be clear, this change most likely has zero effect on you, our users. It has no effect on our customers that engage with us either in cloud or on premises."
No, that's just not true. So many users, from small hobby side-projects, to large open source projects, and mega-corps care about the licensing of dependencies, each for their own reason, and will not want to build on top of proprietary software that imposes draconian licensing terms.
It doesn't matter what they say, read the license. It's vague and there is no legal precedent. It's a big risk for anyone who cares about licensing issues for their projects.
I find these kind of obscure, “don’t worry” posts to increase my worrying. Part of the simplicity of open source is that it’s available for easy audit. Having to hire lawyers to use a product means I probably won’t use it.
I also think having people saying “we’re open, but read the fine print” is not good for open source collaboration as it increases confusion and complexity.
Elastic is moving the way of a commercial software company. That’s perfectly fine as it’s their company, but it’s just different than open source.
Yup. If you, understanding your product, your users, and your licensing, write a post for your users not to worry, it means that you thought about your changes and came to a well informed position that there was reason for worry.
Well, you try to make it sound unlikely, but it's exactly like corporate messaging that there are no plans for layoffs in the wake of bad financial news.
The idea that a license change made to prevent competition and enable a business model centered around extracting monopoly rents from customers has no effect on customers is ludicrous. It's whole point is to have an adverse effect on customers.
Or you might have a history of people being mad at you (for good reasons, like the story of security of the ELK stack). They know very well everybody will get mad again, so they precede all explanations by "don't worry".
> It doesn't matter what they say, read the license.
I would love to but the terms within the ElasticSearch codebase on Github are quite confusing. Here's the text of the LICENCE.TXT file.
Source code in this repository is covered by one of three licenses: (i) the
Apache License 2.0 (ii) an Apache License 2.0 compatible license (iii) the
Elastic License. The default license throughout the repository is Apache License
2.0 unless the header specifies another license. Elastic Licensed code is found
only in the x-pack directory.
The build produces two sets of binaries - one set that falls under the Elastic
License and another set that falls under Apache License 2.0. The binaries that
contain `-oss` in the artifact name are licensed under Apache License 2.0 and
these binaries do not package any code from the x-pack directory.
Aside from not showing copies of the applicable licenses, it seems you have to read the code headers to determine which source file has which license. There are a lot of ways to respond to competitive threats from Amazon, but this approach is increasingly chaotic the closer you look.
The license change to the dual-license with SSPL and Elastic License hasn't happened — this is the state so far and all the code outside the `x-pack` folder is Apache v2 licensed.
Does this even work? ES was considered 'one work' at some point, right? It's developed together, not file-by-file. How is it possible then to license it file-by-file? Wouldn't most of those files be derivative works of the old 'one work' anyway? (Meaning they have to keep the original license, meaning "the default license, Apache License 2.0"?)
Sure, at some point someone started to create a plugin for ES (let's say the security/ACL thing in x-pack, used to be called Shield or something like that), they used the ES API and they used runtime linking. (I have no idea if that's okay or not, has been tested in court or not. I know the US Supreme Court will say something about that in June.) But when developing any feature in that plugin nobody thinks of just that plugin. Folks think about ES as a whole, indexes, shards, documents, terms, maybe even in terms of low-level Lucene primitives.
I think it's practically impossible to wear the OSS and the proprietary hat at the same time. (Or separately but on the same project.)
If ES is the sole copyright holder, they can license it to whomever they wish under whatever license they wish. IANAL, but it seems perfectly coherent to me that they can say "If you build the software this way, we release it to you under X license. If you build it that way, we release it under Y license."
Open-source and free software licenses don't imply that the source must remain served on some site, and it doesn't imply that the license for the code cannot change for future versions of that code necessarily- as it depends on the license and/or other factors.
But if you have a copy of the license and the code and it permitted use of it perpetually, then it can continue to be used. That's my understanding.
If you're a paying customer, you are probably fine.
If you're using SSPL'd Elastic (or Mongo DB, the risks are the same) for anything serious -- i.e. beyond a hobby, get legal advice ASAP.
SSPL isn't an OSI certified license; many would call it at best a 'shared source' license because of the riders attached.
[DELETED because, as user `gpm` points out, OSI doesn't own 'open source' as a trademark, sorry about that -- the need for legal advice doesn't go away, however.] In fact given their kvetching about Amazon and their trademark, Elastic's cheerleading of open source in this and the original blog post seems to be a bit misleading and doing OSI's trademark a disservice.[/DELETED]
Trademarks are not a requirement for defining terminology. The word "cake" is not trademarked, but if I sell you a used car tire when you buy a "cake" from me, I still lied and misled you about the product.
I don't think we really need that. The current solution works relatively well: anyone using open source in a sense other than that described by the OSI, is reliably met with a hailstorm of criticism on HackerNews for being disingenuous. That's as it should be. It's a term of art in the software world, and we don't insist on legal enforcement of every term of art.
I tend to capitalise the term, Open Source, to emphasise that I'm using it an a precise way. I do the same with Free Software. Not ironclad, but I figure it probably helps.
With all of that said, I don't think anyone should be permitted to deliberately mislead people when they're pushing a product. It's obviously right that false advertising is forbidden by law.
That’s what I used to think, but now more companies use “open” with non-OSI licenses and they aren’t run out of town and told STFU.
Personally, any project using “open” in the name that’s not OSI, I pretty much ignore. But it seems to be growing (eg, “open core”, “openai”, stuff like this taking about open with non-open licenses).
It’s getting hard to filter out. One of the benefits I think to CCn is that it clearly lets users know what is and is not allowed. Having OSIn might help with people who don’t read licenses for fun.
I think "OSI Approved Open Source License" could easily be an OSI trademark, if it's not already.
Ironicallly, like many other organizations, Elastic themselves have used OSI's approval as a benchmark for 'open source'[1]:
> Is X-Pack now open source?
> Updated on 2018-04-24 with a link to the Elastic License
> Open source licensing maintains a strict definition from the Open Source Initiative (OSI).
> As of 6.3, the X-Pack code is open under the Elastic License. However, it will not be 'open source' as it will not be covered by an OSI approved license. The interaction model for open X-Pack will be identical to the open source Elastic Stack, including the ability to inspect code, create issues and open pull requests via our existing GitHub repositories.
> I think there are valid differences in opinion in what “open source” means
Disagree. It's a well standardised term of art: it means what the OSI define it to mean. It's pretty precise, and is not a meaningless marketing term like premium. Similarly free software (and especially Free Software) means what the FSF defines it to mean.
When people start using these terms to mean whatever they feel like it should mean, it muddies the waters for those of us trying to have serious discussions about these topics. Tellingly, such redefinitions are generally broader than the accepted OSI definition, so as to include whatever product someone is trying to push.
> Tellingly, such redefinitions are generally broader than the accepted OSI definition, so as to include whatever product someone is trying to push.
I disagree. In fact I'll present the counter example of "myself". I don't agree with the OSIs definition of open source, I think it run contrary to the plain meaning of the term, and is contrary to pre-OSI use of the term. I've argued that numerous times on this forum (and I'm going to avoid repeating these arguments in depth here, just google "gpm Open Source site:news.ycombinator.com"/"gpm Open Source site:lobste.rs" and you will be able to find the arguments).
I have never pushed a product claiming to be open source that does not meet the OSIs definition, nor do I anticipate I ever will, since that seems to be a great way to make discussions about the product devolve into arguments about licensing, which is terrible advertising.
The fact that these arguments usually only come up when there is a reason to argue, i.e. someone has used the term in a way outside of the OSIs definition, does not mean that people only think the right definition of the term is something else when it's for their own benefit.
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.
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 adopt your own definition of flap, to refer to both flaps and ailerons, no-one is going to sue you, but no-one is going to know what you're talking about. Your use of the term will be considered not merely different, but wrong.
Similarly, you could try telling a physicist that you consider the words power and force to be interchangeable. They're not going to sue you, but they're also not likely to entertain your deliberate misuse of standard terms.
Are pilots and physicists gatekeeping by being so insistent that you use their terms their way?
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.
> when it was first used it had a broad scope for more or less anything where source was made available to users
I'm not sure the early history of the term really matters. Presumably early aeronautical engineers and early physicists had to all agree on the terms of their field. It's fortunate that they did so, and now that their field is mature, their terms are clear and unambiguous.
Someone without an education in physics might not be able to intuit that physicists use the terms strength, hardness, and toughness in distinct and precise ways.
> The OSI definition is a newer more narrow definition adopted long after the term was in broad use.
I'd say it's a more considered, more precise, more meaningful definition.
> the literal meaning of the words open and source do not have connotations beyond the source being available for viewing
I already gave the example of flap, a precise term-of-art in aviation that reuses a non-technical English word in a way that cannot simply be intuited.
I also don't see that open needs to be a synonym of viewable. I think it's fine that open be used to refer to something broader, as in the Open University for instance. [0]
Apparently the OSI was founded February 1998, the same month the term open source was first coined [0][1]. The OSI says [2] The Open Source Definition was then created during the launch of the OSI in Feb. 1998 by revising the DFSG and removing Debian-specific references.
This seems to indicate that the OSI's precise definition was pretty much there from the beginning, unless they didn't really coin the term open source and it was floating around beforehand. I've heard from others that open source was in use before the OSI definition, so perhaps that's the case.
As I mention in my response though, I don't think the term's early history much matters.
You say you’ve heard that but you cannot find the proof, because if it was in use, it was only used occasionally. They coined the term and they gave it the definition.
It's especially ... ironic, that they think Amazonification is not-ok, but Enterprizificaion (open core) is a-ok.
That said hosting ES is basically the same as building a carwash, or a gas station, or let's say a printing house. You get the machinery and build your own support services around it.
Even the unit economics are not that different. AWS spent probably millions of dollars to push the marginal price down. The initial cost of procurement for machinery might be zero for ES as opposed to buying a printing press, but none of the aforementioned sectors are limited by the cost of machinery. In case of brick and mortar services the cost of land, labor, construction, and logistics are all a lot more important.
Yes, okay, but what about AWS's advantage, their "moat"? Elastic will never be able to match that. This is the same problem that plagues the browser, phone OS (and other) markets. Google can easily spend a billion USD each year on fiddling with Chrome and Android. Mozilla, Canonical, KDE, and others can't.
AWS has the platform advantage, Google has money.
It seems these market forces virtually force ES to become a "public good" like the Linux kernel. (Or Elastic could try to fork it and stop using any kind of free/open/available license. And try to find business niches.)
But at this point the cat is out of the bag. Likely no amount of license engineering will be sufficient to overcome AWS' advantage.
The cloud providers would just build a competing service if they couldn't co-opt an existing popular open source solution. Or anoint an adjacent solution, like solr in the case of elasticsearch. But what can be done and we really haven't seen a "open-core" type infra component try this yet: is require open-sourcing changes. The opendistro approach sorta gets us there, in a hard-fork sense, but seems in adequate and is really only being done for connivence rather than licensing requirements. But we already have a licensing solution: the AGPL. But no enterprise or saas startup wants to touch AGPL software for the fear of it contaminating proprietary code. So it seems to me the solution is a hybrid APGL for cloud providers and apache/mit for others approach. Such a license seems feasible to write and would be superior to open-core for most users.
... a bit theoretical, but how is the GPLv3 with the anti-Tivo provision okay?
OSI definition 10: License must not restrict interface, and def. 9. License must not restrict other software it gets distributed with. (So I can't put my encrypted bootloader and verifier into the same thing.)
The open source world needs to come together and create a license that is well crafted. Otherwise we will keep seeing these less suitable licenses.
So far the FOSS world seems to be pretending this problem doesn’t exist. Pretending a problem doesn’t exist doesn’t make the problem go away. It makes you go away as you become irrelevant.
There is the AGPL, but it's not quite right. It also has the letters G-P-L in it, which spooks a ton of people still influenced by Microsoft's billion dollars worth of anti-GPL FUD. (I'm convinced you could just rename the GPL and all those problems would go away.)
> The open source world needs to come together and create a license that is well crafted.
It has created several.
It hasn't created licenses well-crafted for purposes directly contrary to the purpose of having open source software, because that's not what the open source community is interested in.
> So far the FOSS world seems to be pretending this problem doesn’t exist.
From the point of view of the FOSS world, the issue here is not a problem; creators having an exclusive ability to monetize software as a service isn't a purpose open source is intended to serve; in fact, avoiding the lock-in that results from such exclusivity is a big part of the point.
> From the point of view of the FOSS world, the issue here is not a problem; creators having an exclusive ability to monetize software as a service isn't a purpose open source is intended to serve; in fact, avoiding the lock-in that results from such exclusivity is a big part of the point.
If the creators get nothing, then why bother? Why slave away to make software just to give free labor to billion dollar companies while you get nothing? Is free labor for Amazon what open source is about?
If open source refuses to adapt to the realities of today's software ecosystem, it will die out... or at least "serious" open source projects will die out and all that will remain is hobbyist level stuff, abandonware, and half-done academic projects.
Personally I do think FOSS in its present form is going to die for most major projects. You'll still see FOSS libraries, building blocks, academic projects, and some major projects that really are large and old enough to have enough real grassroots contributors to keep them going. For major projects in the future you're going to have something more like a shareware model but with source-available.
Nobody creating a new large-scale project today is going to give it a license that they know will result in somebody else productizing it, making a fortune, and giving them nothing. At least Amazon acknowledges where things came from... in some cases the productizers even rename the project and don't even give the author credit.
FOSS and its gift culture ethos just isn't working in today's world. The software market of today is a dark forest.
> FOSS and its gift culture ethos just isn't working in today's world.
It absolutely is working the same way it always has (to which “gift culture” matters only around the edges). It doesn't work for people who want to start a business with a business model of using copyright law to extract monopoly rents, but then, it never has, and that's always been the point.
And, yes, it's not, for that reason, a good fit for narrow software entrepreneurship, but that's always been the domain of proprietary software.
What's new is startups building on OSS to build mind share, and then trying to shift to rent extraction while wanting to pretend to still be interested in OSS.
I don't think I totally disagree, but here's the problem: if OSS is not a good fit for software entrepreneurship, then it puts a really severe cap on how advanced, polished, easy to use, or well supported OSS can be, because pushing really hard on software development and implementing tens of thousands of hours of fine-grained polish is far beyond what the vast majority of people can afford to (or are willing to) volunteer for free.
It places really polished products beyond the realm of OSS. If you're fine with that, then there's no problem. Perhaps OSS has achieved its goal, namely creating a free and open software ecosystem for nerds and by nerds.
I can't think of a single OSS project used (directly) by a large number of the general public that does not have a company behind it. I think that says something.
> if OSS is not a good fit for software entrepreneurship, then it puts a really severe cap on how advanced, polished, easy to use, or well supported OSS can be, because pushing really hard on software development and implementing tens of thousands of hours of fine-grained polish is far beyond what the vast majority of people can afford to (or are willing to) volunteer for free.
Even if they start out as labors of love, OSS that gets beyond the niche stage tends not to have most work done “for free”, it's done (or paid for) by people/firms who are using the software in their business, but where the software is supporting, not the thing being sold. (Whether the OSS is infrastructure that is invisible to customers, or whether what is being sold is support and professional services tied to the OSS software.)
Very few OSS projects get popular enough and are structurally amenable to that kind of group contribution scenario. Of those that are, in most cases it results in an unusable hodge podge of crap rather than a well crafted product.
> Very few OSS projects get popular enough and are structurally amenable to that kind of group contribution scenario.
Yes, very few open source projects ever move out of the fringes of relevance. That's always been true. The idea that there has been some radical change making OSS less relevant is just false; what has happened is that OSS has gotten enough mindshare that people who want to use business models that OSS has never been a good fit want to use OSS as an early marketing gimmick, and then pivot out of it without paying a price for not being OSS. And are upset that people who do care about OSS are calling them on their B.S. when they try it.
I think we have a very different view about the goals of OSS then, and I think your idea of its goals is narrower.
I wish all software could be at least source-available and preferably available under even more liberal terms if that could be made to work. That way we could see how things work, learn from things, debug with the benefit of source, port things to different platforms or fix platform problems without waiting for the vendor, contribute if for no other reason than experience, and preserve software after vendors go belly-up without having to resort to emulating old platforms whole cloth.
I also wish there was mainstream adoption of open software for privacy and security reasons. I wish people could use operating systems, web browsers, messengers, and so on whose source could be audited so people could understand privacy implications.
That would all give us more freedom and more transparency, but it also requires a business model to sustain those kinds of projects. As it stands nobody outside geekdom uses open source software because there is no business model to sustain OSS with the degree of polish demanded by end users.
Yep, it's also incompatible with virtually all copyleft open source licenses. So if you were using any AGPLv3 code with elastic you now have to switch to Amazon's fork.
Yes, it's incompatible, although you might be fine if you aren't distributing it or running it as a service. SSPL requires re-licensing of all code to the SSPL, GPL has provisions that disallow re-licensing.
> the simple requirement that if you provide the product as a service, you must also publicly release any modifications as well as the source code of your management layers under SSPL
This provision is effectively impossible for anyone to comply with in practice. Calling this a "simple requirement" is a barefaced lie.
Especially that no independent party with any authority (ie. a court) determined what's covered under "management layers". If I use a custom kernel (that's optimized to run the JVM and has filesystem and block storage optimizations for ES), do I have to provide the source for that? (It seems trivial that it's not "management", but naturally Elastic's interest lies in arguing that yes, that are covered under management layers too.)
The problem of the known open source licenses (vs this no-precedent one) is that they were made long time ago for other situations and they do a poor job at protecting open source authors from the abuse that we see from Amazon and similar.
I'm confused by the "abuse" part. If I think the author of the GPLed project "foobar" is a jerk, and I fork it and maintain it without colaborating with foobar's original author, am I "abusing" the GPL?
Personally, I don't think so, and I think I should have the right to do so. I wonder how this is different from Amazon behavior here. (I want to make clear that I'm not saying Shay or anybody at elastic is anything. This is for the sake of the example.)
Now foobar's author can stop me from using his project name by registering a trademark on it. But the GPL is working as intented.
At the end, "maintaning" a fork of Elastic is wasted engineering effort and time, it would be better to collaborate. But I personally think Elastic should just ignore Amazon and keep doing what their doing, instead of making their product proprietary.
I never said forking is abusing. But if you fork it, position it as an official product with the same name on your platform and lie on twitter saying that your foobar was a collaboration with the original foobar author then yes, you are definitely abusing your power.
On the other point: "the GPL is working as intented" yes but not as the authors want, hence the change of license! Nothing wrong with that IMHO.
So what would be your advice for them in this situation? They are developing a product for Amazon for free, Amazon is making tons of money on it and they don't receive anything back.
This lack of clarity in law will likely result in huge issues in the sale of your startup if you ever go that route. Who wants to buy a potential lawsuit because of a database selection?
No, that's just not true. So many users, from small hobby side-projects, to large open source projects, and mega-corps care about the licensing of dependencies, each for their own reason, and will not want to build on top of proprietary software that imposes draconian licensing terms.
It doesn't matter what they say, read the license. It's vague and there is no legal precedent. It's a big risk for anyone who cares about licensing issues for their projects.