Feature request: add SPDX parsing support to license ID algorithm

[ngie-eign]

I appreciate and have leveraged the license ID support in the identify package in the past to help identify licenses in files.

Many projects have started shifting from full licensing tort to SPDX identifiers for brevity, and unfortunately the tool/package doesn't identify these cases properly today.

An example failing case:

➜  /tmp python3
Python 3.12.13 (main, Jun 14 2026, 01:09:32) [Clang 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd7080 on freebsd15
Type "help", "copyright", "credits" or "license" for more information.
>>> from identify import identify
>>> identify.license_id("acpi.c")
>>>

Having a way to parse out the SPDX IDs would improve the usability of the library.

[asottile]

the intention of the license identification is to take LICENSE files and guess what license they are

I would assume there's already far better tools for parsing spdx comments (and personally I'm not too interested in maintaining one myself especially because I find the comments to be purely clutter)

[ngie-eign]

the intention of the license identification is to take LICENSE files and guess what license they are

That wasn't called out in the doc strings -- this is why I was so confused integrating the API (in the past).

I would assume there's already far better tools for parsing spdx comments (and personally I'm not too interested in maintaining one myself especially because I find the comments to be purely clutter)

Yeah, that's fair. This project seems like a better alternative for implementing this support: https://pypi.org/project/license-expression/ . It's what the official python bindings use for the larger SPDX project.

Would integrating that library (instead of reinventing the wheel like I did in #602) be ok?

[asottile]

I'm not entirely sure what your overall goal is

[ngie-eign]

I'm not entirely sure what your overall goal is

To have a simple CLI tool for getting licensing information for a source file. If identify-cli is the wrong tool -- I understand. My only ask is that it would be nice if the requirements/expectations are explicitly called out with the APIs.

[asottile]

yeah I would probably just contribute that to that other library, or write a small wrapper around it!