Changes in the package.xml about licensing

tl;dr License declaration of ROS packages can be clearer and support automated linting and the creation of Debian copyright files.

In the last TSC meeting, a change to REP-149 was accepted. It allows for a precise declaration of multiple licenses per package.

The changes explained
It changes the license tag by adding two attributed: source-files and type. The source-files attributed uses a pattern based on a simplified shell glob syntax that defines which source files the license applies to. The type attribute specifies of what type the license identifier is. It can be either freeform (default) or spdx.

There are multiple motivations for this change: It allows the automatic creation of a Debian copyright file. This is a file that Debian packages must have, but ROS packages were missing or used an incomplete subset so far. This information being readily available also makes it easier for users of the packages to create Software bills of material (SBOMs). But the changes also make it easier to check the provided license declaration automatically.

I have created some tooling to enable the previously mentioned automatic checking of licenses and creation of copyright files. At the moment, the main functionality is the checking. Copyright file creation is currently only a POC. But the next step is to integrate it into bloom such that every ROS packages gets correctly created copyright files in the future.

For package maintainers
Please use the license linter to check your package. It already supports the new attributes. And consider defining the spdx type, which could become mandatory in the future. But, using a valid SPDX identifier will give already today additional features like checking if you provide the correct license text.


The changes to REP-149 do not seem to include a discussion of potential alternatives which were considered, so I’m curious to know why this specific implementation was chosen over any others.

Having done something similar myself recently, could you say something about what made you use this approach?

1 Like

Sorry Gijs, but I am not sure what you are looking for. There is quite some discussion in the PR: What implementation are you refering to?

And what are you currently working on in this field? Would be curious to learn more.

How does this change reflect in catkin and catkin_lint? Do these packages need an update to support the new attributes?

I’ll answer myself: the changes are incompatible with catkin:

catkin_pkg.package.InvalidPackage: Error(s) in package 'project/package.xml':
- The "license" tag must not have the following attributes: type

Shouldn’t such changes come with an increase of the package format version number?

1 Like

Hi Martin.
Thanks for your research. Yes, I think this needs an increase in the schema version. But I will look into this.
Cheers Christian

1 Like