Discussion:
(L)GPL and C++ templates issue
(too old to reply)
Maciej Sobczak
2004-10-18 20:32:05 UTC
Permalink
Hi,

I think this is a good forum to ask this question. The problem affects
C++ programmers that release libraries with LGPL licence and those who
use such libraries in non-GPL products.

Let's imagine a library containing some template definitions. The
library has a LGPL license. I'm not concerned about what is the
"derivative work" and was is not. I have problem with something different.
The most fundamental thing in (L)GPL is to ensure that every user of the
software has full rights to modify (and possibly improve) the code. This
is what FSF calls "freedom" and that's basically good.
Let's now suppose that someone releases a product (not necessarily GPL)
that uses this LGPLed library. Now, I'm the user of this software and,
by inclusion, the user of the library. I want to benefit from my basic
rights to modify (and possibly improve) this library. Let's say that I
got the library source code and modified it. What next? I cannot compile
it in separation and link with the rest of the product (or just link it
dynamically), because I have modified the template code and to see my
modifications in the library I have to instantiate the template, which
means recompile the main product, which means... yes, I need the source
code of the product, which is not necessarily open source.

We can generalize this problem to any technology with the following
property:

If module A uses module B, then module A's source code must be
re-processed in order for the module B's modifications to take effect.

C++ with templates has this property (module B is a template library)
and I can imagine that there can be (if not today then in the future)
tons of other software technologies where this property is also true.

My conclusion is that (L)GPL license on the C++ library that has at
least one template definition *forces* every software using this library
to be distributed with source code, because otherwise the user cannot
benefit from his basic rights to modify this LGPLed library, which is a
clear violation of the license.
This in turn means that LGPL does not meet its intended goals.

What about libraries without template definitions?
a) They will have them in next versions, which must be LGPL.
b) I want to modify those libraries (and I have the right to do so) by
adding the template definitions. The modified library must be LGPL.


My following conclusion is that (L)GPL license was invented without any
thought about software technologies other than C with its traditional
compile&link production cycles, where modules can be compiled in separation.

