Releasing NumPy under GPL would make it incompatible with SciPy, which may be _slightly_ inconvenient to the scientific Python community:
https://scipy.github.io/old-wiki/pages/License_Compatibility.html https://mail.scipy.org/pipermail/scipy-dev/2013-August/019149.html Robert On Thu, Oct 27, 2016 at 5:14 PM, Julian Taylor < jtaylor.deb...@googlemail.com> wrote: > On 10/27/2016 04:52 PM, Todd wrote: > >> On Thu, Oct 27, 2016 at 10:43 AM, Julian Taylor >> <jtaylor.deb...@googlemail.com <mailto:jtaylor.deb...@googlemail.com>> >> wrote: >> >> On 10/27/2016 04:30 PM, Todd wrote: >> >> On Thu, Oct 27, 2016 at 4:25 AM, Ralf Gommers >> <ralf.gomm...@gmail.com <mailto:ralf.gomm...@gmail.com> >> <mailto:ralf.gomm...@gmail.com <mailto:ralf.gomm...@gmail.com>>> >> wrote: >> >> >> On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr >> <oleksandr.pav...@intel.com >> <mailto:oleksandr.pav...@intel.com> >> <mailto:oleksandr.pav...@intel.com >> <mailto:oleksandr.pav...@intel.com>>> wrote: >> >> Please see responses inline. >> >> >> >> *From:*NumPy-Discussion >> [mailto:numpy-discussion-boun...@scipy.org >> <mailto:numpy-discussion-boun...@scipy.org> >> <mailto:numpy-discussion-boun...@scipy.org >> <mailto:numpy-discussion-boun...@scipy.org>>] *On Behalf Of *Todd >> *Sent:* Wednesday, October 26, 2016 4:04 PM >> *To:* Discussion of Numerical Python >> <numpy-discussion@scipy.org <mailto:numpy-discussion@scipy.org> >> <mailto:numpy-discussion@scipy.org >> <mailto:numpy-discussion@scipy.org>>> >> *Subject:* Re: [Numpy-discussion] Intel random number >> package >> >> >> >> >> On Wed, Oct 26, 2016 at 4:30 PM, Pavlyk, Oleksandr >> <oleksandr.pav...@intel.com >> <mailto:oleksandr.pav...@intel.com> >> <mailto:oleksandr.pav...@intel.com >> >> <mailto:oleksandr.pav...@intel.com>>> >> wrote: >> >> Another point already raised by Nathaniel is that for >> numpy's randomness ideally should provide a way to >> override >> default algorithm for sampling from a particular >> distribution. For example RandomState object that >> implements PCG may rely on default >> acceptance-rejection >> algorithm for sampling from Gamma, while the >> RandomState >> object that provides interface to MKL might want to >> call >> into MKL directly. >> >> >> >> The approach that pyfftw uses at least for scipy, which >> may also >> work here, is that you can monkey-patch the >> scipy.fftpack module >> at runtime, replacing it with pyfftw's drop-in >> replacement. >> scipy then proceeds to use pyfftw instead of its built-in >> fftpack implementation. Might such an approach work here? >> Users can either use this alternative randomstate >> replacement >> directly, or they can replace numpy's with it at runtime >> and >> numpy will then proceed to use the alternative. >> >> >> The only reason that pyfftw uses monkeypatching is that the >> better >> approach is not possible due to license constraints with >> FFTW (it's >> GPL). >> >> >> Yes, that is exactly why I brought it up. Better approaches are >> also >> not possible with MKL due to license constraints. It is a very >> similar >> situation overall. >> >> >> Its not that similar, the better approach is certainly possible with >> FFTW, the GPL is compatible with numpys license. It is only a >> concern users of binary distributions. Nobody provided the code to >> use fftw yet, but it would certainly be accepted. >> >> >> Although it is technically compatible, it would make numpy effectively >> GPL. Suggestions for this have been explicitly rejected on these >> grounds [1] >> >> [1] https://github.com/numpy/numpy/issues/3485 >> >> > Yes it would make numpy GPL, but that is not a concern for a lot of users. > Users for who it is a problem can still use the non-GPL version. > A more interesting debate is whether our binary wheels should then be GPL > wheels by default or not. Probably not, but that is something that should > be discussed when its an actual issue. > > But to clarify what I said, it would be accepted if the value it provides > is sufficient compared to the code maintenance it adds. Given that pyfftw > already exists the value is probably relatively small, but personally I'd > still be interested in code that allows switching the fft backend as that > could also allow plugging e.g. gpu based implementations (though again this > is already covered by other third party modules). > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > -- Robert McLeod, Ph.D. Center for Cellular Imaging and Nano Analytics (C-CINA) Biozentrum der Universität Basel Mattenstrasse 26, 4058 Basel Work: +41.061.387.3225 robert.mcl...@unibas.ch robert.mcl...@bsse.ethz.ch <robert.mcl...@ethz.ch> robbmcl...@gmail.com
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
