Modify license to GPLv3 #35
Conversation
ymd-stella
force-pushed
the
modify-license
branch
from
b2b1b59
to
bbdf503
Compare
ymd-stella
force-pushed
the
modify-license
branch
from
bbdf503
to
725fa4b
Compare
|
Woah woah, what? GPL defies the entire point that OpenVSLAM was made for if you read their paper. It completely blocks companies like mine and most others from even considering to use this work - not to mention its illegal to relicense like this.
this seems to clear things. The licenses are only for the software, not the ideas or algorithms themselves. If there are no instances of direct code copying, this is completely OK. Their statement on liability is absurd. No one but them is under any issue if the code was taken as-is when the license was versioned under BSD2, that’s not how this works. They cannot retroactively relicense it. This was forked while it was BSD2 and unless we pull updates from it after they relicensed, we can keep BSD2. Their explanation makes it clear its out of an abundance of caution, but that statement I linked to above makes it clear that there is no licensing issues. Software licenses don’t apply to ideas or algorithms, only specific code. If nothing was copied, this is all OK. |
|
This is something I want to find a solution to because this license would completely block most ROS users, including myself, from even being able to file a ticket on this project (let alone use it in Nav2) |
|
@SteveMacenski I literally don't understand why they closed the open source project since they "did not observe any potential copyright infringement incidences". Honestly, I don't think they tell us the full history... Well, now I'm super confused about what all of this means in practical effects. For example, my usage of OpenVSLAM has been to my dissertation. In this scenario, I could be affected as same as you with commercial intentions? Do you mind clarify about "[...] completely block most ROS users"? I'd appreciate follow-up on your interests in solving it, and also be useful as possible to help. |
I think they are, it reads to me like their legal department said to remove the source from circulation to be safe. It's easier to just nuke it and walk away since they already got their publication out of it and weren't maintaining it anyhow. They did mention that this only came up from an internal review ("some internal concerns ") so it doesn't seem like anyone was actually making a problem about it externally / from ORB-SLAM people (lets be honest, GitHub is littered with mislicensed ORB-SLAM copies, they clearly don't care). "we did not observe any potential copyright infringement incidences" -> even their internal review concluded that it was OK, but they're being hyper conservative. They then have a paragraph trying to shift liability, which is completely incorrect and untrue. Further, no one externally even made a problem about it so there shouldn't be a concern 🤷. What I read from this is that someone internally made a problem, and because they think they are skirting the line, they decided to be conservative and remove everything because they got what they wanted out of it already (publication), even though none of the actual copyright holders ever expressed an issue.
In purely practical terms, anyone from any company basically cannot use this software anymore. I couldn't contribute, assist, or even file tickets on this project - nor could we use this to offer VSLAM integrations into the ROS2 ecosystem.
Yes, you are also required to release all of your source code modifications with pretty strict versioning / changelog requirements. Anything you link against this work for must also be GPLv3 and made available to people who ask. Keep in mind that they/we cannot blanket relicense things, there's much more process that would have to go into that (including wavers from every single author of this project and copyright holders). The licenses available are just as anything else is and its versioned in Git. So if we don't update after a project changes a license, we're still good to go under the original license. They didn't even change to GPLv3, they just removed it from circulation entirely, so there's no reason to think we need to change licenses at all if we also do not believe the code they developed is infringing - which they themselves concluded it probably didn't. This has happened in larger projects before where they went from a permissive license to a stricter one. Anyone with a fork and developing on the old version is OK to keep the permissive license. It is still their work they licensed as BSD2. It only becomes an issue if they pull in updates from the main project after the license was changed (then that contaminates the project and forces you to move to the new license). As long as we never pull in updates (which there aren't any because they closed it down), we're good, I believe. All of this is clearly with the understanding that I'm not a lawyer, just someone that deals with open source software alot What I suggest is we continue to operate under BSD-2.0 because AIST concluded there wasn't probably an issue and no one from ORB-SLAM expressed a concern. If we get an email from the ORB-SLAM copyright holders (Universidad de Zaragoza) as a cease and desist, then we take the appropriate steps. But even from my first-glance review, I don't see an issue in this codebase that would make me at all concerned. |
|
Thank you for your comment. The question of code similarity is a difficult one. I think we need to take a very hard look at whether OpenVSLAM can be written from the ORB_SLAM2 paper alone, without reading the ORB_SLAM2 code. Of course I am not a legal expert and the above is my personal view. I think we should respect the fact that the original author stopped the release and recommended to use it under GPLv3. I have thought about what we can do to protect our rights regarding ORB_SLAM2 and OpenVSLAM. I think it would be good to clarify that the similarity between OpenVSLAM and ORB_SLAM2 is based on the ORB_SLAM2 paper. To do this, I think it would be a good idea to find similar codes and give comments that correspond to the descriptions in the ORB_SLAM2 papers. If we can make such an effort, we may consider continuing to publish under the BSD license. |
|
I don't think that's necessary, but additional comments isn't a bad idea either. Either way, the relicensing though this PR proposes is technically illegal since you (nor I) have the right to blanket relicense other's work. Really, relicensing is actually at a complete impasse since the authors are not responsive, we would need every single one of their written permission to change the licensing for each commit in their contributions. Which is about 30 people. This is why other open source projects make people sign copyright handoffs so that the maintainers can do things like relicense without asking permission. But since this (nor anything in ROS) have such CLA's in place, you'd have to get all 30 to sign off on it before you could relicense.
I believe it can be. I just did a bit of a glance around between the two and I really don't see enough similarities to make it seem that it has a problem in that regard. I can commit to spending a couple of hours and really diving into it, but I really think this is OK given AIST's position, the glancing I've done, and the paper's explanation of the implementation.
The openvslam paper does this at length, its pretty well understood they employ similar techniques. |
* Add .github/workflows/main.yml * [Backport] Adding map->camera_link tf (stella-cv#9) * adding map->odom tf * adding ft map->camera_link * updating files to fix frame transfomation * initializing the parameters * adding mutex; setting camera_link_ once * checking tracking status * updating with ros2 branch * updating w ros2 branch * adding the TF after branch update * applying clang-format-6.0 * [Backport] Update .github/workflows/main.yml * [Backport] Update CI workflow (Add tf publisher) * [Backport] Refactoring openvslam_ros - Simplify redundant processes. - Use message stamps * [Backport] Fix missing dependencies * [Backport] Publishing tf timestamp in the future (stella-cv#23) * publishing pose's timestamp in the future * changing tf timestamp * removing unnecessary changes * [Backport] Update Dockerfile b95ee0ffb944d84b5cf5339909808096a95055e9 * [Backport] Add Dockerfile.socket * [Backport] Fix docker src path * [Backport] Fix map frame transformation (stella-cv#27) * Fix map frame transformation * Rename from cv_to_ros to rot_ros_to_cv_map_frame * [Backport] Add topics/parameters list * [Backport] Filter nan in depth image * [Backport] Filter nan only for CV_32FC1 * [Backport] Support initial pose on ROS-wrapper side (stella-cv#29) * Support initial pose * Apply clang-format * Fix comments * Meet review suggestions * Simplify conversion statements * [Backport] Use fbow * [Backport] Move CI workflows to github actions (stella-cv#34) * Update .github/workflows * Remove wercker.yml * Remove DBoW from docker image for CI
No description provided.