The GNU Lesser General Public License (LGPL) is a member of the GNU family of open source licenses, along with the GNU GPL v2, the GNU GPL v3, and the GNU AGPL License. Like the others, it was published by the Free Software Foundation as part of Richard Stallman’s GNU Project. And like the others, it’s a copyleft license.

But unlike the GPLs and AGPL, the LGPL is what’s known as a “weak copyleft” license. This type of license straddles the line between strong copyleft licenses (such as the GPLs) and permissive licenses like the MIT or BSD licenses. However, LGPL is slightly different from other weak copyleft licenses, like the Mozilla Public License or Eclipse Public License, due to its special safe harbor for dynamic linking integration.

The LGPL is primarily applied to libraries. In fact, when the first version of this license was released in 1991, GNU LGPL stood for GNU Library General Public License. The name was changed when version 2.1 was published in 1999. The Free Software Foundation released the most recent version, Version 3.0, in 2007 along with the latest version of the GNU GPL (also v3).

Keep reading for an overview of the LGPL License, its requirements and permissions, and current usage in the open source software development community.

The LGPL License: An Overview

The LGPL License was created as a kind of “bridge” between the strong copyleft requirements of the GPLs and comparatively lax — and increasingly popular — permissive licenses, such as the MIT License.

As a copyleft license, LGPL requires users to release the source code of any changes to the original software. However, this requirement applies to a narrower set of code than the “regular” GPL.

A strong copyleft license (GPL v3, for instance) applies to the entire software program, including linked libraries and other components. If any part of your program uses GPL’d code, you must release the whole program under the GPL. Not so if your program uses LGPL’d code. Say, your code links to a library licensed under the LGPL. If you were to modify that library and distribute it, then you’d have to release the changes. But if your program simply uses the library, there’s no need to share your source code for your part of the program. You could even make your part of the program proprietary if you wanted to.

A note on static vs. dynamic linking: The LGPL has different requirements depending on how the library is integrated with the remainder of the program. Generally, dynamic linking of LGPL code is considered best practice, as static linking makes meeting the license requirements more complicated. While it is possible to comply with LGPL code that is integrated into proprietary code as a statically linked library, it requires more effort. There is a kind of safe harbor for using LGPL code as a dynamically linked library; for statically linked libraries, a distributor must offer access to not only the library’s source code, but other information or materials necessary to rebuild the program. However, many programming languages have no equivalent of static linking, so that makes the dynamic linking safe harbor extremely helpful and effective in LGPL compliance.

Versions of the LGPL License

Both the LGPL v2.1 and LGPL v3 are still in use today. While the Free Software Foundation recommends using the latest version (v3), v2.1 remains the most popular. The two versions are very similar in terms of requirements. However, version 3.0 of the LGPL is based on GPL version 3.0, and similarly, requires users to include any installation information necessary to update and reinstall the software if the program is being used as part of a consumer device. In addition, LGPL v3 includes an explicit grant of patent rights, meaning that the developers who created or contributed to the code relinquish their patent rights with regard to any subsequent reuse of the software.

Finally, there are differences in how users can license derivative works of LGPL code.

  • Derivative works of LGPL v 2.1 code must be licensed under the same (or, if allowed by the licensor, a later version of LGPL) — or GPL v2 or later.
  • Derivative works of LGPL v3 code must be licensed under the LGPL v3 — or GPL v3 or later. You would not be able to license a derivative work of LGPL v3 under GPL v2 or LGPL 2.1

Requirements

Users of code licensed under the GNU LGPL (both LGPL 2.1 and LGPL 3) must:

  • Include a copy of the full license text and the original copyright notice
  • Make available the source code when you distribute a derivative work based on the licensed library
  • License any derivative works of the library under the same or later version of the LGPL or GPL as described above

Using the Licensed Code

The LGPL License (both versions) allows users of the licensed code to:

  • Use the code commercially: Like GPL, LGPL imposes no conditions on using the code in software that’s sold commercially.
  • Change the code: Users can rework the code, but if they distribute these modifications, they must release these updates in source code form.
  • Place warranty: Distributors of the original code can offer their own warranty on the licensed software.

The LGPL does not permit sublicensing of the code, nor does it allow contributors to be held liable for legal issues or damages.

LGPL vs. Other Weak Copyleft Licenses

While the LGPL is the only weak copyleft license in the GNU family, it’s certainly not the only one in use today. Other options include the Mozilla Public License 2.0 (MPL), the CDDL (Common Development and Distribution License), and the Eclipse Public License.

Also known as a “file-based copyleft” license, the MPL allows developers to keep the MPL’d code in separate files, then combine that code with additional code to create an aggregate work. The new/additional files can be released under a different license. The CDDL was drafted based on the MPL (version 1.1), so the two licenses share many key provisions.

Like the MPL and CDDL, the EPL allows for sublicensing. The EPL also offers legal protections to contributors, requiring companies that use EPL’d code to defend them in any lawsuits that might arise involving the software.

The MPL, EPL, CDDL, and v3 of the LGPL all include an explicit grant of patent rights.

Use of LGPL

Weak copyleft licenses like the LGPL fill a gap between permissive and strong copyleft licenses, offering some of the benefits of both types of licenses. They’re an appealing option for developers looking to balance contributing to the OSS community with a desire to have their code incorporated into proprietary software. The LGPL’s grant of patent rights is also attractive, as it protects potential users from expensive lawsuits. In addition, the license is backed by the GNU Project, a well-known and respected organization in the open source software domain.

Looking to the Future

In terms of popularity, copyleft licenses, including weak ones like the LGPL, are losing ground to more permissive options. Still, this license fills an interesting niche in the OSS world, both as part of the GNU family of licenses and as a license specifically aimed at software libraries.