From vladimir.fonov at gmail.com Mon Aug 13 14:07:48 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 13 Aug 2012 14:07:48 -0400 Subject: [MINC-development] issue with mincresample -like In-Reply-To: <1344880244.13634.1392.camel@talos> References: <1344880244.13634.1392.camel@talos> Message-ID: <50294274.7020607@gmail.com> > From: Haz-Edine Assemlal > To: MINC development discussion & planning > > Subject: issue with mincresample -like > Date: Mon, 13 Aug 2012 12:14:37 -0400 > > Hi, > I may found a bug in mincresample (2.1). The '-like' option does not > properly copy the direction cosines values, although it is close (see > below). Interestingly, this bug does not occur on version 1.4.. > > Here is an example: > > Like image: > {'xspace': (0.9981327898977128, 0.046475758059076284, > -0.039635055744158695), > 'yspace': (-0.046313143258233096, 0.9989143988555348, > 0.005011638517282589), > 'zspace': (0.03982494758149069, -0.0031666567204868285, > 0.9992016542396965)} > > Output image: > {'xspace': (0.9981327898977128, 0.046475758059076284, > -0.039635055744158695), > 'yspace': (-0.0463131432582331, 0.9989143988555349, > 0.00501163851728259), > 'zspace': (0.03982494758149069, -0.0031666567204868285, > 0.9992016542396965)} > > Note that I fixed this (quick and dirty hack) with an additional > software using EZMinc. From vladimir.fonov at gmail.com Fri Aug 17 14:05:46 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Fri, 17 Aug 2012 14:05:46 -0400 Subject: [MINC-development] experiments with EBTKS and N3 Message-ID: Hello Everybody, I've been trying to fix a bug in N3, causing it to crash on some files. It turned out that the results of sharpen_hist was not making sense when compiled on some platforms: this behaviour would present itself was compiled on Debian 6, but wouldn't happen when compiled on Ubuntu 12.04. It turned out that the problem was caused by differences in implementation of FFT in EBTKS. The underlying function Mat._fft was implemented in Matrix.h for generic case , and then redefined in MatrixSpec.cc for cases of complex and complex . It turned out that generic implementation was incorrect, but specific implementation for complex and complex was correct. So, when due to some strange reasons linker would find specific implementation from MatrixSpec.cc , sharpen_hist would work as expected. Right now, I have made a lot of changes in EBTKS ( develop branch on https://github.com/BIC-MNI/EBTKS ). Right now N3 seem to work properly regardless how it is compiled, but the results on 32bit are not quite the same as on 64bit platform. -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From a.janke at gmail.com Sun Aug 19 06:56:20 2012 From: a.janke at gmail.com (Andrew Janke) Date: Sun, 19 Aug 2012 20:56:20 +1000 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References: Message-ID: Hi Vlad, Thanks for all this work, myself I hadn't seen this (being in general a Ubuntu-phile). My preference would be to dump the FFT code in EBTKS all together and use fftw! happen to know if this works or are the results again different to EBTKS's version of FFT? There is an example MINC usage of fftw in mincfft (still in cvs/minc_dev/mincfft IIRC) if this helps. In the meantime I see you are using the develop branch, any chance of pushing the changes over to the master and tagging a release? From there I can put a new .tar.gz up on packages.bic.mni.mcgill.ca/tgz this is something that I think definitely warrants a new release. Thanks a On 18 August 2012 04:05, Vladimir S. FONOV wrote: > Hello Everybody, > > I've been trying to fix a bug in N3, causing it to crash on some > files. It turned out that the results of sharpen_hist was not making > sense when compiled on some platforms: this behaviour would present > itself was compiled on Debian 6, but wouldn't happen when compiled on > Ubuntu 12.04. > > It turned out that the problem was caused by differences in > implementation of FFT in EBTKS. The underlying function Mat._fft > was implemented in Matrix.h for generic case , and then redefined in > MatrixSpec.cc for cases of complex and complex . It > turned out that generic implementation was incorrect, but specific > implementation for complex and complex was correct. > So, when due to some strange reasons linker would find specific > implementation from MatrixSpec.cc , sharpen_hist would work as > expected. > > Right now, I have made a lot of changes in EBTKS ( develop branch on > https://github.com/BIC-MNI/EBTKS ). > > Right now N3 seem to work properly regardless how it is compiled, but > the results on 32bit are not quite the same as on 64bit platform. > > -- > Best regards, > > Vladimir S. Fonov ~ vladimir fonov gmail com > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From vladimir.fonov at gmail.com Sun Aug 19 15:55:41 2012 From: vladimir.fonov at gmail.com (Vladimir S. Fonov) Date: Sun, 19 Aug 2012 15:55:41 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

Message-ID: <503144BD.9060702@gmail.com> Hello, the error was in the interface between Mat and underlying FFT routine in EBTKS. The library now seem to be producing the same result as R - I made a small test in https://github.com/BIC-MNI/EBTKS/blob/develop/testing/ebtks_test_fft.cc Before making a new release version, autoconf/automake stuff have to be updated. Or we can completely switch to cmake. On 19/08/2012 6:56 AM, Andrew Janke wrote: > Hi Vlad, > > Thanks for all this work, myself I hadn't seen this (being in general > a Ubuntu-phile). My preference would be to dump the FFT code in EBTKS > all together and use fftw! happen to know if this works or are the > results again different to EBTKS's version of FFT? > > There is an example MINC usage of fftw in mincfft (still in > cvs/minc_dev/mincfft IIRC) if this helps. > > In the meantime I see you are using the develop branch, any chance of > pushing the changes over to the master and tagging a release? From > there I can put a new .tar.gz up on packages.bic.mni.mcgill.ca/tgz > this is something that I think definitely warrants a new release. > On 18 August 2012 04:05, Vladimir S. FONOV wrote: >> Hello Everybody, >> >> I've been trying to fix a bug in N3, causing it to crash on some >> files. It turned out that the results of sharpen_hist was not making >> sense when compiled on some platforms: this behaviour would present >> itself was compiled on Debian 6, but wouldn't happen when compiled on >> Ubuntu 12.04. >> >> It turned out that the problem was caused by differences in >> implementation of FFT in EBTKS. The underlying function Mat._fft >> was implemented in Matrix.h for generic case , and then redefined in >> MatrixSpec.cc for cases of complex and complex . It >> turned out that generic implementation was incorrect, but specific >> implementation for complex and complex was correct. >> So, when due to some strange reasons linker would find specific >> implementation from MatrixSpec.cc , sharpen_hist would work as >> expected. >> >> Right now, I have made a lot of changes in EBTKS ( develop branch on >> https://github.com/BIC-MNI/EBTKS ). -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From a.janke at gmail.com Sun Aug 19 20:53:14 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 20 Aug 2012 10:53:14 +1000 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: <503144BD.9060702@gmail.com> References:

<503144BD.9060702@gmail.com> Message-ID: > the error was in the interface between Mat and underlying FFT routine in > EBTKS. The library now seem to be producing the same result as R - I made a > small test in > https://github.com/BIC-MNI/EBTKS/blob/develop/testing/ebtks_test_fft.cc ok. > Before making a new release version, autoconf/automake stuff have to be > updated. Or we can completely switch to cmake. I'll update the autoconf/make when you push the changes across from the develop branch. a From jordigh at octave.org Sun Aug 19 22:11:24 2012 From: jordigh at octave.org (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Sun, 19 Aug 2012 22:11:24 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

Message-ID: On 19 August 2012 06:56, Andrew Janke wrote: > My preference would be to dump the FFT code in EBTKS > all together and use fftw! 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. If this is acceptable, and I hope it is, I'd be happy to work on the FFTW integration. - Jordi G. H. From a.janke at gmail.com Sun Aug 19 22:49:59 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 20 Aug 2012 12:49:59 +1000 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

Message-ID: > 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! Thanks a From vladimir.fonov at gmail.com Mon Aug 20 01:01:01 2012 From: vladimir.fonov at gmail.com (Vladimir S. Fonov) Date: Mon, 20 Aug 2012 01:01:01 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

Message-ID: <5031C48D.60504@gmail.com> 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. 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 gmail.com From jordigh at octave.org Mon Aug 20 09:00:35 2012 From: jordigh at octave.org (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Mon, 20 Aug 2012 09:00:35 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: <5031C48D.60504@gmail.com> References:

<5031C48D.60504@gmail.com> Message-ID: On 12-08-19 10:49 PM, Andrew Janke wrote: > On 19 August 2012 22:11, Jordi Guti?rrez Hermoso > 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 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. From a.janke at gmail.com Mon Aug 20 09:18:20 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 20 Aug 2012 23:18:20 +1000 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com> Message-ID: >> 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? whoops, that should be this: https://github.com/BIC-MNI/mincfft It's a stand alone minc tool to do FFT's and magnitude/phase calculations. I wrote it to take care of FID reconstructions a while back. The licence on this code is supposed to be GPL but I note I have copied in the wrong licence file (std MINC) while copying things from CVS to GIT. So no, not a wrapper, but a stand alone GPL tool to do FFT's on MINC volumes. > Since mincfft really serves no purpose, can we just directly call > FFTW? Is there still a reason to keep the GPL out of MINC? The long standing reason to keep GPL out of MINC is to assist with any possible future use by commercial companies. (Siemens might just one day decide to export files in MINC). There are also a few ex MINC devs who have gone on to do commercial development who might comment. Granted these sort of restrictions have now been shown to be not that much of an issue with the test of time. Remember that MINC is now a 15 year old project! Note also that there are GPL MINC packages, most of what Jason Lerch wrote for example. The hard part is keeping all the licences straight in metapackages. You will also find de-GPL'ifiying in MINC mincsample in the develop branch is an example: https://github.com/BIC-MNI/minc/tree/develop/progs/mincsample I originally used the GPL version of this in GSL but switched the original mt19937 code with a more liberal licence: https://github.com/BIC-MNI/minc/blob/develop/progs/mincsample/mt19937ar.h a From a.janke at gmail.com Mon Aug 20 09:28:02 2012 From: a.janke at gmail.com (Andrew Janke) Date: Mon, 20 Aug 2012 23:28:02 +1000 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com>

Message-ID: Now fixed! mincfft was originally based upon a tool that louis wrote from NR code and I updated to use fftw for 2D+3D FFT's. Seems that while I had the GPL COPYING file in my local CVS repository (automatic from automake/autoconf) I never uploaded it to the BIC (private) cvsroot and thus the shift to GIT never saw this? Wierd, probably caused by an errant entry in a .cvsignore somewhere. a On 20 August 2012 23:18, Andrew Janke wrote: > The licence on this code is supposed to be GPL but I note I have > copied in the wrong licence file (std MINC) while copying things from > CVS to GIT. From zijdenbos at gmail.com Mon Aug 20 10:15:22 2012 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 20 Aug 2012 10:15:22 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: <5031C48D.60504@gmail.com> References:

<5031C48D.60504@gmail.com> Message-ID: 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 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 gmail.com > > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From jordigh at octave.org Mon Aug 20 10:21:29 2012 From: jordigh at octave.org (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Mon, 20 Aug 2012 10:21:29 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com> Message-ID: On 20 August 2012 10:15, Alex Zijdenbos wrote: > Are there any (viable) FFT code/libraries out there that do not > carry a viral license? I prefer the term "hereditary license". It's not an infection. It's a gift that has been passed down to other generations. I like the GPL. I think the GPL is a great way to do business and be fair to your users. At any rate, if you really think the GPL is a poison, you can use the original FFTPACK instead of FFTW. It sucks compared to FFTW, old, slower, unmaintained, but it won't force you to be nice to your downstream users and give them source. This is the path that Scipy takes. - Jordi G. H. From jordigh at octave.org Mon Aug 20 10:46:59 2012 From: jordigh at octave.org (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Mon, 20 Aug 2012 10:46:59 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com>

Message-ID: On 20 August 2012 09:28, Andrew Janke wrote: > On 20 August 2012 23:18, Andrew Janke wrote: >> The licence on this code is supposed to be GPL but I note I have >> copied in the wrong licence file (std MINC) while copying things from >> CVS to GIT. > Now fixed! This was unnecessary, btw. You don't have to change the license of your code in order to link it with the GPL. You just cannot use a license that imposes conditions that the GPL doesn't impose. - Jordi G. H. From vladimir.fonov at gmail.com Mon Aug 20 11:56:12 2012 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Mon, 20 Aug 2012 11:56:12 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com> Message-ID: Hello, Let me explain my previous email in more details. The problem with N3 came from sloppy c++ wrapper around FFT library. There are might be other potential problems with this c++ library, because it its mainly unsupported and have been tweaked around many times also there are no documentation and no regression tests for it. The real improvement would be to address problems mentioned above, for example by going over code and making test cases for all functionality of EBTKS. The possible performance improvement of replacing existing Fft code with FFTW is going to be negligible, at least for N3 (and I think this is the only place where it is used currently). On Mon, Aug 20, 2012 at 9:00 AM, Jordi Guti?rrez Hermoso wrote: > On 12-08-19 10:49 PM, Andrew Janke wrote: > >> On 19 August 2012 22:11, Jordi Guti?rrez Hermoso >> 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 > 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. > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development -- Best regards, Vladimir S. Fonov ~ vladimir fonov gmail com From zijdenbos at gmail.com Mon Aug 20 13:11:30 2012 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Mon, 20 Aug 2012 13:11:30 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com>

Message-ID: Well, ideological arguments aside, there is a reality out there; part of which is that MINC is not a new project but has been distributed with its no-strings-attached BSD-like license for almost 20 years now. Migrating it to a restrictive license like GPL will have very practical, negative effects on part of its current user base (including me, but I am sure there are quite a few others). I don't think that should be taken lightly. -- Alex On Mon, Aug 20, 2012 at 10:21 AM, Jordi Guti?rrez Hermoso wrote: > On 20 August 2012 10:15, Alex Zijdenbos wrote: > >> Are there any (viable) FFT code/libraries out there that do not >> carry a viral license? > > I prefer the term "hereditary license". It's not an infection. It's a > gift that has been passed down to other generations. I like the GPL. I > think the GPL is a great way to do business and be fair to your users. > > At any rate, if you really think the GPL is a poison, you can use the > original FFTPACK instead of FFTW. It sucks compared to FFTW, old, > slower, unmaintained, but it won't force you to be nice to your > downstream users and give them source. This is the path that Scipy > takes. > > - Jordi G. H. > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From jordigh at octave.org Mon Aug 20 13:31:10 2012 From: jordigh at octave.org (=?UTF-8?Q?Jordi_Guti=C3=A9rrez_Hermoso?=) Date: Mon, 20 Aug 2012 13:31:10 -0400 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com>

Message-ID: On 20 August 2012 13:11, Alex Zijdenbos wrote: > Well, ideological arguments aside, [snip] > Migrating it to a restrictive license You did not push ideology aside as you said you would; you used ideologically-loaded words such as "restrictive" for the GPL. :-( > like GPL will have very practical, negative effects on part of its > current user base (including me, but I am sure there are quite a few > others). I don't think that should be taken lightly. In that case, FFTPACK or maintaining the current FFT implementation are the only reasonable choices. There is no point in writing wrappers for GPL'ed libraries like FFTW. There is an idea that only the method in which things communicate matters, that if you make a wrapper that uses pipes instead of dynamic linking, then you're exempt from the GPL. According to the FSF, this is not the case. The nature of the data that is passed around also matters, not the method alone: http://www.gnu.org/licenses/gpl-faq.html#MereAggregation So, if MINC doesn't need very good FFT computations, you can use an inferior method. It's probably easiest to follow Vladimir's original suggestion and just maintain what is currently there. I'm less capable of doing this myself, however. It's very easy for me to hook in FFTW into MINC. It's less easy for me to figure out what is wrong with the current FFT implementation. - Jordi G. H. From a.janke at gmail.com Mon Aug 20 22:09:45 2012 From: a.janke at gmail.com (Andrew Janke) Date: Tue, 21 Aug 2012 12:09:45 +1000 Subject: [MINC-development] experiments with EBTKS and N3 In-Reply-To: References:

<5031C48D.60504@gmail.com>

Message-ID: Hi Jordi, On 21 August 2012 00:46, Jordi Guti?rrez Hermoso wrote: >> Now fixed! > > This was unnecessary, btw. You don't have to change the license of > your code in order to link it with the GPL. You just cannot use a > license that imposes conditions that the GPL doesn't impose. You are no doubt right. However I tend to use a GPL licence on any code that links to anything GPL to save confusion down the line. It also makes it very obvious (to me) when packaging things at the "MINC" level as to which things can and can't go into MINC itself. a