You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ponymail.apache.org by Sean Palmer <sb...@apache.org> on 2022/09/15 15:53:58 UTC
Is it feasible to continue to use ElasticSearch for Foal?
On 14 January 2021, Elastic N.V. announced that they would be dual
licensing ElasticSearch under SSPL and the Elastic License starting
with version 7.11.0 which was released on 10 February 2021. The last
release of ElasticSearch under the Apache License 2.0 was 7.10.2 on 14
January 2021.
https://en.wikipedia.org/wiki/Elastic_NV
https://www.elastic.co/blog/licensing-change
https://en.wikipedia.org/wiki/Server_Side_Public_License
https://www.elastic.co/licensing/elastic-license
https://github.com/elastic/elasticsearch/releases/tag/v7.11.0
https://github.com/elastic/elasticsearch/releases/tag/v7.10.2
Neither the SSPL nor the Elastic License are OSI or FSF approved. They
are proprietary licenses, and the board of OSI directors describe the
SSPL as a "fauxpen" license. Foal currently uses elasticsearch[async]
version >=7.13.1,<7.14.0, which are marked, correctly, as being
released under the Apache License 2.0 because the _Python libraries_
are licensed as such, but the software with which they communicate
upstream, the ElasticSearch database, is proprietary.
https://opensource.org/sspl-not-open-source
https://github.com/apache/incubator-ponymail-foal/blob/aec347deb09154959d278a4a918f3779699434a6/tools/requirements.txt
The ASF does allow its projects to interact with external data sources
served by software which does not use an approved license:
"It does not matter, unless the terms for that platform affect the
Apache product's licensing. For example, creating a product that runs
on Windows or Java, uses a web service such as Google Services or
Yahoo Search, or is a plugin for a product such as JBoss or JIRA is
fine"
https://www.apache.org/legal/resolved.html#category-x
But Foal will eventually have to take a permanent stance on this issue
because of the ElasticSearch compatibility matrix. The ElasticSearch
7.10 series, the last to be licensed under the Apache License 2.0, is
already not available for installation on Debian 11. It requires
OpenJDK 11, which has a limited support lifespan and is currently
slated to end in "October 2024". This means that Foal has to decide
what to do about ElasticSearch within two years at most.
https://www.elastic.co/support/matrix
https://access.redhat.com/articles/1299013
It would be possible to migrate to OpenSearch, a fork still using the
Apache License 2.0. But it is not possible to maintain compatibility
with both ElasticSearch and OpenSearch because the Python clients were
made incompatible on the ElasticSearch side on 30 June 2021, and
although OpenSearch declared that they will try to maintain client
compatibility, there is no such compatibility noted in their own
matrix. There is also no approved migratation method from
ElasticSearch on the server side from 8.0 onwards to OpenSearch, from
either team.
https://github.com/elastic/elasticsearch-py/pull/1623
https://aws.amazon.com/blogs/opensource/keeping-clients-of-opensearch-and-elasticsearch-compatible-with-open-source/
https://github.com/opensearch-project/opensearch-py/blob/main/COMPATIBILITY.md
--sbp
Re: Is it feasible to continue to use ElasticSearch for Foal?
Posted by Claude Brisson <cl...@renegat.net.INVALID>.
What about just using Apache Solr?
Claude
On 15/09/2022 17:53, Sean Palmer wrote:
> On 14 January 2021, Elastic N.V. announced that they would be dual
> licensing ElasticSearch under SSPL and the Elastic License starting
> with version 7.11.0 which was released on 10 February 2021. The last
> release of ElasticSearch under the Apache License 2.0 was 7.10.2 on 14
> January 2021.
>
> https://en.wikipedia.org/wiki/Elastic_NV
> https://www.elastic.co/blog/licensing-change
> https://en.wikipedia.org/wiki/Server_Side_Public_License
> https://www.elastic.co/licensing/elastic-license
> https://github.com/elastic/elasticsearch/releases/tag/v7.11.0
> https://github.com/elastic/elasticsearch/releases/tag/v7.10.2
>
> Neither the SSPL nor the Elastic License are OSI or FSF approved. They
> are proprietary licenses, and the board of OSI directors describe the
> SSPL as a "fauxpen" license. Foal currently uses elasticsearch[async]
> version >=7.13.1,<7.14.0, which are marked, correctly, as being
> released under the Apache License 2.0 because the _Python libraries_
> are licensed as such, but the software with which they communicate
> upstream, the ElasticSearch database, is proprietary.
>
> https://opensource.org/sspl-not-open-source
> https://github.com/apache/incubator-ponymail-foal/blob/aec347deb09154959d278a4a918f3779699434a6/tools/requirements.txt
>
> The ASF does allow its projects to interact with external data sources
> served by software which does not use an approved license:
>
> "It does not matter, unless the terms for that platform affect the
> Apache product's licensing. For example, creating a product that runs
> on Windows or Java, uses a web service such as Google Services or
> Yahoo Search, or is a plugin for a product such as JBoss or JIRA is
> fine"
>
> https://www.apache.org/legal/resolved.html#category-x
>
> But Foal will eventually have to take a permanent stance on this issue
> because of the ElasticSearch compatibility matrix. The ElasticSearch
> 7.10 series, the last to be licensed under the Apache License 2.0, is
> already not available for installation on Debian 11. It requires
> OpenJDK 11, which has a limited support lifespan and is currently
> slated to end in "October 2024". This means that Foal has to decide
> what to do about ElasticSearch within two years at most.
>
> https://www.elastic.co/support/matrix
> https://access.redhat.com/articles/1299013
>
> It would be possible to migrate to OpenSearch, a fork still using the
> Apache License 2.0. But it is not possible to maintain compatibility
> with both ElasticSearch and OpenSearch because the Python clients were
> made incompatible on the ElasticSearch side on 30 June 2021, and
> although OpenSearch declared that they will try to maintain client
> compatibility, there is no such compatibility noted in their own
> matrix. There is also no approved migratation method from
> ElasticSearch on the server side from 8.0 onwards to OpenSearch, from
> either team.
>
> https://github.com/elastic/elasticsearch-py/pull/1623
> https://aws.amazon.com/blogs/opensource/keeping-clients-of-opensearch-and-elasticsearch-compatible-with-open-source/
> https://github.com/opensearch-project/opensearch-py/blob/main/COMPATIBILITY.md
>
> --sbp