distributing GPL code in our release archives

[wjwwood]

It was brought to my attention that we're distributing the so/dll (and executable) for uncrustify in our archives we uploaded to our release website:

https://github.com/ros2/ros2/releases/tag/release-bouncy-20180720

The implication was that this might be an issue due to mixing licenses in the binary, and at the very least unattractive to companies that want to avoid GPL but still use our binary packages.

I'm not sure what if anything we should do about it. I didn't investigate if there's any kind of legal reason to avoid distributing the GPL binaries in our archive, nor did I investigate how we might avoid this gracefully. I just wanted to open this up to see if anyone on @ros2/team had an opinion about it.

[anhosi]

At the end of section 2 GPL states that mere aggregation of GPL software does not place the whole distribution medium under GPL. IMHO that is the case here as nothing in the binary release is linked against uncrustify.

For companies using the binary packages a NOTICE file or something similar listing all contained software (especially third party) and the respective licenses would be great.

[mikaelarguedas]

I understand the concern, though as pointed out above we don't link against it anywhere and just provide the executable for testing purposes.

In general our stand is that the binaries should allow people to use the system, run examples etc by providing all the runtime dependencies (but not contain all the dependencies needed for development). IMO these testing libraries fall under the "dependencies needed for development" category and so don't need to be in the archives.

Somes idea from the top of my head:

1. dont ship any of the linters in our "fat" archives (several ways that could be done)
2. add a NOTICE file listing all the "dual" licences present in the archives (as we also vendor some MIT code and BSD code in there)

Edit: TLSF is also GPL so not shipping linters would be enough to get rid of all GPL code in the archives. That may actually be a more problematic thing to solve as we do have som demos linking against it.

[wjwwood]

Sounds like the NOTICE file (along with a notice in the release page on GitHub) seems like the best solution for now. In the future we might choose to make narrower archives (similar to our variants in the .deb packages), which might avoid GPL code.

[wjwwood]

@anhosi Any input on what should be in the NOTICE file or how it should be structured? I'll draft it after hearing from you.