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

Reply via email to