Re: Libpropc++

[Chris Vine <chris cvine freeserve co uk>]

On Thursday 18 August 2005 11:38, Foster Gareth wrote:
> > Since template code cannot be 'separated' from the rest of a program
> > into a shared library, all the files that depend on a
> > template library
> > (such as, in fact, libsigc++) will have to be open-sourced in
> > order to
> > comply with the terms of the LGPL. This does indeed implicate
> > that you'd
> > have to open-source at least a part of your program in order
> > to be able
> > to use libsigc++.
>
> I've heard about this problem in the context of other open source
> libraries. Does anyone know if there is there any scope for this being
> addressed in the forthcomming C++ standard, is it even on the agenda for
> that revision or perhaps the next?

Did you really mean addressing this in "the C++ standard"?  You just need to 
address it by employing an appropriate licence.

Header and source files in libstdc++ (as supplied with gcc) apply the GPL with 
a special exemption to cover executable programs compiled from source code 
using it, in the following terms:

  As a special exception, you may use this file as part of a free software
  library without restriction.  Specifically, if other files instantiate
  templates or use macros or inline functions from this file, or you compile
  this file and link it with other files to produce an executable, this
  file does not by itself cause the resulting executable to be covered by
  the GNU General Public License.  This exception does not however
  invalidate any other reasons why the executable file might be covered by
  the GNU General Public License.

This is a modified GPL rather than a modified LGPL, I think because no-one was 
very sure what the LGPL means anyway, whereas it was thought that allowing 
linking (static or dynamic), macros, inline functions and template 
instantiation without causing the result to be governed by the GPL was 
understood by anyone writing C++ programs.  On the other hand the first 
sentence of the "special exception", in referring to using it as part of "a 
free software library", does not make much sense either, since the remainder 
of the "special exception" is concerned with the use of the library to create 
an executable program.

Section 5 of the LGPL says this:

  "5. A program that contains no derivative of any portion of the
  Library, but is designed to work with the Library by being compiled or
  linked with it, is called a "work that uses the Library".  Such a
  work, in isolation, is not a derivative work of the Library, and
  therefore falls outside the scope of this License.

  However, linking a "work that uses the Library" with the Library
  creates an executable that is a derivative of the Library (because it
  contains portions of the Library), rather than a "work that uses the
  library".  The executable is therefore covered by this License.
  Section 6 states terms for distribution of such executables.

  When a "work that uses the Library" uses material from a header file
  that is part of the Library, the object code for the work may be a
  derivative work of the Library even though the source code is not.
  Whether this is true is especially significant if the work can be
  linked without the Library, or if the work is itself a library.  The
  threshold for this to be true is not precisely defined by law.

  If such an object file uses only numerical parameters, data
  structure layouts and accessors, and small macros and small inline
  functions (ten lines or less in length), then the use of the object
  file is unrestricted, regardless of whether it is legally a derivative
  work.  (Executables containing this object code plus portions of the
  Library will still fall under Section 6.)

  Otherwise, if the work is a derivative of the Library, you may
  distribute the object code for the work under the terms of Section 6.
  Any executables containing that work also fall under Section 6,
  whether or not they are linked directly with the Library itself."

The point arising here is that section 5 of the licence claims that any 
program which links with, or uses non-trivial macros or inline functions, is 
a "derivative" to be released under section 6, and section 6 requires the 
object code of the program to be freely copiable (ie non-proprietary) unless 
it only links dynamically with the LGPLed library by "a suitable shared 
library mechanism" .  For templates, with most compilers this is probably 
impossible.  With those which support the export keyword it may be possible 
to separate out object files in this way, although I doubt it.

What a load of mumbo-jumbo.  The LGPL is a masterpiece of unintelligibility.

Under English law (I do not know about others) authors can release their code 
on whatever terms they want (unless they have assigned the copyright or have 
developed the code in the course of their employment).  To deal with the 
template problem a library can presumably be released under a modified LGPL 
which adds "templates of any length" after "small macros and small inline 
functions (ten lines or less in length)", or it can be released under a 
libstdc++-like "GPL with exceptions", allowing unrestricted linking and/or 
unrestricted template instantiation when creating executables.

Probably libsigc++ ought to do this (I think libsigc++-2 has one or possibly 2 
authors).  I do not imagine the author(s) intend it only to be usable by 
programs which release their source code.  A cautious developer of 
proprietary code would not use libsigc++ as it stands (probably he should use 
the boost equivalent which is on BSD-type terms).

glibmm uses some but not many templates (Glib::RefPtr comes to mind).  It is 
an interesting thought therefore whether it (and so gtkmm) may be used by 
non-GPL code.

Chris