Continue publishing under 2-clause BSD license

[ymd-stella]

Check out the work required to continue publishing under the BSD license.

#35 (comment)

I think it would be good to clarify that the similarity between OpenVSLAM and ORB_SLAM2 is based on the ORB_SLAM2 paper

Tasks:

• (moved) Clarify the functional correspondence between the ORB_SLAM2 code and OpenVSLAM code and evaluate the similarities #239
• Clarify the scope of contribution for each paper and treat it appropriately in README.md (for moral issue)
  • ORB_SLAM/ORB_SLAM2
  • ProSLAM
  • UcoSLAM

[ymd-stella]

Extracted similar modules between ORB_SLAM2 and OpenVSLAM.

• data modules
  • Frame - data::frame
  • KeyFrame - data::keyframe
  • MapPoint - data::landmark
  • Map - data::map_database
  • KeyFrameDatabase - data::bow_database, module::loop_detector, module::relocalizer
• visualization modules
  • Viewer - pangolin_viewer
  • MapDrawer, FrameDrawer - publish::*
• other modules
  • System - system
  • Initializer - solve::fundamental_solver, solve::homography_solver, solve::essential_solver, initialize::*
  • Tracking - tracking_module, module::frame_tracker, module::keyframe_inserter, module::local_map_updater
  • LocalMapping - mapping_module, module::local_map_cleaner, module::two_view_triangulator
  • LoopClosing - global_optimization_module, module::loop_bundle_adjuster
  • Optimizer - optimize::*
  • ORBextractor - feature::*
  • ORBmatcher - match::*
  • PnPsolver - solve::pnp_solver
  • Sim3Solver - solve::sim3_solver

Based on these correspondences, similarity should be assessed by making comparisons at a appropriately abstract level. It is important to note that their creative expression may be limited by ideas. (Please refer Merger doctrine.)

(As a side note, the structure of the module and the choice of libraries to use are clearly ideas rather than creative expressions. Therefore, I think there is no problem with similarities.)

This is too abstract task description for others to work with, so I'll give an example.
The following is the part of the Initializer that achieves the same function.

• https://github.com/OpenVSLAM-Community/openvslam/blob/b6c40f671f4fa226b933df47dd1b466dbfdab2ee/src/openvslam/solve/homography_solver.cc#L13-L76
• https://github.com/raulmur/ORB_SLAM2/blob/f2e6f51cdc8d067655d90a78c06261378e07e8f3/src/Initializer.cc#L124-L172

I think this is what @masahi mentioned in xdspacelab/openvslam#12 (comment).
As for the fact that the initialization order of the variables is exactly the same, I don't think it is acceptable if you look at it with strict evaluation criteria.

@SteveMacenski I would like to ask your opinion on whether the above similarity is acceptable or not, and if not, how it should be handled to continue publishing under 2-clause BSD license .

[SteveMacenski]

There's significant changes in the project architecture / filesystem and "although written from scratch" (from that link) tells me its on the right side of that line. There's better structured code for things like the camera models and such. Tons of optimizations and better written / faster ways of doing things ORB-SLAM2 completely lacks and uses OpenCV for.

The things you link to are similar to a degree. Finding a homography is an incredibly common thing to do and there's only so many ways to do it. How many formulations are there to find a homography given more or less the same sets of information? Within research code, there are just a few ways people that do this alot just do it naturally because they're all being educated by the same textbooks and graduate course slides / openCV demo code.

I look at those 2 sets of code and see completely insufficient similarities to count as derivative work. They use completely different underlying libraries (openCV vs something they made themselves) but only the same math. I agree with kensakurada's comment on the last comment in that thread. normalize is a very common function name in all of computer vision programming.

I think the main thing you're just seeing here is that they employ the same math, which if I were to implement this would look similar to both of these. But OpenVSLAM's is clearly different (different libraries, where this is happening in the codebase, optimizations and design decisions made, etc).

In my opinion, this is all above board. They've done things their own unique way based on the same ideas. Noting that 2 codebases are similar which employ similar mathematical and theoretical formulations is only natural, but the design intent across them and how they go about solving these problems based on their own requirements are very different.

[masahi]

