Universal method to scope PURL to organization

[nicorikken]

Issue triggered from FOSDEM 2026 Fringe: FOSS license and security compliance tools workshop
Fri, Jan. 30, 2026. In a working group about 'internal use of PURL' this came up.

Request

Provide a universal (across formats) way in PURL spec to make PURL specific to an organization.

Suggestion

Include a organization specific namespace, like:

• com.company
• com.company.department.repo

Note the naming conflict package repository namespace.

Use-cases

• Organization wanting to link internal packages. These could be proxied, vendored-in, or custom with a conflicting name.
• Large software projects like Linux Kernel might want to govern a specific set of PURL groups.

Prior work

• mvn package format supports repo_url query parameter. This is format-specific.
• CycloneDX allows namespacing property fields.

Side-issues

• Stating equivalent packages, so vulnerabilities can still be matched regardless of the location of distribution (if indeed equivalent).
• Keeping track of namespaces to prevent conflicts.
• Governance of authoritative list, to avoid false claims. Maybe structure multiple departments of a larger organization.
• Public record of registered namespaces to check.
• SBOM validation including validation of this organization namespaces.
• API to query validity of a PURL based on packages in registries by the organization.
• Format to define equivalent packages.

Related issues

Most of this is already covered by Issues

• Define PURL types for software that is not covered by a package manager #784
• New PURL type for non-packaged software #516
• and the new project/repo: https://github.com/package-url/purl-registry
  The scid PURL type proposal (Define PURL types for software that is not covered by a package manager #784) is probably the most pertinent.