Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
2 tasks done
Juniper-vdg opened this issue Dec 11, 2020 · 15 comments
Closed
2 tasks done

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

Juniper-vdg opened this issue Dec 11, 2020 · 15 comments
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged

Comments

@Juniper-vdg
Copy link
Contributor

Juniper-vdg commented Dec 11, 2020

  • I have searched the issues of this repo and believe that this is not a duplicate.
  • 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 Juniper-vdg added kind/feature Feature requests/implementations status/triage This issue needs to be triaged labels Dec 11, 2020
@wlievens
Copy link

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

@samru-rai
Copy link

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
Copy link

kronion commented May 13, 2021

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
Copy link

dsch commented Nov 28, 2021

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
Copy link

CHE1RON commented Sep 7, 2023

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
Copy link

robertlagrant commented Sep 8, 2023

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
Copy link

takeda commented Sep 8, 2023

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
Copy link
Contributor Author

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
Copy link

robertlagrant commented Sep 11, 2023

@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
Copy link

juancaoviedo commented Feb 1, 2024

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
Copy link

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

@lukasz-eond
Copy link

lukasz-eond commented Apr 3, 2024

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
Copy link
Contributor Author

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

@Juniper-vdg Juniper-vdg closed this as not planned Won't fix, can't repro, duplicate, stale Apr 3, 2024
@jameslewellyn
Copy link

jameslewellyn commented Apr 30, 2024

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: dhatim/python-license-check#118

Copy link

github-actions bot commented Jun 1, 2024

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 github-actions bot locked as resolved and limited conversation to collaborators Jun 1, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged
Projects
None yet
Development

No branches or pull requests