I don't know the current code, but when I was looking at it, the similarity was way more than coincidence. That one can only tell if you spend a lot of time on ORB_slam codebase. At that time I also wondered publishing openvslam as bsd while the original code was GPL is a good idea (in terms of morality etc).

[ymd-stella]

@masahi I think there are similarities in terms of structure and algorithms, but I think that is because it is based on the methodology of the ORB_SLAM2 paper.
However I think the similarity at the code level is low. (It would appear that the only similarities are in the few areas where there is less freedom of expression.)
Just to confirm, is the similarity you are pointing out the former(structure/algorithm level) or the latter(code level)?

[masahi]

It was almost two years ago so my memory is not clear, but I would say it is code level. I didn't read the paper because it was not out yet, see xdspacelab/openvslam#12 (comment), so the only way to understand this work was by reading the code. I had code-level understanding of ORB_slam (I had to debug their code because it was full of bugs), so reading openvslam code it was obvious to me that what it does is basically the same as ORB_slam. My impression back then was this is "ORB_Slam2 rewritten from scratch in a clean way", that's it.

It is probably ok from a legal pov, since this is a from scratch implementation and non-tech people don't understand the code (and hence such ambiguous statement from the termination release). But seeing this code published without acknowledgement to ORB_slam, with BSD license, was enough to convince me that this was not something I wanted to use (for moral reason).

[ymd-stella]

I will describe my opinion from a moral point of view. I take "for moral reason" to mean because it goes against the will of the ORB_SLAM2 developers.

Let's consider the will of the ORB_SLAM2 developers in choosing the GPL. I think the purpose of GPL is to encourage people to contribute to the community by making the code public. In other words, the goal is to make ORB_SLAM2 a better Visual SLAM, or for the ORB_SLAM2 community to get a better Visual SLAM.

Since the repository of ORB_SLAM2 has been abandoned for maintenance, their actions show that the intention of the developers of ORB_SLAM2 is not the former now. On the other hand, it is a contribution to the ORB_SLAM2 community that OpenVSLAM continues to be developed as Visual SLAM that includes the features of ORB_SLAM2. Therefore, I believe it does not against the will of ORB_SLAM2 developers.

In order to develop OpenVSLAM that inherits the idea of ORB_SLAM2, I believe it is beneficial that OpenVSLAM is licensed under the BSD license. I think that using the GPL will lead to shrinking the community by narrowing the real scope of application.

(Of course, we need to make sure there are no legal issues.)

[masahi]

I do agree that bsd would be beneficial to the community. What I don't like, as a person who is passionate about open source software, is the dishonesty and lack of respect for ORB_slam from the openvslam team, refusing to admit that this is ORB_slam derivative work. In the termination release, they even described ORB_slam as "another SLAM software that happens to be similar to openvslam", when ORB_slam was released years before openvslam. Let me remind you that the concern around the similarity between the two was raised from both outside (see xdspacelab/openvslam#12) and inside (see the termination release) of their org. Do you still believe that openvslam is genuinely novel and worth completely different licensing than ORB_slam?

Probably the best way forward is to contact ORB_slam authors and ask if they are ok with openvslam being BSD. The reason they chose GPL and not more liberal ones is probably to prevent commercial use of their software and making money. They also have a new system and it is still GPL https://github.com/UZ-SLAMLab/ORB_SLAM3. If the reason for GPL was simply due to their dependencies being GPL, then there is a good chance they are no problem openvslam being BSD (assuming it has no GPL deps).

[ymd-stella]

Do you still believe that openvslam is genuinely novel and worth completely different licensing than ORB_slam?

