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: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-03-23 12:58:20

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