Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Correct Apache-2.0 license short identifier #301

Merged
merged 1 commit into from
Mar 17, 2021

Conversation

destogl
Copy link
Contributor

@destogl destogl commented Jan 18, 2021

According to the following sources, there is a missing "-" in the Apache license's short identifier.

** Why is this important?**
Many packages in ROS2 are using the Apache license. There are potential legal issues in the future if developers are using the wrong short identifier (as I was doing).

According to the following sources, there is a missing "-" in the Apache license short identifier.

* https://opensource.org/licenses/Apache-2.0
* https://spdx.org/licenses/Apache-2.0.html

** Why is this important?**
Many packages in ROS2 are using the Apache license. There are potential legal issues in the future if developers are using the wrong short identifier (as I was doing).
Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable to me. The only problem is that we have been suggesting the previous "Apache 2.0" for a long time, and many packages already use it. I guess it is not a huge problem; those packages can migrate over time. Still, I'd like some feedback from @tfoote before I merge this.

@shr-project
Copy link
Contributor

shr-project commented Jan 20, 2021

It's definitely an improvement, but maybe a link to SPDX list of identifiers (https://spdx.org/licenses/) would be better as the next one "BSD" has the same issue (without specifying which clause version) and "BSD" is by far the most common license value in package.xml files (most likely because it's the default in generated package.xml and shown in many examples), see:
ros-infrastructure/catkin_pkg#296
with some statistics from current rosdistro packages.

@clalancette
Copy link
Contributor

The thing is, we don't do any checking (automatically or manually) to ensure that the license tag is one of the approved ones. Adding manual testing to our process would be very tedious, so I wouldn't sign up for doing that on every new package that comes into https://github.com/ros/rosdistro. We could write a GitHub action or something for it, but we'd also have to have an "escape valve" for allowing other licenses; there are sometimes valid reasons for it.

One other thing: in ROS 2, the vast bulk of our packages use a license field of "Apache License 2.0" (which is the long form, not the short one). There are a few rogue packages that use "Apache 2.0", but those should be cleaned up. So with that said, I'm actually wondering if we should switch the recommendation to that instead.

Copy link
Member

@tfoote tfoote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should definitely use the canonical format. Long form vs short form doesn't really matter. Though I generally like the more compact representations. It is probably not worth actively migrating.

@herb-kuta-lge
Copy link
Contributor

herb-kuta-lge commented Mar 17, 2021

Though I generally like the more compact representations.

How about recommending that SPDX identifiers be used: https://spdx.org/licenses/ . They're nice and compact (and precise, too).

@tfoote
Copy link
Member

tfoote commented Mar 17, 2021

I would support recommending using spdx identifiers. We should probably do that in a separate PR though as this is just a fixup.

@clalancette
Copy link
Contributor

I'm going to go ahead and merge this one for now. We can follow-up with some of the other suggestions in other PRs.

@clalancette clalancette merged commit 921f5ff into ros-infrastructure:master Mar 17, 2021
@destogl destogl deleted the patch-1 branch May 9, 2021 06:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants