This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2011)

The GNU Lesser General Public License (formerly the GNU Library General Public License) or LGPL is a free software license published by the Free Software Foundation (FSF). It was designed as a compromise between the strong-copyleft GNU General Public License or GPL and permissive licenses such as the BSD licenses and the MIT License. The GNU Library General Public License (as the LGPL was originally named) was published in 1991, and adopted the version number 2 for parity with GPL version 2. The LGPL was revised in minor ways in the 2.1 point release, published in 1999, when it was renamed the GNU Lesser General Public License to reflect the FSF's position that not all libraries should use it. Version 3 of the LGPL was published in 2007 as a list of additional permissions applied to GPL version 3.

The LGPL places copyleft restrictions on the program governed under it but does not apply these restrictions to other software that merely link with the program. There are, however, certain other restrictions on this software.^{[further explanation needed]}

The LGPL is primarily used for software libraries, although it is also used by some stand-alone applications, most notably Mozilla^{[clarification needed]} and OpenOffice.org.

Differences from the GPL[link]

The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software.^[1] The non-(L)GPLed program can then be distributed under any terms if it is not a derivative work. If it is a derivative work, then the program's terms must allow for "modification for the customer's own use and reverse engineering for debugging such modifications." Whether a work that uses an LGPL program is a derivative work or not is a legal issue. A standalone executable that dynamically links to a library, through a .so, .dll, or similar medium, is generally accepted as not being a derivative work (as defined by the LGPL). It would fall under the definition of a "work that uses the Library". The following is an excerpt of paragraph 5 of the LGPL version 2.1:

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.

Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.^{[citation needed]}

One feature of the LGPL is that one can convert any LGPLed piece of software into a GPLed piece of software (section 3 of the license). This feature is useful for direct reuse of LGPLed code in GPLed libraries and applications, or if one wants to create a version of the code that cannot be used in proprietary software products.

Choosing to license a library under the GPL or the LGPL[link]

The former name of "GNU Library General Public License" gave some people the impression that the FSF endorsed that libraries use the LGPL and that programs use the GPL. In February 1999, Richard Stallman wrote the essay Why you shouldn't use the Lesser GPL for your next library explaining that the LGPL has not been deprecated, but that one should not necessarily use the LGPL for all libraries:

Which license is best for a given library is a matter of strategy... Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it... When a free library's features are readily available for proprietary software through other alternative libraries... the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library.^[1]

Indeed, Stallman and the FSF sometimes advocate licenses even less restrictive than the LGPL as a matter of strategy. A prominent example was Stallman's endorsement of the use of a BSD-style license by the Vorbis project for use in its libraries.^[2]

Programming languages specificity[link]

The license uses terminology which is mainly intended for applications written in the C programming language or its family. Franz Inc. published its own preamble to the license to clarify terminology in the Lisp context. LGPL with this preamble is sometimes referred as LLGPL.^[3]

In addition, Ada has a special feature, generics, that may use the MGPL license.^{[clarification needed]}

LGPL regarding class inheritance[link]

Some concern has risen about the suitability of object-oriented classes in LGPL'd software being inherited by non-(L)GPL code. Clarification is given on the official GNU website:

The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.^[4]

See also[link]

Free software portal

• Affero General Public License
• Free Software licensing
• GNU Free Documentation License
• GNU General Public License
• GNAT Modified General Public License
• GPL linking exception

References[link]

External links[link]

• LGPL Official Page
• Derivative Works

v t e GNU Project History GNU Manifesto Free Software Foundation Europe India Latin America History of free software Licenses GNU General Public License GNU Lesser General Public License Affero General Public License GNU Free Documentation License GPL linking exception Software GNU (variants) Hurd GNOME Bash GCC GNU Emacs glibc Coreutils Build system GNUnet Gnuzilla (IceCat) Gnash more... Public speakers Alexandre Oliva Benjamin Mako Hill Bradley M. Kuhn Eben Moglen Federico Heinz Georg C. F. Greve Loïc Dachary Ricardo Galli Richard Stallman Robert J. Chassell John Sullivan Other topics GNU/Linux naming controversy Revolution OS BadVista Defective by Design