[MAINT] Add GPL license

tsalo commented 3 years ago

Closes #4, but I'm still a little unsure if this is enough on its own.

The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language.

@eurunuela @notZaki WDYT?

eurunuela commented 3 years ago

Sounds like that's our case, yes. Thanks for finding out!

tsalo commented 3 years ago

Should we add something to our docstrings then? Maybe something like the following:

This implementation is licensed under GPL-v2 by the GIFT developers.
It has been translated to Python by the ME-ICA developers.
Additional changes may have been made to the translated code that may impact behavior.
For more information about the changes that have been made, see mapca's release notes.

notZaki commented 3 years ago

Are there any popular python modules that use GPL? I would expect the viral nature of the license to be problematic.

I'm also not sure if GPL would allow this package to be merged into nilearn (BSD license).

tsalo commented 3 years ago

Are there any popular python modules that use GPL?

I'm not sure, but we can look around.

I'm also not sure if GPL would allow this package to be merged into nilearn (BSD license).

That's a depressing thought...

eurunuela commented 3 years ago

I honestly have no idea about licenses... I know @smoia looked into the licensing world when he had to choose one for phys2bids, maybe he can help us here.

smoia commented 3 years ago

I'm not sure how I can help you, but here's the little I know/understand:

I didn't see any licence in the GIFT toolbox. Could you please redirect me to it?
You cannot release a GPLv2 based program as a part of a BSD licenced program (you can do the opposite if the BSD is the revised version of the BSD, not the original one). So if GIFT is released under GPLv2, ATM this code can't be merged into nilearn.
However, you can contact the original authors of GIFT and ask them to use a more liberal licence in GIFT or more probably give you explicit permission to release this code with a more liberal licence that could be compatible with BSD (some forms of BSD and probably MIT?).

This is why everyone should use Apache-2 :stuck_out_tongue_winking_eye:

This said and jokes aside, I'm not a lawyer nor have experience in that field, so if @tsalo you can contact the legal department of FIU that might be a safer way to proceed.

eurunuela commented 3 years ago

@smoia the GIFT license is in each of their files and if I remember correctly it's a GPU. See here.

tsalo commented 3 years ago

@smoia Thanks for that info! It's really useful. Someone should really figure out cross-license interactions and share it in something easy to read.

EDIT: So... I say we hold off on contacting the GIFT folks about changing or supporting a new license unless nilearn shows a strong interest. However, I'm still not sure if what I've added in this PR is sufficient for us to publish this code. If we reach a consensus that it is enough, then we can just merge this PR and release.

notZaki commented 3 years ago

If we reach a consensus that it is enough, then we can just merge this PR and release.

I could be wrong, but I think that merging this PR means that any other package that decides to import this module in their code will also have to change their license to GPL. The LGPL, in comparison, is more permissive and wouldn't have this cascading effect.

That's why I was wondering if there even was a popular python module that is licensed under GPL.

eurunuela commented 3 years ago

I could be wrong, but I think that merging this PR means that any other package that decides to import this module in their code will also have to change their license to GPL. The LGPL, in comparison, is more permissive and wouldn't have this cascading effect.

LGPL makes more sense to me then. However, if we're not merging with nilearn, I'd keep the GPL license instead. I don't think we should be permissive if maPCA stays in ME-ICA as only we have permission from GIFT to release the code.

EDIT: So... I say we hold off on contacting the GIFT folks about changing or supporting a new license unless nilearn shows a strong interest. However, I'm still not sure if what I've added in this PR is sufficient for us to publish this code. If we reach a consensus that it is enough, then we can just merge this PR and release.

Yeah, I wouldn't bother GIFT folks with the license cause they're happy with whatever we do as long as the original work is cited and we share the link to it.

So, the way I see it is:

Nilearn wants maPCA in, we go for LGPL.
Nilearn is not interested in maPCA, we go for GPL.

smoia commented 3 years ago

Hey there again!

