MAINT: Relicense +20.3.x - BSD-3-Clause -> Apache License 2.0

[oesteban]

I'm proposing this relicensing because I'm concerned that software deriving from fMRIPrep might not be sufficiently documenting the changes. That poses a problem to the principles of this software and enforcing the documentation of the changes would only increase the transparency of derived works (which is encouraged).

The trigger of this discussion is this issue at the ICA-AROMA BrainHack Donostia project - ME-ICA/aroma#3

[oesteban]

cc/ @nipreps/developers @nipreps/enthusiasts

[effigies]

Looking at that other thread, Apache seems to be causing more uncertainty and headaches. Do we really want to make it harder to adapt our code to different use cases?

[oesteban]

The headaches are more about how to interpret the license, but I think it is very important to make it clear what are the changes in derived works. With version control that should not be particularly problematic. Especially when these changes are, for instance, fixing a bug.

I do not intend to merge this anytime soon, so let's discuss this tomorrow. I also plan to request the acceptance of all fMRIPrep authors (as in papers) before relicensing. (I'm changing this to draft to avoid mistakes)

[mgxd]

I'm proposing this relicensing because I'm concerned that software deriving from fMRIPrep might not be sufficiently documenting the changes.

I agree here - requiring notifications upon any code modifications can only help for the sake of transparency.

[effigies]

Where would be a good place to add guidance on derived works? nipreps.org? fmriprep.org?

[oesteban]

I think nipreps.org - only fmriprep, nibabies and niworkflows are not Apache 2.0 yet.

EDIT: also +1 nipreps.org because that is written in Markdown, rather than RsT (fmriprep.org)

[oesteban]

I would also like to check what the Turing Way says about this and maybe contribute something there. Depending on what finally gets accepted there we could expand the documentation in nipreps.org

[effigies]

https://the-turing-way.netlify.app/reproducible-research/licensing/licensing-software.html

[arokem]

I am not even a contributor to this project, but here is my semi-solicited thoughts: I think that clear instructions on how to document derivatives and changes with a request probably trumps a license change. Apache 2 is not a big change, but folks will come here in the future and scratch their head wondering what they are allowed or not allowed to do. And some of them might just decide not to do anything, because of the uncertainty about what constitutes a change that requires documentation and what would be a compliant way of documenting this change, which would be a shame.

[effigies]

Chat log from Nipreps meeting:

@emdupre

Just to confirm : I think to re-license fMRIPrep you'd need to get an explicit OK from all existing contributors (55, by GitHub's count). is that the plan at this point ?

@effigies

So we would want to have a clear statement of what we expect from derivative projects on the website, basically…

@bbfrederick

I think that makes sense - if you don’t say anything it might seem very onerous (i.e. you have to provide explicit diffs between files, or something like that). If the intention is to ask for something on the level of descriptive text (“I modified the following files to remove the assumptions regarding human brain size and shape”) that seems less daunting.

@yarikoptic

IIRC GPL has similar "requirements". I rarely see them followed though. So, although I am ok to switch to apache-2, I think this reason is largely just a "wishful thinking"

@arokem

Call me a zealot, but I don’t understand why this needs to be required through a legal instrument
You can just ask people to do it
Sorry - strike the word “just” from my recent comment

@yarikoptic

yeah, pretty much what I think too (so in alignment with Ariel)

@poldrack

In general, unless one is willing to hire lawyers to pursue violators, then all OSS licenses are just “wishful thinking”, aren’t they? :-)

@yarikoptic

having a changelog is just a good user- and developer- friedly practice. Having some "NEWS" with major announcements is also a good practice (e.g. Debian uses it to alert users upon upgrades)

@emdupre

I think the cost of re-licensing (in getting an OK from everyone) is actually reasonably high. So being sure that the change will really effect the desired results seems like an important point IMHO !

@arokem

@poldrack: sure. It can have some minor practical implications (e.g., alignment with other orgs, such as Numfocus or JOSS)

@edickie

I have to say I agree with Ariel here.. I feel like the license change will do less (in terms of community behavior change) than a suggestion in the documentaion

[oesteban]

Hey, thank you all for weighing in!

@arokem: Apache 2 is not a big change, but folks will come here in the future and scratch their head wondering what they are allowed or not allowed to do.

