poetry icon indicating copy to clipboard operation
poetry copied to clipboard

Add support to allow or deny specific licenses of dependencies

Open Juniper-vdg opened this issue 5 years ago • 10 comments

  • [x] I have searched the issues of this repo and believe that this is not a duplicate.
  • [x] I have searched the documentation and believe that my question is not covered.

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 😄

Juniper-vdg avatar Dec 11 '20 21:12 Juniper-vdg

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

wlievens avatar Mar 12 '21 08:03 wlievens

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.

samru-rai avatar Mar 25 '21 15:03 samru-rai

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.

kronion avatar May 13 '21 18:05 kronion

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

dsch avatar Nov 28 '21 15:11 dsch

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) 👍

CHE1RON avatar Sep 07 '23 17:09 CHE1RON

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.

robertlagrant avatar Sep 08 '23 09:09 robertlagrant

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.

takeda avatar Sep 08 '23 16:09 takeda

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.

Juniper-vdg avatar Sep 08 '23 17:09 Juniper-vdg

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

robertlagrant avatar Sep 11 '23 15:09 robertlagrant

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!

juancaoviedo avatar Feb 01 '24 16:02 juancaoviedo

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

lukasz-eond avatar Apr 03 '24 10:04 lukasz-eond

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

lukasz-eond avatar Apr 03 '24 10:04 lukasz-eond

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

Juniper-vdg avatar Apr 03 '24 14:04 Juniper-vdg

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

jameslewellyn avatar Apr 30 '24 16:04 jameslewellyn

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.

github-actions[bot] avatar Jun 01 '24 00:06 github-actions[bot]