I'm not really versed in (english) legalese, so I ask for your comments
on this. I may be totally wrong and possibly messed up everything, but
as a C++ programmer who from time to time releases C++ libraries
containing template definitions I'm a little bit concerned. At the
moment I steer away from LGPL license, and the above concern is one of
the reasons.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Ron Natalie
2004-10-19 16:25:21 UTC
Permalink
Post by Maciej Sobczak
The most fundamental thing in (L)GPL is to ensure that every user of the
software has full rights to modify (and possibly improve) the code. This
is what FSF calls "freedom" and that's basically good.,
No, it doesn't assure that. It places restrictions on what people can
do with the code. It's RMS's idea of freedom. In actuallity the BSD/
BOOST/libtiff etc... libraries are much more free (they pretty much
just say do what you want with this but leave the copyright info intact
and don't sue us).
Post by Maciej Sobczak
Let's now suppose that someone releases a product (not necessarily GPL)
that uses this LGPLed library.
If you modify the library code, you must give the modified source code
out as specified in the LGPL license.
Post by Maciej Sobczak
My conclusion is that (L)GPL license on the C++ library that has at
least one template definition *forces* every software using this library
to be distributed with source code, because otherwise the user cannot
benefit from his basic rights to modify this LGPLed library, which is a
clear violation of the license.
You keepputting the (L) in parens like you don't know if you are talking
about the GPL or the Lesser GPL. What you are saying is true of the GPL.
It's not true of the LGPL. The LGPL lets you use the library but only
exposes the "must-give-source" aspects to changes made to library itself.
Post by Maciej Sobczak
This in turn means that LGPL does not meet its intended goals.
You don't seem to understand the FSF goals. Their goal isn't to
provide a flexible open source licensing scheme, it's a stated
goal to kill off all proprietary software. Go to FSF.org, open
up the licenses page, and read some of RMS's rants on why you shouldn't
use the LPGL.
Post by Maciej Sobczak
My following conclusion is that (L)GPL license was invented without any
thought about software technologies other than C with its traditional
compile&link production cycles, where modules can be compiled in separation.
I'm not even sure it had C in mind. The whole GPL boondoggle came from
RMS getting (in his percetion) screwed over work he did on LISP at MIT.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-20 16:30:18 UTC
Permalink
Post by Ron Natalie
Post by Maciej Sobczak
The most fundamental thing in (L)GPL is to ensure that every user of the
software has full rights to modify (and possibly improve) the code.
No, it doesn't assure that.
It doesn't? In what way can it happen that a user of (L)GPL code
does not have full rights to modify that code?
Post by Ron Natalie
It places restrictions on what people can do with the code.
It's RMS's idea of freedom. In actuallity the BSD/BOOST/libtiff etc...
libraries are much more free
As MS wrote above, the purpose of the (L)GPL is to give *all users*
the ability to examine, modify, and redistribute the code. The "more
free" licenses permit some users to deny others these abilities.
That is, they can take the code, examine it, modify it, redistribute
it, and prohibit their recipients from examining this code, modifying
it, or redistributing it. That certainly may be what some people like,
but those downstream second-class users now have much less freedom.
Post by Ron Natalie
The LGPL lets you use the library but only exposes the "must-give-source"
aspects to changes made to library itself.
But "must-be-able-to-relink" is also part of the LGPL requirements.
Since templated libraries can't really be used that way, that vitiates
one of the goals of the LGPL.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
k***@gabi-soft.fr
2004-10-21 17:40:31 UTC
Permalink
Post by Hyman Rosen
Post by Ron Natalie
Post by Maciej Sobczak
The most fundamental thing in (L)GPL is to ensure that every
user of the software has full rights to modify (and possibly
improve) the code.
No, it doesn't assure that.
It doesn't? In what way can it happen that a user of (L)GPL code
does not have full rights to modify that code?
Post by Ron Natalie
It places restrictions on what people can do with the code. It's
RMS's idea of freedom. In actuallity the BSD/BOOST/libtiff etc...
libraries are much more free
As MS wrote above, the purpose of the (L)GPL is to give *all users*
the ability to examine, modify, and redistribute the code.
The original intent of the (L)GPL, as I understand it, was specifically
to allow people to use free software in the development of commercial
programs, e.g. to be able to compile and link using gcc (or g++) even if
the program was to be sold, or the sources not made available, later.

In the end, it was more or less to bring the free development tools in
line with the commercial ones -- there has never been any question that
linking with the libc provided by Sun with Solaris places any
restrictions on my software.

Unless this is possible with g++, of course, g++ becomes pretty much
unusable for many people. I believe, in fact, that LGPL originally came
to be because the GPL on the libraries furnished with gcc was making gcc
pretty much unusable.

(There is the additional problem that corporate lawyers do not always
understand the intent or purpose of these licenses, and sometimes seem
incapable of understanding what they mean. I know of one case where the
corporate legal departement refused to allow us to use g++, even though
we were delivering full sources to the customer, and the customer had no
problem with GPL applying to those sources, since he wasn't distributing
the software anywhere else.)
Post by Hyman Rosen
The "more free" licenses permit some users to deny others these
abilities. That is, they can take the code, examine it, modify it,
redistribute it, and prohibit their recipients from examining this
code, modifying it, or redistributing it. That certainly may be what
some people like, but those downstream second-class users now have
much less freedom.
There are many complicated issues that have to be balanced. If you take
pride in the quality of your work, you certainly don't want people
downstream hacking it in any sloppy fashion, and then redistributing it
as if it were the original. I doubt that the people at g++ were happy
when an internal development version was pawned off as a 2.96 release.
And Knuth is very clear about it in the license to TeX -- you can do
what you want with the sources, but you cannot call the results TeX.
You may consider that taking away freedom, but I consider it pride in
your work. (But of course, both positions are ridiculous
oversimplifications.)

Note too that the "freedom" is largely imaginary. If you understand the
algorithms and the programming techniques involved, it is usually
quicker and easier to develop something new from scratch that it is to
modify undocumented existing source code. And since the license doesn't
require documentation (and I would be at a loss as to how to formulate
text so that the required documentation would be adequate), it's really
as if you didn't have the source code if you want to make a modification
of any quality. (This obviously depends on the size of the project, and
the type of modification.)
Post by Hyman Rosen
Post by Ron Natalie
The LGPL lets you use the library but only exposes the
"must-give-source" aspects to changes made to library itself.
But "must-be-able-to-relink" is also part of the LGPL requirements.
Since templated libraries can't really be used that way, that vitiates
one of the goals of the LGPL.
The "must-be-able-to-relink" seems to contradict the expressed intent
of: "We use this license for certain libraries in order to permit
linking those libraries into non-free programs."

In fact, of course, I suspect that this clause is widely ignored. There
is, after all, commercial software available for Linux, and what
alternative do you have on Linux, other than to link with a library that
is distributed under LGPL?

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-22 17:14:50 UTC
Permalink
Post by k***@gabi-soft.fr
The "must-be-able-to-relink" seems to contradict the expressed intent
of: "We use this license for certain libraries in order to permit
linking those libraries into non-free programs."
The right of all users to be able to examine, modify, and redistribute
is at the core of what the FSF believes, and the LGPL expresses that
as much as the GPL does. The LGPL allows more latitude to proprietary
vendors, in that they can link these libraries into their code and not
cause that code to fall under the same license, but the core freedoms
with regard to the library itself are preserved.

LGPL exists for the cases where it is clear that a GPLed version would
not be used at all. In terms of freedom, it is truly "lesser".
Post by k***@gabi-soft.fr
In fact, of course, I suspect that this clause is widely ignored. There
is, after all, commercial software available for Linux, and what
alternative do you have on Linux, other than to link with a library that
is distributed under LGPL?
If these are shared libraries, then there is no problem, since modified
ones can simply be put in place. But if you do come across cases where
the LGPL on a library owned by the FSF is being ignored, why don't you
contact them? I'm sure they'd be interested.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Ron Natalie
2004-10-23 14:16:57 UTC
Permalink
{Please ensure thart follow-ups contain C++ content and do not
degenerate into discussion of the terms of (L)GPL).
Post by Hyman Rosen
The right of all users to be able to examine, modify, and redistribute
is at the core of what the FSF believes,
Redistribution is very seriously restricted.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Ben Hutchings
2004-10-23 14:19:50 UTC
Permalink
Post by k***@gabi-soft.fr
Post by Hyman Rosen
Post by Ron Natalie
Post by Maciej Sobczak
The most fundamental thing in (L)GPL is to ensure that every
user of the software has full rights to modify (and possibly
improve) the code.
No, it doesn't assure that.
It doesn't? In what way can it happen that a user of (L)GPL code
does not have full rights to modify that code?
Post by Ron Natalie
It places restrictions on what people can do with the code. It's
RMS's idea of freedom. In actuallity the BSD/BOOST/libtiff etc...
libraries are much more free
As MS wrote above, the purpose of the (L)GPL is to give *all users*
the ability to examine, modify, and redistribute the code.
The original intent of the (L)GPL, as I understand it, was specifically
to allow people to use free software in the development of commercial
programs, e.g. to be able to compile and link using gcc (or g++) even if
the program was to be sold, or the sources not made available, later.
In the end, it was more or less to bring the free development tools in
line with the commercial ones -- there has never been any question that
linking with the libc provided by Sun with Solaris places any
restrictions on my software.
Unless this is possible with g++, of course, g++ becomes pretty much
unusable for many people. I believe, in fact, that LGPL originally came
to be because the GPL on the libraries furnished with gcc was making gcc
pretty much unusable.
The C/C++ run-time library (libgcc_s) and the whole of the standard
C++ library (libstdc++) included in GCC are under a special licence,
the "Runtime GPL". This is the GPL plus an exception that allows
their code to be used "as part of a library" without the usual
"copyleft" or "viral" conditions of the GPL or the LGPL.

<snip>
Post by k***@gabi-soft.fr
I doubt that the people at g++ were happy
when an internal development version was pawned off as a 2.96 release.
The absurdity is that GCC "2.96" was distributed by Red Hat, which
employs many of the core GCC developers (following its purchase of
Cygnus). The left hand didn't know what the right hand was doing, it
seems.

<snip>
Post by k***@gabi-soft.fr
Post by Hyman Rosen
Post by Ron Natalie
The LGPL lets you use the library but only exposes the
"must-give-source" aspects to changes made to library itself.
But "must-be-able-to-relink" is also part of the LGPL requirements.
Since templated libraries can't really be used that way, that vitiates
one of the goals of the LGPL.
The "must-be-able-to-relink" seems to contradict the expressed intent
of: "We use this license for certain libraries in order to permit
linking those libraries into non-free programs."
In fact, of course, I suspect that this clause is widely ignored. There
is, after all, commercial software available for Linux, and what
alternative do you have on Linux, other than to link with a library that
is distributed under LGPL?
The key is that the linking is done dynamically, not statically. I
think most proprietary software for Linux does not breach the
copyright of LGPL'd libraries.
--
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Gabriel Dos Reis
2004-10-24 04:11:30 UTC
Permalink
***@gabi-soft.fr writes:

| Unless this is possible with g++, of course, g++ becomes pretty much
| unusable for many people. I believe, in fact, that LGPL originally came
| to be because the GPL on the libraries furnished with gcc was making gcc
| pretty much unusable.

I noted you switched from "g++" to "gcc" in your last sentence;
I wanted to add that the libstdc++ coming with g++ does not use LGPL.
It uses "GPL with runtime exception".

http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html
--
Gabriel Dos Reis
***@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
k***@gabi-soft.fr
2004-10-26 04:16:07 UTC
Permalink
Post by Gabriel Dos Reis
| Unless this is possible with g++, of course, g++ becomes pretty much
| unusable for many people. I believe, in fact, that LGPL originally
| came to be because the GPL on the libraries furnished with gcc was
| making gcc pretty much unusable.
I noted you switched from "g++" to "gcc" in your last sentence;
I wanted to add that the libstdc++ coming with g++ does not use LGPL.
It uses "GPL with runtime exception".
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html
Well, my last sentence was speaking about the historical motivation, not
the current status. And I think that the LGPL was first used with the
libc for gcc.

With regards to the latter part of your sentence: I am overjoyed to hear
it. For those of us working on Sparcs, g++ is often the only reasonable
compiler available.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Gabriel Dos Reis
2004-10-26 22:50:03 UTC
Permalink
***@gabi-soft.fr writes:

| Gabriel Dos Reis <***@cs.tamu.edu> wrote in message
| news:<***@merlin.cs.tamu.edu>...
| > ***@gabi-soft.fr writes:
|
| > | Unless this is possible with g++, of course, g++ becomes pretty much
| > | unusable for many people. I believe, in fact, that LGPL originally
| > | came to be because the GPL on the libraries furnished with gcc was
| > | making gcc pretty much unusable.
|
| > I noted you switched from "g++" to "gcc" in your last sentence;
| > I wanted to add that the libstdc++ coming with g++ does not use LGPL.
| > It uses "GPL with runtime exception".
|
| > http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html
|
| Well, my last sentence was speaking about the historical motivation, not
| the current status. And I think that the LGPL was first used with the
| libc for gcc.

gcc does not come with a libc. It uses the target's system libc.
--
Gabriel Dos Reis
***@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
johnchx
2004-10-21 17:14:21 UTC
Permalink
Post by Ron Natalie
Post by Maciej Sobczak
The most fundamental thing in (L)GPL is to ensure that every user of the
software has full rights to modify (and possibly improve) the code. This
is what FSF calls "freedom" and that's basically good.,
No, it doesn't assure that. It places restrictions on what people can
do with the code. It's RMS's idea of freedom.
Plea to moderators: isn't a flamewar on the merits and evils of the
GPL, LGPL and the FSF wildly off-topic here? Could we nip this in the
bud?

The OP has a legitimate C++ question about the interaction between the
C++ template inclusion model and the LGPL. I hope we can discuss that
without getting into a 200-post thread about what "freedom" means.

--jc

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
k***@gabi-soft.fr
2004-10-20 16:16:34 UTC
Permalink
Post by Maciej Sobczak
I think this is a good forum to ask this question. The problem affects
C++ programmers that release libraries with LGPL licence and those who
use such libraries in non-GPL products.
Let's imagine a library containing some template definitions. The
library has a LGPL license. I'm not concerned about what is the
"derivative work" and was is not. I have problem with something
different. The most fundamental thing in (L)GPL is to ensure that
every user of the software has full rights to modify (and possibly
improve) the code. This is what FSF calls "freedom" and that's
basically good.
Allowing any one to make any possible modification, without requiring
them to change the name, or at least make it clear that the software has
been modified, is good?

My experience with GPL software is that it is only good when you can
ensure that the freedom hasn't actually been used: I download g++ from
the g++ site, and they do have source code control, and don't let just
anyone hack any modification in without verifying that it works. The
"control" aspect of quality control is important if you want the
quality.

(This isn't to say that GPL is always bad. Just that, like most things,
there are cases where it is good, cases where it is bad, and a lot of
cases where it really doen't matter. G++ is g++, regardless of the
license -- GPL doesn't make it any better, but as long as the g++ team
do control the sources, and wild or unsupported copies with unknown
modifications don't start floating around, GPL doesn't make it worse.)
Post by Maciej Sobczak
Let's now suppose that someone releases a product (not necessarily
GPL) that uses this LGPLed library.
In that case, if I understand correctly, the product is controlled by
its licence. The fact that it uses an LGPLed library is irrelevant.
Post by Maciej Sobczak
Now, I'm the user of this software and, by inclusion, the user of the
library. I want to benefit from my basic rights to modify (and
possibly improve) this library.
From what I understand of LGPL, you don't have any.
Post by Maciej Sobczak
Let's say that I got the library source code and modified it. What
next? I cannot compile it in separation and link with the rest of the
product (or just link it dynamically), because I have modified the
template code and to see my modifications in the library I have to
instantiate the template, which means recompile the main product,
which means... yes, I need the source code of the product, which is
not necessarily open source.
Exactly. That is the whole point of LGPL (as opposed to GPL).

