This is an issue for any software which is consuming this as they in turn have issues with license compliance. This was brought to my attention by Wu-Sheng who is the creator of Apache Skywalking. They are using the Elastic Client in the product, and hence this is a problem for them since Apache projects are required to have Apache 2.0 code only. The same can be said for CNCF projects.
i guess we’ll anyway need new clients since they’ll diverge. for now we can stick to the 7.10.2 version of the client libraries as they’re still under Apache 2.0.
but it seems that they only did this for the high level client, the low level one is (for now?) still under Apache 2.0
Yes, they can’t change the released versions’ license. That is for sure.
and the same goes for their new elasticsearch-java client (which however also doesn’t have a release yet)
They never said when they will release from this repo. The current java client is sharing server-side codes, which means partial SSPL. And I get prove from Maven Central.
i guess we’ll anyway need new clients since they’ll diverge. for now, we can stick to the 7.10.2 version of the client libraries as they’re still under Apache 2.0.
We(SkyWalking) don’t want to face an unresolvable security issue one day, because we stick in 7.13.3.
I had stumbled across some narrative a few weeks ago where Elastic was indicating that they intended to make the high level rest open source, but there were dependency issues they were looking to resolve. Of course, I can’t relocate it so either google failed me or they pulled the stmt.
I did see that their doc indicates that the current release is Apache, so there appears to be a disconnect on their end. Does anyone have any friends over there to ask?
It does seem like there would be a lot of value in a Java REST client that works with both OpenSearch and Elasticsearch endpoints, and is Apache 2.0 licensed. Is there a community member who would be particularly interested in kicking this off and serving as administrator / maintainer?
It does seem like there would be a lot of value in a Java REST client that works with both OpenSearch and Elasticsearch endpoints, and is Apache 2.0 licensed.
This is getting more scarier as days passes by: it seems Elastic is burning bridges all around their own territories effectively locking-in users to their ecosystem.
This has, unfortunately, some conseguences on the opensearch side: what should opensearch do about all the connectors and bindings for the different programming languages currently available ? A lot of them are already integrating anti-competitive measures as it has been reported and I guess we should expect all of them to do the same very soon.
what should opensearch do about all the connectors and bindings for the different programming languages currently available ?
I see this as an opportunity for the community to assist much like @amitai did with the plugin template repo. I’d love to see community members fork their client of need/interest and start integrating w/ OpenSearch.
These kinds of changes keep happening. It seems Elastic is going to cut all compatibility.
It is time OpenSearch community to take this client-side issue seriously. We(SkyWalking) really don’t want to write the JSON HTTP request client on our own.
I’m seeing this happening across all the Elastic-provided libraries and of course the other integrations such as beats. I propose that we start a list of recommended/compatible tools to use with OpenSearch, maybe as a page on the website? It would give us a central place to put all the information about what has had its support removed, which are the last working versions, and importantly to surface any forks or alternative tools and give them some visibility. If this sounds useful, I am happy to create this and help to maintain it over time.
Yep. It is definitely happening in a lot of the Elastic-provided libraries. And it’s concerning.
As for documenting these issues, should this go in the docs or on the website? It’s a bit transparent to the end user, but it depends on how we want to manage this going forward. Docs are versioned, website is not.
for the RestHighLevelClient it’s worth pointing to their FAQ entry where they confirm that they do not consider usage of the client as derivative work under their Elastic License 2.0, so it isn’t a viral license for those usages: FAQ on 2021 License Change | Elastic
then again, that’s just an FAQ and not the actual license and they’ve backtracked once before on some other public statement (that they’d never move away from Apache 2.0), so you might want to double-check with your legal department before pulling in RestHighLevelClient >= 7.11