It would still be compatible with SciPy, it would "just" mean that SciPy (and anything else that uses numpy) would be effectively GPL.
On Thu, Oct 27, 2016 at 11:42 AM, Robert McLeod <robbmcl...@gmail.com> wrote: > 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 > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
