Trying to make sense of package-manager metadata

Package managers for operating systems and programming languages have been around for decades. Each package manager, and its accompanying packaging format, has been shaped by the needs of its respective ecosystem, but there is a growing need to make use of package metadata for more than software management: for example, in vulnerability scans, software bills of materials (SBOMs), and more. On May 19, Damián Vicino spoke at the Open Source Summit North America 2026 about his experiences in the past year trying to make sense of the varied metadata provided by more than 20 package managers.

Metadata mess

Vicino said that he has been using package managers for more than 20 years, and that he has been happy with them for most of that time. Two years ago, though, he started working in the open-source program office at Datadog; he needed to gather package metadata—such as the name, version, license, and dependencies of the software—as part of his duties there. For instance, he wanted to be able to grab the name and version of a package to see if there were any CVEs that applied to it; he also wanted to check licenses to ensure compliance.

This is information needed for all kinds of analysis, Vicino said: dependency updates, supply-chain security, vulnerability management, SBOM generation, and more. "If everyone needs to map that data together because you need to read it, why do we have one of the implementations in each of these tools independently?" He explained that there is no shared reference framework, and that it was much harder than he expected to try to get all of the data he needed from each package manager—much less all of them.

He thought that there might be "magical tools" to grab all of the data that he needed to do the analysis he wanted to do, but he could not find any. "So I started writing my own. I saw that was a really, really difficult thing." He showed example metadata (reproduced below from his slides) for Python and Node.js packages, as well as a FreeBSD port Makefile, to illustrate how similar information was expressed differently across package ecosystems.

Real projects today, he said, tend to be a combination of software from multiple sources; a Python project has C dependencies, or a Debian package contains a Python library. If, for instance, a developer is trying to create an SBOM for a project that combines artifacts from various package managers, then "you want the same representation for everything", but that does not exist.

Package manager chaos

Vicino said that there are, of course, reasons why each package manager does things differently: each one had evolved separately because it has its own purpose. Some are designed for operating systems, others are for programming languages; some package managers were created decades ago, others were created just a few years ago. A package manager may be designed around the assumption of a centralized registry, or expect distributed repositories of packages. There is a difference in how they are developed and extended; he pointed out that Python has the PEP specification process, while in other cases "some developer started something, and people started picking it up" without rigorous planning.

Package-manager developers set the rules for how everything works, "but they set different rules than every other package management developer in other ecosystems". Users of those package managers can't easily find the data they want because it isn't available. Maintainers of packages may want to publish specific information, but not know how to do so (if it is possible at all).

Developers want to provide information about all of the varied components in a project, but there is no good way to get all of that information in a unified format. "So who is paying the cost of this? Everyone is paying the cost, it's so confusing." Multi-platform, mixed ecosystem projects are broken, he said.

Not a project that doesn't build: they build, but you don't have the ability to respond to incidents because you don't know that you have an incident. You cannot go into that data and see that there is a CVE seven dependencies down the tree.

Package managers have existed since 1992, Vicino said, so why would the problem be solved now? (The exact date the first package manager was created or published is up for debate. Nevertheless, 1992 was the date he cited.) He believed that external pressure in the form of legal requirements would be the catalyst to push for solutions to the metadata mess. He pointed out that the Cyber Resilience Act (CRA) in the European Union has mandates for SBOMs, "and if you are going to make an SBOM, you need the data. It's going to be a legal requirement. That's real pressure."

CHAOSS working group

That said, after 30-plus years of package-manager development, he did not believe that package managers were going to change to be SBOM-compliant. When Vicino had been trying to find solutions for managing information from disparate package managers, he had asked around to see if anyone else had found the answers he was seeking. He didn't find the answers, but he did find other people asking similar questions. That, in part, led to the creation of the package metadata working group as part of the Community Health Analytics in Open Source Software (CHAOSS) project.

The working group's first meeting was in September 2025, Vicino said. The group wants to help different communities talk to one another and try to document practices across package managers and bridge the gaps between them. He emphasized that the working group is not trying to write new standards; there are already good standards for representing package metadata, such as the System Package Data Exchange (SPDX), CycloneDX, and OpenChain. "We just want to understand for each package manager what's the gap to be able to use that standard."

We thought it'd be easy

The plan is to work on one attribute at a time, he said. The group has a queue of 11 attributes it wants to analyze, beginning with license metadata. The group started with analyzing license metadata because "it was going to be easy and allow us to check how our process works". It turned out, he said, that "our assumptions were completely wrong". The group examined package managers for a number of language ecosystems, operating systems, and also looked at Dockerfiles. That involved looking at documentation, standards, and implementations to see how package managers expose license information.