Note that templates are irrelevant in the issue. If I deliver you a
statically linked program using a LGPL licence, you can't do anything
with it either.

If I've sold you a product, and I stand behind my product, this is
almost a necessary condition.
Post by Maciej Sobczak
We can generalize this problem to any technology with the following
If module A uses module B, then module A's source code must be
re-processed in order for the module B's modifications to take effect.
C++ with templates has this property (module B is a template library)
and I can imagine that there can be (if not today then in the future)
tons of other software technologies where this property is also true.
My conclusion is that (L)GPL license on the C++ library that has at
least one template definition *forces* every software using this
library to be distributed with source code, because otherwise the user
cannot benefit from his basic rights to modify this LGPLed library,
which is a clear violation of the license. This in turn means that
LGPL does not meet its intended goals.
I think that there has been some discussion concerning what LGPL means
with regards to templates. From what I understand of LGPL, however, the
goal is precisely not to contaminate the code which uses it. The intent
of LGPL is precisely that I can use it without my code falling under
GPL. The fact that I link with an LGPL library does NOT give you the
right to modify my code.
Post by Maciej Sobczak
What about libraries without template definitions?
a) They will have them in next versions, which must be LGPL.
b) I want to modify those libraries (and I have the right to do so) by
adding the template definitions. The modified library must be LGPL.
There is no problem with modifying the libraries. But code which is
linked with the libraries is NOT GPL, nor even LGPL. That's the whole
purpose of LGPL.
Post by Maciej Sobczak
My following conclusion is that (L)GPL license was invented without
any thought about software technologies other than C with its
traditional compile&link production cycles, where modules can be
compiled in separation.
I'm not really versed in (english) legalese, so I ask for your
comments on this. I may be totally wrong and possibly messed up
everything, but as a C++ programmer who from time to time releases C++
libraries containing template definitions I'm a little bit
concerned. At the moment I steer away from LGPL license, and the above
concern is one of the reasons.
I think that there are questions concerning templates and LGPL. But the
questions go in the opposite direction -- with templates, I'm using
source code, not a "library" in the classical sense. And traditionally,
LGPL only gives the exception from GPL when I link object code. On the
other hand, all LGPL libraries I've know have had header files. The
header files may not result in any code being generated by the compiler,
but they are source code which I incorporate into my program. And
traditionally, it has been understood that this is OK. I'm not a
lawyer, but from a pratical point of view, I think that the intent
behind LGPL is clear, templates or not.

As I understand it, originally, any use of GPL'ed code in my program
meant that my program must also be GPL. Since then, a number of
exceptions have been defined:

- I can use GPL'ed programs in the generation of my code without
"contamination". (The fact that I compile my program with g++
doesn't mean that my program must be GPL.)

- I can deliver complete GPL'ed programs as part of a larger product,
provided there is sufficient separation of the program (and
presumably the sources). (Sun Workshop comes with emacs. As long
as the emacs is in a separate directory, and none of the emacs
sources were used in the elaboration of the rest of the product, Sun
Workshop does not become GPL.)

- LGPL was created so that linking with the libraries delivered with a
compiler doesn't contaminate my product. Libraries normally also
contain header files, and traditionally, including those has not
meant contamination either, although I'm not sure what the legalese
says about this.

- Finally, some software is available under several licences -- if I
use the GPL'ed version of Ghostscript in my code, my code must also
be GPL, but I can also purchase a version from Adallin with a non
GPL licence, and use it without my code necessarily becoming GPL.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-21 16:35:22 UTC
Permalink
Post by k***@gabi-soft.fr
Allowing any one to make any possible modification, without requiring
them to change the name, or at least make it clear that the software has
been modified, is good?
That is not allowed. Section 2b states
You must cause the files modified to carry prominent notices
stating
that you changed the files and the date of any change.
Post by k***@gabi-soft.fr
My experience with GPL software is that it is only good when you can
ensure that the freedom hasn't actually been used
That's pretty silly. The whole EGCS fork would have been impossible
without the rights granted by the GPL. And any number of companies
have modified gcc to compile to custom processors.
Post by k***@gabi-soft.fr
Note that templates are irrelevant in the issue. If I deliver you a
statically linked program using a LGPL licence, you can't do anything
with it either.
They are very relevant. See sections 5 and 6 of the LGPL. Object files
which contain instantiations of LGPLed functions may (depending on the
law, not just on technical issues) be considered derived works, and may
only be distributed under the LGPL, which means with full source code.
Furthermore, programs which link against LGPLed libraries must use
dynamic linking or must be shipped in a form which allows them to be
relinked.
Post by k***@gabi-soft.fr
The header files may not result in any code being generated by the
compiler,
but they are source code which I incorporate into my program. And
traditionally, it has been understood that this is OK.
This permission is given explicitly by the LGPL.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
johnchx
2004-10-20 16:18:33 UTC
Permalink
Post by Maciej Sobczak
Let's now suppose that someone releases a product (not necessarily GPL)
that uses this LGPLed library. Now, I'm the user of this software and,
by inclusion, the user of the library. I want to benefit from my basic
rights to modify (and possibly improve) this library. Let's say that I
got the library source code and modified it. What next? I cannot compile
it in separation and link with the rest of the product (or just link it
dynamically),
Sure you can, *if* the proprietary application actually conforms to
the LGPL.
Post by Maciej Sobczak
because I have modified the template code and to see my
modifications in the library I have to instantiate the template, which
means recompile the main product, which means... yes, I need the source
code of the product, which is not necessarily open source.
Which means that the application violates the LGPL.

To conform to the LGPL, an application must ensure that all object
code covered by the LGPL resides in a distinct binary module (or
modules) so that it can be separately re-compiled and re-linked into
the proprietary application.

In the C++ context, this means that all instantiations of LGPL'ed
function templates (including member functions of class templates)
must reside in a distinct GPL/LGPL-only module. No LGPL'ed function
template instantiations may be present in a proprietary binary module.

Class template instantiations (*not* including member functions) are
essentially analagous to struct definitions, and follow the same
rules. (IIRC, LGPL'ed struct definitions are traditionally allowed to
be #included in non-GPL/LGPL modules.) This does constrain somewhat
the changes that can be made to the LGPL'ed class template definition,
but successful re-linking always depends on not breaking
"ABI-compatibility", so there is no real loss of freedom here.

Further wrinkles, like template templates and template members of
class templates, are left as an exercise for the reader. :-)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-21 16:04:58 UTC
Permalink
No LGPL'ed function template instantiations may be present in a
proprietary binary module.
Yep. The GNAT (GNU Ada) runtime library has the same issues, since
Ada has generic instantiation. They solve it by extending further
special permissions for files which contain such instantiations as
the result of compilation, so that they have a special exemption.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Markus Elfring
2004-10-24 04:12:48 UTC
Permalink
Post by johnchx
To conform to the LGPL, an application must ensure that all object
code covered by the LGPL resides in a distinct binary module (or
modules) so that it can be separately re-compiled and re-linked into
the proprietary application.
In the C++ context, this means that all instantiations of LGPL'ed
function templates (including member functions of class templates)
must reside in a distinct GPL/LGPL-only module. No LGPL'ed function
template instantiations may be present in a proprietary binary module.
Is it applicable to divide a license between the raw data structures
and the executable code (functions, methods) that works with them?

How do you think about inlined code in this context?
May macros/inline functions be used by a LGPL'ed library in their
public interface?

Regards,
Markus

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Markus Elfring
2004-10-25 13:40:51 UTC
Permalink
Post by Markus Elfring
May macros/inline functions be used by a LGPL'ed library in their
public interface?
It seems that developers and lawyers must look at the situation when
to make a "runtime exception" to the licence for the code.
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Markus Elfring
2004-11-01 11:46:07 UTC
Permalink
Post by Markus Elfring
It seems that developers and lawyers must look at the situation when
to make a "runtime exception" to the licence for the code.
http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/license.html
The page "http://www.7-zip.org/sdk.html" shows an other "special
exception". Is this wording equivalent to the RGPL and sufficient?
https://sourceforge.net/tracker/?func=detail&atid=214481&aid=1057420&group_id=14481

Regards,
Markus

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

johnchx
2004-10-25 16:52:22 UTC
Permalink
Post by Markus Elfring
Post by johnchx
In the C++ context, this means that all instantiations of LGPL'ed
function templates (including member functions of class templates)
must reside in a distinct GPL/LGPL-only module. No LGPL'ed function
template instantiations may be present in a proprietary binary module.
Is it applicable to divide a license between the raw data structures
and the executable code (functions, methods) that works with them?
I wouldn't say that we're dividing the license, we're just trying to
articulate what the license authorizes the licensee to do with the
licensed code.

The intent of the LGPL is to allow authors to distribute proprietary
binary modules which are link-compatible with the LGPL'ed binary
(a.k.a. a library). Link compatibility means that the proprietary
module needs to include the (mangled) names of the types and functions
exposed by the library. The customary way to accomplish this is to
include the declarations in the proprietary module.

The key principle -- in my opinion at least -- is whether including
LGPL'ed material in the proprietary module impairs the end-user's
ability to modify & recompile the library and re-link the library into
the proprietary application.
Post by Markus Elfring
How do you think about inlined code in this context?
Executable code instantiated from an LGPL'ed template must reside in a
separate module. Inlining an LGPL'ed function in a proprietary module
would be a violation of the license.

I should probably say explicitly that I believe that re-linking to a
modified library should actually affect the behavior of the
proprietary module. That is, the proprietary module must actually use
the linked-in copy of the code, not its own "private" copy (e.g.
inline function instantiations).
Post by Markus Elfring
May macros/inline functions be used by a LGPL'ed library in their
public interface?
Well, nobody should use macros in their public interfaces.... ;-)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Markus Elfring
2004-10-27 01:03:21 UTC
Permalink
Post by johnchx
Well, nobody should use macros in their public interfaces.... ;-)
I assume that a lot of developers are still thinking about when to use
the keyword "inline" for their programming language.
http://en.wikipedia.org/wiki/In-line_expansion

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Markus Elfring
2004-10-25 19:52:57 UTC
Permalink
Post by Markus Elfring
How do you think about inlined code in this context?
Which consequences does it have on licence issues if a linker decides
to inline functions in the generated executable files?
Must this special case be taken into account to consider the RGPL?

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-26 22:45:31 UTC
Permalink
Post by Markus Elfring
Which consequences does it have on licence issues if a linker decides
to inline functions in the generated executable files?
Your distribution rights depend on the license given to you by
the copyright holder. How the derived work in question is created
is irrelevant (unless the license says otherwise).

The simple solution is to distribute the entire work under the GPL.
All of these questions and difficulties arise from not doing so. If
you really are determined anyway, then it's only right that you pay
for the lawyer who will tell you what you can do. You're certainly
not going to get a meaningful legal opinion from a newsgroup.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
k***@gabi-soft.fr
2004-10-29 14:09:01 UTC
Permalink
Post by Markus Elfring
Which consequences does it have on licence issues if a linker
decides to inline functions in the generated executable files?
Your distribution rights depend on the license given to you by the
copyright holder. How the derived work in question is created is
irrelevant (unless the license says otherwise).
The simple solution is to distribute the entire work under the GPL.
The simplest solution is just not to use anything with a license
remotely similar to GPL in your product.

Of course, GPL isn't the only license which places restrictions on what
I do with the software. So maybe I shouldn't use anything with a
license from Microsoft, or Sun, or ... either.

Maybe the simplest solution is to just not program:-).

Seriously, I think that part of the problem is due to the fact that
there is no jurisprudence concerning GPL and LGPL. And they do make
requirements that aren't "standard" in commercial licenses. If I want
to develop using Sun CC, and the libraries that come with it, my
customer has a contract with Sun, which the corporate lawyers have
approved. Said contract, and the licenses it grants, are full of fancy
legal language, but it is the same legal language that appears in many
other contracts and licenses, and the lawyers can actually look at legal
precedence, to know how courts actually interpret it. Given the GPL,
the lawyers are up in the air: what will a court say about it?

