7 ms·
> Apart from the general consternation about an OSS license becoming non-OSS, can we also talk about the problem that companies are formed, invest a whole lot o
by judofyr 6y ago
> Apart from the general consternation about an OSS license becoming non-OSS, can we also talk about the problem that companies are formed, invest a whole lot of resources into creating a product, open-source it, and then have Amazon eat into their profits by just installing and maintaining that product as a service?
Ten years ago I would be very hesitant adopting ElasticSearch if I knew that they were the only ones allowed to maintain a cloud solution of it. The fact that is was liberally licensed made me less afraid of vendor lock-in.
In my opinion it seems like Elastic wants ElasticSearch to still be perceived as the fully open source project (with all of its good connotations) it once was.
> AWS is the fly in the ointment there, and I don't see how blaming Elastic for not giving us stuff for free any more is anything other than entitled. We should be grateful that ES is OSS at all, and we should want an environment where companies that produce OSS can thrive, instead of blaming them for wanting to get paid for the work that they release freely into the world.
It's okay to release things as non-OSS. It's also okay to release something as OSS first, and then regret later. But it's super weird that they're painting this picture of AWS being a big evil company when they're just doing exactly what is expected. Can't they just say "we're not able to build a company around the liberal license" instead of this "we're such an open company and we love open source and AWS is ruining everything" talk?
- tshaddox 6y ago> In my opinion it seems like Elastic wants ElasticSearch to still be perceived as the fully open source project (with all of its good connotations) it once was. That’s my attitude towards most of these license changes or “open core” pivots. These companies want all the good will and community contributions of “open source” while still being able to wield intellectual property protection laws against other companies who dare compete against them on unrelated, commoditized services like hosting.
- treis 6y agoIt's somewhere between bait and switch & dumping. It's very hard to compete against free. And it's very hard to make money when you give away your product for free. Cloud hosting was a way out of that conundrum. But that window is now closing as the big cloud operators move in + the rise of Docker making hosting much easier.
- tshaddox 6y ago> And it's very hard to make money when you give away your product for free. Cloud hosting was a way out of that conundrum. But surely it's only a conundrum if the primary goal of a software project is for a single company that has the same name as the software project to exclusively make money by selling hosting and/or support for that software while still using an open source license to attract a community of developers to work for you for free. I'd argue that this conundrum is easily resolvable: either have an open source software project for which anyone can sell support and hosting, or have a software company that develops proprietary software and sells it and related services.
- rossjudson 6y agoThe only mistake Elastic seems to have made here is not releasing ElasticSearch under something like the SSPL in the first place. Of course, it didn't exist then. Almost every user would have been free to use it exactly as they do today.
- stingraycharles 6y agoI think AWS is a case of someone ruining it for the rest. Yes, they’re allowed to do that and there’s nothing wrong legally, but in the end everyone will be worse off. I would be much more hesitant choosing an storage solution if I knew the parent company has problems monetizing upon it.
- mbreese 6y ago> more hesitant choosing an storage solution if I knew the parent company has problems monetizing You should be hesitant about choosing any mission critical product where you don't know how the vendor will make money. This is even the case with stable vendors. How many products has Google killed over the years because they could figure out how to make them profitable (enough)?
- johncena33 6y ago> How many products has Google killed over the years because they could figure out how to make them profitable (enough)? HN never ceases to amaze me. This is a post on pattern of exploitative and anti-competitive behavior of AWS. Somehow HN crowd found a way to whine about Google. Every single day multiple anti-Google posts on HN front page was not enough.
- chillfox 6y agoIt is simply the effect of Google spending their reputation as if it is a never ending fountain of free cash.
- rossjudson 6y agoHow many products has Google not killed?
- antonvs 6y agoIt's quite a long list.
- 6y ago
- floatingatoll 6y agoThe 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 licenses. This makes ElasticSearch more open source, rather than less, because now anyone who uses it has to "open" their source code. That's the premise of GPLv3 in a nutshell, and I'm hard-pressed to understand how it's a drawback here. Have I misunderstood and their new license somehow reduces the openness of their source code to the world?
- Conan_Kudo 6y ago> 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. If this was AGPL, I'd agree with you. IANAL, but SSPL is so broad that it could be construed to cover the Linux kernel, which is a no-no. :(
- floatingatoll 6y agoWhat real, non-theoretical, "would stand up in a courtroom" risk is there if the SSPL extends to cover the Linux kernel? SSPL: you have to share your source code to the Linux kernel if you sell Elasticsearch-as-a-service" GPL: you have to share your source code to the Linux kernel if you release binaries SSPL+GPL: you have to share your source code to the Linux kernel if you sell Elasticsearch-as-a-service or if you release binaries As long as the source is duly published under the merged SSPL+GPL conditions above, anyone trying to bring a GPL case against Elasticsearch-SSPL-on-Linux-GPL may discover that their judge refuses to enforce the GPL's hostility clause, because the SSPL strengthens the intent of the GPL without weakening it in any respect. We'll never know until someone gets to a judge, though, but my armchair speculation bet is that the "can't combine this license" clause won't hold up when the combination increases the total amount of Copyleft in play without decreasing it in any regard. I hope someone takes this to court and doesn't settle, or else we'll never find out :) (I'm not your lawyer, this isn't legal advice, etc.)
- btinker 6y ago> In my opinion it seems like Elastic wants ElasticSearch to still be perceived as the fully open source project (with all of its good connotations) it once was. This. It is too bad they couldn't have satisfactory financial success building on open source and it is their right and perfectly fine to switch to a different model, but their justification as well as the SSPL dual licensing muddle the water unnecessarily. At least the blogpost clearly states it is no longer open source, but then it goes "it's just definition, we're actually totally free and open, just, you know, not OSI free and open". SSPL software is not free software, it is not FOSS. Calling it "free and open software" is misleading at best.
- kemitchell 6y agoI don't have any problem calling SSPL software "open source". Or AGPL software, for that matter. What's not free or open about applying copyleft to network services?
- rpdillon 6y agoThe license discriminates based on field of endeavor, invoking additional constraints on the basis of what you use the software for. The legal team for Fedora expressed this well, I think: > It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IQIOBOGWJ247JGKX2WD6N27TZNZZNM6C/ https://lists.fedoraproject.org/archives/list/devel@lists.fe... I think it is this discrimination that makes in not as free or as open as AGPL and GPL.
- kemitchell 6y agoThe field-of-endeavor and persons-or-groups discrimination arguments don't stand up. They just sound nice if you want to knock the license. If SSPL discriminates against a "field of endeavor" that is making proprietary software, or against "persons or groups" that are proprietary software developers, all copyleft licenses do. That was the point. Here's Richard Stallman on the GPL: > I make my code available for use in free software, and not for use in proprietary software, in order to encourage other people who write software to make it free as well. I figure that since proprietary software developers use copyright to stop us from sharing, we cooperators can use copyright to give other cooperators an advantage of their own: they can use our code. https://www.gnu.org/philosophy/pragmatic.html https://www.gnu.org/philosophy/pragmatic.html The quote from Fedora perfectly encapsulates the difference between the OSI review process as people perceive it and the OSI review process as it really was. Are we judging license terms, or what we believe to have been in the secret heart of the company that wrote them? What happens when someone else uses the license, as when independent hackers choose GPL, or startups choose AGPL? Commercial software makers have plenty to fear from GPL, AGPL, and other open source copyleft licenses, because so many of their business models entail slurping up other people's open code, but not sharing their own. Those licenses prohibit building proprietary software with open code, just not if you happen to "compose" a service with network API calls, rather than build a program by copying code snippets, using frameworks, and linking libraries.