Wheels licensing

[pombredanne]

The Pypi wheels (in particular the manylinux ones) contain prebuilts libraries for openblas (bsd) and libgfortran.... (gpl with runtime exception?) but no information about their licenses and where to get the corresponding sources. It would be great to have some clarity in this domain.
The same issue exists with numpy numpy/numpy#8689

[rgommers]

Where were you looking for that information or would you expect to find it?

[pombredanne]

I found that in the Linux wheels in the .lib directory. For instance: libgfortran-ed201abd.so.3.0.0 and libopenblasp-r0-39a31c03.2.18.so

I would have expected to have found somewhere in the wheel some documentation about the licenses and versions of these .so and where I could get the sources (in particular for libgfortran). Ideally I guess these source may be could also be released on Pypi, as a side sdist? Just an idea.

Wheels have unfortunately limited ways to add extra data unless this is package data, so that would likely need to be some package data of sorts I guess?

[rgommers]

I would have expected to have found somewhere in the wheel some documentation about the licenses

That is feasible. Inside the license file, adding info about all vendored code and bundled binary libs would be useful.

Ideally I guess these source may be could also be released on Pypi, as a side sdist? Just an idea.

No, that would be completely impractical. We are not going to redistribute source code of other projects. Such an idea would get even more impractical if you go higher up the stack - would an application using numpy and scipy then redistribute numpy/scipy source code?

Wheels have unfortunately limited ways to add extra data unless this is package data, so that would likely need to be some package data of sorts I guess?

Don't think there's a good place in the .dist-info directory. In LICENSE.txt is the way to go I think.

[pombredanne]

@rgommers you wrote

No, that would be completely impractical. We are not going to redistribute source code of other projects. Such an idea would get even more impractical if you go higher up the stack - would an application using numpy and scipy then redistribute numpy/scipy source code?

I agree it may not be super practical but that would likely be needed to be squeaky clean on the compliance side at least for libgfortran.... which requires source code redistribution and is vendored as a binary.

Don't think there's a good place in the .dist-info directory. In LICENSE.txt is the way to go I think.

For licenses, there is one special place in wheels that lands in dist-info (for a single file see https://bitbucket.org/pypa/wheel/issues/138/include-more-than-one-license-file-or ) which is enabled with this setup.cfg snippet:

[metadata]
license_file = LICENSE.txt

[rgommers]

I agree it may not be super practical but that would likely be needed to be squeaky clean on the compliance side at least for libgfortran.... which requires source code redistribution and is vendored as a binary

do you have any examples of projects doing that? a link should suffice I'd think.

[rgommers]

For licenses, there is one special place in wheels that lands in dist-info

Thanks, didn't know about that. Wouldn't it just duplicate what we already have in scipy/LICENSE.txt though? So adding more info to that LICENSE.txt file is still the way to go?

[pombredanne]

@rgommers you wrote:

do you have any examples of projects doing that? a link should suffice I'd think.

I am doing this: For any thrid-party binaries that I vendor in https://github.com/nexB/scancode-toolkit I release the exact corresponding source code and notes here: https://github.com/nexB/scancode-thirdparty-src

[pombredanne]

Thanks, didn't know about that. Wouldn't it just duplicate what we already have in scipy/LICENSE.txt though?

This is weird and less documented feature. Eventually license documentation is a tad messy ;) and I would like to fix it https://github.com/pombredanne/spdx-pypi-pep/

So adding more info to that LICENSE.txt file is still the way to go?

This sure is. That or a separate file for third-parties is commonly done too. I will be glad to help in any way I can there.

[rgommers]

I agree it may not be super practical but that would likely be needed to be squeaky clean on the compliance side at least for libgfortran.... which requires source code redistribution and is vendored as a binary.

As usual there is lots of conflicting information to be found, but https://www.gnu.org/licenses/gcc-exception-3.1.en.html says nothing about redistribution. It's not clear not me that a link to the source code is not enough and actual redistribution is needed. Do you have an authoritative source?

[pombredanne]

This exception is just that: an exception to the GPL. It does not remove the obligations of source code redistribution for libgfortran itself. The exception just weakens the GPL copyleft to something that is actually gentler that an LGPL such the copyleft does not flow to the calling code (here scipy).

[pombredanne]

The authoritative source is the GPL text here. And I guess some would consider me an authority in this domain too.

[njsmith]

@pombredanne: I disagree with your interpretation. The runtime exception states: "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". Our wheel is a combination of the Runtime Library (libgfortran) with Independent Modules (scipy), and that sentence pretty clearly states that the GPL text does not apply.

[rgommers]

It does not remove the obligations of source code redistribution for libgfortran itself.

Independent of whether the GPL applies, what is the definition of redistribution:

• a link to the source (which is a one-liner in LICENSE.txt to the version we used)
• a separate repo with source code on GitHub (like in your example)
• a separate sdist on PyPI (which is what you suggested)
• ...?

I always understood it as allowing anyone who asked access to the source code, which means a link is fine.

[njsmith]

@rgommers: you can't really talk about this independent of the GPL, because it's the GPL text that (if it applies) imposes the requirement of "redistributing source", and defines what that means. Specifically it looks like the details are in section 6 of the GPLv3 (that page doesn't seem to let me link to the section directly, unfortunately).