License Metadata

For an array of license identifiers or names (short form SPDX identifiers, or long form license names),
returns an array of metadata for the corresponding license, if the license is recognized. If the query
parameter includetext=true is set, the returned metadata will also include the license text.

Example request body:

[
  "Apache-2.0",
  "BSD Zero Clause License"
]

Return value

// Response schema:
Array<{
  licenseId: string,
  name?: string,
  deprecated?: string,
  crossref?: string
  classes: Array<string>
  text?: string
}>

// Example response:
[
  {
    "licenseId": "Apache-2.0",
    "name": "Apache License 2.0",
    "deprecated": false,
    "crossref": "https://spdx.org/licenses/Apache-2.0.html",
    "classes": [
      "fsf libre",
      "osi approved",
      "permissive (silver)"
    ]
  },
  {
    "licenseId": "0BSD",
    "name": "BSD Zero Clause License",
    "deprecated": false,
    "crossref": "https://spdx.org/licenses/0BSD.html",
    "classes": [
      "osi approved",
      "permissive (bronze)"
    ]
  }
] 

License policy schema

{
  allow?: Array<string>
  warn?: Array<string>
  options?: Array<string>
}

Elements of the allow and warn arrays strings representing items which should be allowed, or which should trigger a warning; license data found in pacakge which not present in either array will produce a license violation (effectively a "hard" error). For example, to allow Apache-2.0 and MIT to the allow list, simply add the strings "Apache-2.0" and "MIT" to the allow array. Strings appearing in these arrays are generally "what you see is what you get", with two important exceptions: strings which are recognized as license classes and strings which are recognized as PURLs are handled differently to allow for more flexible license policy creation.

License Classes

Strings which are license classes will expand to a list of licenses known to be in that particular license class. Recognized license classes are:
'permissive',
'permissive (model)',
'permissive (gold)',
'permissive (silver)',
'permissive (bronze)',
'permissive (lead)',
'copyleft',
'maximal copyleft',
'network copyleft',
'strong copyleft',
'weak copyleft',
'contributor license agreement',
'public domain',
'proprietary free',
'source available',
'proprietary',
'commercial',
'patent'

Users can learn more about copyleft tiers and permissive tiers by reading the linked resources.

PURLs

Users may also modify their license policy's allow and warn lists by using package URLs (aka PURLs), which support glob patterns to allow a range of versions, files and directories, etc.

purl qualifiers which support globs are filename, version_glob, artifact_id and license_provenance (primarily used for allowing data from registry metadata).

Examples:

Allow all license data found in a specific version of a package 4.14.1: pkg:npm/[email protected]
Allow all license data found in a version range of a package: pkg:npm/lodash?version_glob=15.*
Allow all license data in the test directory of a given package for certain version ranges: pkg:npm/lodash@15.*.*?file_name=lodash/test/*
Allow all license data taken from the package registry for a package and version range: pkg:npm/lodash?version_glob=*&license_provenance=registry_metadata

Available options

toplevelOnly: only apply the license policy to "top level" license data in a package, which includes registry metadata, LICENSE files, and manifest files which are closest to the root of the package.

This endpoint consumes 1 unit of your quota.

This endpoint requires the following org token scopes: