Hi List,
We're developing a C++ template library and planning to release it under LGPL plus an exception. I'm writing in the hope that someone here can help us with properly formulating this exception.
The exception that we want to formulate is very simple:
We want to allow any software of any kind under any license to use our template library in any way, while remaining distributable under its own license.
But while we allow unrestricted _use_, we want to only allow _changes_ under the terms of the LGPL, so that back-contribution of changes is forced. This is why we're choosing the LGPL and not the BSD, for instance.
Our problem is that we aren't lawyers, so it's difficult to reach a correct formulation. One of us came up with this formulation:
As a special exception, you may consider instantiation of templates or use of macros or inline functions from this file en pair with using a normal linked library. Thus you can use it this way without causing the using part to be converted into the LGPL. This file itself is however always covered by the LGPL.
Any feedback on it would be much appreciated. We guess it should be reformulated, but don't know how.
Benoit
Hi Benoît,
On Wed, Oct 25, 2006 at 12:27:48PM +0200, Benoît Jacob wrote:
But while we allow unrestricted _use_, we want to only allow _changes_ under the terms of the LGPL, so that back-contribution of changes is forced. This is why we're choosing the LGPL and not the BSD, for instance.
I think what you want here is the following: LGPL-like behavior when someone is using using your templates as a classical old-good-times C library, and GPL-like behavior for anything else. I believe the best option is using GPL + linking exception. I would definitely consider the exception used in the GCC C++ std. library (and other packages such as GNU Common C++ and some of its derivatives):
The exception in the GCC C++ std. library is:
// 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.
In Common C++, it is extended and clarified like this:
// 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 exception applies only to the code released under the name GNU // Common C++. If you copy code from other releases into a copy of GNU // Common C++, as the General Public License permits, the exception does // not apply to the code that you add in this way. To avoid misleading // anyone as to the status of such modified files, you must delete // this exception notice from them. // // If you write modifications of your own for GNU Common C++, it is your choice // whether to permit this exception to apply to your modifications. // If you do not wish that, delete this exception notice.
HTH.
Hi Federico,
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).
The exception in the GCC C++ std. library is:
I am glad you mention it because this is something we have looked at, but we were left with a big question open: what would we have to change in the formulation of this exception in order to make it applicable to the LGPL instead of GPL ? Is such a transposition possible at all?
We would also have to modify it to apply to all software, not only libraries.
Benoit
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.
Thanks a lot Federico for this explanation.
Following your advice, we're going GPL + exception following closely the eCos exception.
Benoit
Le samedi 28 octobre 2006 20:02, vous avez écrit :
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.