Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Official Elasticsearch Python library no longer works with open-source forks

github.com

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Official Elasticsearch Python library no longer works with open-source forks

#131

Post by iavael »

raxxorrax wrote: post #117
toomuchtodo wrote: post #7

Earlier quoted context omitted.

It is easy to judge another’s actions from afar when it’s their meal and roof they’re working for. It’s okay for Amazon (a trillion dollar company) to make money off of their work but not themselves? Imho, the problem isn’t “well it’s not open source anymore then.” The problem is people who give more weight to a religion/philosophy than sustainability. Who cares if it’s open source if the people developing it can’t s…

But you can actually multi-licence code. Put it under GPL and offer other licencing agreements for commercial actors. Copy-left inhibits commercial exploitation while your business licenses get you the money. That is entirely possible.

> Copy-left inhibits commercial exploitation

It doesn't.

Re: Official Elasticsearch Python library no longer works with open-source forks

#132

Post by __app_dev__ »

jka wrote: post #128
kelnage wrote: post #111

Elastic, like others at the time, have used open source to their advantage - to start. The obvious one is that it is built around the Apache Lucene, and I have no doubt that this is one of the reasons ES ended up being initially released under the Apache license. Secondly, being released under a permissive open source license definitely helped with its adoption. I was working as a senior developer in a UK Government…

I keep hearing the AGPL-makes-corporations-wince argument, and I'm curious: what are the reasons given? Does the AGPL really place such burdens on the organization such that the benefits of a locked-open, community-guaranteed (albeit popularity not guaranteed) technology aren't worthwhile? Or is it kind of a cargo-culting and cultural-norms phenomenon where people don't use AGPL projects because they've heard that ot…

I the early 2000's to mid 2010's I worked at an Architecture Firm (Buildings not Software) and at the time and likely now all plotters (large printers) depend on a software called Ghostscript. It's AGPL which prevents it from being bundled with any other software unless you negotiate a very expensive contract with their sales people.

If a company risks installing it or supporting it company wide then your risk lawsuit and having your business shutdown. The work-around is that for every user's computer IT must manually install the driver (a windows DLL file).

To me if I see AGPL it makes me think that it's likely a predatory business with good lawyers; and for this reason I would stay away from it even on personal projects unless there is no alternative.

Re: Official Elasticsearch Python library no longer works with open-source forks

#133

Post by jka »

__app_dev__ wrote: post #132
jka wrote: post #128

Earlier quoted context omitted.

I keep hearing the AGPL-makes-corporations-wince argument, and I'm curious: what are the reasons given? Does the AGPL really place such burdens on the organization such that the benefits of a locked-open, community-guaranteed (albeit popularity not guaranteed) technology aren't worthwhile? Or is it kind of a cargo-culting and cultural-norms phenomenon where people don't use AGPL projects because they've heard that ot…

I the early 2000's to mid 2010's I worked at an Architecture Firm (Buildings not Software) and at the time and likely now all plotters (large printers) depend on a software called Ghostscript. It's AGPL which prevents it from being bundled with any other software unless you negotiate a very expensive contract with their sales people. If a company risks installing it or supporting it company wide then your risk lawsui…

Thank you. For me the AGPL is at the complete other end of the spectrum: it's a stake in the ground to say "this software must be allowed to progress", even if the originating entity ceases to exist.

As I'll mention in a sibling thread, I think that lawyers can be extremely risk averse in software licensing (it's their professional incentive structure) and that is my guess where this cultural meme about AGPL comes from.

Re: Official Elasticsearch Python library no longer works with open-source forks

#134

Post by jka »

kelnage wrote: post #130
jka wrote: post #128

Earlier quoted context omitted.

I keep hearing the AGPL-makes-corporations-wince argument, and I'm curious: what are the reasons given? Does the AGPL really place such burdens on the organization such that the benefits of a locked-open, community-guaranteed (albeit popularity not guaranteed) technology aren't worthwhile? Or is it kind of a cargo-culting and cultural-norms phenomenon where people don't use AGPL projects because they've heard that ot…

In one of the of the organisations I mentioned, they had a strict policy against using any GPL dependencies, let alone the AGPL. I tried discussing this with the legal policy person but they were quite resolute - they feared it’s use could “infect” our code and therefore must be avoided. I frankly doubt there’s any sort of cost-benefit analysis being done here. Certainly in my experience it was much more driven by le…

Thanks - yep, that matches my rough understanding of the view from the ground too.

Statisticians and scientists sometimes talk about 'type 1' errors and 'type 2' errors - false positives and false negatives. I can rarely remember which is which, but I think that generally, software license/contract legal professionals never want to advise a client about something that later turns out to be a liability.

That's fine, because it protects their firm's reputation, and it maintains the client's trust (which needs to be strong). But I think that in the context of software licenses, this has led to an overly strong aversion (and indeed self-replicating idea) about the AGPL and other copyleft licenses.

