Re: [boost] Can a Boost library use a component like GMP and mfpr that have a LGPL license ?

Subject: Re: [boost] Can a Boost library use a component like GMP and mfpr that have a LGPL license ?
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-03-20 16:58:30

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