Can a Boost library use a component like GMP and mfpr that have a LGPL license ?
I am raising this issue for discussion because it seems to me that it is important to resolve this issue before development of the GTL library by Lucanus Simonson and others. I suspect this is not the only time this will crop up, especially with the two very well developed and refined 'big' multiprecision number libraries, GMP (http://gmplib.org) and mfpr (www.mfpr.org). Boost lacks any equivalent libraries (apart from some un reviewed, but probably functional, big integer offerings). GMP and mfpr have already been used within John Maddock's Boost.Math library, but only to calculate extremely accurate reference values, so *users* do not have to use GMP and mfpr. Fernando Cacciola wrote "While in the case of GTL, it is technically up to the user to pick up "their own" multiprecision number types, they actually can't do that without an external non-boost library since such number types do not exists in the SCL." I agree that it would be unfortunate to re-invent the wheel to produce our own (probably inferior) version of these components. So what do we do? Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost? IANAL but I feel this issue should be resolved and a decision recorded. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
I suspect this is not the only time this will crop up, especially with the two very well developed and refined 'big' multiprecision number libraries, GMP (http://gmplib.org) and mfpr (www.mfpr.org).
[...]
I agree that it would be unfortunate to re-invent the wheel to produce our own (probably inferior) version of these components.
So what do we do?
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
If these libraries are comfortable why do not just add some links to them in the boost web site and recommend them for users who may need this kind of features ? In the infortunate case where their APIs would be not suitable with boost concepts maybe an adaptation layer could be sufficient ? Kind regards, Herve
On Fri, Mar 20, 2009 at 09:46, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
Distributing together does not make a derivative work, so no permission is required (or even customary, near as I can tell) to create a "Boost with GMP & MPFR" package that users could download. I think having them become a pseudo-library is unrealistic, since their license doesn't fit the Boost guidelines and many users will already have them installed separately (for GCC or other packages). ~ Scott
Hi Paul,
So what do we do?
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
CGAL already distributes the Windows versions of gmp and mpfr, so I know they don't mind. OTOH, there are practical issues with distibuting them since they cannot be built in windows without the separate port provided by Brian Gladman: http://www.gladman.me.uk/
IANAL but I feel this issue should be resolved and a decision recorded.
At the very least I think it should be discussed whether is OK or not to depend on external components, to what extent, and how so. As pointed out by Sebastian Redl, there is some form of precedence to this in Boost.Python and Boost.MPI, both naturally requiring Python and MPI, resp. Those libs are specifically wrappers for the external components, while in the case under consideration (GTL), the external GMP (and potentially MPFR) libs are DEPENDENCIES, thus it could be argued that this is different than Boost.Python and Boost.MPI and the required functionality *should^* exist within Boost itself. A much more direct precedence for the GTL case is the Boost.Rational library. It depends on an integer concept and external big integers are reasonable and even almost required in practice. But the GTL case is slightly different because, IMO, the dependent concept should explicitely require unlimited precision since the library specifically uses it to *guarantee* robustness. Thus, unlike the case with Boost.Rational, users should be totally forbiden from using built-in types. They should be left with no choice but to pick some external component fulfilling the unlimited precision requirement, otherwise, GTL will have no choice but to fail to guarantee 100% robustness. From the POV of standarization of boost libraries (one of the principal goals), dependencies on libraries such as GMP or MPFR poses a problem since those libraries provide highly mature *C* interfaces, not C++ (there is a gmpxx wrapper lib but it is hardly used compared to the gmp C API). They can't and won't ever be standarized, at least not within the "C++" SCL (but they could theoretically be standarized in std C and so included in std C++) OTOH, producing a high quality Boost library equivalent in performance and functionality to GMP/MPFR is very very difficult since those GNU projects have been evolving and maturing for many years. It seems to me somewhat unrealistic to expect something like that in Boost. A different and much less ambitious goal could be to come up with a good C++ *interface* to *those* libraries. That is, C++ number types specifically designed to be implementable on top of a C API like that of GMP and MPFR. As to what to require to GTL, I think it should be allowed to depend on concepts which have no models on either native types nor standard library or boost components, even if that clearly indicates the need for an external library. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
Hi, Fernando Cacciola wrote:
A different and much less ambitious goal could be to come up with a good C++ *interface* to *those* libraries. That is, C++ number types specifically designed to be implementable on top of a C API like that of GMP and MPFR.
This is the approach we planned to take. In our geometry library (GGL) we want to optionally calculate with large number types as GMP or CLN. The GGL (or other geometry libraries who might take the same approach) is completely independant from GMP and from their license. It can just work together. We will work this out in the upcoming preview of GGL. We realize that it is not applicable for geometry alone, so we make it independant from it and might submit it as a separate, small, header-only library. The sample (link below) shows a numeric_adaptor, having a policy of either gmp, or just ieee types, or other big number types as cln (not worked out). Other policies might elaborate adaptive precision. See http://geometrylibrary.geodan.nl/num/numeric_adaptor.html Details might change of course, such as the place of the member variable in either adaptor or policy, but the sample will give the general idea. Regards, Barend Gehrels, Amsterdam Bruno Lalande, Paris
Paul A. Bristow wrote:
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
Is there any reason to require boost to be self-contained ? Why can't it depend on external libraries for some cases, especially if those libraries are already freely available and hugely popular, thus the chances that they are already present are high. I agree that it would be good not to expose this dependency through the API, though, so if it got replaced, API compatibility would be maintainable. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Paul A. Bristow wrote:
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
Is there any reason to require boost to be self-contained ? Why can't it depend on external libraries for some cases, especially if those libraries are already freely available and hugely popular, thus the chances that they are already present are high. I agree that it would be good not to expose this dependency through the API, though, so if it got replaced, API compatibility would be maintainable.
You mean, the way Boost.Regex can be configured to use IBM's ICU library for handling Unicode? And Boost.Python requires Python? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
Stefan Seefeld wrote:
Paul A. Bristow wrote:
Might we enter into discussion with GMP and mfpr developers to get explicit permission to package their library within Boost?
Is there any reason to require boost to be self-contained ? Why can't it depend on external libraries for some cases, especially if those libraries are already freely available and hugely popular, thus the chances that they are already present are high. I agree that it would be good not to expose this dependency through the API, though, so if it got replaced, API compatibility would be maintainable.
You mean, the way Boost.Regex can be configured to use IBM's ICU library for handling Unicode? And Boost.Python requires Python?
Yes, there are certainly lots of examples of external dependencies. Another example is my boost.xml sandbox project, which (right now) depends on libxml2, and we had long discussions in the past whether that was a good idea or not. The overall agreement was that it was, as long as it could be replaced by other 'back-ends' without affecting the API. That's what I was alluding to in my comments above. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: 20 March 2009 22:46 To: boost@lists.boost.org Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr that have a LGPL license ?
Is there any reason to require boost to be self-contained ? Why can't it depend on external libraries for some cases, especially if those libraries are already freely available and hugely popular, thus the chances that they are already present are high. I agree that it would be good not to expose this dependency through the API, though, so if it got replaced, API compatibility would be maintainable.
You mean, the way Boost.Regex can be configured to use IBM's ICU library for handling Unicode? And Boost.Python requires Python?
Yes, there are certainly lots of examples of external dependencies.
I understand that there are dependencies, but are those libraries being used in items that are being *sold*? Lots of people are no doubt using Boost.Python, but are they selling products using it? The proposed GTL sounds to me as though it is a prime candidate for inclusion in actual 'Sat-Navy' products. Does this make any difference? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
I understand that there are dependencies, but are those libraries being used in items that are being *sold*?
How do copyleft licenses cause a problem with selling software? Especially "non-viral" ones such as the LGPL?
On Sun, Mar 22, 2009 at 05:42:47PM -0000, Paul A. Bristow wrote:
Yes, there are certainly lots of examples of external dependencies.
I understand that there are dependencies, but are those libraries being used in items that are being *sold*?
Lots of people are no doubt using Boost.Python, but are they selling products using it?
The proposed GTL sounds to me as though it is a prime candidate for inclusion in actual 'Sat-Navy' products.
Does this make any difference?
Not in my view. Why do you ask the question? Is there some reason you think it might matter whether the Boost libraries appear in products being sold? Cheers, -Steve
Steve M. Robbins wrote:
On Sun, Mar 22, 2009 at 05:42:47PM -0000, Paul A. Bristow wrote:
Yes, there are certainly lots of examples of external dependencies. I understand that there are dependencies, but are those libraries being used in items that are being *sold*?
Lots of people are no doubt using Boost.Python, but are they selling products using it?
The proposed GTL sounds to me as though it is a prime candidate for inclusion in actual 'Sat-Navy' products.
Does this make any difference?
Not in my view. Why do you ask the question? Is there some reason you think it might matter whether the Boost libraries appear in products being sold?
The potential problem Paul is asking us to consider is not the boost library but the dependent non-boost library, such as GMP in the case of GTL. AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is no problem in using them in commercial products, even closed source applications (provided a copy of the license is distributed with said product), so I don't think there should be any restriction on allowing Boost libs to depend on LPGL libs. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
Steve M. Robbins wrote:
On Sun, Mar 22, 2009 at 05:42:47PM -0000, Paul A. Bristow wrote:
Yes, there are certainly lots of examples of external dependencies. I understand that there are dependencies, but are those libraries being used in items that are being *sold*?
Lots of people are no doubt using Boost.Python, but are they selling products using it?
The proposed GTL sounds to me as though it is a prime candidate for inclusion in actual 'Sat-Navy' products.
Does this make any difference?
Not in my view. Why do you ask the question? Is there some reason you think it might matter whether the Boost libraries appear in products being sold?
The potential problem Paul is asking us to consider is not the boost library but the dependent non-boost library, such as GMP in the case of GTL.
AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is no problem in using them in commercial products, even closed source applications (provided a copy of the license is distributed with said product), so I don't think there should be any restriction on allowing Boost libs to depend on LPGL libs.
The LGPL requires you to construct your code in such a way that you can relink with a new library. It also requires you to allow users to reverse engineer the code for debugging. Commercial users of Boost may not like those terms. Cheers, Walter Landry wlandry@caltech.edu
On Sun, 22 Mar 2009 23:22:10 -0700 (PDT), Walter Landry <wlandry@caltech.edu> wrote:
Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
The potential problem Paul is asking us to consider is not the boost library but the dependent non-boost library, such as GMP in the case of GTL.
AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is no problem in using them in commercial products, even closed source applications (provided a copy of the license is distributed with said product), so I don't think there should be any restriction on allowing Boost libs to depend on LPGL libs.
The LGPL requires you to construct your code in such a way that you can relink with a new library. It also requires you to allow users to reverse engineer the code for debugging. Commercial users of Boost may not like those terms.
My company, for example, would be interested in the BGL, but quite unable to include an LGPL library, since our copy protection mechanism kills the application if it detects a debugger. This would be a license violation. (We probably wouldn't need bignum functionality. As long as the BGL can be used without the bignum libraries, we'd probably be happy.) Sebastian
On Mon, 23 Mar 2009 10:53:19 +0100, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
My company, for example, would be interested in the BGL, but quite unable to include an LGPL library, since our copy protection mechanism kills the application if it detects a debugger. This would be a license violation. (We probably wouldn't need bignum functionality. As long as the BGL can be used without the bignum libraries, we'd probably be happy.)
We'd also enjoy having a license as flexible as possible. I don't want to waste time brainstorming all the customer's use cases and spending lawyer fees to validate the license compatibility. Restrictions incur costs. -- EA http://www.bureau14.fr/
Sebastian Redl wrote:
AFAICT, in the case of LPGPled libs such as GMP and MPFR, there is no problem in using them in commercial products, even closed source applications (provided a copy of the license is distributed with said product), so I don't think there should be any restriction on allowing Boost libs to depend on LPGL libs.
The LGPL requires you to construct your code in such a way that you can relink with a new library. It also requires you to allow users to reverse engineer the code for debugging. Commercial users of Boost may not like those terms.
My company, for example, would be interested in the BGL, but quite unable to include an LGPL library, since our copy protection mechanism kills the application if it detects a debugger. This would be a license violation. (We probably wouldn't need bignum functionality. As long as the BGL can be used without the bignum libraries, we'd probably be happy.)
Huh, they basically exclude copy protection in the terms of their license? I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake? Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. That can be performed with 64 bit unsigned integer if you keep track of the sign seperately. The only other places where I need high precision are the computation of the sweep-line intercept for comparing the y coordinates of segments that intersect the sweep-line and the actual computation of intersection points. Instead of using mp rational I could provide robust calculations "by hand" if I implement enough of what is in a multi-precision rational to get by or come up with some tricks. Long double only barely fails in my pseudo-exhasutive testing of line intersection computation. Since its result is only off by a small margin I could potentially detect these errors and handle them specially. The important aspect of the intersection computation is that when it snaps to the the integer grid both line segments must intersect that integer grid box. This check can be performed with point on-above-or-below line segment based degree-2 predicates (on-above-or-below can be implemented with slope comparison) that don't need multi-precision or rationals and then I can search adjacent grid boxes for one that meets the criteria for correctness if the check fails for the one computed by floating point approximation. Happily I have the ability to validate such fancy (read error-prone) code against the known correct big-num reliant implementation I already have. Luke
Sebastian Redl wrote:
My company, for example, would be interested in the BGL, but quite unable to include an LGPL library, since our copy protection mechanism kills the application if it detects a debugger. This would be a license violation. (We probably wouldn't need bignum functionality. As long as the BGL can be used without the bignum libraries, we'd probably be happy.)
Huh, they basically exclude copy protection in the terms of their license? They require that it is still possible to debug the LGPLed library in
Simonson, Lucanus J wrote: the context of the combined work. If there's a debugger killer as part of the copy protection (and every effective CP needs one), that's obviously not possible.
I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake?
Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry libraries called that?
Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. I'm fairly certain that I don't need that. So it's a question of how modular the library is.
Sebastian
Sebastian Redl wrote:
Sebastian Redl wrote:
My company, for example, would be interested in the BGL, but quite unable to include an LGPL library, since our copy protection mechanism kills the application if it detects a debugger. This would be a license violation. (We probably wouldn't need bignum functionality. As long as the BGL can be used without the bignum libraries, we'd probably be happy.)
Huh, they basically exclude copy protection in the terms of their license? They require that it is still possible to debug the LGPLed library in
Simonson, Lucanus J wrote: the context of the combined work. If there's a debugger killer as part of the copy protection (and every effective CP needs one), that's obviously not possible.
I didn't trust the LGPL when I read it because it was obviously written by a lawyer. Did you mean GTL and type BGL by mistake?
Yes. I typed BGL for Boost Geometry Library. Isn't one of the geometry libraries called that?
I think it's called ggl, generic geometry library. Boost geometry library would be confusing.
Ideally I'd like to eliminate dependence on big-num for robustness, for performance reasons if not license concerns, but this requires some fancy programming. For instance, the degree-2 predicate of slope comparison requires 65 bits when the input is 32 bit coordinates. I'm fairly certain that I don't need that. So it's a question of how modular the library is.
Well, I have no explicit dependency on big num, just provide the ability to override non-robust arithmetic by specifying a big num data type. I have no direct code dependency on any external library, only the stl. What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information. Thanks, Luke
Simonson, Lucanus J wrote:
What features of a geometry library do you need? I'm always interested to know so that I can focus on the pieces that are (will be) used the most. You can tell me off list if you prefer not to advertise this information.
It's pretty vague at this time. We've been doing without, and looking at it to optimize some algorithms that currently work on rasters. We're mostly looking for quickly doing many, many polygon intersections in a huge floating point coordinate system. (Transformed to integer rasters at a given resolution.) The whole thing is about geographic data. Sebastian
Sebastian Redl wrote:
It's pretty vague at this time. We've been doing without, and looking at it to optimize some algorithms that currently work on rasters. We're mostly looking for quickly doing many, many polygon intersections in a huge floating point coordinate system. (Transformed to integer rasters at a given resolution.) The whole thing is about geographic data.
Do you need map overlay, or is polygon intersection enough? I have both, but most other libraries only provide intersection. Luke
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Sebastian Redl Sent: Monday, March 23, 2009 2:01 PM To: boost@lists.boost.org Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr that have a LGPL license ?
Huh, they basically exclude copy protection in the terms of their
license? They require that it is still possible to debug the LGPLed library in the context of the combined work. If there's a debugger killer as part of the copy protection (and every effective CP needs one), that's obviously not possible.
I assume you are referring to the "Combined Works" section of the LPGL. This is the only paragraph I can find containing the string "debug". * * 4. Combined Works. * You may convey a Combined Work under terms of your choice that, * taken together, effectively do not restrict modification of the * portions of the Library contained in the Combined Work and * reverse engineering for debugging such modifications, if you * also do each of the following: * The term "Library" means "the library that is licensed under the LGPL". Note that the wording says >debugging< and NOT a >debugger<. Debugging can be carried out in different ways. For instance, the library can be instrumented using printf/cout. While the ability to run a debugger is certainly convenient, I fail to see how this mandates it. Some may object to the reverse engineering clause but its only an issue if reverse engineering is actually needed. If you say up front how you use the library then there should be no need to reverse engineer anything.
Sebastian _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Sebastian Redl wrpte:
Huh, they basically exclude copy protection in the terms of their license? They require that it is still possible to debug the LGPLed library in the context of the combined work. If there's a debugger killer as part of the copy protection (and every effective CP needs one), that's obviously not possible.
In the case of DRM, the law in some countries requires to provide information for interoperability on demand anyway, so what the LGPL requires is actually required for any software in those countries.
On Sun, Mar 22, 2009 at 10:37:48PM -0200, Fernando Cacciola wrote:
Steve M. Robbins wrote:
On Sun, Mar 22, 2009 at 05:42:47PM -0000, Paul A. Bristow wrote:
Yes, there are certainly lots of examples of external dependencies. I understand that there are dependencies, but are those libraries being used in items that are being *sold*?
Lots of people are no doubt using Boost.Python, but are they selling products using it?
The proposed GTL sounds to me as though it is a prime candidate for inclusion in actual 'Sat-Navy' products.
Does this make any difference?
Not in my view. Why do you ask the question? Is there some reason you think it might matter whether the Boost libraries appear in products being sold?
The potential problem Paul is asking us to consider is not the boost library but the dependent non-boost library, such as GMP in the case of GTL.
The way I read Paul's question was roughly: Even though Boost library A has external dependencies, it doesn't matter since no-one is selling products based on it. Proposed library B, on the other hand, may be used commercially so we need to examine its external dependencies more carefully That may not have been the intent. If it was, however, it seems to me curious to place additional restrictions on proposed library B. I don't see why Boost ought to be concerned with the context in which a proposed library might be used. My 2 cents, -Steve
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steve M. Robbins Sent: 28 March 2009 09:36 To: boost@lists.boost.org Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr that have a LGPL license ?
On Sun, Mar 22, 2009 at 10:37:48PM -0200, Fernando Cacciola wrote:
Steve M. Robbins wrote:
On Sun, Mar 22, 2009 at 05:42:47PM -0000, Paul A. Bristow wrote:
Yes, there are certainly lots of examples of external dependencies. I understand that there are dependencies, but are those libraries being used in items that are being *sold*?
Lots of people are no doubt using Boost.Python, but are they selling products using it?
The proposed GTL sounds to me as though it is a prime candidate for inclusion in actual 'Sat-Navy' products.
Does this make any difference?
Not in my view. Why do you ask the question? Is there some reason you think it might matter whether the Boost libraries appear in products being sold?
The potential problem Paul is asking us to consider is not the boost library but the dependent non-boost library, such as GMP in the case of GTL.
The way I read Paul's question was roughly:
Even though Boost library A has external dependencies, it doesn't matter since no-one is selling products based on it. Proposed library B, on the other hand, may be used commercially so we need to examine its external dependencies more carefully
Correct.
That may not have been the intent. If it was, however, it seems to me curious to place additional restrictions on proposed library B. I don't see why Boost ought to be concerned with the context in which a proposed library might be used.
Well I was only asking if anyone was concerned. I feel we might be concerned if the effect was that the library was not used. This would be a waste of time. It would also be waste of time if it was decided at the review stage that the licensing implications make it unacceptable as a Boost library. Hence raising the question now seemed prudent. I get the sense that a few would-be commercial uses are concerned about this. But that others suggest packaging may make it possible to use with other license-OK GMP-like packages. At least, there seems little likelihood that GMP would act 'aggressively' - there seem to be people using it in similar situations. But it still is not the ideal situation as other libraries where there is clearly no need to get lawyers involved - we can just say "everything has the Boost license". However, there seems to be little enthusiasm for re-inventing a package that GMP and mpfr seems to have solved well - just to get a Boost license. So perhaps we can consider the matter decided? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com E-mail message checked by Spyware Doctor (6.0.0.386) Database version: 5.12060 http://www.pctools.com/uk/spyware-doctor-antivirus/
participants (15)
-
Barend Gehrels -
Edouard A. -
Eric Niebler -
Fernando Cacciola -
herve martin -
kjell_elster＠hotmail.com -
Mathias Gaunard -
Paul A. Bristow -
Schrader, Glenn -
Scott McMurray -
Sebastian Redl -
Simonson, Lucanus J -
Stefan Seefeld -
Steve M. Robbins -
Walter Landry