Elastic has also closed source the Java clients, as you can see from Mvn: Maven Repository: org.elasticsearch.client » elasticsearch-rest-high-level-client » 7.13.3 (mvnrepository.com) We should think about building similar clients which are Apache 2.0 licensed.
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.
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: https://mvnrepository.com/artifact/org.elasticsearch.client/elasticsearch-rest-client/7.13.3
and the same goes for their new elasticsearch-java client (which however also doesn’t have a release yet): elasticsearch-java/LICENSE.txt at main · elastic/elasticsearch-java · GitHub
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.
@jkowall Thanks for bringing this up.
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?
This is so weird.
I can’t imagine a lot of folks want to use a non-free client since it’s literally compiled with your software. That’s a big red flag.
Then having the documentation say something else from the source. Yikes.
So, I do wonder what the real strategy is on this for them.
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.
Based on the Elastic’s comment in Verify connection to Elasticsearch by sethmlarson · Pull Request #1623 · elastic/elasticsearch-py · GitHub I think you should expect them to actively work against this strategy.
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.
Totally understand what you’re saying here.
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.
i’ve now created a ticket for OpenSearch to publish the OpenSearch
RestHighLevelClient to maven:
i hope that this can be done soon(-ish) as it’s e.g. also needed for
spring-data-elasticsearch to properly support OpenSearch: elastic version/license check in elasticsearch client library · Issue #1880 · spring-projects/spring-data-elasticsearch · GitHub
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.
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