-
Notifications
You must be signed in to change notification settings - Fork 311
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
[all] Clean licenses #139
[all] Clean licenses #139
Conversation
[ci-ignore]
Hi, Thanks for this PR and nice work. This PR:
Once the CI will confirm nothing is broken and upon @matthieu-nesme agreement I suggest we merge this PR without waiting 1 week :) |
Warning, you did change headers in extlibs (at least CImg). |
GG mathieu |
26b7643
to
813932c
Compare
Thanks Matthieu ! |
[ci-build] |
From the forum (https://www.sofa-framework.org/community/forum/topic/still-license-issues-with-sofa-plugins/): I noticed that there was a pull request targeting license stuff not long ago (v16.12), which is nice, but I still found some delicate license issues, which potentially can cause trouble for users of SOFA and the SOFA-devs. Just from a first look into the plugin folder for all plugins, that do NOT contain the string “LGPL”, I found conflicting license information. I didn’t yet check the “LGPL”-plugins or SOFA in general for potential transitive license issues (conflicting with licenses of third-party dependencies). It’s also hard to make a pull request for this issues as it is something that the SOFA devs have to decide.
General notes: |
for the plugins I know: regarding the versions of LGPL and GPL pick the ones you prefer :p I've got no idea of their subtle differences. +1 for license (vs licence)! |
:-) The differences between LGPL and GPL are everything but subtle. It has a huge impact for the users. For example: GPL requires in general, that someone who uses the code, has to make the own code GPL as well and hence it must be open source, too. This is not acceptable for many organizations and companies. And this is why the two licenses are not compatible at all. :/ Unfortunately, it is very easy to "poison" own code this way without even noticing by having a dependency that has a minor GPL part. |
The subtle point is not LGPL vs GPL but GPLv1 vs GPLv2 vs GPLv2.1 vs GPLv3... |
I see. :) What do you guys think about a CMake option for explicitly allowing to include non-LGPL parts in the SOFA build (default ON to stay compatible, and maybe even tag it as advanced option)? The idea is that if this switch is off, all the non-LGPL parts (or non-compatible parts) like the applications and a few plugins don't even show up for configuration anymore (technically the add_directory() call into these directories is never made in that case). Currently I have to bundle our own SOFA tarball for the purpose of getting rid of the non-LGPL parts and patch the build system a little bit to, in a nutshell, accept that parts are missing. I can continue to do so, but I'm also interested in contributing something like that. I imagine to follow the license rule mentioned in the top-level readme file: Exclude a few directories in principle and dynamically lookup the plugins if they are LGPL or not. This way, plugin developers wouldn't need to add a list entry somewhere depending on the license. They would just need to follow a convention in order to make the license determinable by the script. Could be as simple as a LICENSE.txt file or even the implementation of the getModuleLicense() function, which should be easy to parse (and is only missing in a single plugin at the moment). Opinions? |
@kislinsk I really like the idea of having CMake options to be aware and control the build according to the license requirement. On my side I have no time nore experience to do that so I cannot help on that. EDIT1: This discussion can probably be continued in the "Issues". |
I will add a few commits to clean the points showed by @kislinsk like the |
Licenses organization is now specified in the main README file. Default license is LGPL as specified by LICENSE.LGPL.txt at root. Everything is LGPL except directories (and their content recursively) with a license file specifying a different license.
As plugins are not really part of SOFA (and are going to move to their own repository soon), I finally think we should not add the SOFA license header to them. Still, I suggest to have some license template for plugins. Something like this:
I will remove all plugins-concerned commits from this PR and create a new one for them. What do you guys think? |
813932c
to
8f3caae
Compare
I just removed all plugin-concerned commits. They are still available on guparan/sofa:clean_licenses_pr_139. |
…cence.txt into license.LGPL.txt. This changed has not been propagated in the cpack config.
This PR is big but should finally clean all licenses in SOFA.
Here is what I did:
WARNING: I found a contaminating paste of GPL code in LCPcalc.cpp:501 (lcp_lexicolemke function). Since I didn't found any usage of this function in SOFA (including plugins), I removed it.
Please tell me if this is OK. Otherwise, we will have to discuss about GPL contamination.
Fix wrong or missing LGPL headers in applications/plugins(commits removed)Fix wrong or missing GPL headers in applications/plugins: OptiTrackNatNet, SofaPML and SofaVRPNClient(commits removed)Fix wrong license in SofaHAPI/initSofaHAPI:58 (should be LGPL)(commits removed)This PR:
Reviewers will merge only if all this checks are true.