(in the context of cost-benefit, it's hard to justify the upside from using and helping contribute towards a software commons, but I think it can be significant, perhaps depending on project context and popularity)

Re: Official Elasticsearch Python library no longer works with open-source forks

#135

Post by PeterZaitsev »

Oh my. I'm not sure if there is any Open Source company which fell so low - to Break the Drivers... I'm also not sure what they are looking to reach with this step as Developers who want their applications to work both with Elastic and OpenSearch will not need to go right into AWS hands...

Re: Official Elasticsearch Python library no longer works with open-source forks

#136

Post by pabs3 »

AmericanChopper wrote: post #114
pabs3 wrote: post #96

Earlier quoted context omitted.

There are lots of open source projects that aren't bait and switch, like the Linux kernel, or Python. So I would encourage you to reconsider a blanket fork-everything policy and at least contribute to the projects that aren't backed by VC-funded companies and instead have a diverse community of contributors with multiple copyright holders.

Yeah I should have been more specific. I’m just whining about the open source as a business model type of projects. My general approach has been, when I’m capable and have the time to, to fix any issues or obvious feature deficiencies that I come across in open source projects that I use. I still do that, but I now only contribute my changes back to projects that seem more trustworthy.

I wonder what criteria you apply to determine the trustworthiness of a project. For me, signing a CLA or otherwise not using inbound=outbound licensing is a major one, as well as any project backed by a company with VC funding. Any project backed by a single organisation instead of a group of people from lots of different organisations is a red flag, with some exceptions for long-term known-trustworthy non-profits.

None of that helps with a situation like Audacity/MuseCore though, if developers are willing to sell out their project copyrights, that isn't something that you can really protect against, except maybe discussing people's opinions on that openly.

The other issue with withholding changes from upstream is the potentially infinite cost of updating your changes as the project evolves, things like git-imerge, mergify or git-mergify-rebase can reduce that burden by letting you do incremental rebases/merges though. Normally I don't contribute to projects with a CLA assigning extra rights to corporations over the license, but I've been considering signing one just to drop the maintenance burden.

https://github.com/mhagger/git-imerge https://github.com/brooksdavis/mergify https://github.com/CTSRD-CHERI/git-mergify-rebase

Re: Official Elasticsearch Python library no longer works with open-source forks

#137

Post by AmericanChopper »

pabs3 wrote: post #136
AmericanChopper wrote: post #114

Earlier quoted context omitted.

Yeah I should have been more specific. I’m just whining about the open source as a business model type of projects. My general approach has been, when I’m capable and have the time to, to fix any issues or obvious feature deficiencies that I come across in open source projects that I use. I still do that, but I now only contribute my changes back to projects that seem more trustworthy.

I wonder what criteria you apply to determine the trustworthiness of a project. For me, signing a CLA or otherwise not using inbound=outbound licensing is a major one, as well as any project backed by a company with VC funding. Any project backed by a single organisation instead of a group of people from lots of different organisations is a red flag, with some exceptions for long-term known-trustworthy non-profits. N…

That’s pretty much the criteria I use. At my most recent job I left behind a Telegraf fork after running in to the Influx CLA.

But the more important criteria is deciding what changes are feasible to support with a fork. The projects that I find to be most suspect typically come with an enterprise support license, and if you’re struggling to get your issues fixed with one of them, then the best long term solution is usually to abandon the product. Forking for a bug fix would typically be a temporary solution, and hopefully the first merge conflict you run into is the vendor actually fixing the issue, otherwise you can take your time to find a product that offers better value for money.

There’s lots of things I don’t especially like about the large enterprise workplace, but I really detest vendors that fleece them with high price, low quality products/services.

Re: Official Elasticsearch Python library no longer works with open-source forks

#138

Post by altdataseller »

dragonwriter wrote: post #124
altdataseller wrote: post #73

Earlier quoted context omitted.

At the end of the day, CTOs and decision makers in corporations don't go with the company that position themselves as "allies". They go with the company that is shipping important new features, with better support and resiliency. If Elastic is shipping features faster than AWS is, then they'll go with Elastic. I bet most CTOs aren't even aware of the politics happening - it's only the echo chamber in Hacker News that…

> They go with the company ...that is the bigger name and perceived as lower risk, better enterprise support, and fits with less internal work in their broader strategy even if that means sacrificing feature speed. I mean, at least, most of the established market, rather than startups burning through VC dollars. But even the latter is likely to do one stop shopping with a big cloud vendor like Amazon unless particula…

Indeed, that’s why Elastic has their own cloud service that you can host in AWS.

Re: Official Elasticsearch Python library no longer works with open-source forks

#139

Post by altdataseller »

nijave wrote: post #125
altdataseller wrote: post #70

Earlier quoted context omitted.

1) Is outside contribution really important going forward? Most of the Elasticsearch contributors are probably already employed by Elastic. 2) Open source doesn't attract new customers. There's nothing special about having software where anyone can contribute freely, that makes it attractive to customers. There is however, something special in making it free to download, setup and use in your own servers that makes i…

>There's nothing special about having software where anyone can contribute freely, that makes it attractive to customers Community, support, acquisition, extendability and code quality. Community/Support -- lots of documentation available for free, generally multiple vendors that offer paid support, free access to updates. Don't have any data but I suspect finding people to support/run it is easier (skills are more m…

3 of those 4 still apply to Elasticsearch. Mongo, another example has the same license and loads of docs freely available. You can still hire devs to add any missing features to Mongo (albeit you will have to fork it). You can still view their issues in GitHub too

Re: Official Elasticsearch Python library no longer works with open-source forks

#140

Post by raxxorrax »

iavael wrote: post #131
raxxorrax wrote: post #117

Earlier quoted context omitted.

But you can actually multi-licence code. Put it under GPL and offer other licencing agreements for commercial actors. Copy-left inhibits commercial exploitation while your business licenses get you the money. That is entirely possible.

> Copy-left inhibits commercial exploitation It doesn't.

Perhaps exploitation is too negative and it is not true for some cases, but most companies do not employ it or use it as a component because of the restrictive licence.
Post reply on HN