[Numpy-discussion] Intel random number package

[Julian Taylor]

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.debian at googlemail.com <mailto:jtaylor.debian at googlemail.com>>
> wrote:
>
>     On 10/27/2016 04:52 PM, Todd wrote:
>
>         On Thu, Oct 27, 2016 at 10:43 AM, Julian Taylor
>         <jtaylor.debian at googlemail.com
>         <mailto:jtaylor.debian at googlemail.com>
>         <mailto:jtaylor.debian at googlemail.com
>         <mailto:jtaylor.debian at googlemail.com>>>
>         wrote:
>
>             On 10/27/2016 04:30 PM, Todd wrote:
>
>                 On Thu, Oct 27, 2016 at 4:25 AM, Ralf Gommers
>                 <ralf.gommers at gmail.com <mailto:ralf.gommers at gmail.com>
>         <mailto:ralf.gommers at gmail.com <mailto:ralf.gommers at gmail.com>>
>                 <mailto:ralf.gommers at gmail.com
>         <mailto:ralf.gommers at gmail.com> <mailto:ralf.gommers at gmail.com
>         <mailto:ralf.gommers at gmail.com>>>>
>                 wrote:
>
>
>                     On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr
>                     <oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>
>                 <mailto:oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>>
>                 <mailto:oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>
>                 <mailto:oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>>>> wrote:
>
>                         Please see responses inline.
>
>
>
>                         *From:*NumPy-Discussion
>                         [mailto:numpy-discussion-bounces at scipy.org
>         <mailto:numpy-discussion-bounces at scipy.org>
>                 <mailto:numpy-discussion-bounces at scipy.org
>         <mailto:numpy-discussion-bounces at scipy.org>>
>                         <mailto:numpy-discussion-bounces at scipy.org
>         <mailto:numpy-discussion-bounces at scipy.org>
>                 <mailto:numpy-discussion-bounces at scipy.org
>         <mailto:numpy-discussion-bounces at scipy.org>>>] *On Behalf Of *Todd
>                         *Sent:* Wednesday, October 26, 2016 4:04 PM
>                         *To:* Discussion of Numerical Python
>                 <numpy-discussion at scipy.org
>         <mailto:numpy-discussion at scipy.org>
>         <mailto:numpy-discussion at scipy.org
>         <mailto:numpy-discussion at scipy.org>>
>                         <mailto:numpy-discussion at scipy.org
>         <mailto:numpy-discussion at scipy.org>
>                 <mailto:numpy-discussion at scipy.org
>         <mailto:numpy-discussion at scipy.org>>>>
>                         *Subject:* Re: [Numpy-discussion] Intel random
>         number
>                 package
>
>
>
>
>                         On Wed, Oct 26, 2016 at 4:30 PM, Pavlyk, Oleksandr
>                         <oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>
>                 <mailto:oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>>
>                 <mailto:oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at intel.com>
>
>                 <mailto:oleksandr.pavlyk at intel.com
>         <mailto:oleksandr.pavlyk at 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 at scipy.org <mailto:NumPy-Discussion at 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.mcleod at unibas.ch <mailto:robert.mcleod at unibas.ch>
> robert.mcleod at bsse.ethz.ch <mailto:robert.mcleod at ethz.ch>
> robbmcleod at gmail.com <mailto:robbmcleod at gmail.com>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>