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

5 Likes

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

Are they for human consumption or for machines?

1 Like

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.

1 Like

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.

3 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.

1 Like

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

  • Bring the license information into the packages for ROS1

Totally fine for me. Then, I think you are pretty much set already:

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

This is the go-to option. Everything else seems overkill or too complicated. I’d also suggest to only target melodic and noetic dev branches and ignore the rest.

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.

This is vital in getting any traction. Involve OSRF and the quality assurance group. They need to be on board. The rest of the maintainers might much more easily follow once this is set up for the ROS core packages…
If you can get this to land in ros/ros and ros/ros_comm, I’d already consider this a success. The rest would then “only” be replication of whatever happend to those repos (granted, much work and probably quite a few discussions).

You should probably present this (one of) the next Quality Assurance Working Group Meetings. Next happens to be on October 1st :slight_smile: October Quality Assurance Meeting Thursday, October 1st 2020 :jack_o_lantern:

Would be much appreciated, but I guess you should talk to the OSRF/QA-Working Group first…

The topic was presented to the QAWG during the October meeting and I gave a short insight into the current status of our discourse.

A first report for the ros_comm-noetic-devel is available.
I allocated licenses to 652 files and circa 45 files are unclear and have to be discussed.

Is someone able to perform a review of the report?
If so, please contact me, because there might be some steps to reduce the review effort.

1 Like

@ArneF What do you expect from a review? I.e. could you clarify what a review should look like and (roughly, no details) what steps you’d think are necessary?

For around 550 files the license allocations have been done by the tool. For these file a spot check, if the correct license is allocated, should be done. For the other 100 files the license allocation was done manualy. For these files every license allocation should be checked. (At least during the first reviews)
Unfortunately until now I have not figured out how to tag manual and automated license allocation in the report. :frowning:
The 45 files with unclear license situation have to be discussed later, because they might also need input from the maintainer or author.