Question about licensing

[sorenstoutner]

While reviewing the Debian package, I noticed an inconsistency in the licensing information.

Setup.cfg lists the license as LGPLv2.1+.

https://github.com/vpelletier/python-libusb1/blob/master/setup.cfg#L15

But it also lists the license as LGPLv2+.

https://github.com/vpelletier/python-libusb1/blob/master/setup.cfg#L8

I assume the project used to be LGPLv2+ and was switched at some point to be LGPLv2.1+. Is that the case?

[vpelletier]

I indeed switched from the GPLv2+ to the LGPL.

COPYING.LESSER contains the 2.1, the commit message mention 2.1+, and libusb1 is available under the 2.1+ (and the commit message says in broken english that I intended to align with libusb1's license), so signs point at my intent to switch to 2.1+.

...and I just checked pypi's list of classifiers, and 2.1(+) is absent. I could not immediately find who maintains this list, and have not yet searched for a possible discussion about this missing classifier.

[sorenstoutner]

Thanks for the clarification.

My recommendation would be to try changing:

https://github.com/vpelletier/python-libusb1/blob/master/setup.cfg#L8

From:

License :: OSI Approved :: GNU Lesser General Public License v2 or later (LGPLv2+)

To:

License :: OSI Approved :: GNU Lesser General Public License v2.1 or later (LGPLv2.1+)

It would be interesting to see how PyPI interprets that. There is a possibility it handles it just fine, even thought it isn't in the list.

[vpelletier]

There is a possibility it handles it just fine, even thought it isn't in the list.

My understanding is that this should be rejected by pypi during uploads. I could search some more:

I could not immediately find who maintains this list

Found it: pypa/trove-classifiers repository.

and have not yet searched for a possible discussion about this missing classifier.

I found one relevant discussion.

It references PEP-639, which deprecates the use of license classifiers. It mentions that removing ambiguous license classifiers would be a hard-break requiring authors which use these to update their metadata before they can upload to pypi, hence my expectation that pypi would reject an ad-hoc LGPL-2.1 classifier string.

It also deprecates the the License field, replacing it with License-Expression. But this seems to be only useful for packages covered my multiple license (especially when it's not A-or-B). In the case of python-libusb1, there is a single license so I would rather keep License than discover that the new metadata broke compatibility with some older python out there.

So I think I'll remove the license classifier: it should only be meaningful within the pypi package repository, and even there it is supposed to be deprecated. Would this work for you ?

[sorenstoutner]

Yes, that would be fine. All the other documentation in the package is clear that the license is the LGPL-2.1+, so if this line is remove there will no longer be any confusion.

If for some reason you need to leave this line for compatibility reasons, you could also add some documentation to the project, perhaps in README or the top of COPYING, explaining that the LGPL-2.0+ line is not precise but must exist for PyPI and that the actual license is LGPL-2.1+.

Debian is just a stickler for having accurate copyright and licensing information, which is collected in debian/copyright.

https://salsa.debian.org/python-team/packages/python-libusb1/-/blob/master/debian/copyright?ref_type=heads

One of the automated tools that checks this file currently complains that the license is incorrect and should actually be LGPL-2.0+ for some files. If I need to, I can override this check with a comment pointing to an explanation in README or COPYING.

[merwok]

replacing it with License-Expression. But this seems to be only useful for packages covered my multiple license

No, it’s fine for all cases. You can use the SPDX identifier for LGPLv2.1+ with the new option.
You don’t risk incompatibility with Python, as there is no packaging infrastructure in the stdlib, it’s all in external tools (twine, packaging, flit, setuptools, pypi…)