Hi, On Tue, Oct 7, 2014 at 5:13 PM, Julian Taylor <jtaylor.debian@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)

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

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. 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

this applies to the mingw-w64 builds as well see also: https://gcc.gnu.org/ml/fortran/2014-10/msg00038.html From: "Joseph S. Myers" <joseph at codesourcery dot com> To: FX <fxcoudert at gmail dot com> Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, fortran List <fortran at gcc dot gnu dot org> Date: Mon, 6 Oct 2014 20:38:14 Subject: Re: [patch] Add -static-libquadmath option Since -static-libquadmath introduces LGPL requirements on redistributing the resulting binaries (that you provide source or relinkable object files to allow relinking with modified versions of libquadmath) that don't otherwise generally apply simply through using GCC to build a program even if you link in GCC's other libraries statically, it would seem a good idea for the documentation of this option to make that explicit. Joseph S. Myers ____ -carlkl 2014-10-10 23:28 GMT+02:00 Julian Taylor <jtaylor.debian@googlemail.com>:

On 10.10.2014 23:07, Matthew Brett wrote:

...

Hi,

On Tue, Oct 7, 2014 at 5:13 PM, Julian Taylor <jtaylor.debian@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)

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

You'd probably have to rebuild gfortran with quadmath disabled. It is a configuration flag of the gcc build. Then rebuild the binaries with that toolchain.

But I'm not convinced it needs to be removed. Is LGPL really a problem? As long as you don't static link it (and not also ship the objects) it should be fine also for commercial programs. Note that there is no -static-quadmath flag, most likely because it would allow accidental license violation. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

Hi Travis, the Anaconda binaries (free packages as well as the non-free addons) link against Intel MKL - not against ATLAS. Are this binaries really free redistributable as stated? The lack of numpy/scipy 64bit windows binaries with opensource blas/lapack with was one of the main reasons to start with the development of a dedicated mingw-w64 based compiler toolchain to support OpenBLAS / ATLAS based binaries on windows. Cheers, carlkl 2014-10-08 1:32 GMT+02:00 Travis Oliphant <travis@continuum.io>:

Hey Andrew,

You can use any of the binaries from Anaconda and redistribute them as long as you "cite" Anaconda --- i.e. tell your users that they are using Anaconda-derived binaries. The Anaconda binaries link against ATLAS.

The binaries are all at http://repo.continuum.io/pkgs/

In case you weren't aware:

Another way you can build and distribute an "application" is to build a 'conda' meta-package which lists all the dependencies. If you add to this meta-package 1) an icon and 2) an entry-point, then your application will automatically show up in the "Anaconda Launcher" (see this blog-post: http://www.continuum.io/blog/new-launcher ) and anyone with the Anaconda Launcher app can install/update your package by clicking on the icon next to it.

Users can also install your package with conda install or using the conda-gui.

Best,

-Travis

On Mon, Oct 6, 2014 at 11:54 AM, Andrew Collette < andrew.collette@gmail.com> 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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion

--

Travis Oliphant CEO Continuum Analytics, Inc. http://www.continuum.io

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

Travis Oliphant <travis@continuum.io> wrote:

Microsoft has actually released their Visual Studio 2008 compiler stack so that OpenBLAS and ATLAS could be compiled on Windows for these platforms as well. I would be very interested to see conda packages for these libraries which should be pretty straightforward to build.

OpenBLAS does not compile with Microsoft compilers because of AT&T assembly syntax. You need to use a GNU compiler and you also need to have a GNU environment. OpenBLAS is easy to build on Windows with MinGW (with gfortran) and MSYS. Carl's toolchain ensures that the binaries are compatible with the Python binaries from Python.org. Sturla

Travis Oliphant <travis@continuum.io> wrote:

A good mingw64 stack for Windows would be great and benefits many communities.

Carl Kleffner has made 32- and 64-bit mingw stacks compatible with Python. E.g. the stack alignment in the 32-bit version is different from the vanilla mingw distribution. It also, for the first time, allow us to build SciPy with gfortran instead of g77 on Windows, which means we don't have to limit the Fortran code in SciPy to Fortran 77 legacy code. Sturla