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 <robbmcleod@gmail.com> wrote:
Releasing NumPy under GPL would make it incompatible with SciPy, which may be _slightly_ inconvenient to the scientific Python community:



Robert

On Thu, Oct 27, 2016 at 5:14 PM, Julian Taylor <jtaylor.debian@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@googlemail.com <mailto:jtaylor.debian@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@gmail.com <mailto:ralf.gommers@gmail.com>
         <mailto:ralf.gommers@gmail.com <mailto:ralf.gommers@gmail.com>>>
        wrote:


            On Thu, Oct 27, 2016 at 10:25 AM, Pavlyk, Oleksandr
            <oleksandr.pavlyk@intel.com
        <mailto:oleksandr.pavlyk@intel.com>
         <mailto:oleksandr.pavlyk@intel.com
        <mailto:oleksandr.pavlyk@intel.com>>> wrote:

                Please see responses inline.



                *From:*NumPy-Discussion
                [mailto:numpy-discussion-bounces@scipy.org
        <mailto:numpy-discussion-bounces@scipy.org>
                <mailto:numpy-discussion-bounces@scipy.org
        <mailto:numpy-discussion-bounces@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.pavlyk@intel.com
        <mailto:oleksandr.pavlyk@intel.com>
         <mailto:oleksandr.pavlyk@intel.com

        <mailto:oleksandr.pavlyk@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.mcleod@unibas.ch

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion