License Field Inconsistencies Across npm, PyPI, and crates.io

说明与用途

npm、PyPI 和 crates.io 的许可证字段不一致，导致自动确定依赖项许可证变得困难。作者研究了每个注册表如何存储许可证信息，发现 npm 提供了明确的 SPDX 标识符，PyPI 使用多个部分填充的字段，而 crates.io 的稀疏索引缺少许可证信息，需要单独调用 REST API。

问题

Determining a dependency’s license using only the registry’s API is unreliable because each registry exposes license information differently.

结果

The study revealed that npm consistently provides a single SPDX license field, PyPI offers three partially populated fields with the new license_expression being most reliable, and crates.io’s sparse index lacks license data entirely, requiring a separate REST call.

工作流

• 1. Query npm: GET https://registry.npmjs.org/{pkg}/latest and read the top‑level license field.
• 2. Query PyPI: GET https://pypi.org/pypi/{pkg}/json and examine info.license, info.license_expression, and info.classifiers for License :: entries.
• 3. Query crates.io: use the sparse index https://index.crates.io/{path} to get version data (no license field) and, if needed, the separate REST endpoint https://crates.io/api/v1/crates/{pkg} for license info.
• 4. Normalize the retrieved data into a consistent SPDX identifier or full license text.
• 5. Store the normalized license in a SBOM or compliance report.
• 6. If any field is missing, fall back to the next available field or flag the package for manual review.

证据

npm answered cleanly. The other two did not, and not in the way I expected.

来源

PyPI’s GET … doesn’t have one license field. It has three: info.license, info.license_expression, and info.classifiers.

来源

cargo doesn’t talk to crates.io’s website. It talks to a sparse index … No license key.

来源