CGAL users discussion list

[Phil Weir <>]

Hello Patric and Maria,

Apologies for chipping in as an non-involved person, but I think I can 
see part of where the confusion is coming from:

The philosophical background to the GPL family of licenses comes from 
the "four freedoms" (http://www.gnu.org/philosophy/free-sw.en.html), so 
I think Maria's ambiguity in applying the LGPL is based in its purpose.

On 02/12/2016 10:06 AM, Patric Schmitz wrote:
> On 02/12/2016 06:29 AM, Maria Dubrovskaya wrote:
> > Concerning the 2nd point from my mail you didn't get completely,
> > I meant providing the last chosen CGAL features' versions
> > integration support. I read about it somewhere in a forum.
> Hmm I still don't know what you're referring to and can't find
> anything on 'CGAL versions integration support'. What is this
> supposed to be, some dynamic functionality loading / plugin
> mechanism? Or something that has to to with forward-compatible
> API? I can only be guessing, but I think the answer to your
> question 2. is no, regarding the licensing implications from
> using CGAL in your application.
I think this might be to do with the concept of being able to include 
'new features' in LGPL code -- this is about freedom for someone using 
your code to modify and improve the LGPL libraries, rather than any 
responsibility for the developer to ensure specific features can be 
incorporated, (whether added to CGAL by Geometry Factory or anybody 
else). Actually rewriting the LGPL library, with the new 
features/improvements they want, to continue working with your other 
binaries, is the job of the consumer modifying the library (although 
/actively/ using technical measures to block a modified LGPL library may 
be a bit different, at least in LGPL/GPLv3). Presumably, as long as the 
modified library continues to return sensible results for the calls you 
make, without altering the API, it is likely to keep working.

The 'four freedoms' don't say anything about a right to be able to run 
the newest upstream version against old code (i.e. right to forward 
compatibility) -- that would be a nightmare to maintain!
> > Probably it concerned the FAQ you sent to me
> > (http://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic).
> > By the way, the 1st point of the FAQ is what I don't get quite well.
> > If I understand correctly, I must build my application with
> > dynamical linking as well to allow user link against my application?
> > But my application doesn't a priori support the newer library
> > version, so that may just never work...
> > Do you see the sense of this?
> Applications cannot be linked against. The point this FAQ entry
> clarifies is about your question 4. wether you can link against
> CGAL statically. It says that you either link dynamically against
> the library, which is typically the case, and that does *not*
> impose any restrictions on your application.
>
> If you link statically against CGAL, you are required to supply
> your application's .o files so that the user is able to relink
> with a different version of the library, as he would be by just
> swawpping in another shared object file if using dynamic linking.
>
> This does not (necessarily) relate to newer versions of the
> library. It could just as well be a modified version of the same
> library version (or any other ABI-compatible version) which
> retains the user's right to modify the LGPL code your application
> is making use of.
As Patric says, this is to do with allowing modified library versions to 
be used (freedom to modify/improve) -- which, on a technical level, 
requires dynamic linking or access to the object files -- but the 
responsibility to make sure the improvements work correctly is still the 
responsibility of the person modifying.

All the best,
Phil

--
__________________________
Phil Weir | NUMA Engineering Services Ltd.
Block 1, Quayside Business Park,
Mill St, Dundalk,
Co. Louth, Ireland.
Tel: +353 42 9395821 | Fax: +353 42 9390220

_______________________