Weekly Edition
Return to the Press page
| |||||||||||||
LGPL 2.1, Qt 4.5 and C++ templates
George Makrydakis
investigates some potential problems in using the LGPL v2.1 license
with C++ libraries.
"But I have not seen in the FAQ, so far, a series of licensing issues related to the unmodified LGPLv2.1 license proposed. One of these issues has to do with C++ templates for starters. While it is true that Qt 4.4 right now, does not use templates for signals and slots, it does have templates in container classes. Does an unmodified LGPLv2.1 - I assume that this is their intent, from what comes out of the current FAQ and republished by all other websites - take into consideration the use of C++ templates and template metaprogramming techniques by third party code, when instantiating these LGPLv2.1 templates in a non LGPLv2.1 license model (even OSI compliant)? C++ template instantiation is known for actually nesting code inside the end user code in ways that transcend the wording of an unmodified LGPL 2.1 license."
(Thanks to Martin Langsjoen).
(Log in to post comments)
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 19:34 UTC (Thu) by boudewijn (subscriber, #14185) [Link]
It's a bit of a storm in a teacup, one that, I bet, nobody had foreseen.
After all, gtkmm doesn't advertise an exception clause either. But it is possible, of course, that that C++ library doesn't have any templates or inlines in there.
Anyway, see http://labs.trolltech.com/blogs/2009/01/14/nokia-to-licen...
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 21:33 UTC (Thu) by aseigo (guest, #18394) [Link]
It's one of the more unique things about working in the Qt world: every
single choice made is scrutinized with extreme zeal and no prejudice. Where some other projects get simple passes, Qt and KDE tend to come under extreme scrutiny.
The good side of this is that potential problems get caught and we are
The down side of this is that too often time and energy gets wasted
This will all get straightened away before the 4.5.0 release, so any
Also, I believe that most/all of the non-trivial bits of inlined code are
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 5:11 UTC (Fri) by tajyrink (subscriber, #2750) [Link]
I don't think there is any conspiracy... everyone can just cool down. The discussion in the other thread claiming Qt as superior or not was quite pointless, and now would be good time to stop arguing (about things that are matter of opinion) and start wondering about all the great things that G-world & Qt can share and what can be added to Qt when the community can actually participate into it to a greater extent.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 23:22 UTC (Thu) by ikm (subscriber, #493) [Link]
The link said: "We're really, really sorry, but there's nothing here!". I think it describes the whole topic quite fully.
Macros Posted Jan 15, 2009 19:47 UTC (Thu) by endecotp (guest, #36428) [Link]
Are templates any more problematic than macros in C headers?
It's matter of scale Posted Jan 15, 2009 23:59 UTC (Thu) by khim (subscriber, #9252) [Link] While there are exist macropackages which are as problematic as C++ templates (boost metaprogramming package, for example) they are quite rare and usually it's easy to see that you are using such a package. But templates are 100 times more pervasive in C++ world and so it's easy to just forget about such problems. Nokia is aware of the problem - that's good.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 19:53 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] There are two cases: the template is expanded to an inline function, or the template is expanded to a non-inline function.If it's inline, then the following text from LGPLv2.1 is relevant: 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.)If it's non-inline, then the normal mode of operation of gcc is to produce an expansion of the function as a separate function in the same object file, marked as COMDAT so that the linker will eliminate all copies but one. But the problem is that the object file will contain a non-inline function that might be bigger than ten lines. Partly for this reason, some time ago libstdc++ changed from LGPL2.1 to GPL2 with an exception; the exception language makes the libstdc++ licensing more permissive than LGPL2.1 licensing would have been. As the author of the linked-to article makes clear, LGPLv3 fixes this problem, and as best I can tell is strictly more permissive than LGPLv2.1, so even those who don't like some provisions of GPLv3 might want to consider its use. There is a workaround that is possible; you can compile your code with the -fno-implicit-templates option, then produce separate code that explicitly expands the needed templates, and places them in a separate object file. Doing this right can be a pain, because each template expansion has to be identified and arranged for. You then achieve a clean separation between "code that is part of the library" and "code that uses the library". This might be the right remedy for people who are legally cautious and need to deal with an LGPL2.1 C++ library that has templates. But sometimes you'd like a feature that GCC doesn't have: no implicit templates for some templates (those that are LGPL), but automatic template expansion for other templates (those where licensing isn't a problem).
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 19:57 UTC (Thu) by ncm (subscriber, #165) [Link]
What one might like better is a compiler option that defers all template instantiation to link time, so that the ".o" files provided for the program contain no template instantiations.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 23:16 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Sun had that (a repository for template expansion at link time), but it was a royal pain in the ass to use; your build was always getting fsck'd by a corrupt repository, or the database would wind up locked.g++ does have the -frepo option, but it should be considered experimental.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 0:28 UTC (Fri) by ncm (subscriber, #165) [Link]
It would only be needed when generating the ".o" files to distribute at release time, along with the program, in compliance with the LGPL, so any inconvenience would be well contained.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 15:59 UTC (Fri) by elanthis (guest, #6227) [Link]
C++0x is adding an official feature for this called "extern templates."
G++ had had that feature for a few releases now, too.
Not only might it help with this scenario, but it also _vastly_ improves compile times in many cases, as the compiler doesn't have to reinstantiate each template in every compilation unit.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 20:05 UTC (Fri) by ncm (subscriber, #165) [Link]
"extern template" is a feature of C++98, unchanged in C++0x. It's not universally implemented yet. The standard doesn't say how to implement it. It would be surprising if it helped much here, particularly if the LGPL library template components are not declared "extern". I would also be surprised to find it helping much with compile times. Its real purpose appears to be to help library vendors avoid exposing their source code to library users.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 16:18 UTC (Fri) by robert_s (subscriber, #42402) [Link]
...so you'd need an optimizing compiler to run every time a program is linked.
Seriously, one of the points of templates is it allows a compiler to optimize (or even implement) different instantiations completely differently. You would need a compiler built into your linker.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 19:56 UTC (Fri) by ncm (subscriber, #165) [Link]
Hey, guess what! You do have an optimizing compiler available when you link C++ programs. Try linking a C++ program using just <tt>ld</tt>, sometime.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 16, 2009 10:41 UTC (Fri) by mmutz (guest, #5642) [Link]
> There is a workaround that is possible; you can compile your code with
> the -fno-implicit-templates option, then produce separate code that > explicitly expands the needed templates, and places them in a separate > object file.
How can this fly in the face of combining proprietary code (MyT) with LGPL
Interesting problem, indeed.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 24, 2009 4:07 UTC (Sat) by vonbrand (subscriber, #4458) [Link] The problem here (AFAICS) is not so much legal as technical: If my library's code is in templates, and I fix a template, having the object for the rest of the program won't get the fixed template. This way you really aren't replacing the library with a new version. I haven't looked at the "expanded templates in separate object files", but if a user has no way to recreate them, it makes no technical sense either.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 25, 2009 22:27 UTC (Sun) by landley (guest, #6789) [Link]
> As the author of the linked-to article makes clear, LGPLv3 fixes this
> problem, and as best I can tell is strictly more permissive than > LGPLv2.1, so even those who don't like some provisions of GPLv3 might > want to consider its use.
Except that LGPLv3 is convertible to GPLv3 only, and is thus strictly incompatible with GPLv2. (Unless I'm misreading?)
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 15, 2009 19:56 UTC (Thu) by socket (guest, #43) [Link] This reminds me of a lesser-known variation on the GPL I came across a couple years ago, inspired by exactly the same question of metaprogramming. Franz, maker of a Common Lisp environment, has some LGPL'd lisp code, and has written their own preamble to the LGPL which attempts to address what they see as C-centric tunnel vision in the LGPL.It's only a few paragraphs -- much less than a screenful, and worth a read for how they try to interpret the license so it's coherent in a lisp context. Given Stallman's own knowledge of Lisp and metaprogramming, I'm surprised the LGPL is so C-centric. I know he discourages the use of the LGPL, but it almost makes me wonder whether the ambiguity is deliberate.
LGPL 2.1, Qt 4.5 and C++ templates Posted Jan 24, 2009 4:14 UTC (Sat) by vonbrand (subscriber, #4458) [Link] This LISP clarification sounds wery much an OOP idea in the lines of "subclasses don't inherit the license". I don't see anything particularly LISPy in this, just bog-standard (by now) OO, which just wasn't the rave when (L)GPL were written.
Almost all languages OTHER than C have this issue Posted Jan 15, 2009 20:45 UTC (Thu) by dwheeler (guest, #1216) [Link] Almost all languages OTHER than C have issues with re-linking and templates, beyond those presented by C, and this keeps getting solved-again-differently by different language communities. A more-standard interpretation/solution would be nice!The GNAT Modified GPL is widely used among Ada developers, and the Franz preamble has many Lisp users. The Wikipedia article on GPL linking exceptions points to some relevant discussion.
Almost all languages OTHER than C have this issue Posted Jan 15, 2009 21:34 UTC (Thu) by aseigo (guest, #18394) [Link]
> A more-standard interpretation/solution would be nice!
Agreed; when intention and legal verbage don't line up nicely due to
Almost all languages OTHER than C have this issue Posted Jan 15, 2009 23:18 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]
The FSF already revisited the legal verbiage, and LGPLv3 doesn't have the problems mentioned in the article.
<p> Unfortunately, there's been so much FUD spread that many are staying away from GPLv3/LGPLv3 based on misconceptions.
|
|||||||||||||