Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] LGPL questions

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] LGPL questions


Chronological Thread 
  • From: Phil Weir <>
  • To:
  • Subject: Re: [cgal-discuss] LGPL questions
  • Date: Fri, 12 Feb 2016 10:31:51 +0000
  • Authentication-results: mail2-smtp-roc.national.inria.fr; spf=None ; spf=Pass ; spf=Pass
  • Ironport-phdr: 9a23:bcvqsBUJ2x+gwwQOMgYeSaEHjILV8LGtZVwlr6E/grcLSJyIuqrYZhCPt8tkgFKBZ4jH8fUM07OQ6PC/Hzdeqs/f+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3CwN5K6zPF5LIiIzvjqbpq8KVOFsD3WT1SIgxBSv1hD2ZjtMRj4pmJ/R54TryiVwMRd5rw3h1L0mYhRf265T41pdi9yNNp6BprJYYAu3MVv9nFvkAUHxmbjh0t4XXskzIQgKLo3cdSW4LiQFgAg7f7Ri8UI2inDH9s79F2CiedfL7TKp8DSyi7qMtVxLpkg8BKjswtmDa3J8jxJlHqQ6s8kQsi7XfZ5uYYacmcw==

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

_______________________




Archive powered by MHonArc 2.6.18.

Top of Page