python-poetry / poetry

Python packaging and dependency management made easy
https://python-poetry.org
MIT License
31.14k stars 2.25k forks source link

Add support to allow or deny specific licenses of dependencies #3480

Closed Juniper-vdg closed 5 months ago

Juniper-vdg commented 3 years ago

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:

[tool.poetry.licenses]
allowed = ["MIT", "Apache-2.0"]
forbidden = ["GPL-2.0-or-later", "GPL-3.0-or-later"]
ignore-dependencies = ["numpy"]

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 the poetry 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 šŸ˜„

wlievens commented 3 years ago

I like this idea, is there another tool which does this on top of poetry in the meantime?

samru-rai commented 3 years ago

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.

kronion commented 3 years ago

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.

dsch commented 2 years ago

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

CHE1RON commented 1 year ago

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) šŸ‘

robertlagrant commented 1 year ago

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.

takeda commented 1 year ago

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.

Juniper-vdg commented 1 year ago

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.

robertlagrant commented 1 year ago

@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"?

juancaoviedo commented 7 months ago

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!

lukasz-eond commented 5 months ago

@Erik-vdg , any plans to start developing it? Or any tools that can be used in the meantime?

lukasz-eond commented 5 months ago

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
Juniper-vdg commented 5 months ago

Awesome, thanks for the find @lukasz-eond! I'll mark this request as closed then.

jameslewellyn commented 4 months ago

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

github-actions[bot] commented 3 months ago

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.