[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cadaver licensing issues: openssl and GPL again

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.

Steve Langasek
postmodern programmer

Attachment: pgpHxoE0AYPbg.pgp
Description: PGP signature

Reply to: