Can I use catkin_virtualenv to help release a non-GPLv2 package with bloom?
I'm trying to release the packages dual-quaternions and dual-quaternions-ros to the ROS buildfarm using bloom. A dependency of my package isn't in apt-get and only available through pip. catkin_virtualenv seems to provide a solution for that through macros that will install the pip package in a virtualenv. That package however has the GPLv2 license, while dual-quaternions has an MIT license. Can I use catkin_virtualenv to release my package or does that violate the license requirements?
I doubt you'll get an answer about this here on this forum. But let's see.
I considered posting on opensource.stackexchange.com but decided not to since
catkin_virtualenvsuggests using their tag here and thought this might be useful to others specifically releasing with bloom in the future. Question is still valid but I don't think I can usecatkin_virtualenvas noted in my comment anyways.If your package distributes GPLv2 sources then your package should probably include that in the license information. But moreover I'm not familiar with any released packages which use catkin_virtualenv to create a vendored copy of a dependency. They could be out there but I don't know about them and would discourage their use. In the ROS 2 ecosystem we've created "vendor" packages to provide needed libraries when the upstream version is missing or insufficient. I don't of any vendor packages that are pure Python packages like you'd get from pip. The very long solution to this is to try and get the python library packaged by Debian, Ubuntu, and other platforms you want your package to support so you can depend on it like any other system package.
There are great answers in https://www.gnu.org/licenses/gpl-faq..... The inputs to a build tool determine it's license requirements, not the use of the build tool itself.
MIT + GPL in -> catkin_virtualenv -> GPL Out
https://www.gnu.org/licenses/gpl-faq....
Remember dpkg and debhelper are GPL packages themselves. Just by using them doesn't automatically make a built artifact subject to the GPL.
You need to make sure the package you are building though is correctly licensed. If for example that work imports a GPL'd python library, a case could be made that that constitutes dynamic linking