As I understand it the wiki is talking about including code in
numpy/scipy itself, all code in numpy and scipy must be permissively
licensed so it is easy to reason about when building your binaries.
The license of the binaries produced from the code is a different
matter, which at that time didn't really exist as we didn't distribute
binaries at all (except for windows).
A GPL licensed binary containing numpy is perfectly compatible with
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).
I it is not numpy that is GPL licensed it is the restriction of another
component in the binary distribution that makes the full product adhere
to the most restrictive license
But numpy itself is always permissive, the distributor can always build
a permissive numpy binary without the viral component in it.
On 10/27/2016 05:42 PM, Robert McLeod 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 <mailto: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>
<mailto: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>>
<mailto: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>>
<mailto: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>>
<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>>
<mailto: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>>
<mailto: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
<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 <mailto:NumPy-Discussion@scipy.org>
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
robert.mcl...@unibas.ch <mailto:robert.mcl...@unibas.ch>
robert.mcl...@bsse.ethz.ch <mailto:robert.mcl...@ethz.ch>
robbmcl...@gmail.com <mailto: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
