Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
On 30 Oct 2014 03:58, Sturla Molden sturla.mol...@gmail.com wrote: [...] We cannot bundle NumPy or SciPy binaries with FFTW due to GPL [*], but as I understand it we already have permission from Intel to bundle binary wheels linked with MKL. Accelerate is a system library, so that does not pose a license problem. [*] Actually, we could, but the binaries would be tainted with a viral license. And binaries linked with MKL are tainted by a proprietary license... They have very similar effects, in both cases you can use the binary just fine for whatever you want, but if you redistribute it as part of a larger work, then you must (follow the terms of the GPL/follow the terms of Intel's license). -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
On 30/10/14 03:58, Sturla Molden wrote: MKL has an API compatible with FFTW, so FFTW and MKL can be supported with the same C code. Compatible with big caveats: https://software.intel.com/en-us/node/522278 Henry ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
Nathaniel Smith n...@pobox.com wrote: [*] Actually, we could, but the binaries would be tainted with a viral license. And binaries linked with MKL are tainted by a proprietary license... They have very similar effects, The MKL license is proprietary but not viral. Sturla ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
On Thu, Oct 30, 2014 at 11:11 AM, Sturla Molden sturla.mol...@gmail.com wrote: Nathaniel Smith n...@pobox.com wrote: [*] Actually, we could, but the binaries would be tainted with a viral license. And binaries linked with MKL are tainted by a proprietary license... They have very similar effects, The MKL license is proprietary but not viral. For our purposes, it has the same effect, though. As a project policy, we only want to put out official binaries that can be used in both proprietary and GPLed projects. Since proprietary licenses and GPL licenses are mutually incompatible, we cannot use components that are either proprietary or GPLed in our official binaries. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
On 30 Oct 2014 11:12, Sturla Molden sturla.mol...@gmail.com wrote: Nathaniel Smith n...@pobox.com wrote: [*] Actually, we could, but the binaries would be tainted with a viral license. And binaries linked with MKL are tainted by a proprietary license... They have very similar effects, The MKL license is proprietary but not viral. If you like, but I think you are getting confused by the vividness of anti-GPL rhetoric. GPL and proprietary software are identical in that you have to pay some price if you want to legally redistribute derivative works (e.g. numpy + MKL/FFTW + other software). For proprietary software the price is money and other random more or less onerous conditions (e.g. anti-benchmarking and anti-reverse-engineering clauses are common). For GPL software the price is that you have to let people reuse your source code for free. That's literally all that viral means. Which of these prices you find more affordable will depend on your circumstances. Either way it's just something to take into account before redistributing tainted binaries. -n ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
I think that numpy.fft should be left there in its current state (although perhaps as deprecated). Now scipy.fft should have a good generic algorithm as default, and easily allow for different implementations to be accessed through the same interface. I also agree with the above. But I want to add that in this case it would be wise to include some (sophisticated) testing suite to ensure that all possible libraries implement the DFT with high accuracy. numpy's fftpack (or scipy's) has the advantage that it is old and well tested. FFTW also provides extensive benchmarks of speed and accuracy. Other libraries do not. Most users just want an fft function that works and not bother with details like numerical accuracy. When I encountered such an issue (https://github.com/hgomersall/pyFFTW/issues/51) it took me really a long time to track it down to the fft function. One remark to FFTS: does it implement double precision yet? The corresponding issue (https://github.com/anthonix/ffts/issues/24) seems to be still open but I did not look into it. If it does not it is not suited as a fftpack replacement (I hope I did not overlook some comment about that in the thread). Cheers Nils PS: although I am a long time user of numpy, I am fairly new to the list. So hello! ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
On Thu, Oct 30, 2014 at 4:28 AM, Nathaniel Smith n...@pobox.com wrote: On 30 Oct 2014 11:12, Sturla Molden sturla.mol...@gmail.com wrote: Nathaniel Smith n...@pobox.com wrote: [*] Actually, we could, but the binaries would be tainted with a viral license. And binaries linked with MKL are tainted by a proprietary license... They have very similar effects, The MKL license is proprietary but not viral. If you like, but I think you are getting confused by the vividness of anti-GPL rhetoric. GPL and proprietary software are identical in that you have to pay some price if you want to legally redistribute derivative works (e.g. numpy + MKL/FFTW + other software). For proprietary software the price is money and other random more or less onerous conditions (e.g. anti-benchmarking and anti-reverse-engineering clauses are common). For GPL software the price is that you have to let people reuse your source code for free. That's literally all that viral means. I wrote a summary of the MKL license problems here: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows#blas--lapack-libraries In summary, if you distribute something with the MKL you have to: * require your users to agree to a license forbidding them from reverse-engineering the MKL * indemnify Intel against being sued as a result of using MKL in your binaries I think the users are not allowed to further distribute any part of the MKL libraries, but I am happy to be corrected on that. Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
On Thu, Oct 30, 2014 at 10:24 AM, Matthew Brett matthew.br...@gmail.com wrote: On Thu, Oct 30, 2014 at 4:28 AM, Nathaniel Smith n...@pobox.com wrote: On 30 Oct 2014 11:12, Sturla Molden sturla.mol...@gmail.com wrote: Nathaniel Smith n...@pobox.com wrote: [*] Actually, we could, but the binaries would be tainted with a viral license. And binaries linked with MKL are tainted by a proprietary license... They have very similar effects, The MKL license is proprietary but not viral. If you like, but I think you are getting confused by the vividness of anti-GPL rhetoric. GPL and proprietary software are identical in that you have to pay some price if you want to legally redistribute derivative works (e.g. numpy + MKL/FFTW + other software). For proprietary software the price is money and other random more or less onerous conditions (e.g. anti-benchmarking and anti-reverse-engineering clauses are common). For GPL software the price is that you have to let people reuse your source code for free. That's literally all that viral means. I wrote a summary of the MKL license problems here: https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows#blas--lapack-libraries In summary, if you distribute something with the MKL you have to: * require your users to agree to a license forbidding them from reverse-engineering the MKL * indemnify Intel against being sued as a result of using MKL in your binaries Sorry - I should point out that this last 'indemnify' clause is including attorney's fees. Meaning that, if someone sues Intel because of your software, you have to pay Intel's attorney's fees. Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
