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~\S1, the rules for verbatim copying of source, are

equivalent to those in GPLv2~\S1.

Second, LGPLv2.1~\S8 is equivalent GPLv2~\S4\@. In both licenses, this

section handles termination in precisely the same manner.

LGPLv2.1~\S9 is equivalent to GPLv2~\S5\@. Both sections assert that

the license is a copyright license, and handle the acceptance of those

copyright terms.

LGPLv2.1~\S10 is equivalent to GPLv2~\S6. 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~\S11 is GPLv2~\S7. 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~\S12 adds the same features as GPLv2~\S8. 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~\S13 sets up the FSF as the steward of the LGPL, just as GPLv2~\S9

does for GPL. Meanwhile, LGPLv2.1~\S14 reminds licensees that copyright

holders can grant exceptions to the terms of LGPL, just as GPLv2~\S10

reminds licensees of the same thing.

Finally, the assertions of no warranty and limitations of liability are

identical; thus LGPLv2.1~\S15 and LGPLv2.1~\S16 are the same as GPLv2~\S11 and \S

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 derivative works, so the re-distributors can make

some proprietary derivatives. Since we simply do not allow the

license to stretch as far as copyright law does regarding what

derivative works must be relicensed under the same terms, we must go

further to explain which derivative works we will allow to 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.

\section{Additions to the Preamble}

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:

\begin{itemize}

\item To encourage the widest possible use of a Free Software library, so

  it becomes a de-facto standard over similar, although not

  interface-identical, proprietary alternatives

\item To encourage use of a Free Software library that already has

  interface-identical proprietary competitors that are more developed

\item To allow a greater number of users to get freedom, by encouraging

  proprietary companies to pick a Free alternative for its otherwise

  proprietary products

\end{itemize}

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 derivative works: ``works that use

the library,'' and ``works based on the library.''  Unlike the GPL, the LGPL must

draw some lines regarding derivative works. We do this here in this

license because we specifically seek to liberalize the rights afforded to

copyright law would otherwise prohibit if the copyright holder exercised

his full permitted controls over the work.

\section{An Application: A Work that Uses the Library}

In the effort to allow certain proprietary derivative works and prohibit

``works based on the library,'' and ``works that use the library.''  The

distinction is drawn on the bright line of binary (or runtime) derivative

works and source code derivatives. We will first consider the definition

of a ``work that uses the library,'' which is set forth in LGPLv2.1~\S5.

We noted in our discussion of GPLv2~\S3 (discussed in

Section~\ref{GPLv2s3} of this document) that binary programs when

compiled and linked with GPL'd software are derivative works of that GPL'd

software. 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 derivative works are controlled by the terms of the license (in GPLv2~\S3),

and distributors of such binary derivatives must release full

corresponding source\@.

In the case of LGPL, these are precisely the types of derivative works

we wish to permit. This scenario, defined in LGPL as ``a work that uses

the library,'' works as follows:

\newcommand{\workl}{$\mathcal{L}$}

\newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$}

\begin{itemize}

\item A new copyright holder creates a separate and independent work,

  \worki{}, that makes interface calls (e.g., function calls) to the

  LGPL'd work, called \workl{}, whose copyright is held by some other

  party. Note that since \worki{} and \workl{} are separate and

  independent works, there is no copyright obligation on this new copyright

  holder with regard to the licensing of \worki{}, at least with regard to

  the source code.

\item The new copyright holder, for her software to be useful, realizes

  that it cannot run without combining \worki{} and \workl{}.

  Specifically, when she creates a running binary program, that running

  binary must be a derivative work, called \lplusi{}, that the user can

  run.

\item Since \lplusi{} is a derivative work of both \worki{} and \workl{},

  the license of \workl{} (the LGPL) can put restrictions on the license

\end{itemize}

We will talk about the specific restrictions LGPLv2.1 places on ``works

that use the library'' in detail in Section~\ref{lgpl-section-6}. For

now, focus on the logic related to how the LGPLv2.1 places requirements on

the license of \lplusi{}. Note, first of all, the similarity between

this explanation and that in Section~\ref{separate-and-independent},

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 {\em binary combination\/} (\lplusi{}) that must be created to

make the separate work (\worki{}) at all useful is a derivative work of

the LGPLv2.1'd software (\workl{}).

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:

\begin{enumerate}

\item Is the source code of the new copyrighted work, \worki{}, a

  completely independent work that stands by itself, and includes no

  source code from \workl{}?

\item When the source code is compiled, does it create a derivative work

  by combining with \workl{}, either by static (compile-time) or dynamic

  (runtime) linking, to create a new binary work, \lplusi{}?

\end{enumerate}

If the answers to both questions are ``yes,'' then \worki{} 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

\worki{} 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 \worki{} is in fact a ``work based on the library'' is

warranted.

\section{The Library, and Works Based On It}

In short, a ``work based on the library'' could be defined as any

derivative work of 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 copyright derivative works,

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 derivative works of a software program.

Thus, the test to use when considering whether something is a ``work

based on the library'' is as follows:

\begin{enumerate}

\item Is the new work, when in source form, a derivative work under

  copyright law of the LGPL'd work?

\item Is there no way in which the new work fits the definition of a

  ``work that uses the library''?

\end{enumerate}

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

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 derivative work

appeared in some ways to be a work that used the library and in other

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

\section{Subtleties in Defining the Application}

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~\S5 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~\S5, \P 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 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 {\em 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 derivative 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.

Specifically, while we know that a ``work that uses the library'' is one

whose final binary is a derivative work, but whose source is not, there

are cases where the object code --- that intermediate step between source

and final binary --- is a derivative work created by copying verbatim 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 derivative 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

derivative work is created.

LGPLv2.1~\S5\P4 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