ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

How to link license (clearing) information to ROS packages?

Hello all,

Within the ROScan project, which was funded by the European Union H2020 project ROSIN, we performed a license clearing for many ROS “core” packages.
The clearing gives you an overview of licenses within a package.

The results of the clearing are available as SPDX2 reports. As a first step, I would like to start a discussion about a good way to link the report information to the belonging packages.

So maybe the reports can be a part of the ROS packages itself, a part of the ROS wiki information or even the linking with other projects (e.g. https://clearlydefined.io) might be a solution.

For more information about the project click: https://www.rosin-project.eu/ftp/roscan

Results and SPDX reports are available at: https://github.com/boschresearch/ROScan

2 Likes

Could you perhaps give an example of how those reports (.rdfs) could be rendered?

Are they for human consumption or for machines?

The (.rdf) reports are machine readable. I created them with the export function of Fossolgy (the clearing tool I used). The reports can be imported by the tool, so other user are able to reuse them.

(The Good practice to export… tutorial in the repository might give an short overview how to use and create the .rdf files.)

The excel file in the ROScan repository contains the same information, but in a more human readable representation. Unfortunately this excel file has to be maintained manually and can not be imported to any tools.

So these .rdfs would have to be kept up-to-date manually as well? Or would it be possible to automate the process?

Regardless: perhaps storing the .rdfs in the repository could be an option.

Keeping them up-to-date however will not be easy I guess.

1 Like

Yes in the current state the .rdf has to be up-dated manually by two reasons. 1. As far as I know there is now automated system available to handle the whole clearing process and 2. in the current state of license documentation you always will need a manual review.

So storing the .rdf file, together with the commit-id it was created for, in the belonging repository sounds like an easy way. But it has to be done for every supported branch of a package and might be quite equal to the solution clearlydefined is providing.

Sorry for joining the discussion a bit late.

First, I’d like to thank you for those efforts and really looking into the core packages w.r.t. licenses :+1: :clap:

This is an issue for quite a number of companies that would like to use ROS but are “afraid” of the effort of using open source “the right way” might bring (granted, there are many that don’t care at all :cry: ).

As to your question: i think that for the current state of ROS 1, I’d go for adding the reports to the respective branches.
Rationale: ROS 1 will be EOL in 2025, the number of (actively supported) branches will decrease the more ROS 1 distros will reach EOL (effectively, in less then a year we will be down to two).
If the clearing (with Fossology) will be done at, say, every release, the manual effort will be minimal, I guess. I.e., if the repository is rescanned and all prior clearing information is kept. But it would still need to be done.

All in all, I think the ship has pretty much sailed for ROS 1 to get this done consistently. Though any efforts for making this easier (and maybe establishing a base line for ROS 2) are still very worthwhile!

I think this is totally different for ROS 2 though. Probably this would be a good spot now to start a discussion about how this could properly be done “early on” (I realize that “early” is rather “before widespread adoption” than actually “early in the project”).

One thing that could be worthwhile is to define a few best practices about how to specify licensing and copyright information more clearly in ROS packages to begin with.
I’d propose to start with making all core packages REUSE compliant. This is something that e.g. the linux kernel has done. Also, this largely simplifies any further scans and allows direct creation of spdx reports. Additionally, one can integrate checks for reuse compliance with CI/CD. And you could even add badges to the READMEs.
Then again, this is just a proposal and there are probably quite a few other ways to go.

At the end, one small comment about semantics:
I would try to avoid calling this “license clearing information” (even with “(clearing)” in brackets), as clearing is always linked to an existing policy. And this might differ from company to company quite a lot. License A might be totally fine for company X whereas it is a total no-go for company Y.
I’d go with “licensing information” or “licensing definitions” or something similar.

2 Likes

Hi every one,

I was on vacation, so sorry for the delated response.

As @mgruhler mentioned, there are some topics, which are related to our discourse:

  • Bring the license information into the packages for ROS1
  • Discuss and establish a (license information) baseline for ROS2
  • Define a good practice about how to specify licensing and copyright information in ROS packages

Within this thread, I would like to focus on the first issue.

The easy way would be to create an issue and a belonging pull request to add the license info file for each package.

This might be a good solution if we just want do some try outs for some packages, to see if and how the license information file will be accepted and handled by the community.

Maybe there is also a “process” if changes will affect many packages, which I am not aware of.

-> If you know any additional option please write it down here.

At least it would be helpful if the package maintainers are informed about such a change. And if the approach is agreed by the quality assurance group.

I think it is important to bring the license information at right place before the topic will lose its momentum. :slightly_smiling_face:

For the topics about the ROS2 and the how to specify licensing and copyright information we can set up another discourse in parallel.