Project License needs to be compatible with GPLv3

[Zeitsperre]

So this is complicated. Here's what I think we could do:

• Bite the bullet and release the library under GPLv3;
• Dual-license the library by saying that the code contributions we add here are under something permissive (like MIT) but that the bundled project (both copyright and copyleft components) is distributed under GPLv3.

We don't plan on commercializing this project, nor do we see this project being used within another project as a library. What's stopping us here?

Originally posted by @Zeitsperre in #28 (comment)

[huard]

The copyleft part of GPL is bothering me.
I like your second option.

[Zeitsperre]

The more I look into the second approach, the worse it looks. Before we get to the legalese, there's some stuff that would need to happen first:

• Completely segregate the lmoments3 code such that there is no hard dependency anywhere in the code base (like we did for xclim);
• Create a GPLv3-licensed core component with the affected code;
• Specify that all distributed forms of the project in its entirety are licensed under GPLv3 (e.g. Docker Image);
• Specify that the non-GPLv3 components are available under a different, but compatible license (must be MIT or BSD-*; Apache v2 is incompatible);
• To prevent headaches down the road, have any and all contributors sign a Licensing Agreement (CLAs) that informs them that their contributions will be owned by us so that we can possibly change the license without their OK in the future.

This is kind of a nightmare. Again, what are the long-term risks of making this project copyleft?

[SarahG-579462]

One option might be to look into lmo instead of lmoments3, which is licensed under BSD-3. I've tried it out a little bit and it seems to work just as well, although lmoments3 does define the generalized normal distribution differently than scipy/lmo, but we could probably replace it with another distribution...

[SarahG-579462]

Oh, it seems we don't use lmoments.distr.gno anyway, so I think we'd be fine to make the swap, if one of us has some free time.

[Zeitsperre]

lmo isn't available on conda-forge, so we'd want to contribute it there if possible.

Update: Looks like the project is open to being placed on conda-forge. @huard is looking into whether this library can be a drop-in replacement. If so, I can help out there.

[huard]

lmo is not a drop-in replacement, but it's not that difficult either to include.

One complication is that xclim hardcodes the connection between lmoments3 and the PWM fitting method. So if we want to use PWM with another implementation of the distributions, we can't use xclim stats.fit and need to copy-paste the logic elsewhere. No big deal.

Comparing the lmo l_fit to the lm3 lmom_fit, I'm getting results that are quite close for all our supported distributions except for gamma. The difference is due to the fact that for some reason, in lm3 the loc parameter fixed to 0 (we don't want that).

So I think using lmo is a good way forward, my only reservation is that for gamma, the fit is noticeably slower. I'll see what I can do about this, but one fallback option is just to remove the gamma from our list of distributions.

[Zeitsperre]

@huard Could you open an issue about the gamma fit in lmoments3? Sounds like it should be addressed (even if we aren't planning on using it here).

[huard]

I think the issue is that there is analytical solution for loc=0, but not otherwise, so it's not a bug, but a limitation.
xclim can handle this by setting floc, so I think we're covered.
xclim could better document the special case for gamma though.