The license-analysis research focused on the field name, whether the package managers validate license information, the structure for expressing the license, and how many attributes are supported. The group found little agreement on the field name for licenses: "there is 'license', 'licenses', 'licensing info', 'license file', 'license URL'. That's something we can work with, it's just mapping."

Package managers were grouped by how license information was declared in the package metadata. Eight ecosystems use unambiguous declarations, such as SPDX identifiers and expressions (AND, OR, WITH); Cargo, Homebrew, npm, and RPM all fall into that category. Unambiguous means "if you're a maintainer and you want to write the SPDX expression or equivalent, you can. That's the only requirement." It does not mean that the use of such identifiers is required or enforced.

Twelve of the ecosystems have a field for license declaration but use non-standard ways of expressing the license (e.g., free-form text); Debian packages, FreeBSD ports, Maven Central, and Ruby Gems are all in the ambiguous category. Three of the ecosystems do not include a field for license at all; Dockerfiles, for example, do not have a required license field. In addition, some of the package managers validate whether the license information exists, while others do not.

The group used data from the ecosyste.ms project that tracks open-source data to study the license declarations "in the wild" to see how many had valid SPDX data. There were 36,224 packages in the top 1% by popularity, he said, and 60% of those had valid SPDX data. In the top 10%, more than 2.3 million packages, only 47% had valid data. The CSV files used for the project's analysis are on GitHub, as are the scripts for processing and analyzing the data.

Vicino showed examples of good and bad license expressions. Maven Central provided a good example of what not to do with several different ways of expressing the Apache 2.0 license including (but not limited to) "Apache-2.0", "Apache License, Version 2.0", and "APACHE-2". He showed a slide with an example of what "good" would look like, a mandatory SPDX expression with optional escape hatch. SPDX has standard strings for many licenses, such as "Apache-2.0", but the "escape hatch" is needed for those licenses that the standard does not cover. For those, it offers the LicenseRef value, which can take a link to the custom license.

Recommendations

Vicino said it was easy to decide what the group would recommend to package-manager ecosystems: full SPDX expressions, including its operators, that are validated somehow. Currently most attributes, such as dependencies, are validated but "except for very few, nobody validates the license". It is not trivial to do, he said, but there are packages to do license validation for most languages: "so it should be something that can be introduced into package managers".

Where the validation step happens is another question. Some ecosystems have centralized registries; they could make validating the license a part of the publishing process. For distributed ecosystems, he said, it's harder. Validation should be enforced by the publishing tools for packages with a check by the "consumer" tools, but the group does not recommend enforcing a valid license expression by consumer tools "because they don't have a way to fix it" if the expression is invalid.

Of course, a package ecosystem cannot re-declare all of its license metadata overnight. He recommended a five-stage process to transition to valid SPDX identifiers, beginning with parallel support of valid and non-valid identifiers, then requiring new packages to have valid SPDX, updating existing packages, and ultimately deprecating the old format. Unfortunately, he did not mention the work Fedora has been doing to transition from its old short-license-name format to SPDX identifiers, which has followed a similar process. The project kicked off a multi-stage process in 2022, and has made significant progress in becoming SPDX-compliant.

Vicino said that every tool that depends on package metadata could benefit from the work that the group is doing. For example, it would make it easier to examine different ecosystems for known vulnerabilities. The idea is to reduce duplicated work and make better tools: users need not have "insider knowledge" about each package ecosystem to find information.

He said that the group is still looking for people to connect with for some of the package ecosystems, and encouraged interested people to get in touch. Licensing is only one of the attributes the group wants to tackle, though; he said there is also work ongoing related to metadata for source-code URLs, lock files, binary dependencies, funding links, and more. He pointed to information on the last slide of his presentation for links to the group's Slack channel and meeting schedule.

Questions

There was a little time left over for questions. I asked whether the group had looked at the Flatpak or Snap package formats; he said that they had not. I also asked if they had considered grouping the package managers by function: for example, looking at language package managers and operating system package managers separately to see how they were alike or different.

Vicino said that they had considered that at the start of the project, but the things that were most telling was whether an ecosystem used a centralized registry or not, and the age of the ecosystem. Perl's package manager and Debian's are not that different, he said, because they depend on a centralized registry. Older ecosystems have a more copyright- and attribution-centric approach, while newer ecosystems focus more on dependencies or enforcing version numbers. "But we don't see a big difference between how [an] OS-centric package manager works compared to how a language-specific one does."

At that point, the audience had run out of questions just as the session had run out of time.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Minneapolis to attend the Open Source Summit.]