Documentation
Book a demo

Supply chain security

License detection

License detection identifies the license declared by each supported package at upload time and attaches it to the package metadata. It gives you a consistent, normalized view of license exposure across your workspace so you can understand what your developers are pulling in before deciding whether to allow, restrict, or review it.

Note

License detection identifies licenses. To quarantine packages based on their license, see License policy.

How it works

Cloudsmith derives license information from two sources, in order of preference:

  • Package metadata: Each package format exposes license information in a different place. Cloudsmith extracts the raw license string from whichever fields the format uses:

    • For Maven, it reads the POM file
    • For npm, it reads package.json
    • For Python, it reads wheel or sdist metadata

  • License files bundled inside the package: If the format's metadata fields are missing or empty, Cloudsmith falls back to inspecting license files within the package archive. For example, LICENSE or LICENSE.txt.

The raw license string is then matched against the Software Package Data Exchange (SPDX) license list and normalized to its corresponding SPDX identifier. Once normalized, the identifier is stored against the package and made available through the Cloudsmith web app and API.

Best-effort detection

License detection is intentionally lenient. If a license can't be found or cleanly mapped, the package still syncs and becomes available.

In practice, that means:

  • False positives are unlikely: If Cloudsmith reports a package as MIT, it almost certainly is MIT.
  • False negatives can occur: A missing license does not mean the package has no license, it means Cloudsmith could not extract or match one confidently.

Match confidence and manual review

When Cloudsmith matches a raw license string to the SPDX list, it calculates a confidence percentage. Packages fall into one of three states:

  • High-confidence match: The SPDX identifier is automatically applied and displayed on the package.
  • Low-confidence match or long raw string: If the match is below 75%, or the raw license string is longer than 60 characters, Cloudsmith leaves the license empty for you to review and set manually.
  • No license found: Cloudsmith could not locate a license in package metadata or bundled files. You can add one manually by Overriding a license.

Known limitations

When reviewing license data, there are a few limitations that are worth being aware of:

  • Non-SPDX and free-text licenses (for example, BSD License or 3-Clause BSD License) often can't be mapped to an SPDX identifier and will be left unset.
  • Multi-license packages that declare compound expressions (for example, Apache-2.0 AND MIT) may detect only one of the licenses.
  • npm packages sometimes omit license information from their registry-facing metadata, leading to missed detection even when a license file is present in the package.
  • Transitive dependencies are not inspected. Cloudsmith reports the license for each package it directly stores. A package may depend on other packages whose licenses Cloudsmith cannot see and therefore cannot report.

Note

Cloudsmith reports declared licenses, not discovered ones. Detection is based on what the package publisher has stated in metadata or bundled license files.

Important

Cloudsmith is not responsible for packages or dependencies that carry undesirable licenses or affect IP rights.

Supported formats

License detection runs automatically for the following formats:

  • Alpine
  • Cargo
  • Cocoapods
  • Composer
  • Conan
  • Conda
  • CRAN
  • Dart
  • Docker
  • Go
  • Helm
  • Hex
  • LuaRocks
  • Maven
  • npm
  • NuGet
  • Python
  • RPM
  • Ruby
  • Swift
  • Unity

Note

For Unity packages, the license needs to be present in the package.json file to be detected.

For Docker and OCI images, license data comes from the SBOM that Cloudsmith generates automatically during image synchronization. License information is reported for the image's components, not the image itself. Only SBOMs generated by Cloudsmith during synchronization are used; externally supplied SBOMs are not parsed for license data.

Reviewing detected licenses

You can review detected licenses in four places:

Package overview tab

On the Overview tab for every package, you can find a License field containing the detected SPDX identifier. If no license was detected, the field is empty. For Docker and OCI images, click on the SBOM tab for license information.

Workspace and repository search

You can use package search syntax to filter and search for packages by license. This is useful for quickly finding, for example, every GPL-licensed package in a repository.

License compliance dashboard

The Compliance dashboard provides an overview of license coverage and distribution across a workspace or repository.

To open the dashboard, click the Compliance tab of the Cloudsmith web app. Click the Packages with license issues card to see license compliance information for the workspace.

The dashboard summarizes:

  • Number of packages per detected license type
  • Licensed versus unlicensed package counts

You can use the dashboard to spot coverage gaps and to understand your license mix before creating a license policy. For example, large numbers of unlicensed packages in a specific format can indicate malformed upstream metadata.

Packages API

The license is returned on the package object through the Packages API.

For most formats, the license appears in the top-level license field on the package object. For Docker and OCI images, component licenses appear in the SBOM section of the package object.

Overriding a license

You can manually override the detected license on any package. Overrides are useful when:

  • Cloudsmith's confidence was too low to automatically apply a license.
  • The declared license is incorrect or ambiguous, and you have confirmed the correct one.
  • Your organization has purchased a commercial license for a package and wants to record that internally.
  • A package should be excluded from license-based policy decisions.

How license overrides work

Overrides change the license metadata that Cloudsmith holds for the package. They do not modify the package itself or rewrite the license string within the package archive. Overrides are the source of truth that a license policy evaluates against.

Edit a license

  1. From your Cloudsmith dashboard, go to the Compliance tab and click the Packages with license issues card.

  2. Click the edit license data icon on the relevant package row:

  3. In the Edit license data form, choose an SPDX identifier from the dropdown.

  4. (Optional) Add a license URL, any notes explaining why the override was applied, and apply a license override state (both the Ignored and Purchased states mean the package won’t be counted in any license compliance violations).

    • Ignored: The package is excluded from license-based policy decisions. Use this for packages where license evaluation does not apply, for example, internal first-party packages.
    • Purchased: The package is flagged as covered by a commercial license agreement your organization holds. Use this when you have a paid license for a package that would otherwise be restricted by policy.

  5. Click Save changes.