Can a Boost library use a component like GMP and mfpr that have a LGPL license ?

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Can a Boost library use a component like GMP and mfpr that have a LGPL license ?

pabristow
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
[hidden email]



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

herve martin
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Semestersvar

Kjell Elster

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Scott McMurray-2
In reply to this post by pabristow
On Fri, Mar 20, 2009 at 09:46, Paul A. Bristow <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Semestersvar

Kjell Elster

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Fernando Cacciola-2
In reply to this post by pabristow
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Stefan Seefeld
In reply to this post by pabristow
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...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Eric Niebler
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Stefan Seefeld
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...

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

pabristow
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
On
> Behalf Of Stefan Seefeld
> Sent: 20 March 2009 22:46
> To: [hidden email]
> 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
[hidden email]





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Mathias Gaunard-2
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?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Steve M. Robbins-2
In reply to this post by pabristow
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Fernando Cacciola-2
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Walter Landry-4
Fernando Cacciola <[hidden email]> 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
[hidden email]
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Redl

On Sun, 22 Mar 2009 23:22:10 -0700 (PDT), Walter Landry
<[hidden email]> wrote:

> Fernando Cacciola <[hidden email]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Edouard A.
On Mon, 23 Mar 2009 10:53:19 +0100, Sebastian Redl
<[hidden email]> 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/
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Simonson, Lucanus J
In reply to this post by Sebastian Redl
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 impor
 tant 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Redl
Simonson, Lucanus J 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
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Simonson, Lucanus J
Sebastian Redl wrote:

> Simonson, Lucanus J 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
> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Redl
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12