\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}

LGPL's preamble sets forth the limits to which the license seeks to go in

chasing these goals. 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 GPL, 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

those who make derivative works. In GPL, we reach as far as copyright law

allows. In 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 derivative works and prohibit

others, LGPL distinguishes between two classes of derivative works:

``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 LGPL \S 5.

We noted in our discussion of GPL \S 3 (discussed in

Section~\ref{GPL-Section-3} 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 GPL

\S 3), 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}$}

Thus, a two-question test that will help indicate if a particular work is

a ``work that uses the library'' under LGPL 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.

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,

in the same sense that 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 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 LGPL, 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 LGPL applied to each work as

prescribed.

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 LGPL's \S 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 \S 5, \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

derivative work is created.

LGPL's \S 5, \P 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

LGPL'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 LGPL are the same regardless

of the details of the compilation progress.

\label{lgpl-section-6}

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

\S 6 of LGPL\@. \S 6 is much like GPL's \S 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 LGPL \S 6 to make sure

that a user who wishes to modify or update the library can do so.

LGPL \S 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 \S 6(b), which describes the

most common way currently used for LGPL compliance on a ``work that

uses the library.''

\S 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

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 \S 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.

\S 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.

The remaining options in \S 6 are very similar to the other choices

provided by GPL \S 3. There are some additional options, but time does

not permit us in this course to go into those additional options. In

almost all cases of distribution under LGPL, either \S 6(a) or \S 6(b) are

exercised.

Essentially, ``works based on the library'' must be distributed under the

same conditions as works under full GPL\@. In fact, we note that LGPL's

\S 2 is nearly identical in its terms and requirements to GPL's \S 2.

There are again subtle differences and additions, which time does not

permit us to cover in this course.

\section{And the Rest}

The remaining variations between LGPL and GPL cover the following

conditions:

\begin{itemize}

\item Allowing a licensing ``upgrade'' from LGPL to GPL\@ (in LGPL \S 3)

\item Binary distribution of the library only, covered in LGPL \S 4,

  which is effectively equivalent to LGPL \S 3

\item Creating aggregates of libraries that are not derivative works of

  each other, and distributing them as a unit (in LGPL \S 7)

\end{itemize}