On Sat, Oct 12, 2002 at 01:00:26PM +0100, Joe Orton wrote:
> On Fri, Oct 11, 2002 at 07:28:30PM -0500, Steve Langasek wrote:
> > The specific wording of the GPL grants an exception for linking binaries
> > against GPL-incompatible libraries that are part of the OS, *as long as*
> > your GPL binary is not shipped together with your libraries. Debian
> > does not make this distinction; unless we were to make a new gpl-non-ssl
> > archive section, everything that we ship in main is part of a single OS
> > and is shipped together.
> Hmmm, I see the wording:
> "unless that component [of the OS] itself accompanies the executable"
> Surely if your interpretation of this is correct, the *BSD projects
> could not redistribute GPL code linked against their C libraries, which
> they currently do with GCC and more?
The current generation of BSD system libraries are all licensed in a
GPL-compatible manner (BSD license w/o advertising clause). So this is
not a problem unless they try to link gcc against something that has not
had the licensing clause removed, such as OpenSSL. :)
> ...
> > Also, if the only barrier to relicensing is the presence of third-party
> > LGPL code, this is not a barrier at all, since the LGPL permits linking
> > this code against any other object files you choose.
> Can you explain why? The LGPL seems to have exactly the same restriction
> as the GPL about linking against components of the operating system.
The LGPL's definitions are:
A "library" means a collection of software functions and/or data
prepared so as to be conveniently linked with application programs
(which use some of those functions and data) to form executables.
The "Library", below, refers to any such software library or work
which has been distributed under these terms. A "work based on the
Library" means either the Library or any derivative work under
copyright law: that is to say, a work containing the Library or a
portion of it, either verbatim or with modifications and/or translated
straightforwardly into another language. (Hereinafter, translation is
included without limitation in the term "modification".)
"Source code" for a work means the preferred form of the work for
making modifications to it. For a library, complete source code means
all the source code for all modules it contains, plus any associated
interface definition files, plus the scripts used to control
compilation and installation of the library.
You have a collection of such functions and data that are licensed
under the LGPL. Since the LGPL's definition does NOT say "a library is
a collection of software functions [...] that have been compiled and
linked into an ELF shared object", I believe what you have is still
covered by this definition even though the files happen to be included
in your source and may be linked directly into one or more applications.
If there's any doubt, you can probably take the LGPLed code and
structure your source tree such that a static LGPL lib is created prior
to final linking. ;)
Here is what the LGPL says about the requirements on applications using
the library (which implicitly covers other libraries used by that
application, since the LGPL says nothing about other libraries):
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
So neon+OpenSSL is a "work that uses the Library", and the source is not
a derivative work of the Library and is therefore not governed by the
LGPL's requirements on source code.
The binaries are derived works, covered by section 6:
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
[...] Also, you must do one of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, 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. (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.)
[...]
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be 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, unless that component itself accompanies
the executable.
And those are really all the requirements that the LGPL imposes on
source code that is linked to the library to form an executable, but is
not part of the library itself -- i.e., not much. It certainly doesn't
require that they be available under the same terms, since it explicitly
allows closed-source apps to link against LGPL libs; so the OpenSSL
license is not really a problem at all.
Cheers,
Steve Langasek
postmodern programmer
Attachment:
pgpHxoE0AYPbg.pgp
Description: PGP signature