LGPL clarification

Bryan George bgeorge at mitre.org
Wed Nov 1 17:37:07 UTC 2000


Ian Lance Taylor wrote:
> 
>    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.

Unfortunately, what you say doesn't seem to square with what the LGPL
says on the subject of static vs. dynamic linking (from the Preamble):

"When a program is linked with a library, whether statically or using a
shared library, the combination of the two is legally speaking a
combined
work, a derivative of the original library..."

Since dynamically-linked executables are considered derivative works,
Sections 5 and 6 apply.

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

Indeed.

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

Sure, and all that has to happen then is for every company developing
embedded systems to design a dynamic linker into their next-generation
products.  I'm sure they'd be happy to comply. %b

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

Sounds like it may be the way to go.

> Ian

Thanks!

Bryan




More information about the License-discuss mailing list