In the mean time, I use a lot of GLP'ed software. But only in house, or
for experimental work; I'd never deliver anything out of house which
depended in any way on GPL. Simply because I don't know what that might
actually mean.
All of these questions and difficulties arise from not doing so. If
you really are determined anyway, then it's only right that you pay
for the lawyer who will tell you what you can do. You're certainly not
going to get a meaningful legal opinion from a newsgroup.
The problem is that the opinion of the lawyer isn't of any more value
than your opinion or mine. What counts is the opinion of a court.
Normally, when you pay a lawyer, this is what you get; he bases his
opinion on what the courts have decided in similar cases. In the case
of the GPL, however, I don't think that there is a similar case, so he
ends up guessing too.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Markus Elfring
2004-11-01 11:42:52 UTC
Permalink
Post by Hyman Rosen
The simple solution is to distribute the entire work under the GPL.
All of these questions and difficulties arise from not doing so. If
you really are determined anyway, then it's only right that you pay
for the lawyer who will tell you what you can do. You're certainly
not going to get a meaningful legal opinion from a newsgroup.
LGPL has got an exception that is specified in section 5.
"...
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.)
..."

Is this wording not sufficient because a compiler or linker might
decide to inline bigger code sizes as the numbers that were intended
by the LGPL?

http://en.wikipedia.org/wiki/Inline_function
http://en.wikipedia.org/wiki/In-line_expansion