Having seen GIFT's license (it's a GNUv2 and later, thank you @eurunuela for redirecting me to it!), I have to give you the bad news that without the original authors permission the only freedom you have in choosing license for this package is about which version of the standard GPL to adopt ("v2 only", "v2 and later", or "v3") - see here. "V3" is better in many ways (e.g. higher compatibility with other licenses, see here), although "v2 and later" is more compatible with other GPL licenses (nonetheless, I would adopt v3).

I know it's oftentimes overlooked (I think we're overlooking it in physiopy too), but independently of the type of licence you choose, adding the licence file to the package is not enough to "activate" the licence. I would at the very least add the full banner (see around line 280 of the file in this PR for an example) to the main source file of the package (mapca.py). Even better, you could add at least the copyright line (or again the full banner) to each file in the package.

In any case, I would suggest you to ask the original authors the permission to relicense this package as LGPL (v2.1, v2.1 and later, or v3 - v3 would be the best) or, since you're asking to relicense, as Apache 2.0. If you contact them, you might even ask if they want to update their licence to (L)GPLv3. That comes before contacting nilearn's team because otherwise you'd force nilearn to adopt GPL or do nothing.

Also don't worry too much on the finality of this PR. You can always change the licence at a later date, as long as it's compatible with GIFT's licence.

Also, did I mention that v3 is my favourite GPL version? :stuck_out_tongue_winking_eye:

eurunuela commented 3 years ago

Thank you so much @smoia !!

I'd stick to GPL3 for the moment and release. I feel like merging with nilearn will take long, so we can come back to choosing the license in the future. Mainly because there was interest in using the package and it's starting to feel like we're delaying things when we could already release.

notZaki commented 3 years ago

Mainly because there was interest in using the package and it's starting to feel like we're delaying things when we could already release.

I'm not sure if releasing under GPL would be useful to those interested groups, unless they're using GPL too, because every downstream dependency will have to change their license to GPL if they decide to use mapca.

So I think the options would be:

If nilearn is not interested, ask GIFT folks to let us license mapca under LGPL
If nilearn is interested, ask GIFT folks to let us license mapca under BSD (same as nilearn)

eurunuela commented 3 years ago

I'm not sure if releasing under GPL would be useful to those interested groups, unless they're using GPL too, because every downstream dependency will have to change their license to GPL if they decide to use mapca.

Maybe @tsalo knows, was the interest on mapca about developing more tools? Or was it about just using mapca for personal use, e.g. data analysis?

smoia commented 3 years ago

- If nilearn is interested, ask GIFT folks to let us license mapca under BSD (same as nilearn)

It does sound the best idea now that I think about it, for the future. However,

I'd stick to GPL3 for the moment and release. I feel like merging with nilearn will take long, so we can come back to choosing the license in the future. Mainly because there was interest in using the package and it's starting to feel like we're delaying things when we could already release.

This is a better idea for the moment. By making this code publicly available without a (GPL) licence you are violating GIFT's GPLv2 licence. Adding a licence now is (to some extent) more important than which licence you choose - you can always change it at a later moment.

tsalo commented 3 years ago

Currently, the only other package where the devs have expressed an interest is rapidtide, but I think mapca would be useful beyond tedana and rapidtide.

notZaki commented 3 years ago

@smoia That's a good point. In that case, I'm ok with merging this PR too.

tsalo commented 3 years ago

This is a better idea for the moment. By making this code publicly available without a (GPL) licence you are violating GIFT's GPLv2 licence. Adding a licence now is (to some extent) more important than which licence you choose - you can always change it at a later moment.

@smoia Should I change GPLv2 to GPLv3 in this PR then? Or just merge now as-is? EDIT: Never mind, it's clear that we should merge now and change the license later if necessary. Merging.

smoia commented 3 years ago

@tsalo good choice!

I would convert to GPL3 for international support, but that's really up to you people.

However, I would still suggest to add the notice around line 288 of the licence at least in the main workflow!

ME-ICA / mapca

[MAINT] Add GPL license #36