Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration of lmoments3 and eofs is not permitted under GPLv3 #1620

Closed
Zeitsperre opened this issue Jan 24, 2024 · 0 comments · Fixed by #1644
Closed

Integration of lmoments3 and eofs is not permitted under GPLv3 #1620

Zeitsperre opened this issue Jan 24, 2024 · 0 comments · Fixed by #1644
Assignees
Labels
dependencies Pull requests that update a dependency file invalid This doesn't seem right priority Immediate priority standards / conventions Suggestions on ways forward
Milestone

Comments

@Zeitsperre
Copy link
Collaborator

Related discussions for lmoments3: #1619, Ouranosinc/lmoments3#12

Addressing a problem?

It's come to our attention that we are very likely violating GPLv3 with a few small dependencies: lmoments3 and eofs. This is due to the fact that any extension/integrations of code into our code base means that we must also follow the restrictions of the GPLv3.

We have no intention of re-licensing xclim so we need to make some compatibility-related changes moving forwards. These libraries (and functions based uniquely on them) cannot remain in the code base as they are.

We realize that this creates some breakage to existing workflows, but it is in the interest of respecting the principles of Open Source that we unfortunately cannot provide a transitory version of xclim in order to adapt. We are sorry for the inconvenience and apologize to the developers of eofs and lmoments3.

Possible solutions

eofs

We will be removing the code related to eofs in the next release (v0.48.0). This solely served as a convenience wrapper for eofs.standard.Eof. The eofs library is already very compatible with existing data structures found in xclim (xarray/dask) so for users who rely on this functionality, they will simply need to use eofs.standard.Eof directly.

lmoments3

The code related to lmoments3 will also be removed in the next release (v0.48.0), but as we are currently the maintainers for this project, we will be contributing changes there that render the code compatible with xclim.indices.stats.frequency_analysis.

One possible approach is to change the call signature in frequency_analysis to accept scipy-based distributions functions, e.g. The current signature:

def frequency_analysis(
    da: xr.DataArray,
    mode: str,
    t: int | Sequence[int],
    dist: str,
    window: int = 1,
    freq: str | None = None,
    method: str = "ML",
    **indexer: int | float | str,
) -> xr.DataArray

becomes:

def frequency_analysis(
    da: xr.DataArray,
    mode: str,
    t: int | Sequence[int],
    dist: str | Callable,  # where a 'scipy.stats'-like function can be provided
    window: int = 1,
    freq: str | None = None,
    method: str = "ML",
    **indexer: int | float | str,
) -> xr.DataArray

This would ensure that users would simply need to install lmoments3 in their environments and pass their Callable to frequency_analysis to maintain the same functionality.

There are longer-term plans to try and re-license lmoments3 under a more permissive scheme, however until then we cannot keep their project integrated into the xclim code base.

Further reading

https://www.apache.org/licenses/GPL-compatibility
https://opensource.stackexchange.com/questions/6033/can-a-non-gpl-python-program-use-gpl-python-module/6036#6036

@Zeitsperre Zeitsperre added invalid This doesn't seem right standards / conventions Suggestions on ways forward priority Immediate priority dependencies Pull requests that update a dependency file labels Jan 24, 2024
@Zeitsperre Zeitsperre added this to the v0.48.0 milestone Jan 24, 2024
@Zeitsperre Zeitsperre mentioned this issue Jan 24, 2024
5 tasks
@aulemahal aulemahal mentioned this issue Feb 13, 2024
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file invalid This doesn't seem right priority Immediate priority standards / conventions Suggestions on ways forward
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants