GPL with the Classpath exception - clarification needed

Philippe Verdy verdy_p at wanadoo.fr
Wed Mar 25 20:03:20 UTC 2009


Wilson, Andrew [mailto:andrew.wilson at intel.com] wrote:

> Philippe Verdy [mailto:verdy_p at wanadoo.fr] wrote:
> 
> > For a library (including those written in Java), I think 
> however that 
> > it's simpler to use the LGPL (which allows more freedom) 
> than the GPL 
> > with ClassPath Exception (which is more restrictive in the kind of 
> > linking permitted).
> 
> Using LGPL for object-oriented languages may appear simpler, 
> but it can lead to unintended consequences.  The LGPLv2.1 
> limitation on header files to contain no more than "small 
> macros and small inline functions (ten lines or less in 
> length)" is a spectacular mismatch with good coding practice 
> in object-oriented languages such as C++ STL where you want 
> to make liberal use of templates.
> Write macros/inline function definitions longer than ten 
> lines, and you (probably inadvertently) apply LGPLv2.1 to any 
> work using the library, while templates aren't mentioned at 
> all and may or may not be excepted.
> 
> FSF took a step toward fixing this mismatch in LGPLv3 by 
> adding "templates"
> but kept the ten-line limit in header files, above which it 
> is allowed to convey a work compiled using such LGPLv3 header 
> files under a non-free license, but mandatory to include the 
> full text of LGPLv3 and GPLv3 with such works.
> 
> So, there still isn't much "simple" about using LGPL (either 
> version) with an OO library.
> 
> Andy Wilson
> Intel open source technology center

C++ templates are simply an error for me, including in terms of conception
and separation/isolation of layers.

There's no demonstrated benefit in its excessive use of multiple
inheritance, in the way it has been used in the STL.

Java can demonstrate that this is not needed.

Note that this STL design has been abandoned also in .Net, by implementing
more useful concepts: interfaces separated from a single class inheritance.
The same is also true for the Microsoft COM and ActiveX technologies or in
Corba and all other technologies for interactions between heterogeneous or
remote systems. The fundamental key is the interface that allows such
isolation. For working with a LGPL library, all you need is to define this
interface, that must be disclosed and is indemedant of its implementation in
actual classes.

But remember that we were speaking about Java when speaking about the
Classpath exclusion. Where does the LGPL affect Java-written libraries so
that it would not work or would render an application using it fully GPL
licenced with all its requirements?

Even though I've learnt to use C++ since its origin (when it was not even
standardized) and also C since long when there was also still no ANSI
standard, I have always disliked C++.

And even if I use C++ today, I strictly NEVER use the STL, but prefer using
much more portable frameworks that do not enve use the multiple inheritance,
and can use C++ templates only in a limited (but largely sufficient) way,
like it is done in Java, C# or other languages that can support variant
types, introspection and modeling with interfaces and separation from the
implementation (with lots of advantages in terms of choices of deployment).





More information about the License-discuss mailing list