Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I see it as “there are a variety of licenses from which to choose, depending on your goals”. BSD, Apache, and MIT all represent different points in space, as do GPL and AGPL.

When I choose Apache or MIT, I do so for a reason and if you or Amazon use code in compliance with that license, I’m happy and you’re not “exploiting a gap” but rather “complying with the terms I offered”.



Fully agree with this. Free is free, you could always argue that there is "a spirit to open source"; but as with everything there's always going to be people exploiting and using it, that comes with the free.

To me it boils down to if you think that it's worth it: whenever I put MIT or Apache 2.0 on my public Github projects, I don't mind anyone going out making millions on them. Other side of the coin; if I make millions on some obscure library I found on Github with an MIT license, I do not expect them to be outraged about it.

If you do not think it's worth it, as you said there are a range of other licenses out there. I love the notion of human knowledge being free and available to all to the fullest extent, I think it will drive (and has driven) immense value for humankind.


People also seem to miss a point when trying to invoke the "Spirit of the Open Source License": The only reason why Elastic is changing their license is because they want to profit from it. So, isn't that exactly against the "Spirit of Open Source License"? If they truly cared about that, they should be angry about it at all.

Choosing sides here seems to be choosing between two profit seeking companies. Why, as a developer, you should take a side?


I as a developer take the side that allows me to use the open source code as I see fit based on the license terms provided. Elastic initially chose a license which would allow them to capture more of the market/mind space of developers and now that they've accomplished that they want to fully monetize those developers.


It's worth keeping in mind that we don't always know which projects will truly become successful. The precursor to Elasticsearch, Compass, wasn't hugely popular. When I started looking hard at Elasticsearch, with plans to actually use it, I had to spend a lot of time explaining why I didn't want to use Solr, which was much more popular at the time.

In my opinion, the bottom line is this: if Amazon's exploitative behavior is continues then we're going to see more and more open source products shift towards janky-kind-of-open-source or entirely closed licenses. Small or experimental projects will have open and permissive licenses, their authors will have plans for shifting licenses should the product become really successful.

I think it marks the end of this idea that you could have an open source project and then build a commercial offering around it. No matter who you are, odds are good Amazon will get such an offering off the ground faster and they have a built-in market of AWS customers.

Elasticsearch has made their motives clear: they have real concerns that Amazon is diluting their brand and they feel that Amazon is costing them too many customers with their proprietary AWS product. We can quibble about the morals of Amazon's move (they have none, corporations have no morals) but let's not lose sight of the outcome: Amazon has forced another OSS project to switch to a closed license[0].

[0]: https://techcrunch.com/2019/02/21/redis-labs-changes-its-ope...


Amazon's behavior may feel exploitative, but it isn't. That would be like saying Red Hat is exploitative.

Part of the whole concept of free software is that you have freedom of choice with vendors (this is derived from "freedom 0"). Amazon is providing the software and its support as part of the Elasticsearch offering as a managed service. Elastic is a competing vendor, both as a managed service and in a traditional sense too.

Elastic made this decision because they wanted to be the exclusive vendor for Elasticsearch. That's fine, but it's not in the spirit of free software.

If anything, Elastic has exploited the third-party contributors who contributed to Elasticsearch under a CLA by promising to not do what they did and then blaming AWS for doing it anyway.


I don't think it's fair to say that Elastic wants to be the exclusive vendor of Elasticsearch. They have registered and own the trademark, I believe it is fair to say that they want to be the only vendor who can use that trademark. I don't think this is uncommon or unreasonable.

Other companies have built products on Elasticsearch (I worked one one myself at one time) and they haven't been sued by Elastic. In my experience, Elastic has behaved in the spirit of free software. Now that their license has changed I would expect they will receive fewer submissions of code from outside companies. In my opinion, the difference here is both scale and misrepresentation of the offering by Amazon through unauthorized use of Elastic's trademarks.

This is not the first company to change their license in order to avoid providing free improvements to Amazon's proprietary services, I believe that this is unique to Amazon, perhaps because of the size of their AWS customer base. I can't find any similar stories of companies changing their licenses because their code was being used by RedHat.


Trademark disputes are best solved with litigation, not product relicensing.


Another OSS project has chosen to switch to a closed license in response to competition from Amazon.


I'm not sure what value the word "chosen" has in this context.

Amazon is one of the largest and wealthiest technology companies in the world with a large captive audience of customers locked into their AWS product. On what terms could Elasticsearch compete with Amazon, especially when any improvements to the product would effectively be improvements to Amazon's product as well?

While I may step out of the way of an oncoming train, is it really a choice? No, it's clear that an oncoming train forces people to step out of the way.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: