On Wed, October 25, 2006 3:30 pm, Benoit Jacob wrote:
Thanks for your answers. The reasons why we were considering using the LGPL, not the GPL, are that:
- we need to make sure LGPL-licensed software (apps,libs,everything) can
use our library without any worry.
- we don't care too much if proprietary software uses our lib (though we
wouldn't rejoice about that either).
Both issues can be sorted out with a GPL + exception license. In general, using LGPL for C++ libraries is a bad idea -I would say. Besides the "lesser" aspect of the LGPL, it is obsolete in its language (when you have templates and methods implemented in headers, the division between the library and the application using it is not a matter of just linking anymore). In the obsolete language of the LGPL, when you use a template, you would be basically copying code.
Some FAQs about the libstdc++ "runtime exception" are answered here: http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html.
To the best of my knowledge, GPL + linking exception is the best way of extending the LGPL conditions for C++ libraries. Using an exception similar to that of libstdc++ you will of course allow using your library in proprietary applications. If you prefer to avoid that abuse, you could reformulate the exception so that it only allows the library to be used in GPL and LGPL (or a list of free licenses acceptable from your point of view) apps and libs.
It seems the eCos license 2.0 (http://www.gnu.org/licenses/ecos-license.html) is also a case of GPL + exception. This license however adds the restriction that source code of the app. using the library must be available as specified in section (3) of the GPL.