[FR][BUG] Setuptools vendors LGPL-3.0 code, which extends the burden to setuptools' consumers

[teruokun]

What's the problem this feature will solve?

As one of the most-common non-standard-library packages, setuptools historically has been permissively licensed and bundled dependencies generally along the same guarantees, but the addition of autocommand in the vendored code updates from 2024 in 00384a5 means it now contains code under the LGPL-3.0. This means it requires a lot more scrutiny on where it is used, protections from potential modifications, and monitoring where and how it is deployed in order to properly comply with the restrictions on its vendored library.

Describe the solution you'd like

I'd like this to be considered an issue initially to consider the ramifications and if unreasonable, then it's okay to describe this as a "won't fix" type of issue. Otherwise, discussion on the following items would be useful

1. Is it reasonable to ask setuptools to try to limit itself to bundled dependencies under similarly permissive licenses as its own (i.e. BSD, MIT, Apache, Python, etc.)?
2. If so, what would be a good contribution towards replacing the need autocommand (or its dependency) fills?
3. Would it be reasonable to have a test which checks that the vendor packages include permissive licenses?

Alternative Solutions

No response

Additional context

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct

[Avasam]

In jaraco/jaraco.develop#21 , jaraco.develop got rid of the seemingly abandoned autocommand (ref Lucretiel/autocommand#38) in favor of https://github.com/fastapi/typer (MIT licensed). More details and discussion here: jaraco/jaraco.develop#20
Maybe the same could be done for jaraco.text ? It would also help jaraco/jaraco.text#23 as identified in https://github.com/jaraco/jaraco.text/pull/19/files#diff-6f2d4ba9ca9a357d31014946667b7bed1bfdbc6d2530afc77778fa0a36bee457

Whether autocommand, typer, or other. It's simply used to automatically make two functions into a pretty runnable script. Which I don't think setuptools uses, so it might be possible to make it optional with an extra ? (as to avoid pulling in more dependencies into setuptools). I feel like we previously discussed that with Jason in another repo. Iirc he wasn't too thrilled at the idea, but it's vague.

License aside, I feel like there's other good technical reasons to move away from autocommand anyway.

I am not a maintainer, I just recently contributed a lot towards fully typing setuptools (and fixing bugs along the way). But hopefully that fully answers your 2nd point and partially answers your first!

[teruokun]

That's good to hear as I unfortunately didn't have time to look into it deep enough to understand precisely how it was ending up in the dependency tree. The proposed solution to do the similar replacement in jaraco.text sounds like a very reasonable contribution and we might be able to spike that if it removes autocommand from the dependency set. I admit to also being a fan of typer in general, so it seems like a reasonable thing to do given the example. I'll see if I can find the time and then separately ask for the update of the bundled dependencies here for the short term