Live data from Hacker News

Elastic and Amazon reach agreement on trademark infringement lawsuit

elastic.co

181–188 of 188 posts

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#181

Earlier quoted context omitted.

Disclaimer: ex-AWS as well, worked very closely with MemoryDB, but not paid to shill! You're entitled to your opinion but your line of reasoning for how MemoryDB for Redis came to exist or the reasoning about why it isn't in upstream Redis is not factual. MemoryDB's architecture uses Amazon's home grown log replication services as pointed out by Werner Vogel in his blog post about MemoryDB[0]. This architecture is fu…

“meeting customers where they were” I’m a total AWS fanboy, but even I cringe when I read that superficial, customer-centric sound bite. You know who meets people where they are? FOSS maintainers. “Also as far as I know one of the lead committers to Redis is from AWS” Conveniently cryptic, what does from AWS mean? Do they still work there? Did they specialize in log replication?

Disclosure: I work for AWS, but I don't work on Redis or managed services based on Redis.

Madelyn Olson, at present an AWS employee, is one of the members of the Redis core team [1]. The invitation was extended because she had "been actively involved in Redis development for several years, contributing numerous changes throughout Redis, including bug fixes and features."

[1] https://redis.com/blog/redis-core-team-update/

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#182
post #105

Earlier quoted context omitted.

Here's the activity difference for the last year repo | commits | authors ------------+---------+--------- elastic | 2719 | 179 opensearch | 265 | 54 Here's a breakdown based on commits with at least 15 lines of code churn (lines added, changed or deleted). repo | commits | authors ------------+---------+--------- elastic | 1681 | 122 opensearch | 153 | 41 What is interesting about these numbers, is they clearly show…

I think part of the challenge looking at these metrics is the project versus repo structure. For instance, contributions to security are included in the elasticsearch repo but not in the core OpenSearch repo e.g. https://github.com/opensearch-project/security/graphs/contri... But I still think having a bunch of folks contribute isn't trivial and worth highlighting (57 is a ton for many projects) and anytime I see a t…

> I think part of the challenge looking at these metrics is the project versus repo structure

For my tool, I can analyze any combination of repositories so getting the bigger picture isn't challenging. Out of curiosity, I decided to index all the opensearch repos which will take a few hours to index and I'll update this post if I can or just reply to it when the other repos have been indexed.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#183

Earlier quoted context omitted.

What's the point of releasing a chunk of code that relies on internal AWS infra?

I think it’s the fact that the implementation details don’t change the optics; AWS had the resources and talent to both monetize AND be a Good Samaritan by contributing to the upstream. The contributions could have been RFCs, GitHub issues, etc. With that said, I can imagine the rumored culture of AWS engineering doesn’t support wondering souls that typically nurture thoughts of community service for the upstream.

Disclosure: I work for AWS.

There were contributions sent upstream for Elasticsearch bugfixes and enhancements. Some of those PRs are still open, for example [1].

A sampling of additional PRs can be found in this blog post [2].

Further contributions upstream to Apache Lucene have been growing over the years. The new Approximate Nearest Neighbor support in Elasticsearch 8.0 comes from work that was sponsored by Amazon in upstream Apache Lucene [3].

[1] https://github.com/elastic/elasticsearch/pull/64513

[2] https://aws.amazon.com/blogs/opensource/stepping-up-for-a-tr...

[3] https://issues.apache.org/jira/browse/LUCENE-9004

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#184

Earlier quoted context omitted.

Again, you’re leading with the definition-of-FOSS argument. Step back from FOSS for a second. I think most people would agree that there’s somewhat of a moral issue with just taking someone else’s open source software and just hosting it and making billions, with nothing for the creators, because you are a megacorp who is good at hosting. Now, is there a way to solve that and have the benefits of FOSS? Both Mongo and…

You’ve got it precisely backwards. The license placed on a software encodes what you wish to allow other people to do with it. If you have a moral qualm with bigcorps using your work for free, you don’t license in such a way that they can. Make your own license, or slap AGPL3 on it - either way, no bigcorp touches it. But you cannot be mad when you say “I release this code under these terms” and AWS takes you up on y…

Disclosure: I work for AWS, but they don't pay me to share my personal opinions on FOSS licenses here on HN. I'm speaking for myself.

Personally, I am a fan of AGPLv3. But I am uncomfortable with advice to apply APLv3 code in an expectation that BigCorps will not touch it. There are many very large companies, including multinational companies based in China, that have no fear of AGPLv3, and are also prepared to meet the obligations of the license.

Many times I have read (including in comments down thread) that "big companies fear AGPLv3." That may be true in some cases, but not all. And the state of adoption or rejection of community licenses changes over time. 25 years ago, many companies "feared" GPLv2.

That changed, and now GPLv2 is widely accepted. The same could happen for AGPLv3, and personally I think that the movements that advocate for Software Freedom will be closer to achieving their goals if that happened.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#185

Earlier quoted context omitted.

I think we've seen that the corps with the lawyering and engineering know-how will definitely touch AGPLv3

Name one. Google won’t: https://opensource.google/documentation/reference/using/agpl... Unless things have changed recently I know Amazon won’t, and I’m fairly sure Facebook still won’t. For most corporations it’s simply not worth the risk

ICYMI, Amazon Linux includes versions of Ghostscript that are licensed under AGPLv3 (the license changed at version 9.07). [1]

AGPLv3 licensed software is also permitted for use within the company in some circumstances.

[1] https://alas.aws.amazon.com/AL2/ALAS-2021-1598.html

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#186
post #105

Earlier quoted context omitted.

Here's the activity difference for the last year repo | commits | authors ------------+---------+--------- elastic | 2719 | 179 opensearch | 265 | 54 Here's a breakdown based on commits with at least 15 lines of code churn (lines added, changed or deleted). repo | commits | authors ------------+---------+--------- elastic | 1681 | 122 opensearch | 153 | 41 What is interesting about these numbers, is they clearly show…

I think part of the challenge looking at these metrics is the project versus repo structure. For instance, contributions to security are included in the elasticsearch repo but not in the core OpenSearch repo e.g. https://github.com/opensearch-project/security/graphs/contri... But I still think having a bunch of folks contribute isn't trivial and worth highlighting (57 is a ton for many projects) and anytime I see a t…

Looking at pull requests that had commits in the last 14 days in 30 OpenSearch repositories, there were 90 authors, which isn't insignificant.

https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D...

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#188

Earlier quoted context omitted.

I also had a serious problem with AWS Managed ES. In my case, some of the heap didn't free on every garbage collect which would eventually result in cluster failure. This was likely a JVM misconfiguration and was most easily observed by viewing a shrinking sawtooth pattern on the memory graphs. This resulted in a multi day marathon of sleeplessness keeping the cluster alive by continually rolling it every few hours (…

For what it's worth, this is most likely not a JVM configuration issue and more likely an ES/OpenSearch issue.

I'm fairly confident it was because I ended up finding a ticket later where very similar behavior was isolated to a jvm.options configuration problem.

Effectively a newer config file was lacking a jvm.options line that changed the behavior with an older machine setup. I would not be surprised if AWS deployed a new config to an old environment.

Unfortunately, not having direct machine access, I could not confirm whether this was the case in the failing cluster.

Post reply on HN