Regards,
Markus

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
johnchx
2004-10-26 23:29:14 UTC
Permalink
Post by Markus Elfring
Post by Markus Elfring
How do you think about inlined code in this context?
Which consequences does it have on licence issues if a linker decides
to inline functions in the generated executable files?
None whatsoever.

Consider what happens in the case of static linking. The application
developer provides two binary modules:

proprietary.o
lgpl-lib.a

along with the source code for lgpl-lib.a and a linker script which
tells the linker how to combine the two modules into the resulting
executable:

actual-application.exe

The source code for proprietary.o can't include GPL/LGPL code, since
the source isn't provided.

Does the binary which results from the link (actual-application.exe)
include binary code which was generated from LGPL'ed code? Yes, of
course. That's what static linking *means*. (And allowing this is
the key difference between the GPL and the LGPL.)

Linker-inlining simply copies some of the linked binary code to
multiple locations within the resulting executable. But for licensing
purposes, this makes no difference: one copy is covered by the license
exactly the same as many copies, and the license cares nothing about
the address of the copied code within the executable.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Wil Evers
2004-10-21 17:25:30 UTC
Permalink
In article <4174046c$***@news.bluewin.ch>, Maciej Sobczak wrote:

[snip]
Post by Maciej Sobczak
My conclusion is that (L)GPL license on the C++ library that has at
least one template definition *forces* every software using this library
to be distributed with source code, because otherwise the user cannot
benefit from his basic rights to modify this LGPLed library, which is a
clear violation of the license.
This in turn means that LGPL does not meet its intended goals.
[snip]
Post by Maciej Sobczak
I'm not really versed in (english) legalese, so I ask for your comments
on this. I may be totally wrong and possibly messed up everything, but
as a C++ programmer who from time to time releases C++ libraries
containing template definitions I'm a little bit concerned. At the
moment I steer away from LGPL license, and the above concern is one of
the reasons.
I agree; the LGPL is unsuitable for template libraries. The gcc folks are
aware of this; libstdc++, for example, is GPL, not LGPL, but with the
following addition:

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.

- Wil


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Michiel Salters
2004-10-26 13:15:13 UTC
Permalink
Post by Maciej Sobczak
Hi,
I think this is a good forum to ask this question. The problem affects
C++ programmers that release libraries with LGPL licence and those who
use such libraries in non-GPL products.
[...]
Post by Maciej Sobczak
We can generalize this problem to any technology with the following
If module A uses module B, then module A's source code must be
re-processed in order for the module B's modifications to take effect.
C++ with templates has this property (module B is a template library)
and I can imagine that there can be (if not today then in the future)
tons of other software technologies where this property is also true.
True, but irrelevant. There is a specific exception in 6a of the LGPL:

It is understood that the user who changes the contents of definitions
files in the Library will not necessarily be able to recompile the
application to use the modified definitions.

The template case is covered here. If the user changes your Library B,
he will not necessarily be able to recompile the application A.

The boundary case is even more interesting. If you have a pure
template library (compilation only, nothing to link) covered
by the LGPL, the compiled application itself isn't covered.

The introduction of section 5 makes it clear that if the application
is compiled with, but not linked to the library, it's not a
derivative work of the Library, and therefore falls outside
the scope of the LGPL.

In other words, the LGPL works perfectly well. The user can only
replace the Library parts controlled by the linker.

Regards,
Michiel Salters

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Alexander Terekhov
2004-10-26 23:30:34 UTC
Permalink
Michiel Salters wrote:
[...]
Post by Michiel Salters
It is understood that the user who changes the contents of definitions
files in the Library will not necessarily be able to recompile the
application to use the modified definitions.
The template case is covered here. If the user changes your Library B,
he will not necessarily be able to recompile the application A.
He he. Apart from that, one can simply wholeheartedly agree with
the FSF that the [L]GPL is not a contract and just claim that the
distribution of this or that "copy" (in the sense of [17 USC 101]
material object incorporating original and/or derivative work
changing owners) is nothing but an exercise of the non-infringing
"right" (limitation on exclusive rights of the copyright owners)
under 17 USC 109... and hence falls outside the scope of [L]GPL
nonsense.

http://groups.google.com/groups?selm=410F4FD4.243B2F35%40web.de

regards,
alexander.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-28 13:56:13 UTC
Permalink
Post by Alexander Terekhov
17 USC 109
That's silly. The first-sale doctrine applies to distributing
one copy that you received, not to making further copies and
distributing those.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Alexander Terekhov
2004-10-29 02:14:37 UTC
Permalink
Post by Hyman Rosen
Post by Alexander Terekhov
17 USC 109
That's silly. The first-sale doctrine applies to distributing
one copy that you received, not to making further copies and
distributing those.
http://groups.google.com/groups?selm=8k9vb5%24l2k%241%40coward.ks.cc.utah.edu
http://groups.google.com/groups?selm=cduf38%24d58%241%40vegh.ks.cc.utah.edu

Now, and why would then Red Hat, Inc. worry?

< quotes from dmca/sec-104-report-vol-<2|3>.pdf >

Red Hat, Inc.:

Let me just clarify that I don't think anyone today intends to
impact our licensing practices. I haven't seen anything in the
comments, nor have I heard anything today that makes me think
someone does have that intention. What we're concerned about
are unintended consequences of any amendments to Section 109.
The primary difference between digital and nondigital products
with respect to Section 109 is that the former are frequently
licensed. ... product is also available for free downloaded
from the Internet without the printed documentation, without
the box, and without the installation service. Many open source
and free software products also embody the concept of copyleft.
... We are asking that amendments not be recommended that would
jeopardize the ability of open source and free software
licensor to require [blah blah]

