WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.
WARNING: This document is made public for archival and historical purposes only. Not all of the information is current, and accuracy cannot be guaranteed.
However, while the strategic goal of software freedom is to bring as much Free Software into the world as possible, particular tactical considerations regarding software freedom dictate different means. Extending the copyleft effect as far as copyright law allows is not always the most prudent course in reaching the goal. In particular situations, even those of us with the goal of building a world where all published software is Free Software realize that full copyleft does not best serve us. The GNU Lesser General Public License (“GNU LGPL”) was designed as a solution for such situations. The Lesser General Public License is sometimes described as a “weak copyleft” license, because code licensed under LGPL’s terms can be combined with code under non-free licenses, and is sometimes used in that fashion.
The first example that FSF encountered where such altered tactics were needed was when work began on the GNU C Library. The GNU C Library would become (and today, now is) a drop-in replacement for existing C libraries. On a Unix-like operating system, C is the lingua franca and the C library is an essential component for all programs. It is extremely difficult to construct a program that will run with ease on a Unix-like operating system without making use of services provided by the C library — even if the program is written in a language other than C. Effectively, all user application programs that run on any modern Unix-like system must make use of the C library.
By the time work began on the GNU implementation of the C libraries, there were already many C libraries in existence from a variety of vendors. Every proprietary Unix vendor had one, and many third parties produced smaller versions for special purpose use. However, our goal was to create a C library that would provide equivalent functionality to these other C libraries on a Free Software operating system (which in fact happens today on modern GNU/Linux systems, which all use the GNU C Library).
Unlike existing GNU application software, however, the licensing implications of releasing the GNU C Library (“glibc”) under the GPL were somewhat different. Applications released under the GPL would never themselves become part of proprietary software. However, if glibc were released under the GPL, it would require that any application distributed for the GNU/Linux platform be released under the GPL.
Since all applications on a Unix-like system depend on the C library, it means that they must link with that library to function on the system. In other words, all applications running on a Unix-like system must be combined with the C library to form a new whole work that is composed of the original application and the C library. Thus, if glibc were GPL’d, each and every application distributed for use on GNU/Linux would also need to be GPL’d, since to even function, such applications would need to be combined into larger works by linking with glibc.
At first glance, such an outcome seems like a windfall for Free Software advocates, since it stops all proprietary software development on GNU/Linux systems. However, the outcome is a bit more subtle. In a world where many C libraries already exist, many of which could easily be ported to GNU/Linux, a GPL’d glibc would be unlikely to succeed. Proprietary vendors would see the excellent opportunity to license their C libraries to anyone who wished to write proprietary software for GNU/Linux systems. The de-facto standard for the C library on GNU/Linux would likely be not glibc, but the most popular proprietary one.
Meanwhile, the actual goal of releasing glibc under the GPL — to ensure no proprietary applications on GNU/Linux — would be unattainable in this scenario. Furthermore, users of those proprietary applications would also be users of a proprietary C library, not the Free glibc.
The Lesser GPL was initially conceived to handle this scenario. It was clear that the existence of proprietary applications for GNU/Linux was inevitable. Since there were so many C libraries already in existence, a new one under the GPL would not stop that tide. However, if the new C library were released under a license that permitted proprietary applications to link with it, but made sure that the library itself remained Free, an ancillary goal could be met. Users of proprietary applications, while they would not have the freedom to copy, share, modify and redistribute the application itself, would have the freedom to do so with respect to the C library.
There was no way the license of glibc could stop or even slow the creation of proprietary applications on GNU/Linux. However, loosening the restrictions on the licensing of glibc ensured that nearly all proprietary applications at least used a Free C library rather than a proprietary one. This trade-off is central to the reasoning behind the LGPL.
Of course, many people who use the LGPL today are not thinking in these terms. In fact, they are often choosing the LGPL because they are looking for a “compromise” between the GPL and the X11-style liberal licensing. However, understanding FSF’s reasoning behind the creation of the LGPL is helpful when studying the license.
Much of the text of the LGPL is identical to the GPL. As we begin our discussion of the LGPL, we will first eliminate the sections that are identical, or that have the minor modification changing the word “Program” to “Library.”
First, LGPLv2.1 §1, the rules for verbatim copying of source, are equivalent to those in GPLv2 §1.
Second, LGPLv2.1 §8 is equivalent GPLv2 §4. In both licenses, this section handles termination in precisely the same manner.
LGPLv2.1 §9 is equivalent to GPLv2 §5. Both sections assert that the license is a copyright license, and handle the acceptance of those copyright terms.
LGPLv2.1 §10 is equivalent to GPLv2 §6. They both protect the distribution system of Free Software under these licenses, to ensure that up, down, and throughout the distribution chain, each recipient of the software receives identical rights under the license and no other restrictions are imposed.
LGPLv2.1 §11 is GPLv2 §7. As discussed, it is used to ensure that other claims and legal realities, such as patent licenses and court judgments, do not trump the rights and permissions granted by these licenses, and requires that distribution be halted if such a trump is known to exist.
LGPLv2.1 §12 adds the same features as GPLv2 §8. These sections are used to allow original copyright holders to forbid distribution in countries with draconian laws that would otherwise contradict these licenses.
LGPLv2.1 §13 sets up the FSF as the steward of the LGPL, just as GPLv2 §9 does for GPL. Meanwhile, LGPLv2.1 §14 reminds licensees that copyright holders can grant exceptions to the terms of LGPL, just as GPLv2 §10 reminds licensees of the same thing.
Finally, the assertions of no warranty and limitations of liability are identical; thus LGPLv2.1 §15 and LGPLv2.1 §16 are the same as GPLv2 §11 and §12.
As we see, the entire latter half of the license is identical. The parts which set up the legal boundaries and meta-rules for the license are the same. It is our intent that the two licenses operate under the same legal mechanisms and are enforced precisely the same way.
We strike a difference only in the early portions of the license. Namely, in the LGPL we go into deeper detail of granting various permissions to create certain types of combinations, modifications and derivations. The LGPL does not stretch the requirements as far as copyright law does regarding what works must be relicensed under the same terms. Therefore, LGPL must in detail explain which works can be proprietary. Thus, we’ll see that the front matter of the LGPL is a bit more wordy and detailed with regards to the permissions granted to those who modify or redistribute the software.
Most of the LGPL’s Preamble is identical, but the last seven paragraphs introduce the concepts and reasoning behind creation of the license, presenting a more generalized and briefer version of the story with which we began our consideration of the LGPL.
In short, FSF designed the LGPL for those edge cases where the freedom of the public can better be served by a more lax licensing system. FSF doesn’t encourage use of the LGPL automatically for any software that happens to be a library; rather, FSF suggests that it only be used in specific cases, such as the following:
The LGPL’s preamble sets forth the limits to which the license seeks to go in chasing these goals. The LGPL is designed to ensure that users who happen to acquire software linked with such libraries have full freedoms with respect to that library. They should have the ability to upgrade to a newer or modified Free version or to make their own modifications, even if they cannot modify the primary software program that links to that library.
Finally, the preamble introduces two terms used throughout the license to clarify between the different types of combined works: “works that use the library,” and “works based on the library.” Unlike the GPL, the LGPL must draw some lines regarding permissibly proprietary combined works. We do this here in this license because we specifically seek to liberalize the rights afforded to those who make combined works. In the GPL, we reach as far as copyright law allows. In the LGPL, we want to draw a line that allows some derivative works copyright law would otherwise prohibit if the copyright holder exercised his full permitted controls over the work.
In the effort to allow certain proprietary works and prohibit others, the LGPL distinguishes between two classes of works: “works based on the library,” and “works that use the library.” The distinction is drawn on the bright line of binary (or runtime) combined works and modified versions of source code. We will first consider the definition of a “work that uses the library,” which is set forth in LGPLv2.1 §5.
We noted in our discussion of GPLv2 §3 (discussed in Section 5.2 of this document) that binary programs when compiled and linked with GPL’d software are covered as a whole by GPL. This includes both linking that happens at compile-time (when the binary is created) or at runtime (when the binary – including library and main program both – is loaded into memory by the user). In GPL, binary works are controlled by the terms of the license (in GPLv2 §3), and distributors of such binary works must release full corresponding source.
The LGPL, by contrast, allows partial proprietarization of such binary works. This scenario, defined in LGPL as “a work that uses the library,” works as follows:
, that makes interface calls (e.g.,
function calls) to the LGPL’d work, called 
, whose copyright is held by some other party. Note
that since and are separate and independent works, there is no copyright obligation on this new
copyright holder with regard to the licensing of , at least with regard to the source code.
and . Specifically, when she creates a running binary program, that running binary must be a
combined work, called +, that the user can run.
+ is a based on both and , the license of (the LGPL) can put restrictions on the license
of +. In fact, this is what the LGPL does.
We will talk about the specific restrictions LGPLv2.1 places on “works that use the library” in detail in
Section 10.7. For now, focus on the logic related to how the LGPLv2.1 places requirements on the license of +.
Note, first of all, the similarity between this explanation and that in Section 5.1.2, which discussed the combination
of otherwise separate and independent works with GPL’d code. Effectively, what LGPLv2.1 does is say that when a
new work is otherwise separate and independent, but has interface calls out to an LGPL’d library, then it is
considered a “work that uses the library.”
In addition, the only reason that LGPLv2.1 has any control over the licensing of a “work that uses the library” is
for the same reason that GPL has some say over separate and independent works. Namely, such controls exist
because the binary combination (+) that must be created to make the separate work () at all useful is a work
based on the LGPLv2.1’d software ().
Thus, a two-question test that will help indicate if a particular work is a “work that uses the library” under LGPLv2.1 is as follows:
, a completely independent work that stands by itself,
and includes no source code from ?
, either by static
(compile-time) or dynamic (runtime) linking, to create a new binary work, +? If the answers to both questions are “yes,” then is most likely a “work that uses the library.” If the answer to
the first question “yes,” but the answer to the second question is “no,” then most likely is neither a “work that
uses the library” nor a “work based on the library.” If the answer to the first question is “no,” but the answer to the
second question is “yes,” then an investigation into whether or not is in fact a “work based on the library” is
warranted.
In short, a “work based on the library” could be defined as any work based on the LGPL’d software that cannot otherwise fit the definition of a “work that uses the library.” A “work based on the library” extends the full width and depth of derivative, combined and/or modified works under copyright law, in the same sense that the GPL does.
Most typically, one creates a “work based on the library” by directly modifying the source of the library. Such a work could also be created by tightly integrating new software with the library. The lines are no doubt fuzzy, just as they are with GPL’d works, since copyright law gives us no litmus test for determining if a given work is a derivative or otherwise a modified version of another software program.
Thus, the test to use when considering whether something is a “work based on the library” is as follows:
If the answer is “yes” to both these questions, then you most likely have a “work based on the library.” If the answer is “no” to the first but “yes” to the second, you are in a gray area between “work based on the library” and a “work that uses the library.”
You can also perform a similar same analysis through careful consideration of the license text itself. LGPLv2 §2(a) states that if a licensed work is a software library (defined in LGPLv2 §0 as “a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables”), you have permission to distribute modified versions only if those versions are themselves libraries. LGPLv2.1 code can therefore not be compliantly taken from its context in a library and placed in a non-library modified version or work based on the work. For its part, LGPLv2 §6 does not provide an exception for this rule: a combination may be made of a modified version of an LGPL’d library with other code, but the LGPL’d code must continue to be structured as a library, and to that library the terms of the license continue to apply.
Either way you view the rules, these issues are admittedly complicated. Nevertheless, In our years of work with the LGPLv2.1, however, we have never seen a work of software that was not clearly one or the other; the line is quite bright. At times, though, we have seen cases where a particularly large work in some ways seemed to be both to both a work that used the library and a work based on the library. We overcame this problem by dividing the work into smaller subunits. It was soon discovered that what we actually had were three distinct components: the original LGPL’d work, a specific set of works that used that library, and a specific set of works that were based on the library. Once such distinctions are established, the licensing for each component can be considered independently and the LGPLv2.1 applied to each work as prescribed.
Finally, note though that, since the LGPLv2.1 can be easily upgraded to GPLv2-or-later, in the worst case you simply need to comply as if the software was licensed under GPLv2. The only reason you must consider the question of whether you have a “work that uses the library” or a “work based on the library” is when you wish to take advantage of the “weak copyleft” effect of the Lesser GPL. If GPLv2-or-later is an acceptable license (i.e., if you plan to copyleft the entire work anyway), you may find this an easier option.
In our discussion of the definition of “works that use the library,” we left out a few more complex details that relate to lower-level programming details. The fourth paragraph of LGPLv2.1 §5 covers these complexities, and it has been a source of great confusion. Part of the confusion comes because a deep understanding of how compiler programs work is nearly mandatory to grasp the subtle nature of what LGPLv2.1 §5, ¶4 seeks to cover. It helps some to note that this is a border case that we cover in the license only so that when such a border case is hit, the implications of using the LGPL continue in the expected way.
To understand this subtle point, we must recall the way that a compiler operates. The compiler first generates object code, which are the binary representations of various programming modules. Each of those modules is usually not useful by itself; it becomes useful to a user of a full program when those modules are linked into a full binary executable.
As we have discussed, the assembly of modules can happen at compile-time or at runtime. Legally, there is no distinction between the two — both create a modified version of the work by copying and combining portions of one work and mixing them with another. However, under LGPL, there is a case in the compilation process where the legal implications are different. To understand this phenomenon, we consider that a “work that uses the library” is typically one whose final binary is a work based on the Program, but whose source is not. However, sometimes, there are cases where the object code — that intermediate step between source and final binary — is a work created by copying and modifying code from the LGPL’d software.
For efficiency, when a compiler turns source code into object code, it sometimes places literal portions of the copyrighted library code into the object code for an otherwise separate independent work. In the normal scenario, the final combined work would not be created until final assembly and linking of the executable occurred. However, when the compiler does this efficiency optimization, at the intermediate object code step, a combined work is created.
LGPLv2.1 §5¶4 is designed to handle this specific case. The intent of the license is clearly that simply compiling software to “make use” of the library does not in itself cause the compiled work to be a “work based on the library.” However, since the compiler copies verbatim, copyrighted portions of the library into the object code for the otherwise separate and independent work, it would actually cause that object file to be a “work based on the library.” It is not FSF’s intent that a mere compilation idiosyncrasy would change the requirements on the users of the LGPLv2.1’d software. This paragraph removes that restriction, allowing the implications of the license to be the same regardless of the specific mechanisms the compiler uses underneath to create the “work that uses the library.”
As it turns out, we have only once had anyone worry about this specific idiosyncrasy, because that particular vendor wanted to ship object code (rather than final binaries) to their customers and was worried about this edge condition. The intent of clarifying this edge condition is primarily to quell the worries of software engineers who understand the level of verbatim code copying that a compiler often does, and to help them understand that the full implications of LGPLv2.1 are the same regardless of the details of the compilation progress.
Now that we have established a good working definition of works that “use” and works that “are based on” the library, we will consider the rules for distributing these two different works.
The rules for distributing “works that use the library” are covered in LGPLv2.1 §6. LGPLv2.1 §6 is much like GPLv2 §3, as it requires the release of source when a binary version of the LGPL’d software is released. Of course, it only requires that source code for the library itself be made available. The work that “uses” the library need not be provided in source form. However, there are also conditions in LGPLv2.1 §6 to make sure that a user who wishes to modify or update the library can do so.
LGPLv2.1 §6 lists five choices with regard to supplying library source and granting the freedom to modify that library source to users. We will first consider the option given by § 6(b), which describes the most common way currently used for LGPLv2.1 compliance on a “work that uses the library.”
LGPLv2.1 §6(b) allows the distributor of a “work that uses the library” to simply use a dynamically linked, shared library mechanism to link with the library. This is by far the easiest and most straightforward option for distribution. In this case, the executable of the work that uses the library will contain only the “stub code” that is put in place by the shared library mechanism, and at runtime the executable will combine with the shared version of the library already resident on the user’s computer. If such a mechanism is used, it must allow the user to upgrade and replace the library with interface-compatible versions and still be able to use the “work that uses the library.” However, all modern shared library mechanisms function as such, and thus LGPLv2.1 §6(b) is the simplest option, since it does not even require that the distributor of the “work based on the library” ship copies of the library itself.
LGPLv2.1 §6(a) is the option to use when, for some reason, a shared library mechanism cannot be used. It requires that the source for the library be included, in the typical GPL fashion, but it also has a requirement beyond that. The user must be able to exercise her freedom to modify the library to its fullest extent, and that means recombining it with the “work based on the library.” If the full binary is linked without a shared library mechanism, the user must have available the object code for the “work based on the library,” so that the user can relink the application and build a new binary.
Almost all known LGPL’d distributions exercise either LGPLv2.1 §6(a) or LGPLv2.1 §6(b). However, LGPLv2.1 §6 provides three other options. LGPLv2.1 §6(c) allows for a written offer for CCS (akin to GPLv2 §3(b)). CCS may also be distributed by network under the terms of LGPLv2.1 §6(c). Furthermore, under LGPLv2.1 §6(e) the distributor may “verify” that the user has already received, or at least that the distributor has already sent to this particular user, the relevant source1.
Finally, LGPLv3 §6 also requires that:
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License.
This is not identical to the roughly parallel requirements of GPLv2 and GPLv3. Compliance requires slightly different measures with respect to the “credits” or “licenses” or “about” screens in interactive programs.
Essentially, “works based on the library” must be distributed under the same conditions as works under full GPL. In fact, we note that LGPLv2.1 §2 is nearly identical in its terms and requirements to GPLv2 §2.
There are, however, subtle differences and additions. For example not only is CCS required (as would be with normal versions of GPL), but also the CCS provided must enable a developer to regenerate the modified version of the entire combined work, using with a modified version of the LGPL’d work (as a replacement for the version a distributor provided). For example, LGPL’d code is statically linked to a non-copyleft executable, the required source code must also include sufficient material to split the distributed executable and relink with a modified version of the library.
The remaining variations between the LGPL and the GPL cover the following conditions:
Due to time constraints, we cannot cover these additional terms in detail, but they are mostly straightforward. The key to understanding LGPLv2.1 is understanding the difference between a “work based on the library” and a “work that uses the library.” Once that distinction is clear, the remainder of LGPLv2.1 is close enough to GPL that the concepts discussed in our more extensive GPL unit can be directly applied.
1Policy motivations for LGPLv2.1 §6(d) are unclear, but it presumably intended to prevent requiring duplicate deliveries in “whole distribution” situations.