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.

Источник