I think this is where @effigies is getting at with his suggestion of having a clear description of how we interpret that particular clause of the license and giving hints on how to comply.

That said, as @poldrack suggested there's no scenario where we would legally enforce this (and I agree). This brings me to the next point.

I agree with @yarikoptic that this is in a way wishful thinking and, if we are not going to bother about enforcing it why changing the license for this reason? To this, I would expect some particular users to comply by default and worry about the license: companies. The way I see it:

• If you are a researcher and you are forking from fMRIPrep because we all scientists are wonderful, we are not going to chase after you. If you are given clear expectations (and they are reasonable), I would bet anyone falling in this category will be actually willing to meet what is asked by the project (and if not explicitly stated, then the license).
• If you work for a company that is planning to make money out of it, documenting changes is a very cheap price for a license so most of them will be compelled to comply. Obviously, it doesn't take a bright mind to understand that NiPreps will not hire a lawyer if you don't respect the terms of the license, but that's a wholly different story (so different that we would maybe need a lawyer in that case!).

I also have the perception that we need to increase awareness of the importance of licenses. If we start bringing the topic up and devote some lengths to it in our documentation and our meetings, that will clearly signal that licensing is important (perhaps not the particular choice of license, but clearly stating one).

Also, @yarikoptic's comment kind of splits the debate into two questions:

• Whether we should clearly state in our documentation what are our expectations from people deriving from our work in terms of documenting changes (despite maintaining the BSD license for fMRIPrep). - basically @effigies' comment/concern/point.
• Whether we should reflect the above question formally with the actual change of license (and Yarik suggested that GPL has a similar clause regarding derived works). This actually closes the loop with the first comment from Ariel that "Apache 2 is not a big change" - indeed when I thought we should change the license I also thought that this change should be the minimal possible to meet the new expectation.

[effigies]

Just to re-up @emdupre's comment, though, if the main thing that will be useful will be a published statement of expectations, then it might not be worth the effort of getting a sign-off from all contributors.

I would also add that contributors might justifiably refrain from consenting until we clearly lay out how we interpret the change in such a statement, so it would make sense to prioritize that over any attempt to obtain consent to relicense.

[yarikoptic]

from my vague and distant understanding, in defense of "apache 2.0" choice: it is better formulated "legally" (but thus less human friendly), and provides some patent protection *, and thus some companies/institutions might agree to contribute/adopt to products under apache than under BSD-3

*: IIRC, if some company uses apache-licensed product, and holds some relevant patent on functionality implemented in that product, they should not be able to sue the original copyright holder(s) of the product. smth like that

[oesteban]

I would also add that contributors might justifiably refrain from consenting until we clearly lay out how we interpret the change in such a statement, so it would make sense to prioritize that over any attempt to obtain consent to relicense.

This sounds reasonable to me.

Just to re-up @emdupre's comment, though, if the main thing that will be useful will be a published statement of expectations, then it might not be worth the effort of getting a sign-off from all contributors.

I think that making the statement but not changing to a license that backs that statement is an instance of wishful thinking. Those expectations are formally carried out by the license. If you also explain* your license, that is great.

