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.
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.
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.
First, I’d like to thank you for those efforts and really looking into the core packages w.r.t. licenses
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 ).
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.
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.
For the topics about the ROS2 and the how to specify licensing and copyright information we can set up another discourse in parallel.
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).
@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.
The 45 files with unclear license situation have to be discussed later, because they might also need input from the maintainer or author.
).
