Writing an exception to LGPL for a C++ template library

[Benoît Jacob]

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

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.fsfeurope.org/pipermail/discussion/attachments/20061025/7a016096/attachment.pgp

[Federico Montesino Pouzols]

Hi Beno?t,

Post by Benoît Jacob
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.

[Benoit Jacob]

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).
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

[Federico Montesino Pouzols]

Post by Benoit Jacob
Thanks for your answers. The reasons why we were considering using the
- 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.

[Benoît Jacob]

Thanks a lot Federico for this explanation.

Following your advice, we're going GPL + exception following closely the eCos
exception.

Benoit

Post by Federico Montesino Pouzols

Post by Benoit Jacob
Thanks for your answers. The reasons why we were considering using the
- 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.
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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.fsfeurope.org/pipermail/discussion/attachments/20061029/ece0da67/attachment.pgp