* The good & bad news about explaining your license is that if your explanation doesn't actually fit what the license says then there's nothing binding in it. Which is good in the sense that a misinterpretation of it does not really have any consequence, and bad if you hoped your misinterpretation prevails over the license because it doesn't. So, if you ask people to document their changes on derived works based on a BSD license, then there's no consequence from it (i.e., don't expect it to be actually met).

I think that a debate regarding what would be the appropriate licensing terms for open science code and how to incentivize the use and observance is a very interesting idea to bring up to the public - but IMHO beyond fMRIPrep's scope.

Another reason for moving towards Apache 2.0 is that all the other projects under NiPreps have it.

[oesteban]

I have drafted a proposals to set our expectations within the NiPreps documentation:

nipreps/nipreps.github.io#4

Let's get those commented, revised and accepted before we can come back to all fMRIPrep contributors and propose them a concrete plan of action regarding the relicense move.

WDYT?

[effigies]

@oesteban I didn't have time to thoroughly go through what you've got there, but just to share my initial impression: it is a lot, and it feels very legalistic and kind of intimidating. What I would want would be something on the order of:

• A statement of values. Why do we share our code?
• A statement of expectations. How can others repurpose our code in the spirit that we shared it?
• An explanation that the Apache 2 license most closely matches our intent.
• A checklist people can follow to meet the license terms and our expectations.

I think most of what you have looks like it falls into the category of points 3/4, though there might be some 1/2 stuff that can be pulled forward to make the framing a bit friendlier. I'll aim to write something in the 1/2 vein in the next couple days.

[effigies]

First pass here: nipreps/nipreps.github.io#6

I did not attempt a checklist or remove anything that Oscar has written at this point.

[oesteban]

For those who don't feel markdown is very friendly, I've set up an automated build of the documentation, and the current proposal @effigies mentioned above can be seen here: https://deploy-preview-4--vigorous-brahmagupta-fd6bf1.netlify.app/community/licensing/

[oesteban]

(see nipreps/nipreps.github.io#4 for further context on why and how Apache-2.0)

Some of the circumstances surrounding relicensing of FOSS are described here - http://www.catb.org/~esr/Licensing-HOWTO.html#changing

Within that frame of thinking, and considering the principle that every contribution can be (and has been) credited with coauthorship in papers, NiPreps is somewhere between the definitions of "collective work" and "joint work" (which, as per the opinion above, would mark a legal line between who is considered a copyright holder).

Anyways, I will keep pushing to notify everyone about this license change and keep the public discussion open for a while. The goal is that, if someone has not expressed a particular opinion then the individual silence will be assumed to be in agreement with the license change. This is not just because I can't force every contributor to explicitly express their opinion (which then I have to keep track and proof of it), also because this PR is probably the best way to track those opposing opinions anyways.

Long story short - if you are in @nipreps/fmriprep-contributors and object to changing the license from BSD to Apache 2.0, please say so as soon as possible. Objecting should detail how the license change will actually cause an injury to your interest.

When this issue is closed, I'll copy all the responses to this poll https://doodle.com/poll/kfbis4n38sipi9a8 as a comment for archival. I will also request your comments here if you object.

[oesteban]

https://www.nipreps.org/community/licensing/

[oesteban]

@prscheduler 29/07/2021T6:59

[pr-scheduler]

Merge scheduled for 29/07/2021T6:59 UTC time. If you want to change the scheduled time, just comment again with a new time.

[effigies]

@oesteban Thanks very much for the work you put into https://www.nipreps.org/community/licensing/. I read through it again and think it's great!

Here are some suggestions, and one final question: Do we need to contact all contributors before making this change?

[oesteban]

Do we need to contact all contributors before making this change?

I don't think so. From all I have gathered over the last few months, even if fMRIPrep were considered a "joint work" (meaning all contributors are copyright holders) they could file a lawsuit only if they can proof damage in court. That is, in this case, a really hard task because we are moving from BSD to Apache and hence the changes overall are pretty minimal (we are talking about really edge edge-cases). And honestly, looking at our contributor list this sounds just nuts - no one wants this.

But reality is that fMRIPrep could more easily represented as "collaborative work", where contributors may not be copyright holders. An argument of who is a copyright holder then would be had and only of those considered copyright holders could eventually, again, file a lawsuit with the same prospects as above.

Then, it's not like we are changing the license without consulting. We've taken more than 8 months to make sure everyone interested at least once heard of this and could raise their objections. But honestly, I don't know what else we could have possibly done to change the license (except not doing it unless all copyright holders had said yes - whoever copyright holder means).

For further complication, turns out that most of our copyright notices write the CRN or the CRN developers as copyright holders. So, strictly speaking, those are ultimately who may need to be asked if trying to really make an a unanimous decision.

Long story short, I feel pretty confident this will not bring us any issues:

• not legal for the actual relicensing action
• not human because someone complains and expresses objections after this PR is merged.

My impression is that @nipreps/fmriprep-contributors range from the feeling that they are not really concerned by the change, through reflecting that BSD->Apache-2.0 is definitely no biggie, to actually liking the change and the extra-mile we've run with the nipreps documentation.

Hope this is representative of the overall feeling of the community. If I'm missing some important aspect, I'd really appreciate someone gave me a heads up before this PR is merged next July 29. Perhaps @emdupre, considering her long experience with these topics, could give me some angle I'm missing. Happy to correct the course in that case.

Thanks for your comments Chris :)

[pr-scheduler]

⚠️ Merge failed: 'Pull Request is not mergeable' - Please contact support at https://prscheduler.com.