[MINC-development] experiments with EBTKS and N3

[Jordi Gutiérrez Hermoso]

On 12-08-19 10:49 PM, Andrew Janke wrote:

> On 19 August 2012 22:11, Jordi Gutiérrez Hermoso
> <jordigh at octave.org> 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/mincfftw

That link seems broken. But I assume you're attempting to write a GPL
wrapper? The FSF's legal opinion is that this doesn't exclude MINC
from its GPL obligations:

    http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#GPLWrapper

Since the FSF wrote the GPL, I would assume a court would side with
this opinion. People keep wanting to get around the GPL by writing
wrappers. This doesn't achieve the purpose.

>> 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.

Since mincfft really serves no purpose, can we just directly call
FFTW? Is there still a reason to keep the GPL out of MINC?

On 20 August 2012 01:01, Vladimir S. Fonov <vladimir.fonov at gmail.com>
wrote:
> I would very much prefer, if we replace EBTKS with something more or
> less standard, for example GSL.

The GSL's Fourier transforms are based on the old Netlib FFTPACK
routines. They are ok, I guess, but FFTW *is* standard. The only
reason to not use FFTW is a distaste for the GPL. Scipy for example
used FFTW until they were unhappy with the GPL status and they
switched to FFTPACK.

So, the only reason you might have for not using FFTW also applies to
the GSL, which is also GPL'ed. So the GSL gives no advantage over
FFTW.

> I don't really see any advantage of switching internal C routine for
> FFT computation with FFTW.

FFTW is a great package. It's fast, it's flexible, it's standard.
There are good reasons to use it.

> 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"

It look like the patents are at least 20 years old. They've likely
expired by now. But if they haven't, all the more reason to replace
this code. Having non-free code of dubious legal status is worse than
having forever free code.

- Jordi G. H.