dwidenoise attribution

[Lestropie]

Opening a standalone conversation relating to dwidenoise enhancements: issue list #3023, PR #3029.

Somewhat relates to discussion in #2658.

Issue flagged in nipreps/fmriprep#3395 (comment) in discussion with @tsalo. Tagging @oesteban & @effigies in case there are ramifications for inclusion in fMRIPrep.

---

Currently, dwidenoise has as authors @dchristiaens, @jelleveraart and @jdtournier.
It also has a custom NYU copyright.

However with #3029 there is a fairly minimal amount of surviving master code. The specific configuration covered under the original banner of "MPPCA denoising" and implemented on master---no subsampling, no overcomplete local PCA, no variance-stabilising transform, hard MP distribution threshold---is neither unique nor the default.

For #3029 there are therefore decisions to be made regarding attribution:

Command authorship

I've added my name to the tail of the list in #3029. I think there's a case to be made for being at the head of the list, given the magnitude of the overhaul & enhancement. However I won't do it unilaterally; it would need blessing of existing authors based on code review.

Copyright

We have the ability to bake in a default copyright per command, and then individual commands can override that copyright. However it's nevertheless a single fixed copyright per software command. We haven't yet dealt with complex cases where, say, a custom copyright may only apply to a subset of the capabilities of a command, or the software implementation changes drastically relative to that to which the copyright originally applied.

The current NYU copyright is potentially consequential for the inclusion of dwidenoise in fMRIPrep. It explicitly precludes commercial & clinical application, and @tsalo thought this might be a deal-breaker for fMRIPrep (tagging @oesteban & @effigies for confirmation of requirements there).

I don't know where the threshold sits here. I don't want to burn any bridges or push hard for any kind of "transfer of authorship" that isn't justified. I'm openly looking for input from invested parties, some of whom will have greater familiarity with the requisite bureaucracy than I do. If, despite the drastic changes to the code in #3029, the NYU copyright nevertheless needs to remain in place for the command as a whole, and consequentially the new dwidenoise in #3029 can't go into fMRIPrep, then so be it, though it'd be a shame.

[oesteban]

As @tsalo mentions, we are trying to avoid software licensed with limitations beyond attribution/crediting.

That said, it's not a deal breaker on our side, and the feature may be provided optionally, showcasing a warning that the software cannot be used for certain purposes if the feature is employed. We should also make sure that this particular is mentioned in the NOTICE file.

Finally, if the copyright owners are happy to additionally (because the current license may stand to honor NYU's requirements, as it does not seem copyleft) license dwidenoise under MRTrix's general license, everyone wins here.

[oesteban]

I just read on the other thread that there's a patent. It's possible the two licenses can't coexist, but that's beyond my knowledge. Please disregard that part of my comment.