The GNU Lesser General Public License v2.1 - An Overview

by Rowan Wilson on 10 November 2005 , last updated

Introduction

The GNU Lesser General Public License v2.1 (LGPL v2.1 for short) is a variation of the regular GNU General Public License (GPL). Originally known as the GNU Library General Public License, it was drafted by the Free Software Foundation (FSF) to provide a weaker (or Lesser) form of copyleft for use in certain specific circumstances. It can be read at http://www.opensource.org/licenses/lgpl-license.php. A third version of the licence, LGPL v3, was published by the FSF in 2007 to coincide with the publication of the GPL v3.

Background of the LGPL

In computing terminology, the word library can be used to describe a grouping of software functions for use by other programs. In this way the program code to undertake common tasks can be placed in the library, and programmers who wish their programs to perform these tasks can take advantage of the library’s code in order to avoid the redundant work of writing their own version. The library’s functions can either be copied into the program when it is compiled, or alternatively the program can access the library, if necessary, when it is being executed. Having your program use code from someone else’s library requires that you have a licence from the library’s owner to do so - after all, your program is incomplete without the library’s functions, and will only function correctly with the addition of those functions. If the library were licensed under the terms of the GNU General Public License, your program would become a work derived from the library when it makes use of the library and thus the requirement would be that you release your program under GPL.

This fact means that anyone who writes a program that uses a GPLed library must either never distribute the program, or agree to license and distribute their program under the GPL as well. As a result, no closed source program can ever be distributed with a GPLed library that it uses. This is, of course, a desired effect of the GPL.

Nevertheless, sometimes a developer of a library might want to ensure that the library itself remains free while permitting non-free software to make use of it. This might happen if the author is trying to create a standard implementation of a particular software solution, and wants the resulting library to be used as widely as possible, while still being protected from relicensing and closing of its source. It is for these purposes that the GNU Lesser General Public License v2.1 was created1.

Main Features of the LGPL v2.1

The LGPL v2.1 is identical to the GPL in many of its provisions. The points in which the LGPL v2.1 differs from the GPL will be discussed here.

Where the GPL mandates that all derivative works be distributed under the GPL, if at all, the LGPL v2.1 defines a separate class of works which may be derivative but which nevertheless can be licensed in any way. These are referred to as works that use the library. These are, essentially, programs that have been written to take advantage of the LGPL-licensed library but contain little or no actual code from the library in their uncompiled form. Such works may be distributed with the LGPL-licensed library and need not themselves be distributed under the LGPL. The exact extent to which the programs in question may contain code from the library is not precisely defined by the licence, although some guidelines are given.

The LGPL v2.1 also differs from the GPL in placing restrictions on the variety and nature of derivative works that it allows. Licensees may modify an LGPL-licensed library, but if they wish to distribute their modified version it must also be a library. Modifications to LGPL-licensed libraries should not impair the library’s ability to work with a wide range of programs (this condition is phrased in terms of a responsibility to code library functions which are not tightly tied to a specific program’s data-structures).

Provided that a work that uses the library meets these conditions, it can be distributed with the LGPL-licensed library in a number of ways. The aim of the licence here is to preserve the ability of recipients to modify the LGPL-licensed library and still have it work with the (possibly closed source) work that uses it. Any distribution must include the source code to the library, and prominent statements of the ownership of the library. It must also either

  • include the source code of the work that uses the library
  • include a facility which permits the work that uses the library to work with modified versions of the library, provided of course that the modified library retains its interface The second option there is most easily accomplished by having the work that uses the library dynamically access library functions when it is executed, rather than have it copy the library functions into its own code at compile time, and the LGPL v2.1 explicitly suggests this as a way of fulfilling its requirements.

Finally, the LGPL v2.1 permits a programmer to distribute a hybrid library, which contains functions from the LGPL-licensed library and other functions which are not LGPL-licensed. However, a copy of the library with no LGPL-licensed code inserted must also be provided, and a notice of where the uncombined LGPL-licensed library may be obtained.

What Does The LGPL v2.1 Do?

These bullets are intended to summarise the salient points of the LGPL v2.1. They are not intended as a full description of its features. The GNU Lesser General Public License v2.1

  • keeps modified versions of the library itself open source
  • allows non-open source software to use the library, and be distributed with it

Should you use the LGPL v2.1?

The Free Software Foundation has produced a useful document on how to decide whether to use GPL or LGPL Why you shouldn’t use the LGPL for your next library. However the best licence for a project is determined by the project’s strategy, and depends on the details of the situation. It is therefore outside the scope of this overview to address these issues.

OSS Watch has produced a document that highlights the main legal issues to consider when Making your code available under an open source licence.

Further reading

Links:

Related information from OSS Watch:


  1. There are technical means of achieving a similar effect, which mainly involve licensing and publishing the interface to the library and the library itself under separate licences. The publishing of an interface, in a book or printed standard, allows the implementation of that interface without creating a derived worked, because there is case law to this effect - the implicit licence granted on a printed book is different to the explicit licence on the software. Well known examples of this include the C standard library and various DBC (or DataBase Connector) libraries. In each case promoting multi-vendor interoperability is the driving force behind the publishing of the interface.