Time Warner, Inc.:

We note that the initial downloading of a copy, from an
authorized source to a purchaser's computer, can result in
lawful ownership of a copy stored in a tangible medium.

Library Associations:

First, as conceded by Time Warner, digital transmissions can
result in the fixation of a tangible copy. By intentionally
engaging in digital transmissions with the awareness that a
tangible copy is made on the recipient's computer, copyright
owners are indeed transferring ownership of a copy of the work
to lawful recipients. Second, the position advanced by Time
Warner and the Copyright Industry Organizations is premised
on a formalistic reading of a particular codification of the
first sale doctrine. When technological change renders the
literal meaning of a statutory provision ambiguous, that
provision "must be construed in light of its basic purpose"
and "should not be so narrowly construed as to permit evasion
because of changing habits due to new inventions and
discoveries." Twentieth Century Music Corp. v. Aiken, 422 U.S.
151, 156-158 (1975). The basic purpose of the first sale
doctrine is to facilitate the continued flow of property
throughout society.

regards,
alexander.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Hyman Rosen
2004-10-29 14:37:54 UTC
Permalink
Post by Alexander Terekhov
Now, and why would then Red Hat, Inc. worry?
Because that's what lawyers are paid to do.

But no court is going to allow a back-door bypass
of copyright by permitting the resale of copies
made in the course of using a work. Judges aren't
stupid, and the law isn't something you can hack
into by finding tiny flaws.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Thomas Hansen
2004-10-26 22:47:55 UTC
Permalink
Post by Maciej Sobczak
Hi,
I think this is a good forum to ask this question. The problem affects
C++ programmers that release libraries with LGPL licence and those who
use such libraries in non-GPL products.
[snip]

When I released SmartWin (http://smartwin.sourceforge.net) I asked the
OSI (Open Source Initiative) for help regarding licensing issues
because of the very thing you describe here (SmartWin is heavily
template based)
And what he came up with as a solution was a "derived" GPL license
which basically contained everything in GPL but had "exceptions" to
the original license.

I couldn't actuallly modify the existing GPL, first of all because
then I wasn't legally allowed to use the GPL acronym, and second
because that might have made me get ** copyright problems ** !!
;)

So what we landed was that my license was GPL with the exceptions of
tat if anybody utilized the library for building their own
applications that product would NOT be itself restricted by the GPL
license.

I paste in my license here:

BEGINNING OF LICENSE
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
or visit their website at http://www.gnu.org

As a special exception, if other files call macros or inline functions
or instantiate templates from this file, and 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. However, if you distribute such executables, you must
make available the source code to the version of SmartWin which your
executable instantiates templates from, under the terms of your choice
of subsections (a), (b), or (c) of the GPL.
END OF LICENSE



So you see it's basically the GPL license with one exception, this was
what we landed on about a year ago when I initially released SmartWin
and I think it's a very good solution for people building template
based OS Software which they want to let commercial users utilize...


Thomas

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Glen Low
2004-10-26 22:48:59 UTC
Permalink
Post by Maciej Sobczak
Let's imagine a library containing some template definitions. The
library has a LGPL license. I'm not concerned about what is the
"derivative work" and was is not.
You *have* to consider what is a derived work to see if (L)GPL
reciprocity gets triggered.

Interestingly enough, the case for derivative work is actually
stronger with C++ templates. Consider the following spectrum of reuse
technologies:

template instantiation (specialization)
template instantiation (no specialization)
inline function call
class derivation
library function call
pipe to different process on same machine
web service or some other connection to remote process
using the concepts embodied in the code only

Where would you draw the line for what is a derived work? Obviously
the stuff above the line would trigger the need to reciprocate code,
and below not. And FSF and OSI and even different members of each
faction have different opinions about where to draw that line.

However C++ templates essentially force their code to be incorporated
into the derived work, and therefore both GPL and LGPL require code
that instantiates templates to be reciprocated. It's hard to see how
in a C++ program that instantiates templates, the code from the
library and the client code can be cleanly separated.

A few post-GPL OSI-approved licenses struggle to define the territory
cleanly. E.g. Technical Pursuit's RPL defines it like "anything that
is required to run the software", so it tries to put the line at the
bottom. Affero GPL is GPL + a clause about web services.

Ultimately "derivative work" is defined by copyright law, and GPL
needs to be tested in a court of law.

IANAL, TINLA.

Cheers,

Glen Low, Pixelglow Software
www.pixelglow.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Anand Hariharan
2004-10-27 04:07:43 UTC
Permalink
Post by Maciej Sobczak
Hi,
I think this is a good forum to ask this question. The problem affects
C++ programmers that release libraries with LGPL licence and those who
use such libraries in non-GPL products.
We can generalize this problem to any technology with the following
If module A uses module B, then module A's source code must be
re-processed in order for the module B's modifications to take effect.
Write a test module C whose sole purpose is to evaluate module B.
Module C (of course) uses module B. Now improve your LGPLed library
all you want and measure how much C improves by it.

You cannot, of course, see how your changes improved the product you
purchased - the license that came with that product didn't extend you
that freedom when you purchased it.

- Anand

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Loading...