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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
