Why licenses of vendored libraries are not distributed in wheels?

[McSinyx]

This issue is opened as suggested on IRC. The question was originally raised by PyDon:

• The source distribution and the source tree controlled by git include vendor libs' LICENSE files

• However, wheels (and thus installed versions) of pip don't include these files

• As stated in Vendoring Policy,

  Vendored libraries MUST be accompanied with LICENSE files.

We wonder if the LICENSE files are to accompanied installed vendored libraries. As pip is licensed under MIT, I believe packages shipped along (i.e. vendored) with pip must be released under MIT-compatible licenses, i.e. permissive licenses. If so, I think pip may impose MIT over those libraries and inclusion of their licenses are just the matter of courtesy. I am not a lawyer so there's a high chance that I am wrong though, and if that's the case, we might need to do something about it.

In addition, I think our vendoring policy might want to require libraries to be vendored must be available under a MIT-compatible license. If this is agreed upon, I'll file a PR to clarify it.

[uranusjr]

This should probably be raised in pypa/packaging-problems instead; pip does not build the wheel on its own, and cannot control what goes into it.

Edit: I misread the issue; this is about pip not packaging licenses with its vendored packages. In that case I think it is simply an oversight on writing MANIFEST.in. We can fix that easy enough.

[McSinyx]

In that case I think it is simply an oversight on writing MANIFEST.in

I think MANIFEST.in only handle sdist, which already distribute license files at the moment. That being said, the setuptools configuration is not difficult to be modified to include LICENSE* files. So do you confirm that we should vendor the licenses in wheels as well?

[uranusjr]

Not 100% sure, but I think there’s no reason not to, so I’d say let’s fire a PR and see if anyone objects…

[McSinyx]

Thanks, I'm doing it now, instead of sitting here waiting for my burn-out to go down 😄

Edit: as said by @pfmoore below, I'll wait for more opinions from other pip's maintainers for a consensus on this.

[pfmoore]

I'm somewhat worried about the extra size this would add to the pip wheel. It's an extra 100k, which is a 7% size increase. For something downloaded as often as pip, that's a non-trivial increase...

I'm not going to make an issue of this (I have no idea of the legal implications), but pip is downloaded a lot, and we should be careful about how much bandwidth we consume...

[pradyunsg]

I'm not going to make an issue of this (I have no idea of the legal implications)

I'd like to only make this change if there's legal implications to not doing so.

[dstufft]

We can probably ask the PSF for a recommendation here.

[GadgetSteve]

I would suggest asking the FSF (Free Software Foundation) if their legal team think that there is an obligation for a distribution tool such as pip to attempt to ensure that packages distributed include either a License or Copying file. A quick check on the wheels currently sitting on my system showed that of 81 wheels 45 included license, 3 copying and 33 neither. Rather than a change to pip maybe the lack of a file inside of a wheel would be better as an upload check on pypi?

[uranusjr]

There are many licenses that do not require a copy of the license text. A general PyPI check is unfortunately not feasible since there is no standard way to declare the license used by a given Python package. I suggest we focus on fixing its own vendoring licenses here; the license check suggestion has much wider implications and is not suitable to be discussed here.