https://en.wikibooks.org/wiki/SPM/Octave -> not supported, but maybe we can package it up nevertheless.

I should e-mail the ML asking if we can provide matlab toolboxes that are open source or not.

I met with some of the SPM developers on Friday to discuss octave compat. among other things. It is of interest to them but not currently working. I would hope we can provide open source MATLAB toolboxes like SPM in /etc/share/matlab/spm or equivalent that can then be added easily for those who do have MATLAB installed.

What ML should be consulted? Any guidance for where toolboxes should be installed if permitted to include?

Happy to take this package and work with the developers if we are agreed that this is something that can be a part of Fedora Project. This would address questions regarding three other important projects for MEEG analysis, NutMEG, EEGLAB and FieldTrip which are also GPL licensed.

The functionality in SPM that it is not available in other neuroimaging packages is the dynamic causal modeling which is an application of computational neuroscience to neuroimaging analysis using neural mass models (in this case Jansen and Rit, 1995).

Great meeting with Guillaume Flandin yesterday, who is the head of SPM development at the FIL UCL. He has done an enormous amount of work to not only make changes in SPM but also submit fixes upstream to Octave to get SPM working. We covered is testing and his most complete tests are using the Wakeman & Henson dataset:

https://legacy.openfmri.org/dataset/ds000117/

Guillaume has Octave-compat scripts that process the MRI, FMRI and MEG/EEG through preprocessing and modeling to at least group GLM results. He would appreciate any testing we can do of such functionality with the understandable caveat that SPM will probably never officially support Octave.

If I use his scripts to test the functionality he has covered so far it will leave me with SPM data structures ready for dynamic causal modeling which will be very important for verifying other tools later. I can confirm that nothing requires MATLAB in order to be built so there shouldn't be any problem distributing this at all. Couldn't be happier.

So I'm not clear about this. Queries:

• does the latest release of SPM work with Octave?
• if upstream does not support it, who do users go to if they have issues with using SPM with Octave?

I'm very loathe to provide packages for Octave if upstream does not support them officially. We DO NOT want to take on the responsibility of checking for correctness, and we do not want to take on the liability that may occur in cases of lack of correctness . Upstream can always say "we do not support octave" if something breaks if they do not officially support it.

TLDR: Unofficial support or "it works, yeh" is not good enough when correctness is at stake.
Ad hoc user-end testing is also not good enough.

In the present state, at most, we can provide Octave packages for SPM via a COPR that warns "Upstream does not support Octave. Please use at your own risk".

What do you think?

Your point is well taken and important. Guillaume makes several points that I empathize with as an academic too (as I am sure you do as well). Help me understand the distinctions being made here.

The upstream lead developer is a contributing member of the GNU Octave developer community but he is not supported by them and they are under no obligation to support changes that are required to support SPM. When he comes up for performance review at his paid position, where he is evaluated for his responsibilities as head of SPM, the support for GNU Octave will not be considered because of institutional guidelines, grant support, etc..
And, in previous cases where the problem has been found to be in GNU Octave, the person reporting the issue is the same person who is eventually closing the issue:)

I think the problem we are having here is what does official "support" mean in this case and I think you are both making cases for different stakeholders without actually being in disagreement about what it means in practice.

SPM as upstream in this case will definitely try and replicate the problem and identify its source. If the problem is fixable in SPM code, the change will be made. If the problem is due to GNU Octave, the problem will be brought to GNU Octave development's attention (as upstream to SPM) and an issue opened. I see this as exactly what would happen with an issue identified in Mathworks' MATLAB where there is no guarantee that the fix will be made or, if it will, when with Mathworks either. GNU Octave, at particular versions/platforms will undergo the same unit and system testing as SPM receives on various MATLAB version/platform configurations. At this point I think Guillaume only supports OpenSUSE but I will find out for sure. The testing I would do would match him on Fedora was the point I was trying to make. Sorry if that was unclear.

There have also been changes in GNU Octave's goals to be more tolerant to MATLAB compatibility as opposed to just being MATLAB-like that are definitely important moving forward. That was not always the case. Guillaume and I also discussed (because I am old enough to remember:) how this is in some ways parallel to S-Plus and R when the two packages co-existed and in some ways S-Plus was considered the "true" language definition/interpreter. He has proposed SPM as a GNU Octave test for MATLAB compatibility for various well argued reasons. Perhaps some of our concerns and questions should be directed at upstream GNU Octave too.

I hope this helps. My respect for you and other longtime contributors has only deepened when asked to support my snap opinions about these issues. This is an important issue as I think it effects almost every neuroimaging package included so far. Many groups consider the officially supported build/install the tarball of binaries downloaded that includes the libs they built with, etc. and all other install methods are unsupported. NeuroDebian's FSL packages for instance are considered unsupported by upstream (FSL) as I understand it.

Always happy to hear other thoughts on this.

My only concern is correctness. If we can guarantee that, I'm all for including these packages. So, if we can run the same tests for SPM on Octave as can be done on Matlab, that's perfectly fine.

I do understand the realities that we face when it comes to our volunteering work. In a similar way, my work on NeuroFedora will not earn me my PhD. But, I hope we'll all agree that we cannot allow these realities to affect scientific correctness. We'd rather that researchers use validated software on whatever platform than unvalidated software on Fedora.

On the note of realities, we've also got to be pragmatic in our duties. As package maintainers, we are middlemen between upstream and users. While we work hard to help upstreams, we are not upstream, and we don't have the cycles to be upstream for all the packages we're going to maintain (about 70 now) either. The only way we can manage to maintain NeuroFedora in a sustainable way in the long term is if upstreams do their bit to ensure correctness, and we replicate this validation when we make our packages.

So that's all I'm saying really: if upstream does validate SPM on octave (their duty, this), and we can run those tests on Fedora to check that our build process does not introduce regressions/errors (our duty, this), we can totally include SPM in our package list.

How does that sound?

That sounds super appropriate. Software sustainability is really a key feature/goal/ideal of the GNU and Fedora Projects so please keep reminding me why we do things the way we do them:) When I consider the original list of projects that we put together, I think I would do prioritize things differently now. So many tools that were written to be a part of a single paper, too hard to get running on a different platform/env., without out-of-case testing, without documentation in some cases:) it is sad but it doesn’t change what the right thing to do is in this case. [I think I am writing this more for myself at this point].

I am working with upstream (Guillaume) to understand their testing and Octave is certainly a part of it. Until I see anything missing from what he is doing currently I am going to press on and keep learning from upstream. You and other reviewers can help along the way.

This thread is more relevant than just SPM’s consideration. I think its important to note somewhere Ben Goldacre’s recent thread on the lack of institutional support for open code for research and yet its incredible asymmetrical impact, the software sustainability institute and the research software engineering (RSE) group that will be meeting in Feb. I think. Not sure where best to note some of these.

Best reference for issues with SPM/octave as well as build instructions

https://en.wikibooks.org/wiki/SPM/Octave

Working on this now. WIP spec here: https://github.com/sanjayankur31/rpm-specs/blob/spm12/octave-SPM12.spec

Bundles https://github.com/fieldtrip/fieldtrip. May have to package that separately.

https://andysbrainbook.readthedocs.io/en/latest/SPM/SPM_Overview.html

https://github.com/sanjayankur31/rpm-specs/blob/spm12/octave-spm12.spec

WIp is here. Needs lots of work.

WIP here now: https://pagure.io/octave-spm12

Still needs some work, but shouldn't be too hard.