SuiteSparse licensing issue; Ceres can solve pose graph problems only under GPL, affecting downstream projects #1026
Comments
|
I do not believe it is the responsibility of (open-source) projects to make their users aware of legal intricacies. Some users simply may not care because their projects are already compatible with the corresponding license. However, if you do care, e.g., in a commercial context, you do need to assess the eligibility of using a software product regardless of its license by a legal professional. Nevertheless, Ceres Solver does already mention that some components are used under GPL terms. It is therefore not clear why we need an additional notice. Apart from that, there is simply no generic way to know what license a specific version of dependency requires.
Unknowingly violating is only an excuse for situations where the license of a software being used (directly or indirectly) is either not (carefully) assessed or simply ignored. Using Intel MKL as a sparse linear algebra backend has been already proposed in #726. Therefore, |
@sergiud I would say that it is not fair to call a legal intricacy clearly stating under which license your software is available to your users, and which used 3rd party library licenses are you subjecting them to. Every software package has to do this. Standalone applications typically do this in the "about" window, while libraries usually do it in a If you distribute software that uses a GPL library, the GPL says that it is your obligation (in this case, this would be the Ceres authors) to inform your users of their rights and obligations they have under the GPL. I would argue that the notice on the cited wiki page is too obscure and inadequate, so much that even Google released downstream software (Cartographer, at time maintained by Google) where nobody had any idea that it is GPL because of a lack of this being well documented. A much more appropriate and standardized place to do this would be the Since direct Ceres users are mostly developers and researchers, and it appears that there is a big lack of awareness about this, I think it would be a good faith thing to print a notice about this while e.g. while CMake is Okay, enough with legalese. There was a technical point to this issue too -- I have been made aware that there was dramatically more progress with integrating MKL into Ceres behind closed doors inside private forks of Ceres than #726 would suggest, and that upstreaming this work was turned down by the maintainers because of different reasons, including lack of adoption and overhead of maintaining the MKL support. My proposition with this issue is that there in fact is adoption, and the fact that non-GPL Ceres is not able to solve big sparse problems like pose graphs might be an argument in favour of adopting MKL. It is the only other non-GPL sparse linear library that I am aware of that can handle these kinds of problems. If you know of another, please share. |
While I understand what you are saying, you are mixing very different issues here. The Ceres Solver license is stated in the At this point we can agree that the issue arises not in Ceres Solver but rather in projects that integrate Ceres as a dependency (i.e., Cartographer) which seem to do a poor job documenting the license their (binary) distribution is subject to. Cleary, this is not something that can be solved in Ceres directly. |
Ugh, I don't really want to be bogging down the discussion with more legalese, but the form of the distributed software is irrelevant here. If what you claimed was a factor, the GPL license obligations could be avoided by simply shipping the source to the customer under NDA (or the source of a GPL shim) and instructing them to build it themselves. Also, the GPL wouldn't have any power with projects written in non-compiled interpreted languages, because they don't have any binaries to distribute to begin with. We know well that this is not the case. Ceres does distribute code which uses a GPL library (includes its headers and links it, by default, without explicit opt-in, if present on user's PC while building Ceres). Distributing software that uses, includes or links GPL code, whether in binary or source code form, it is still distributing said software, and is still subject to GPL's obligations to inform the user of their rights and obligations under GPL. |
If that were to be true, conditionally excluding code at compile-time that references GPL licensed software would not allow a project to be distributed under a more permissive license. Yet, this is a standard practice. |
|
If that option to use the GPL software is there, and even more so, enabled by default, the user has to be made aware of the GPL. Period. Nowhere did I claim that you cannot conditionally exclude GPL code in order to obtain a GPL-free version, nor did I claim that Ceres itself can not be distributed under a more permissive license which will apply in such a non-GPL case. I just claim that Ceres users have to be made aware when and if Ceres is using GPL code, especially when this is the case by default. And the default doesn't even matter. Just the existence of this option and the related code which uses and includes the GPL library warrants the My belief that the issue is actionable in 3 ways:
I can propose a MR covering points 1 and/or 2 if there is agreement about this. |
|
@ojura what you are proposing as an obligation on Ceres is inconsistent with standard practice in other large OSS projects, and crucially would be inaccurate for commercial licensors of SuiteSparse. For example OpenCV's own LICENSE file makes no mention of there being build configurations that would change the result to GPL. Furthermore, this is the reason OpenChain exists, as the answer is not trivial when considering the entire transitive dependency graph. For example, OpenCV can depend upon FFMPEG, which in turn may be licensed under LGPL, GPL or non-free licenses (see here). OpenCV's official website also makes no reference to this in their license section as these dependencies are optional, even if (like Ceres) they are enabled by default if detected. Your reference to our LICENSE file including references to libmv is different in an important way: the Ceres repository contains code which is a derivative of libmv code. It is not the case that libmv is a dependency for Ceres, only that two of our examples contain code taken from libmv. Regardless of how (or even if) you compiled the Ceres source, this licensing would therefore remain. It is not sustainable, or indeed necessarily accurate given that licenses can, and do, change between compatible API versions, for each library to hard-code the licenses of their possible dependencies (and their dependencies etc) when this may not even be exposed once installed. A good, and particularly relevant, example of this Eigen's sparse ordering methods which were LGPL-ed until Google (not coincidentally) paid Tim Davis to permit them to be licensed under MPL v2 (see here). The LICENSE file for a project covers only the code contained within that project, it does not represent an aggregation of the licenses of its possible dependencies when built (given their own possible options), and it should not be understood as such. In the OpenCV + FFMPEG example, howsoever you choose to build FFMPEG is up to you, and responsibilities for that decision are also yours. OpenCV does not include or modify its license in any way when use of FFMPEG is enabled. This is further complicated again by the LGPL in particular, which is understood as not being parasitically transitive when dynamic libraries are used for LGPL dependencies, however would be if static versions were used. Again, the choice of how the dependencies are provided at build-time is a free choice for the user, but the implications and responsibilities are also theirs.
You can release your own code on GitHub (or anywhere else) under whatever license you choose. What licenses it is subject to when built is a separate matter that may be beyond your control. You might choose to use only non-SuiteSparse sparse linear algebra library option backends in Ceres in your own code, but if a user chooses to compile Ceres with SuiteSparse then the result is that your project as built is also GPL, regardless of your original intentions. The assumption that the presence of SuiteSparse must imply the GPL is also incorrect. SuiteSparse is explicitly offered under a commercial license, which commercial customers (such as Google) should and do have. We cannot determine whether a client has a commercial license to use SuiteSparse as the source code is identical. As a result it would be both erroneous and very damaging to assume that this was the case, and incorrectly update the license of Ceres, as that would now propagate. This is why in any (responsible) commercial context, fully managed build environments are used so that the licenses as-used can be tracked transitively and reported, whether according to OpenChain or something similar if/when required. There are many different ways to do this, for example Conan. For these reasons, 1) and 2) as you described are not a change I (or the other maintainers) would support as they would cause significant issues for commercial users. Whilst we continue to reference SuiteSparseQR (which can be GPL) and not just CHOLMOD (which can be LGPL or GPL depending upon how it is used) I don't have any issue with us emitting an additional CMake There should not be any issues with 3) in principle, provided that they comply with our contribution guidelines and go through our usual review process we can certainly incorporate them. That original ticket is assigned to me already, so I will have a look at that in the near future. |
|
@alexsmac In your example, you cited OpenCV possibly being GPL because FFmpeg might be built as a GPL library. I believe that is a straw man and not a fair and direct comparison. In that case, yes, how you build ffmpeg is up to you. OpenCV is not directly calling into a purely-GPL licensed library if it is using ffmpeg which is generally not GPL (but might be - up to how the user built it). In contrast to that, Ceres ships code that, AFAIK, directly calls by default into supernodal CHOLMOD for solving, which is GPL, and into SPQR for covariance estimation, which is GPL too. I would compare this being closer to the Linux ZFS situation: ZFS is including Linux headers and calling directly into the kernel GPL code, which is problematic because the ZFS license is not GPL-compatible (like Apache 2 fortunately is).
This is way offtopic, but also incorrect. LGPL is not inherently incompatible with static linking; that is a common misconcetion. LGPL obligations can be fulfilled by shipping the proprietary compiled object files and everything needed (linker flags, ...) to enable the user to relink the final binary themselves with their own versions of LGPL libraries. Sure, LGPL compliance is much easier to achieve by using the dynamic linker which enables simply swapping the dynamic libraries. But it is not the only way, and certainly not impossible with static linking, as you suggested.
I did not assume or claim this anywhere that SuiteSparse commercial license holders have to worry about the GPL. I thought this was obvious and well understood, and am really surprised that you brought it up. This is really a non-issue and is just a matter of semantics and appropriate wording (perhaps just a single word, GPL may apply, might be enough!) to make it clear to the user that whatever license that they have for SuiteSparse, GPL or commercial, applies when building and linking Ceres. I am sure that the commercial users are well aware that they have a commercial SuiteSparse license, given the hefty price tag on it. The assumption you quoted does apply to non-commercial users. I believe that just because SuiteSparse is available under a commercial license besides the GPL, it is not an excuse for Ceres to ship code directly calling into it without mentioning at all that the GPL may apply. I honestly thought that the word may was implied in this entire discourse and was not expecting you to invalidate the entire argument just because SuiteSparse is also available under a commercial license. I would be certainly be very happy with a CMake/Bazel notice that GPL may apply when Ceres built with SuiteSparse is used. Anything to raise awareness. Again, lots of users are using Ceres and depending on things “just working” when they throw a few million (slightly exaggerating here) cost functions at Ceres, without realizing that Ceres without SuiteSparse would (currently) not be able to do this at all. This is totally different than OpenCV, where you might be able to rebuild the 3rd party dependency, ffmpeg, in non-GPL mode and barely notice the difference. Regarding 3, I can not disclose much more, but I know that the some of the maintainers were in private talks about a done and working MKL integration being upstreamed, and it was turned down for some maintenance burden reasons which IMHO should be dwarfed by this SuiteSparse GPL compliance problem, and the lack of alternatives. If you can make anything happen towards moving this forward, I would greatly appreciate it! |
You are contradicting yourself in the same sentence. Regardless, the case is absolutely the same and perfectly comparable: OpenCV does call into FFMPEG functionality. What else it is supposed to be doing? Other than that it is not clear why do you believe otherwise.
How exactly did you arrive at the conclusion that the sole presence of an option that lets the user choose whether GPL licensed software is used warrants a GPL banner? According to you, it is not relevant whether such an option is even enabled. However, this means that binary packages of Ceres that do not contain any traces of GPL software are also affected. Anything else would contradict your assertions.
Awareness of what exactly? Hypothetical GPL software use, performance loss, or both? Frankly speaking, at this point it is not clear what the goal of this discussion is. Also note that there is absolutely no obligation whatsoever to display a banner in a
This is a perfectly fine personal opinion, which however, lacks any foundation without any suggestions for improving the notice in the official documentation. Following the discussion, this is the most reasonable place to revise instead of messing around with the already complicated package configuration. Package configuration should be limited to build specific information not legal information.
This description is inaccurate and in fact deceptive:
Given these points and those brought up by Alex, I would also reject 1 and 2 as you suggested including the |
|
I feel like a lot of what I've said has been twisted into nonsense because of some misunderstandings (and I hope not malice), and that the discussion is getting quite unproductive.
Ceres ships SuiteSparse integration code. This code includes the GPL headers and directly calls functions from these headers. This integration code is thus GPL-tainted. Building Ceres with this integration code enabled makes the build of Ceres itself GPL, because Ceres will have references to symbols from a GPL library. If you're distributing code that uses GPL libraries, especially directly, as a first-class dependency, you have to be loud and clear about it, I don't know how to put it in more simpler terms. The user (as in a developer using Ceres-user) must be more clearly made aware of implications of this through the documentation -- it would help to have it more prominently mentioned in LICENSE, in the CMake cache option description for SuiteSparse, a dedicated licensing page in the docs site, etc.
Of course it matters. It extremely matters, because it determines the license of the resulting binary and whether references to GPL symbols are present in it.
Sorry, but that is extremely silly, I have not claimed this at all. When I was talking about the mere presence mattering of an option which controls if Ceres code for integrating SuiteSparse is being built, I was obviously talking about the need to make developer-users aware about this, not about the end application users. If I run clone and make of Ceres and its tests on an Ubuntu distribution, I will most likely end up with a GPL build without being clearly informed of that, and this is a problem I am trying to point out. Also, if developing on Linux and using a pre-packaged version of Ceres, I will also miss being informed of the GPL implications, because the only page which briefly mentions this issue is
No, for a certain class of problems, it simply doesn't. Some time ago, I tried waiting to see if a SuiteSparse-free Ceres can finish a pose graph optimization (which otherwise takes a couple of seconds with a SuiteSparse build), but I gave up waiting after a couple of days. |
|
@ojura I suggest you tune down your attitude that indeed turned the whole discussion very unproductive by at least two notches to keep the remaining discussion civilized. In my responses, I used your own statements to show the problems with the issue description and suggestions you provide here. No more and no less. |
|
Sorry if the post felt heated, but I felt some attitude from you too. I felt that you turned my statements upside down, put some words in my mouth I never said and then derived some really absurd statements from that. That was frustrating. Also, I never directly attacked you, while you said that my attitude turned the discussion very unproductive, which is a personal attack. That is not okay. In the end, the fact is that you end up with a binary with GPL symbols referenced in it if you build Ceres with the default options. And this is because Ceres is using a 1st class GPL dependency and building code to integrate it, unless specifically opted out. Prior to and in my last post, I did suggest several places where we could improve the documentation to make this licensing thing crystal clear to developer-users, as it really ought to be. Please give it a read later with a cooler head, with no hard feelings. Happy holidays! |
This issue effectively prevents (legal) commercial use of Ceres with SuiteSparse linked in (specifically CHOLMOD/Supernodal, which is GPL) as shipped by default with e.g. Ubuntu.
Can we do something about this? For example, there should be a notice which, if e.g.in CMake,
find_package(SuiteSparse)succeeds, that lets the user know that they are using Ceres under GPL.When a
ceres::Problemis instantiated without changing the default parameters, the default solver settings (which usually Just Work (TM) for larger problems) make use of SuiteSparse if available. So many users with larger problems depend on this without knowing.Also, if the user decides to rebuild Ceres and disable SuiteSparse in order to comply with GPL, they get punished with a huge performance hit. For example, formerly Google’s project, Cartographer SLAM, is quite popular for lidar mapping and navigation in mobile robotics. It uses Ceres for sparse pose graph optimization.
cartographer-project/cartographer_ros#247
cartographer-project/cartographer#971
Cartographer is licensed under an Apache 2 license, but in reality this is an illusion, because it requires Ceres to be built with SuiteSparse in order to be usable at all (enforcing this was contributed by me -- cartographer-project/cartographer#189 -- not knowing that this would turn Cartographer into GPL).
I know of several robotics companies which ship systems and software based on Cartographer that uses Ceres with SuiteSparse, and are unknowingly violating the GPL.
Could we use e.g. Intel’s MKL as a sparse linear algebra backend? I am not too happy about it being closed source, but currently I do not see another way to use Ceres and especially Cartographer under the terms of the license written on the lid - the Apache 2 license - legally.
The text was updated successfully, but these errors were encountered: