Just as a side note: For similar reasons (long announced library functionality) I have been maintaining a fork of this repository for about 1.5 years already as well: https://github.com/stefan6419846/pip-licenses-lib This should include most of the relevant fixes as well, although it completely omits all rendering functionality.

We at Aidora have also created a fork: https://github.com/aidora-inc/pip-licenses

Would it perhaps make sense to create a separate fork under a joint organization to which multiple contributors can commit? It seems there is enough interest, but right now the efforts are quite fragmented. Also, many of the forks don't seem to be on pypi, reducing their usefulness.

In theory, this might be a possible solution, although the preferred solution should still be to keep the original repository alive - maybe by adding a collaborator. Otherwise, everyone has to replace their dependencies. (I am aware that myself having a fork on PyPI for quite some time now contradicts this a bit, but past development has shown that for some features integration into the CLI proved to be challenging.)

Sure, if @raimon49 was kind enough to provide maintainer rights to someone else, I agree that it would be a better option.

In the short term if @raimon49 is busy with other things, publishing a pip-licenses2 to PyPI that people can use would be great. If this project comes back, that's great, but at least in the meantime we can all rally around a package that can get updates.

That will also make it easy to merge those changes back into this repo if it comes back.

it looks like @raimon49 has made a total of 3 commits in the last 6 months. Something might have come up in their life, My office also just forked it locally but would be nice not having to do that. Happy to up vote a new consortium that would maintain it and push it to pypi.

Did anyone try to get in touch with the original author directly? The past has shown that this might have more impact due to GitHub notifications just flooding the inbox regularly.

@stefan6419846 I reached out to the author directly. I will report back if I get a response.

It has been two weeks without a response. I think it's time for a fork and publish to PyPI.

This is excellent news, sincere thanks to everyone involved! Our project has switched onto pip-licenses-cli and everything works, we were able to remove all the version guards that had been preventing us updating.

Hi, there. I'm sorry I haven't been able to respond for so long. I just commented on the PEP 541 request. pypi/support#6874 (comment)

This discussion also includes @johnthagen , a past contributor. Therefore, I feel a great sense of gratitude and trust.

I quit being a programmer for personal reasons. However, transferring this repository to @pip-licenses org is possible. I'd appreciate your comments on what actions would be better.

Great to hear back from you. In general, I am open to grant trusted third-parties access to the organization to continue maintenance. Nevertheless, given that I am currently maintaining a fork (although split into two packages), I am not sure how to continue with this in the least breaking way to satisfy the users needs. Maintaining competing packages, possibly even in the same organization and the usual low adaption efforts to keep it working (except for PEP 639 and similar changes, which lead to the real issues for most users), does not feel right.

In general, I am open to discussions on this topic and help maintaining the package as with my current forks. Having additional trusted collaborators would be nice to avoid similar situations in the future, although this requires more evaluation and documented processes to ensure collaborators/maintainers follow common guidelines. I wanted to have a look into this in the past, but given that it has not yet been urgent and there have been more relevant tasks, I did not yet start with it.

Maintaining competing packages, possibly even in the same organization and the usual low adaption efforts to keep it working (except for PEP 639 and similar changes, which lead to the real issues for most users), does not feel right.

@stefan6419846, Having now worked with you a bit over on your fork, I understand your reservations (there is a bit of project divergence now). However, I wouldn't go so far as to say "does not feel right" (your project is solid), but more importantly, I volunteer to take up maintaining this project as indicated by my PEP-541 request.

@raimon49, I have responded to your comment and I will work to also bring @johnthagen into the process if interested/willing (@johnthagen I would love to hear feedback from you on this! considering you transitioned to @stefan6419846's cli fork)

@sTiKyt, your use-case is aligned with my own, could you please elaborate in a few sentences what level of involvement you are interested in?

As always 🙇 thanks for reading this far, and I hope this helps.

Maintaining competing packages, possibly even in the same organization and the usual low adaption efforts to keep it working (except for PEP 639 and similar changes, which lead to the real issues for most users), does not feel right.

@stefan6419846, Having now worked with you a bit over on your fork, I understand your reservations (there is a bit of project divergence now). However, I wouldn't go so far as to say "does not feel right" (your project is solid), but more importantly, I volunteer to take up maintaining this project as indicated by my PEP-541 request.

@raimon49, I have responded to your comment and I will work to also bring @johnthagen into the process if interested/willing (@johnthagen I would love to hear feedback from you on this! considering you transitioned to @stefan6419846's cli fork)

@sTiKyt, your use-case is aligned with my own, could you please elaborate in a few sentences what level of involvement you are interested in?

As always 🙇 thanks for reading this far, and I hope this helps.

To be fair, I'm not even sure what are the options here to pick the level of involvement 😅 just feel like helping out somehow would be a right thing to do

Having now worked with you a bit over on your fork, I understand your reservations (there is a bit of project divergence now). However, I wouldn't go so far as to say "does not feel right" (your project is solid), but more importantly, I volunteer to take up maintaining this project as indicated by my PEP-541 request.

The CLI is basically the same as pip-licenses, just using another name and a separate core implementation. The divergence mostly comes from refactoring and new features/fixes.

When thinking about the general development, having two forks basically implementing the same still feels wrong, thus joined efforts might make sense. I am aware that - at least for some parts - our views might be different (which is completely fine).

Status update for community

With @raimon49's assistance, I have been onboarded as a maintainer of the project. For the sake of transparency, I want to update all the stakeholders (that's you involved in this discussion) and the community (for posterity). As mentioned before I plan to start with purely custodial upkeep. After I have had a chance to attend to the open PRs and related GHIs, I'll triage the rest of the open GHI, and then circle back to this discussion.

At present, however my vision of how the project moves forward:

• @raimon49 will remain the owner (and of-course the creator and copyright holder)
• I will take lead on maintaining this project. Feel free to ping me for triage and code-review.
• I plan to configure/update some of the project automation around CI/CD
• finally, I plan to then sit back and mostly just actively review submitted PRs and GHI issues (I'll let interested others in the community build new stuff, I'll just focus on maintaining in theory)

Request for comments

@raimon49 feel free to weigh in on this at anytime in the future, and again thank you for all of your time and efforts creating this project.

@stefan6419846 I will continue to value your input on this project especially to provide a bit of diversity in thought. If you ever want to pivot to joining your fork and this project, please feel free to reach out (but no pressure).

@johnthagen, Likewise, I will continue to value your input on this project especially as a previous contributor.

@sTiKyt, please feel free to look through the open GHI, I'm happy to work with you and anyone else who wishes to contribute to the project.

Does anyone else have further concerns, questions or feedback about the project next-steps at this time?

Status update for community (Follow-up)

With @raimon49's assistance, I have been onboarded as a maintainer of the project. For the sake of transparency, I want to update all the stakeholders (that's you involved in this discussion) and the community (for posterity). As mentioned before I plan to start with purely custodial upkeep. After I have had a chance to attend to the open PRs and related GHIs, I'll triage the rest of the open GHI, and then circle back to this discussion.

🎉 v-5.5.0 Released

Starting with the most significant news: Version 5.5.0 has been released (see the patch notes for more details).

Highlights:

• Multiple bug fixes and stability updates
• Improved support for PEP-639
• Released as a trusted publisher from GitHub with build provenance for supply-chain validation.

A heartfelt thank you to @cdce8p for their valuable contributions!

Maintenance Resilience Improvements and Plans

I have established and updated much of the project's automation into a minimal CI/CD pipeline. This foundational step is essential for ensuring the project remains well-maintained amidst the fast-paced landscape of modern technology trends.

I have addressed a significant portion of the backlog and identified the following candidate areas to focus on for the next few releases in the short-to-mid-term scope:

🔢 In no particular order:

• Improvements in handling non-trivial edge cases (e.g., enhanced handling for unexpected formats as raised in issues Better handling of licenses of pep-0621 based libraries #134, Lowercase files not found #208, and Partial matching goes wrong when partial match #231)
• Code quality enhancements (specifically, transitioning from a single-file monolith to a modular Python package as a prerequisite for items like Calling from within Python #81 and adopting a SOLID design)
• Compliance with Python Standards (e.g., full pyproject.toml compliance, PEP-0621 error compliance, PEP-440 version pinning support, etc.)
• Enhancements to CI/CD features, such as CI-friendly output modes in reference to issue Output dependency graph to identify source of bad license that triggered fails-on. #197 and supply-chain license provenance use-case support
• Development of interfaces for external license databases (e.g., issues Feature Request <> License information from PyPi #30, Feature: Check OSS license compatibility #101, and Better handling of licenses of pep-0621 based libraries #134)
• Improvements to CI tests—adding environment caching, build artifacts, and at-scale testing (100+ packages)
• The ability to specify options in pyproject.toml and legacy setup.cfg files

These are broad ideas based on common themes identified in the backlog and my recent review of the codebase. What are your thoughts? Do any of these areas particularly interest you regarding how you use pip-licenses?

• Finally, in the long term, I still plan to continue focusing primarily on reviewing submitted PRs and GHIs, while allowing other interested community members to contribute new features. My focus will remain on maintaining the project effectively.

🙇 Thank you for taking the time to read this update and for your patience during this transition.

@reactive-firewall Thanks for all the work. The only limitation that I've still run into with pip-licenses is

• Packages with multiple LICENSES files not shown in --with-license-file #71