[Project configuration] Licenses to avoid about poetry HOT 4 CLOSED

@caniko I like the idea, but:

1. Do you know of any valid and up-to-date source of truth for those incompatibilities?
2. What about projects that don't provide license info?
3. Do you know of any other packaging-related tool that does this?
4. How would that impact performance? My feeling is that it could add quite an overhead to many operations
5. Until we get standardized license declarations (see PEP 639) it can be difficult to properly parse license information from packages

from poetry.

Do you know of any valid and up-to-date source of truth for those incompatibilities?

Incompatibilities between licenses is common knowledge. You are probably trying ask the source of truth poetry would use, it would have to be a new project where this is crystalized by the authors and maintainers.

How would that impact performance? My feeling is that it could add quite an overhead to many operations

From my POV, performance impact would be minimal; however, I might be missing something.

Until we get standardized license declarations (see PEP 639) it can be difficult to properly parse license information from packages

Good point. Willing to wait.

from poetry.

Using license information to cause locking to fail sounds awful to me!

I'd suggest this is better left to a dedicated tool that checks the results eg - not a recommendation, just the first thing I found - https://pypi.org/project/licensecheck/#description

from poetry.

Given all the information, I would say that it's a plugin candidate or as Dimbleby suggested, a totally separate project. While the idea is nice, the maintenance overhead feels too big for me.

Incompatibilities between licenses is common knowledge.

Well, in poetry-core we have a license list that's over 600 entries long. I doubt anyone but a trained lawyer was able to point out exactly which ones are incompatible with each other.

from poetry.