[Numpy-discussion] Copyright status of NumPy binaries on Windows/OS X

Matthew Brett matthew.brett at gmail.com
Fri Oct 10 17:07:02 EDT 2014


Hi,

On Tue, Oct 7, 2014 at 5:13 PM, Julian Taylor
<jtaylor.debian at googlemail.com> wrote:
> On 06.10.2014 18:54, Andrew Collette wrote:
>> Hi all,
>>
>> I am working with the HDF Group on a new open-source viewer program
>> for HDF5 files, powered by NumPy, h5py, and wxPython.  On Windows,
>> since people don't typically have Python installed, we are looking to
>> distribute the application using PyInstaller, which embeds
>> dependencies like NumPy.  Likewise for OS X (using Py2App).
>>
>> We would like to make sure we don't accidentally include
>> non-open-source components... I recall there was some discussion here
>> about using the Intel math libraries for binary releases on various
>> platforms.  Do the releases on SourceForge or PyPI use any proprietary
>> code?  We'd like to avoid building NumPy ourselves if we can avoid it.
>>
>> Apologies if this is explained somewhere, but I couldn't find it.
>>
>> Thanks!
>> Andrew Collette
>
>
> Hi,
> the numpy win32 binaries on sourceforge do not contain any proprietary
> code. They are build with mingw 3.4.5 and are using a f2c'd version of
> netlib blas and lapack which so far I know is public domain.
> I think the macos wheels on pypi are built using ATLAS but they do also
> contain libquadmath which is LGPL licensed. Its probably pulled in by
> fortran (could maybe be removed by a rebuild as neither blas nor numpy
> use it)

Yes, the OSX builds use gcc 4.8.2 and ATLAS [1], and bundle these libraries:

tar tvf numpy-1.9.0-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl
| grep .dylib

numpy/.dylibs/libatlas.dylib
numpy/.dylibs/libcblas.dylib
numpy/.dylibs/libf77blas.dylib
numpy/.dylibs/libgcc_s.1.dylib
numpy/.dylibs/libgfortran.3.dylib
numpy/.dylibs/liblapack.dylib
numpy/.dylibs/libptcblas.dylib
numpy/.dylibs/libptf77blas.dylib
numpy/.dylibs/libquadmath.0.dylib

The libquadmath library is indeed LGPL.   libgcc_s.1 and libgfortran

These libraries are covered by GPLv3 with the "runtime library
exception [2, 3] for code built with gcc and linked against the relevant
runtime libraries.

Here's the relevant text from the exception [2]

"""
You have permission to propagate a work of Target Code formed by combining the
Runtime Library with Independent Modules, even if such propagation would
otherwise violate the terms of GPLv3, provided that all Target Code was
generated by Eligible Compilation Processes. You may then convey such a
combination under terms of your choice, consistent with the licensing of the
Independent Modules.
"""

My understanding of this license is that we are free to distribute our own
linked code under any "terms of our choice" - in our case the BSD license.

However, we are also distrubuting the libraries libgcc, libgomp, libgfortran,
libquadmath, albeit buried in a hidden directory within the wheel.

>From the FAQ entry "I use a proprietary compiler toolchain without any parts
of GCC to compile my program, and link it with libstdc++." [3] I infer that we
need to provide a link to the source code for these standalone runtime
libraries.  I hope a link on the pypi page and a README in the relevant
directory will be enough but we should probably get some advice.  Otherwise I
believe we avoid that requirement by doing static linking.

My reading of that FAQ entry is that anyone can link against the included
gcc runtime libraries under the same runtime library exception, and so will
not need to apply any GPL terms to their linked code.

Julian - it would be good to remove libquadmath with a rebuild - any
pointers on how to do this?

Cheers,

Matthew

[1] https://github.com/MacPython/numpy-atlas-binaries/travis_install.sh
[2[ http://www.gnu.org/licenses/gcc-exception-3.1.html
[3] http://www.gnu.org/licenses/gcc-exception-faq.html



More information about the NumPy-Discussion mailing list