Ben Bucksch wrote:
> For some bizarre reasons, we link in libstdc++, which is LGPLed on gcc
> Linux. We currently do this dynamically, which is the standard, but
> causes major problems during distribution (the user has the have the
> exact same version of the lib installed that wer eon the build system)
> for other bizarre technical reasons. Bug 79681 proposes to link the lib
> statically, but cls raised a concern that this might force Mozilla to be
> under the (L)GPL, i.e. be illegal.
(The usual disclaimer: I am not a lawyer, and this is not legal advice.
It's my own personal opinion.)
I don't believe this to be the case. I basically agree with your
analysis, with minor exceptions as noted below.
> My response: My understanding of the LGPL
> <http://www.gnu.org/copyleft/lgpl.html>, sections 5 and 6:
>
> Linking (dynamically or statically) changes the executable to be a
> derivative of the LGPLed lib. But that fact solely doesn't force the
> whole binary to have a GPL-compatible license. Rather, the executables
> have to follow some restrictions the GPL imposes, outlined in Section 6.
I think you meant to say LGPL here, rather than GPL.
> One restriction seems to be that the user must be able (legally and
> practically) to use a new/changed version of the LGPLed lib. (Another
> restriction might be the copyright notice, see below.)
>
> With /dynamical/ linking, this is trivial.
Right, in this case the requirements of LGPL section 6(b) are fufilled.
The user can simply replace the preexisting copy of libstdc++ with a new
one, to which Mozilla (or a Mozilla-based product) can dynamically link.
> Replacing a /statically/
> linked lib would require the user to have the object code or source code
> of the non-GPL portion, and exactly that is what the LGPL requires the
> distributor to provide.
> In the case of Mozilla, the user has the source -> can recompile and
> relink -> LGPL terms are fulfilled.
Right, in this case the requirements of LGPL section 6(a) are being
fulfilled: "... if the work is an executable linked with the Library,
[accompany the work] with the complete machine-readable 'work that uses
the Library', as object code and/or source code, so that the user can
modify the Library and then relink to produce a modified executable
containing the modified Library." Here Mozilla is the "work that uses
the library", and is being supplied as source code.
> That might not be true for vendors
> which mix Mozilla code with proprietary code - they would have to supply
> object code (.o files) for the proprietary parts, if they are linked
> statically with Mozilla code.
Right, again this is based on LGPL section 6(a). Here the "work that
uses the library" is Mozilla plus additional proprietary bits; you can
supply the Mozilla part of the work as source code, and the other part
as object code, as allowed by 6(a).
> The latter seems to be the only new
> restriction when statical linking is used.
That's not quite true IMO. The difference between static linking and
dynamic linking is the difference between LGPL sections 6(a) and 6(b).
Note that 6(a) also requires you to provide source code for the library
itself in the case of static linking, which is not the case with 6(b)
and dynamic linking. However this seems to be irrelevant in this case,
given the exception you quote below regarding system libraries.
> Some nit-picking:
>
> > You must give prominent notice with each copy of the work that the
> > Library is used in it and that the Library and its use are covered by
> > this License. You must supply a copy of this License. If the work
> > during execution displays copyright notices, you must include the
> > copyright notice for the Library among them, as well as a reference
> > directing the user to the copy of this License.
>
> Strictly, does this also apply to a dynamically linked libstdc++?
I believe it does, _if_ the nature of the linking is such that LGPL
section 6 would come into effect.
To review, distributing Mozilla by itself in source form would not
trigger LGPL section 6, since the Mozilla source by itself "contains no
derivative of any portion of the Library" and "therefore falls outside
the scope of [the LGPL]", per LGPL section 5. However distributing
Mozilla in executable form could trigger section 6, e.g., if the Mozilla
executable included material from the libstdc++ header files.
> Even it's not actually used? There's an exception:
>
> > However, as a special exception, the source code distributed need not
> > include anything that is normally distributed (in either source or
> > binary form) with the major components (compiler, kernel, and so on)
> > of the operating system on which the executable runs
>
> but it only speaks about the source code.
Right, IMO in the case of libstdc++ this exception basically eliminates
the requirement in LGPL section 6(a) to "[accompany] the work with the
complete corresponding machine-readable source code for the Library ..."
However, as you note, the exception does not eliminate the copyright
notice requirements in section 6.
Frank
--
Frank Hecker work: http://www.collab.net/
[EMAIL PROTECTED] home: http://www.hecker.org/
