setuptools contains code under LGPLv3, BSD, Apache, and PSFL

[tiran]

setuptools license information suggests that setuptools only contains code under MIT license. However that is incorrect. Setuptools vendors and ships code that has different licenses

• Since commit 00384a5 and 71.0.0, setuptools has been vendoring the autocommand package. The autocommand package has the copyleft license LGPLv3
• importlib_metadata, importlib_resources, and packaging are under Apache Software License. packaging is also under BSD license
• typing_extesion is under Python Software Foundation License

Please make sure that setuptools correctly declares all licenses of code that is bundled and shipped with setuptools.

I'm a bit concerned that setuptools started to include LGPL software without declaring it. LGPL code is also problematic in closed source and proprietary software. Does Python import count as static or dynamic linking?

[tiran]

The LGPLv3 issue is has been filed as #5045 a month ago.

[tiran]

I did a bit more digging. @carsongee raised the license concern in the PR that added LGPLv3 software, #4457 (comment) . The comment was made after the PR landed. It still should not have been ignored by the maintainers.

Also it was completely unnecessary to add the autocommand package. The package is used in two script files that are not even importable Python modules. The code is not used by setuptools at all.

• setuptools/_vendor/jaraco/text/strip-prefix.py
• setuptools/_vendor/jaraco/text/show-newlines.py

[carsongee]

Thanks for raising it @tiran !

[abravalheri]

It still should not have been ignored by the maintainers.

I don't think it was ignored, it is probably more of a matter of bandwidth.

---

Regarding use of LGPL, @jaraco would it be OK if we assign the analysis of the issue to you? (as it involves some libraries introduced earlier in some of your commits)

---

Regarding the statement setuptools license information suggests that setuptools only contains code under MIT license, this was one of my concerns with the adoption of license = MIT in pyproject.toml (expressed in #4975 (comment)). My proposal is as follows:

• Remove license = "MIT" from pyrpoject.toml until a tool appears in the community that is capable of automatically calculating a complete license expression and can be used during setuptools "vendoring" process. My opinion is that license = "MIT" gives the wrong impression about the licensing.
• Rely on license_files = <glob> in pryproject.toml to correctly include all the license files and clearly communicate the intent in the metadata (not sure if simply using the default implicit value that will produce the correct License-File: core metadata is enough)
• Add a second file (e.g. NOTICE) that indicates that setuptools also include bundled projects distributed under other licenses and indicate to the reader where to find these other license files.

If we agree on this proposal, I can go ahead and implement it.

[tiran]

PEP 639 was created so projects can express more complex license information with an SPDX license expression. This would be a great way for setuptools to show case the PEP and provide its users with an example for a SPDX license expression.

I don't think it was ignored, it is probably more of a matter of bandwidth.

You need to have a discussion how the setuptools maintainers are going to prioritize incoming issues. Any tickets about license and legal issues should be handled at the same priority as high/critical CVEs.

The LGPLv3 code is about to land in the next security releases of Python 3.9 to 3.11. The code has already been committed to the CPython git repo. Do you know the consequences of copyleft code in a Python release, which ought to be under a permissive license? I don't know, but I'm worried.

setuptools is a critical piece of infrastructure. Please be more careful and mindful in the future. When in doubt, get in contact with PSF legal team. The Python Software Foundation has resources.

[abravalheri]

Just as a follow-up on this:

• I am leaving the assessment regarding LGPL to Jason, as it concerns a dependency from one of his libraries.
• I contacted the PSF legal team on 16th July regarding licensing expression and compliance requirements. I also mentioned the LGPL concerns. I am currently awaiting their response.

PEP 639 was created so projects can express more complex license information with an SPDX license expression. This would be a great way for setuptools to show case the PEP and provide its users with an example for a SPDX license expression.

I fully agree that adopting SPDX expressions would be beneficial. However, until we have tooling that supports automatic derivation/verification during the vendoring stage, I don’t believe we’ll be able to support that effectively.

That’s why I reiterate the proposal in #5049 (comment), suggesting a PR that excludes the license expression and focuses on clearly specifying licenses via license-files, to avoid any misunderstandings (this follows the discussion in the PyPA discourse).

[Avasam]

I missed this more recent discussion, but as I mentionned in #5045 (comment) making autocommand optional in jaraco.text should be easy enough. Or even replacing it with a non-GPL alternative, like was done in jaraco/jaraco.develop#21 using fastapi's typer.

I can provide a PR this week, I have previously contributed in all the mentioned repositories.