As I understand it the wiki is talking about including code in
licensed so it is easy to reason about when building your binaries.
binaries at all (except for windows).
SciPy. It may not be compatible with some other component which has an
actually incompatible license (e.g. anything you cannot distribute the
source of as required by the GPL).
a permissive numpy binary without the viral component in it.
Post by Robert McLeodReleasing NumPy under GPL would make it incompatible with SciPy, which
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
On Thu, Oct 27, 2016 at 10:43 AM, Julian Taylor
On Thu, Oct 27, 2016 at 4:25 AM, Ralf Gommers
On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr
Please see responses inline.
*From:*NumPy-Discussion
*Sent:* Wednesday, October 26, 2016 4:04 PM
*To:* Discussion of Numerical Python
*Subject:* Re: [Numpy-discussion] Intel random
number
package
On Wed, Oct 26, 2016 at 4:30 PM, Pavlyk, Oleksandr
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
<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
https://mail.scipy.org/mailman/listinfo/numpy-discussion
<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
_______________________________________________
NumPy-Discussion mailing list
https://mail.scipy.org/mailman/listinfo/numpy-discussion