License protects creative expression, not ideas; Ideas are protected by patents. Licensing does not impose any restrictions on the use of ideas. Even if we implement a new library based on the idea of ORB_SLAM2 without changing any of its functionality, we can still publish it under our own license. (As long as we don't steal the creative expression in the ORB_SLAM2 code.)

You may be confused because ORB_SLAM2 is a complex system. Maybe it's better to replace it with a simple library that you know well and do some thought experiments. (In addition, the fact that some of the code is suspected to have actually been stolen may have contributed to the confusion.)

[masahi]

Sure I get your point, indeed what I said above was not precise. So idea being the same is no problem wrt licensing, and whether or not it is novel doesn't matter. What you are concerned about, and the reason the code was taken down, is code similarity, correct?

I don't think code was stolen or copy-pasted as is. They reimplemented the same idea differently using the original code as reference, but failed to acknowledge the original work. You should also note the last sentence in the termination release: "If you are considering and using the downloaded OpenVSLAM as a derivative work based on ORB-SLAM2 under the GPLv3 license, there may be no issues on this matter.". So they admit that if you continue BSD, there could be issues.

[ymd-stella]

but failed to acknowledge the original work.

Could you please tell me more about it?
It seems to be listed as a reference in README.md, but does that mean it's not enough?

You should also note the last sentence in the termination release: "If you are considering and using the downloaded OpenVSLAM as a derivative work based on ORB-SLAM2 under the GPLv3 license, there may be no issues on this matter.". So they admit that if you continue BSD, there could be issues.

Rather than saying that continuing to use BSD will cause problems, the claim seems to be that using GPLv3 will eliminate any doubt of problems. I think those are distinctly different claims.

[masahi]

Could you please tell me more about it?

I think having ORB_slam listed as one of references doesn't count as an acknowledgement, since unlike other systems in the reference, openvslam code is based entirely on ORB_slam. I don't know the code of other systems, but given that the termination release only mentions ORB_slam, I think we can assume that other systems are not concerned. So I'd expect a special treatment for ORB_slam, rather than merely listing it as one of prior works. Also when xdspacelab/openvslam#12 was opened, there was no reference to prior work whatsoever. From these points, I'm 100% sure that the authors deliberately tried to hide the fact their system is ORB derivative. That's what I mean by "they failed to acknowledge the original work". Hope this makes sense.

continuing to use BSD will cause problems

I agree this is a different statement, what I said is there could be issues. I think this is a reasonable interpretation of that statement.

[ymd-stella]

I don't know the code of other systems, but given that the termination release only mentions ORB_slam, I think we can assume that other systems are not concerned. So I'd expect a special treatment for ORB_slam, rather than merely listing it as one of prior works.

For example, is it sufficient to include it in the overview in README.md?

From these points, I'm 100% sure that the authors deliberately tried to hide the fact their system is ORB derivative.

I think this is an overstatement. I checked the history, and in fact, other references such as ProSLAM and UcoSLAM were added at the same time. They are also clearly listed as references in the paper. Please be careful about what you say so as not to defame the authors.

[masahi]

For example, is it sufficient to include it in the overview in README.md?

Yes, in my opinion, the readme should clearly state that this is an ORB derivative work. But I'm not an openvslam user, so it is up to you.

I checked the history, and in fact, other references such as ProSLAM and UcoSLAM were added at the same time. They are also clearly listed as references in the paper.

I don't understand how your statements above relate to my claim of the authors hiding the fact that their system is ORB derivative? I know these references are added at the same time. Treating ORB just like any other prior works is the very reason of my suspicion.

My confidence is also based on my experience and knowledge of ORB_slam codebase, and openvslam authors refusing to admit that their work is ORB derivative. I don't think authors acted on a good faith. But again, I'm not a user, just wanted to give my perspective.

[ymd-stella]

Thanks for your comments.
I just realized that the paper was not available at the time of xdspacelab/openvslam#12 (comment).

In conclusion, it seems that the heart of the problem that @masahi pointed out is simply a lack of description. For each of the papers that OpenVSLAM refers to, it needs to be made clear which part of the software is involved. I believe that if the contribution of the papers is clearly shown, the moral problem will be solved.
@masahi states that he does not know about ProSLAM or UcoSLAM, and then says that ORB_SLAM2 should be given special treatment because of its large contribution. This opinion is probably correct, but it is impossible for someone who does not know about ProSLAM or UcoSLAM to judge whether the contribution is large or not to the whole. Therefore, it seems that we need to first clarify where ProSLAM and UcoSLAM are contributing in OpenVSLAM.

(Note that whether or not it is possible to use a BSD license is different from the moral issue above. The similarity of the code should continue to be checked separately.)

[masahi]

Sounds good, thanks. I agree with your point on licensing and moral issues being separate topics.

ORB_SLAM2 should be given special treatment because of its large contribution

A supporting evidence to pick up ORB_slam, among other works, is the fact there are more than one person, who:

• Have read both ORB_slam and openvslam code
• And raised concerns around code similarity

This includes me, the person who sent xdspacelab/openvslam#12 (see his comment), and internal people at authors' org. This didn't happened for other systems. If you do the same exercise, I believe there is a good chance you'd reach the same conclusion.

Another evidence is only ORB_slam was mentioned in the termination release.

These facts shouldn't be a coincidence. This is the reason I believe openvslam is ORB_slam2 derivative, and hence it should be given special treatment in the acknowledgement.

So I highly recommend taking a look at ORB_slam code base in detail. As one data point, I spent about a month trying to make the output of ORB_slam deterministic. I found a number of bugs in the process. So I believe I know what I am talking about here.

[ymd-stella]

The reason they chose GPL and not more liberal ones is probably to prevent commercial use of their software and making money.

As a side note, GPL does not prevent commercial use. As long as you accept the release of the source code, you can use it commercially.

[masahi]

The reason they chose GPL and not more liberal ones is probably to prevent commercial use of their software and making money.

As a side note, GPL does not prevent commercial use. As long as you accept the release of the source code, you can use it commercially.

Well, that doesn't happen in practice, does it? Commercial people usually cannot release their code, that's why people are complaining here.

[SteveMacenski]

But seeing this code published without acknowledgement to ORB_slam, with BSD license, was enough to convince me that this was not something I wanted to use (for moral reason).

I see no morality issues. Their paper clearly mentions the similarities and references the ORB-SLAM papers liberally. If the README wanted to be updated to mention that this method is a similar implementation of the ORB-SLAM2 paper, then I think that would be OK. More clarifications on the technique is never bad, but this is not derivative. If I re-implement ORB-SLAM2, that's not a derivative of the codebase and I'm under no obligation to contact or ask permission from ORB-SLAM2 authors what so ever. So why would this be any different?

Adding something in the readme mentioning this implements a similar (but far more optimized) version of ORB-SLAM2, that seems like a very reasonable thing to add to make more clear, but I don't think we're under any moral obligation to do so. If it aids a user in working with or understanding the codebase more, then I think its useful information. If it doesn't then its purely academic that this method is based on ORB-SLAM2 and they should be referencing the OpenVSLAM paper which makes this abundantly clear.

What I don't like, as a person who is passionate about open source software, is the dishonesty and lack of respect for ORB_slam from the openvslam team, refusing to admit that this is ORB_slam derivative work. They reimplemented the same idea differently using the original code as reference, but failed to acknowledge the original work.

This is totally incorrect, read the paper, this is the codebase corresponding to an academic work. This is well understood, documented, and referenced. If you fail to read the complete documentation of a project / academic work, you can't blame the authors for not making it clear in only the parts you picked and chose to read. They have a readthedocs, academic paper, and readme. As an open source developer that also publishes papers along side my work, projects like this building on my ideas are the exact reason I open source my research code, this is the most ideal situation that someone can build on my work and build something even better.

As a side note, GPL does not prevent commercial use. As long as you accept the release of the source code, you can use it commercially.

It does, effectively any company will refuse to use or contribute to GPL code and nothing foundational in ROS is GPL. If this goes GPL, I and my team would immediately cease working on this project and look for suitable alternatives. Medium and large companies can't touch GPL for the most part, this is well understood and non-debatable. Our legal departments would never allow it. LGPL is as far as any company would practically go unless they had literally no other option.

[masahi]

Sure I read the paper, and from the paper alone, I can see that people would get the impression that openvslam is a completely new system / has no relation to ORB_slam. They mentioned ORB_slam as one of prior works, together with others. They compare against ORB_slam in the experiment.

But reading the code, the influence of ORB_slam codebase on openvslam was immediately obvious to me (and not just me, as I mentioned in #37 (comment)). And the code similarity is what we are concerned about here and was the reason the codebase was taken down. So if you don't think openvslam code is a derivative of ORB_slam code, just because there are corresponding paper/doc for it, please take some to study both codebases carefully. My claim is based on my understanding of ORB_slam codebase and I don't think I'm "totally incorrect".

Also it seems we have different opinions on what amounts to a "derivative" software, but I'm fine with that.

[masahi]

Here are another examples of code similarity, that I didn't mention in xdspacelab/openvslam#12 (comment). The point is to show that I didn't cherry-pick parts I read as claimed by the following statement

you can't blame the authors for not making it clear in only the parts you picked and chose to read

Note that they use different function/class/variable names, but if you know ORB_slam codebase well enough you can see obvious correspondences.
https://github.com/raulmur/ORB_SLAM2/blob/master/src/System.cc
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/system.cc

https://github.com/raulmur/ORB_SLAM2/blob/master/src/Tracking.cc
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/tracking_module.cc
(for example, they even use the same magic constant https://github.com/raulmur/ORB_SLAM2/blob/master/src/Tracking.cc#L474 https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/tracking_module.cc#L225)

openvslam code split what was in Optimizer.cc into three files:
https://github.com/raulmur/ORB_SLAM2/blob/master/src/Optimizer.cc
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/optimize/global_bundle_adjuster.cc
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/optimize/local_bundle_adjuster.cc
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/optimize/pose_optimizer.cc

https://github.com/raulmur/ORB_SLAM2/blob/master/include/ORBextractor.h#L32-L43
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/feature/orb_extractor_node.h#L13-L32

Here, openvslam reproduced the same bug I found in ORB_slam. Sorting by pointers and do something that depends on the order of sorted elements leads to non-deterministic result (here, they break out of the loop in the middle https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/feature/orb_extractor.cc#L464).
https://github.com/raulmur/ORB_SLAM2/blob/master/src/ORBextractor.cc#L684
https://github.com/OpenVSLAM-Community/openvslam/blob/main/src/openvslam/feature/orb_extractor.cc#L453

I could go on but I think it's enough. Basically the core of slam system (feature extraction, matching, local mapping, tracking, graph optimization etc) are too similar at code level to conclude that openvslam and ORB_slam are independent projects. This should be more than necessary to convince you that openvslam is ORB_slam derivative @ymd-stella

Actually now that I looked at the code again, it seems to me that the openvslam codebase is just too similar to ORB_slam codebase and I would say it violates the protection of "creative expression" mentioned in #37 (comment). They even inherited the exact same bug coming from a misuse of an exact same data structure/algorithm. Thoughts? @ymd-stella

[ymd-stella]

I think you are stating a conclusion based on insufficient evidence. I take it that you think you have listed enough evidence, but only a few are increasing.

In the first half, it seems to be mainly about software architecture and module structure. I have already pointed out that in #37 (comment).

On the other hand, the last point is about data structure and code. I think this is still not enough evidence. The bugs should be removed, but the implementation is going to be complex. We cannot deny the possibility that they will choose this implementation based on their rational decision.
(ref. raulmur/ORB_SLAM2#283 )

By the way, the magic number in the link in parentheses has the same value but different semantics: in ORB_SLAM2 it is the number of keyframes, but in OpenVSLAM it is the number of seconds.

I think that It is true that ORB_SLAM2 is a great contribution to OpenVSLAM as the idea (architecture, module structure, choice of library, algorithm and data structure). However, in terms of creative expression, I believe that similarities are only a small part of the whole. I think that if we remove those similarities that are accidentally or intentionally mixed in, we will be on the right track. (I think it's like the Sorites paradox.)

[masahi]

Before you say these are not enough evidence, have you actually taken a look at the contents/implementation of each file? When I list System.cpp and system.cpp etc, I'm not merely saying that file/module structures are similar like you said in #37 (comment), but that the contents of the two files are too similar. Please take your time and do side-by-side comparison of the two codebases, that's the level of detail I'm talking about. As I said at the beginning #37 (comment), spotting the similarity requires good understanding of ORB_slam codebase, so merely eyeballing the two code without careful attention to details will likely lead to a wrong conclusion.

On the other hand, the last point is about data structure and code. I think this is still not enough evidence. The bugs should be removed, but the implementation is going to be complex. We cannot deny the possibility that they will choose this implementation based on their rational decision.
(ref. raulmur/ORB_SLAM2#283 )

Again a statement like this only shows that you haven't put deep thought into this. The fix to the bug is simple and obvious, instead of comparing pointers, just assign a unique, deterministic id to each node and compare them. That's what I did to fix ORB_slam orb extractor non determinism. Without this fix, every time you apply orb_extractor to the same image, you get different sets of key points. I think that's absurd.

Overall I get the impression that people here don't bother to read the code when the code is the very problem, and for some reason very confident that openvslam is not a ORB_slam derivative despite the overwhelming evidence and concerns raised by multiple person both internally and externally. Similarity is NOT accidental! If I'm bothering you too much I'll be happy to walk away.

[SteveMacenski]

We've read the code and we come to another conclusion. I think where we're missing each other is that similar does not mean derivative. I agree there are similarities, but there are also similarities with any reasonably implemented VSLAM system I'd make too - does that mean I too have to consider my implementations derivative? That's obviously not the case.

Would anyone using inheritance to design sensor interfaces for VSLAM camera models have to consider themselves derivative of openVSLAM because they did it? Of course not, that's one of a few obvious design choices.

Studying how someone else designed a system and then building a better one with different design improving on one cannot be considered derivative - that's literally how academia works - you hear people's ideas and you create your own building on it. And clearly the reviewers of the OpenVSLAM paper felt it had its own novelty or else it wouldn't have passed peer review and been published. Else, you're saying I can never work at another software company again because I know how CompanyA designed their systems and anything I do in the future informed by that knowledge would be derivative and we must give licensing rights back to CompanyA. Lessons learned are not derivative or we really start to go down a rabbit hole of how the human brain synthesizes new ideas from knowledge.

They've non-trivially improved on the the ORB-SLAM algorithm and ideas in performance, reliability, software design, scalability, and more. They themselves also concluded no code was lifted from ORB-SLAM after a detailed review and any examples I've seen are sufficiently different in sufficiently different contexts that I find no problem with this.

As in ORB–SLAM [10,11] and ProSLAM [15], the graph-based SLAM algorithm [6] with the indirect method is used in OpenVSLAM.

In literally sentence 2 about OpenVSLAM's algorithm, it calls tribute to ORB-SLAM.

[mirellameelo]

@ymd-stella Thanks for your engagement. Allow me to express my concern... As you even said, you are not an expert in this license stuff. I genuinely believe such a complex thing, that leads to a lot of interpretation (different ones, as you can see in this thread) can not be that trivial to solve. Alghtout I deeply respect your contributions and intentions, I'd suggest a more cautious way, and especially, taking some specialist's feedback (Maybe @SteveMacenski has a juridical team to help us with that, then we can find practical, effective, and safe tasks to move on).

Also, did you try emailing the authors? Maybe asking for more legal information and directions to the community in case we intend to continue the project in this fork.

[SteveMacenski]

My opinion on this is that we forked it while it was listed as BSD-2.0 and the version of the code is also versioning the license. From @ymd-stella, the original authors, and my review, we don't find any direct code copying but rather just using many of the same ideas (and properly cited in the paper).

My recommendation of action given this is to continue under the legally appropriate license (BSD2) when this work was forked since we literally cannot legally re-license it to anything else without all 30 contributors OKs (including the non-responsive authors). So changing to GPLv3 is literally not even an option. We could make any new contributions be under that license, but we cannot change what is currently existing (which is the only thing of question, anything new wouldn't be of concern to even want to change the license). We should also add a comment in the readme about how the OpenVSLAM method implements a technique similar to ORB-SLAM and ProSLAM in case for some reason that isn't immediately clear.

If/when someone with the proper authorization of ORB-SLAM decides they think there's an issue with this, we can deal with it then. However, I do not believe there is any reason to think there's any issue with this work under its current license.

[masahi]

I agree there are similarities, but there are also similarities with any reasonably implemented VSLAM system I'd make too

I generally agree with your point on different SLAM systems end up having similar structures - Although I've only read ORB_slam code deeply, I can imagine different systems influencing each other on their design and implementation.

The point I've been making, however, is that for the case of ORB_slam and openvslam, the similarity is well over that line. For example, how can you explain the fact that openvslam ends up having the exact same implementation bug, using the exact same data structure/algoirthm, as I pointed above? I would say this amounts to "direct code copying". The point is not to call out this one snippet, similar code correspondences are all over the codebase.The only reasonable explanation I think of is because openvslam was developed using ORB_slam codebase as a reference. If you don't like the word derivative, a statement like "openvslam is built on / based on ORB_slam implementation" also works for me.

That said, if you say you've read the code and reached different conclusion, there is nothing I can do. If you don't see unreasonable similarities between the two, I can only assume that you haven't done the reading as thoroughly as I did. I don't see any point arguing who is right, so I stop here.

I do agree that keeping BSD would be the most reasonable thing to do for now, given that the original code was published with it (which was a mistake IMO) and it is too late to fix this.

[mirellameelo]

Sounds great. So, in short, we all good to go in this fork - without changing the license for the last release (which is illegal) nor for new contributions. The only practical task here is to make (more) clear in the readme file the relation between OpenVSLAM and ORB-SLAM, which is something already pointed out in Stella's comments. But, should this be done in the code-level analysis, or just a simple small note could be sufficient?

[masahi]

Here is my opinion:

• Code level analysis should be done by current maintainers, no matter what.
• README should clearly state and acknowledge the contribution ORB_slam had on openvslam. Treating ORB_slam merely as one of prior works, like the current README does, is disrespectful to ORB_slam given the obvious, enormous influence ORB_slam code had on openvslam.

Seriously, unlike the original openvslam authors, nobody should have a special attachment to openvslam code. I don't get why it is so hard to admit that development of openvslam code was not possible without ORB_slam code. Isn't this a proper ethics OSS project should have among each other? And don't forget the fact that one project is GPL while the other is BSD.

[mirellameelo]

@masahi Thanks for replying. I am not able to see why a code-level analysis would help the actual maintainers to be ok - legally speaking (That's why I insist on an expert's opinion). Honestly, it sounds more like someone here is already facing some action.
In my point of view, no one besides the authors can express the real contribution coming from Orbslam, and no one here has the power to force them to recognize anything, especially things that clearly, you are supposing by yourself (no matter how convenient are your arguments...). For me, this is not the point. The point is how we can operate from now and on...

[junzhang3141]

@mirellameelo did you guys create a slack channel for this project? I am willing to help

[mirellameelo]

@junzhang3141 Nice!
It is not Openvslam's slack group, but Nav2's, where there is a channel regarding the SLAM. Try to get in with this link, please.

[ymd-stella]

The Openvslam's community is https://github.com/OpenVSLAM-Community/openvslam/discussions. I do not recommend discussion in closed community such as Nav2 slack. OpenVSLAM also used to have a slack community, but now it uses GitHub Discussions.

[TheBricktop]

I know that re-licensing is out of question now but why wouldn't anyone think of LGPLv3 ? As I understand it allows to dynamically link the compiled library and use its underlying functions without compromising whole rest of the application (like for example some of commercial apps) and protect the foss code.

[ymd-stella]

Clarify the scope of contribution for each paper and treat it appropriately in README.md (for moral issue)

UcoSLAM

Features that are not present in ORB_SLAM2, but only in OpenVSLAM and UcoSLAM, include the following

• Ability to save/load maps
  • I looked at the code and confirmed that it was in the original unstructured and simple storage format.
• parallelized KeyPoint detector
  • I looked at the code and confirmed that it uses threads for parallelization; OpenVSLAM uses OpenMP for similar parallelization.

The basic architecture and algorithms seem to be based on ORB_SLAM2. However, parts of the code have been obfuscated and we cannot get into the details. In fact, it is stated in the paper that one of the rule for keyframe insertion is the same as that of ORB_SLAM2. Also, the benchmark results of ORB_SLAM2 and UcoSLAM described in the paper are quite close (The paper states that it is slightly better).

Conclusion

The parallelized KeyPoint detector part may have been inspired by UcoSLAM, but only the author seems to know. There are other implementations of saving and loading, so I'm not sure if they were inspired by UcoSLAM. For example, MathewDenny/ORB_SLAM2@cb8116d. Looking at Table 1 of the OpenVSLAM paper, it appears that UcoSLAM is cited for comparison of map saving and loading feature.

references

• web site and code
• paper

[ymd-stella]

ProSLAM

It was designed to be a simple, lightweight VisualSLAM. I haven't looked at all the functions, but they may have been influenced by the directory structure, module structure, and configuration.

references

• code
• paper

[ymd-stella]

The discussion about the license here has been finalized, and the moral issues have been improved by updating the README. The rest of the investigation into code similarity will be done at #239. If you find any problems with the distribution under the BSD license, please create another issue.