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

I have some doubts. Consider I took a ros2 package having BSD License 2.0. I took that package and made some edits. Can I rename the maintainer and author name in package.xml as my name.

I don’t think this is the right place for that question. You should consider asking on Robotics SE: Newest 'ros' Questions - Robotics Stack Exchange.

(Not a lawyer, but) That being said, I think the license and the <author> and <maintainer> tags are separate. If the license allows you to use and modify the original code, then you’re good. If the license requires you to keep the original attribution, then keeping the original copyright notice is probably enough. Keeping the original <author> is probably just a nice thing to do to give credit to the original author.

By the way, “BSD License 2.0” does not exist, so you should double-check. It’s probably BSD 2-Clause. I think some ROS 1/ROS 2 files mistakenly mention that license.

You must comply with what the license says regarding attribution. Most licenses used in ROS require attribution to be kept. That doesn’t strictly apply to the <maintainer> and <author> tags, but keep in mind that:

  1. If you’re not actually the maintainer of the package in its original repository, then you shouldn’t be changing the maintainer tag. If you’re doing a fork, then you could change the maintainer tag assuming that you’re maintaining your fork, but you would have to rename the package to get it accepted to the build farm for packaging.

  2. If you’re not the author and only made a couple of small edits, then naming yourself as the author is, at best, disingenuous. At worst it could be taken quite badly by the community. If you’ve made significant changes, then listing yourself as an additional author is the better way to go.

Both the <maintainer> and <author> tags support having multiple instances, so it’s possible to have multiple authors listed and multiple maintainers listed.