[MINC-development] experiments with EBTKS and N3

[Alex Zijdenbos]

First of all, thanks Vladimir for digging all this up! Very nice work
(and no I didn't write/include the FFT code in EBTKS, even though it
has my name all over it :-) )

On Mon, Aug 20, 2012 at 1:01 AM, Vladimir S. Fonov
<vladimir.fonov at gmail.com> wrote:
> Hello,
>
> I would very much prefer, if we replace EBTKS with something more or less
> standard, for example GSL.
> I don't really see any advantage of switching internal C routine for FFT
> computation with FFTW.

I fully agree that getting rid of EBTKS woud be great. Personally I do
see an advantage to internal C code vs linking to externally
maintained libraries: it means MINC won't be subject to the whims of
whoever maintains that other library, with all the compatibility
issues that may entail. We already have that with things like
NetCDF/HDF5. Now perhaps we can expect GSL to be more stable in that
sense; but hey, gcc has been changing the game at every turn as well,
causing a good bit of grief over the years.

However both these options would bring the GPL into MINC (or at least
into N3), which will be a problem for a number of users (myself
included). At this point there is no telling where the MINC library
may have been incorporated in other packages by virtue of its BSD-like
license; if MINC would adopt the GPL now this would cause many
headaches and will likely result in divergent development. N3
specifically is pretty much a standard and I've come across commercial
software packages that include it; I am not sure what would happen to
them if N3 would start carrying the GPL (they'd be stuck with an old
version I'd guess).

Clearly there are good arguments for starting to rely on libraries
available out there, but I'd say we should minimize that, and
compartmentalize it as much as possible.

Are there any (viable) FFT code/libraries out there that do not carry
a viral license?

-- Alex

>
>
> P.S. Regarding license - interesting read in
> https://github.com/BIC-MNI/EBTKS/blob/develop/templates/MatrixSupport.cc ,
> starting at " NOTE: This routine uses at least 2 patented algorithms"
>
>
>
> On 12-08-19 10:49 PM, Andrew Janke wrote:
>>>
>>> I know FFTW from my GNU Octave work, and I think I could hook it in. A
>>> caveat: FFTW is GPL, so the resulting package would have to be under
>>> GPL-compatible terms. The original McGill license is fine, but if
>>> people want to grab it and make non-free derivatives, they won't be
>>> able to do it if we link to FFTW.
>>
>>
>> Indeed, my approach to this a while ago was to write this:
>>
>>     https://github.com/BIC-MNI/mincfft
>>
>> Using much the same interface as Louis originally used in his NR code.
>> The idea was then to distribute the mincfft package as a separate
>> entity thus ameliorating licence difference issues.
>>
>>> If this is acceptable, and I hope it is, I'd be happy to work on the
>>> FFTW integration.
>>
>>
>> More than happy for your help. So if possible the way I'd approach
>> would be to remove the dependency on fft's in EBTKS and instead fork a
>> system call to mincfft in either N3 or EBTKS. This was the original
>> motivation for mincstats (to replace volume_stats) but reproducing the
>> *exact* behaviour of volume_stats proved difficult so it never made it
>> to the drop in replacement stage in N3. :(
>>
>> On the FFTW3 note, let me know if I/we've done anything "suboptimal" in
>> mincfft!
>
>
>
> --
> Best regards,
>  Vladimir S. Fonov ~ vladimir.fonov <at> gmail.com
>
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development
>