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

kiss-icp depends on plyfile (MIT vs GPL v3) #425

Closed
Samahu opened this issue Jan 21, 2025 · 4 comments
Closed

kiss-icp depends on plyfile (MIT vs GPL v3) #425

Samahu opened this issue Jan 21, 2025 · 4 comments

Comments

@Samahu
Copy link

Samahu commented Jan 21, 2025

Hi,

During a review of the software licenses used by some of our projects we noted that kiss-icp list plyfile as one of their dependencies:

Image

Kiss-ICP is listed as an MIT license but plyfile is GLP v3 as shown in the table below:

 kiss-icp            1.1.0       MIT License                                        
 plyfile             1.0.3       GNU General Public License v3 or later (GPLv3+)    

This may be seen as conflict between the two licenses (depending on how you interpret GPL, I am not a legal expert). So we were wondering if that is something you guys already went over and decided that the use of plyfile doesn't infringe the kiss-icp license.

@nachovizzo
Copy link
Collaborator

Hello there! thanks for pointing this out.

Indeed, none of us is expert in licensing. We will try to investigate a bit how to solve this, but meanwhile

  • the plyfile library is only used in the "python" interface, in case you are only using the C++ core library form kiss-icp, or the ROS wrapper, none of this code is being used. So I'd assume we are safe on that matters
  • if you are using the python package, but you have your own dataloaders, then you can delete the pairs luco dataloader, which is the only one which uses this library (
    from plyfile import PlyData
    )
  • @benemer , @tizianoGuadagnino 3rd option would be to remove the dataloader completely or remove the dependency, I think we did this in a rush and probably can use any of the other 3rdparty dependencies to load this data, wdty?

@tizianoGuadagnino
Copy link
Collaborator

I vote to completely wipe out the dataloader guys . I honestly didn't even remember it was there. Probably we use it twice in our lives. @Samahu, thanks a lot for pointing this out

@benemer
Copy link
Member

benemer commented Jan 23, 2025

I am also OK with removing it. We do not even report the results in the paper. Good catch @Samahu!

@tizianoGuadagnino
Copy link
Collaborator

Handled in #426

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

No branches or pull requests

4 participants