LGPL clarification

[Ian Lance Taylor]

   Date: Wed, 01 Nov 2000 11:13:38 -0500
   From: Bryan George <bgeorge at mitre.org>

   As I said, that is how the LGPL _appears_.  However, a close reading of
   the license text reveals what again appears to be a poison pill where
   commercial interests are concerned.  Sections 5 and 6, in particular,
   seem in fact to put strings on executables that a company might want to
   sell.  Section 5 states:

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

   And Section 6 states:

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

   These statements are very unfortunate, because they cross the boundary
   that the LGPL intends to establish between the OSS and commercial
   worlds, and dictate terms on the distribution of executable programs
   using LGPL-covered libraries.

The LGPL is basically designed to support shared libraries.  If you
can distribute your package as a shared library, then the LGPL does
not put any restrictions on the program which uses the library.  This
is how you avoid the restriction in section 5--the work is linked with
the library at run time, so there are restrictions on the end user
(the end user effectively can not distribute the linked program), but
not on the program which uses the library.

If you can not distribute your package as a shared library, then you
will indeed have difficulties getting it adopted by proprietary
interests.  It is technically possible, because the proprietary code
can be distributed in object code form, but I've never heard of
anybody actually doing that, and I think that most companies would
balk.

   - Am I interpreting the aforementioned sections of the LGPL correctly? 
   I am not a lawyer, so if there is a reasonable interpretation of the
   license that renders the objections I've raised moot, please enlighten
   me.

I'm not sure whether you are, but you may be.

   - Assuming I'm interpreting the LGPL text correctly, are there any
   reasonable circumstances under which a company might be able to develop
   and deploy a binary executable without being subject to the stated
   conditions?

Distribute your package as a shared library.

   - If not, would it be difficult to surgically alter the LGPL to remove
   the OMAREC and maintain GPL compatibility?

No.  All you have to do is retain section 3.

Ian