Closed Juniper-vdg closed 5 months ago
I like this idea, is there another tool which does this on top of poetry in the meantime?
I would also like this feature a lot!
GitHub has it's own implementation to check for licenses. One can extract the packages by running pip freeze. See here for further information.
Protection against undesired licenses is a good idea, but I would still love to see poetry
provide license auditing capabilities for anything that it does ultimately install. Other tools like pip-licenses do a decent job, but they can't distinguish between production and development dependencies like poetry
could.
Something like poetry licenses --production
would be very helpful.
What would be the preferred way to implement this feature? As a plugin or as part of the core?
Possible CLI extensions:
poetry show --licenses
: Show the licenses in the list of packages
poetry show --no-dev --licenses
: Show the licenses in the list of production packages
poetry check
: verify licenses against configured allowed/forbidden licenses
poetry add requests
: Check the license during adding of a new dependency
bumping this as it would greatly benefit our use cases. listing licenses is a hard requirement for many customer projects these days, and it would be most helpful to have poetry
do this, since it already knows everything (like what's dev, optional, production, etc) š
Coincidentally enough I also am hitting this: license listing is essential for OSS projects and it would be fantastic if the poetry show [--no-dev] --licences
open could be pursued.
It's important with OSS as well as with businesses. I was thinking that maybe if you use AGPL you could be safe, but then there are also open source licenses (maybe not as popular) that are incompatible.
I guess one might care less about licenses for some hobbyist project.
Coming back to my request after almost three years. :)
I would still personally like this functionality included to Poetry, and I see that there's some desire for this from the community. However, in Poetry's current era, I believe license reporting and auditing functionality might be a concern for a minority of poetry developers, so this functionality is probably best implemented as a Poetry plugin.
According to the Poetry documentation, plugins should not modify core poetry commands in any way. Therefore I believe that such a plugin could work by placing its functionality within the license
namespace.
Some possible commands for such a plugin are below, keeping with the option pattern that exists in current poetry commands:
poetry license show [--with groups] [--without groups] [--only groups]
: Display in a hiearchical manner the licenses used by dependencies in the project
poetry license check [--with groups] [--without groups] [--only groups]
: Checks that the specified dependency groups follow the license rules as specified in pyproject.toml. Returns a detailed report if there are any failures.
@Erik-vdg I think that's a great summary. What does "in a hierarchical manner" mean in this instance? And what's the difference between "with" and "only"?
Absolutely, I completely agree with this idea. As the adoption of open-source development continues to grow, ensuring compliance with licensing requirements becomes increasingly important. While this feature may cater to few devs initially, I believe its relevance will only expand over time as more organizations embrace open-source software. Looking forward to seeing how this evolves!
@Erik-vdg , any plans to start developing it? Or any tools that can be used in the meantime?
Actually, it turns out that python-license-check can be used with pyproject.toml
now, so this Feature Request seems to me no longer needed:
liccheck -s pyproject.toml
Output:
% liccheck -s pyproject.toml
gathering licenses...
47 packages and dependencies.
check authorized packages...
45 packages.
check unknown packages...
2 packages.
library1 (2020.4.5.1): ['Mozilla Public License 2.0 (MPL 2.0)']
dependencies:
library1 << requests << coreapi << drf-yasg
library1 << sentry-sdk
library2 (10.3.0): ['Historical Permission Notice and Disclaimer (HPND)']
dependency:
library2
Awesome, thanks for the find @lukasz-eond! I'll mark this request as closed then.
Actually, it turns out that python-license-check can be used with
pyproject.toml
now, so this Feature Request seems to me no longer needed:liccheck -s pyproject.toml
Output:
% liccheck -s pyproject.toml gathering licenses... 47 packages and dependencies. check authorized packages... 45 packages. check unknown packages... 2 packages. library1 (2020.4.5.1): ['Mozilla Public License 2.0 (MPL 2.0)'] dependencies: library1 << requests << coreapi << drf-yasg library1 << sentry-sdk library2 (10.3.0): ['Historical Permission Notice and Disclaimer (HPND)'] dependency: library2
Unfortunately, liccheck appears to be broken on Poetry dependency groups: https://python-poetry.org/docs/managing-dependencies/
It appears liccheck only looks for the old notation for extra dependencies: https://github.com/dhatim/python-license-check/blob/8b0cb0a4d4ab62180f82ed2f007930480fa6cf99/liccheck/command_line.py#L478
Would it be possible to re-open this issue in light of this lack of support? I feel like adding a --licenses option into "poetry show" is the cleanest solution to keeping the tooling aligned. Thanks!
EDIT: I have added an issue to liccheck to mirror this request for Poetry: https://github.com/dhatim/python-license-check/issues/118
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Feature Request
At my work, there exist strict requirements on what Licenses our projects can use (a common example is software with a GPL license). I would really like it if Poetry could help me follow these requirements.
I know that there are existing tools that can assist with this, such as python-license-check, and we can set that up in our CI environment to enforce our requirements. However as a more developer-friendly approach, I would like it if Poetry checked License requirements for me when adding a new package, so that I get very early feedback if a package would not be allowed.
I would like to define my license rules in pyproject.toml. Here is an example of potential configuration options to communicate the intent:
With this configuration, I would like it if when I ran the command
poetry add package-with-gpl-license
to not install the dependency and return a helpful error message.Similarly, I would like it if my pyproject.toml did have
package-with-gpl-license
listed as a dependency, that thepoetry check
command would return an error with a helpful message.I recognize that this may be a niche use case for many Poetry users, so if this is more appropriate as a plugin in the future as mentioned in #1237 please let me know! Thanks in advance š