Re: [eigen] Switch to LGPL 3 ?

[ Thread Index | Date Index | More Archives ]

Hi again,

I did some investigation and found again this very useful table:

According to this table, the only license that prevents a project from using a 
LGPL3'd Eigen is the "GPL 2 only". All other licenses, including "GPL 2 or 
later" and "LGPL 2 only", are fine.

The problem is that two projects potentially interested in Eigen2 are "GPL 2 

- OpenBabel
- Cyrille's Krita plugins

I'm not too worried about Cyrille's Krita plugins as I guess there are only 
few copyright holders so he/they could relicense if he/they wanted to.

I'm much more worried about OpenBabel, because a relicensing depends on the 
good will of the OpenEye corporation which released the source code as GPL2 
several years ago. On the other hand, given the poor quality of the initial 
code they contributed, I guess most of it has been/will eventually be 
rewritten? Geoff, maybe if you explain them that most of the code they wrote 
has been rewritten and that nevertheless you were scrupulous enough to keep 
all their copyright lines, they might be understanding and accept to 
relicense at least to "GPL 2 or 3" ?



On Wednesday 23 January 2008 08:54:44 Benoît Jacob wrote:
> Hi List,
> Last time I proposed a switch to LGPL 3, the main objection was
> compatibility with KDE. Now that KDE is switching to LGPL3/GPL3, this
> objection vanishes.
> You probably saw my CC'd mail to the FSF discussion list. It is being held
> for moderation as I'm not a member, I don't know for how long, anyway I
> don't hope much anymore from it.
> I have looked at the LGPL text and I think I am confident enough that the
> needed changes have been applied to the LGPL, in order to make it usable
> for us.
> Quoting :
> > “The Library” refers to a covered work governed by this License, other
> > than an Application or a Combined Work as defined below. An “Application”
> > is any work that makes use of an interface provided by the Library, but
> > which is not otherwise based on the Library. Defining a subclass of a
> > class defined by the Library is deemed a mode of using an interface
> > provided by the Library. A “Combined Work” is a work produced by
> > combining or linking an Application with the Library. The particular
> > version of the Library with which the Combined Work was made is also
> > called the “Linked Version”.
> So far so good: the above definitions handle the non-linking case. Anyway,
> the
> following section handles explicitly the case of #included code:
> > 3. Object Code Incorporating Material from Library Header Files.
> > The object code form of an Application may incorporate material from a
> > header file that is part of the Library. You may convey such object code
> > under terms of your choice, provided that, if the incorporated material
> > is not limited to numerical parameters, data structure layouts and
> > accessors, or small macros, inline functions and templates (ten or fewer
> > lines in length), you do both of the following: a) Give prominent notice
> > with each copy of the object code that the Library is used in it and that
> > the Library and its use are covered by this License. b) Accompany the
> > object code with a copy of the GNU GPL and this license document.
> This is a bit annoying in my opinion, but keep in mind that in the case of
> a traditional linked library, there are even more annoying clauses and
> nobody seems to complain. I have a feeling that these clauses are often
> overlooked and nobody cares to enforce them, which is a perverse situation,
> but I'm not out there to solve all the problems of software licensing.
> So, OK to relicense?
> I'm interested in everybody's answers, especially Michael's as he holds a
> copyright on one existing file.
> Cheers,
> Benoit

Attachment: signature.asc
Description: This is a digitally signed message part.

Mail converted by MHonArc 2.6.19+