@@ -20,49 +20,49 @@
%\pagestyle{empty}
\begin{document}
\begin{titlepage}
\begin{center}
\vspace{.5in}
{\Large
{\sc Detailed Study and Analysis of GPL and LGPL } \\
\vspace{.7in}
Sponsored by the Free Software Foundation \\
\vspace{.3in}
Columbia Law School, New York, NY, USA \\
\vspace{.1in}
Tuesday 20 January 2003
Tuesday 20 January 2004
}
{\large
Bradley M. Kuhn
Executive Director
Free Software Foundation
Daniel Ravicher
Senior Counsel
\end{center}
@@ -104,48 +104,57 @@ Upon completion of the tutorial, successful attendees can expect to have
learned the following:
\begin{itemize}
\item the freedom-defending purpose of each term of the GNU GPL.
\item the redistribution options under the GPL.
\item the obligations when modifying GPL'd software.
\item how to build a plan for proper and successful compliance with the GPL.
\item the business advantages that the GPL provides.
\item the most common business models used in conjunction with the GPL.
\item how existing GPL'd software can be used in existing enterprises.
\item the basics of the LGPL and how it differs from GPL.
\item how best to understand the complexities regarding derivative
works of software.
\end{itemize}
\bigskip
These course materials are merely a summary of the highlights of the
course presented. Readers of this material should assume that they have
missed the bulk of the material, as the detailed discussion of about these
issues is the true education about GPL and LPGL\@. Merely reading this
material is akin to matriculating into a college course and read only the
textbook instead of going to class.
\end{abstract}
\tableofcontents
\pagebreak
\pagenumbering{arabic}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{What Is Free Software?}
Consideration of the GNU General Public License (herein, abbreviated as
\defn{GNU GPL} or just \defn{GPL}) must begin by first considering the broader
world of Free Software. The GPL was not created from a void, rather,
it was created to embody and defend a set of principles that were set
forth at the founding of the GNU project and the Free Software Foundation
(FSF)---the organization that upholds, defends and promotes the philosophy
of software freedom. A prerequisite for understanding the GPL and its
terms and conditions is a basic understanding of the principles behind it.
The GPL is unlike almost all other software licenses in that it is
designed to defend and uphold these principles.
\section{The Free Software Definition}
\label{Free Software Definition}
@@ -579,48 +588,50 @@ productive. But the law is an obvious instance of how creativity and
incentives do not depend upon perfect control over the products created.
Like jazz, or novels, or architecture, the law gets built upon the work
that went before. This adding and changing is what creativity always is.
And a free society is one that assures that its most important resources
remain free in just this sense.\footnote{This quotation is Copyright
\copyright{} 2002, Lawrence Lessig. It is licensed under the terms of
\href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution
License'', version 1.0} or any later version as published by Creative
Commons.}
\end{quotation}
In essence, lawyers are paid to service the shared commons of legal
infrastructure. Few citizens defend themselves in court or write their
own briefs (even though they are legally permitted to do so) because
everyone would prefer to have an expert do that job.
The Free Software economy is a market that is ripe for experts. It
functions similarly to other well established professional fields like the
law. The GPL, in turn, serves as the legal scaffolding that permits the
creation of this vibrant commercial and non-commercial Free Software
economy.
\chapter{Running Software And Verbatim Copying}
\label{run-and-verbatim}
This chapter begins the deep discussion of the details of the terms of
GPL\@. In this chapter, we consider the first two sections: GPL \S\S
0--2. These are the straightforward sections of the GPL that define the
simplest rights that the user receives.
\section{GPL \S 0: Freedom to Run}
\label{GPLs0}
\S 0, the opening section of GPL, sets forth that the work is governed by
copyright law. It specifically points out that it is the ``copyright
holder'' who decides if a work is licensed under its terms, and explains
how the copyright holder might indicate this fact.
A bit more subtly, \S 0 makes an inference that copyright law is the only
system under which it is governed. Specifically, it states:
\begin{quote}
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.
\end{quote}
In essence, the license governs \emph{only} those activities and all other
activities are unrestricted, provided that no other agreements trump GPL
(which they cannot; see Sections~\ref{GPLs6} and~\ref{GPLs7}). This is
very important, because the Free Software community heavily supports
@@ -647,49 +658,49 @@ Thus, the GPL protects users fair and unregulated use rights precisely by
not attempting to cover them. Furthermore, the GPL ensures the freedom
to run specifically by stating the following:
The act of running the Program is not restricted
Thus, users are explicitly given the freedom to run by \S 0.
\medskip
The bulk of \S 0 not yet discussed gives definitions for other terms used
throughout. The only one worth discussing in detail is ``work based on
the Program''. The reason this definition is particularly interesting is
not for the definition itself, which is rather straightforward, but the
because it clears up a common misconception about the GPL\@.
The GPL is often mistakenly criticized because it fails to give a
definition of ``derivative work''. In fact, it would be incorrect and
problematic if the GPL attempted to define this. A copyright license, in
fact, has no control over what may or may not be a derivative work. This
matter is left up to copyright law, not the licenses that utilize it.
It is certainly true that copyright law as a whole does not propose clear
and straightforward guidelines for what is and is not a derivative
software work under copyright law. However, no copyright license --- not
even the GNU GPL -- can be blamed for this. Legislators and court
even the GNU GPL --- can be blamed for this. Legislators and court
opinions must give us guidance to decide the border cases.
\section{GPL \S 1: Verbatim Copying}
\label{GPLs1}
GPL \S 1 covers the matter of redistributing the source code of a program
exactly as it was received. This section is quite straightforward.
However, there are a few details worth noting here.
The phrase ``in any medium'' is important. This, for example, gives the
freedom to publish a book that is the printed copy of the program's source
code. It also allows for changes in the medium of distribution. Some
vendors may ship Free Software on a CD, but others may place it right on
the hard drive of a pre-installed computer. Any such redistribution media
is allowed.
Preservation of copyright notice and license notifications are mentioned
specifically in \S 1. These are in some ways the most important part of
the redistribution, which is why they are mentioned by name. The GPL
always strives to make it abundantly clear to anyone who receives the
software what its license is. The goal is to make sure users know their
rights and freedoms under GPL and to leave no reason that someone would be
surprised that the software she got was licensed under GPL\@. Thus
throughout the GPL, there are specific reference to the importance of
@@ -740,59 +751,61 @@ comparison test (``the AFC test'') as created and developed by the Second
Circuit. Some Circuits, including the Ninth Circuit and the First Circuit,
have either adopted narrower versions of the AFC test or have expressly
rejected the AFC test in favor of a narrower standard. Further, several
other Circuits have yet to adopt any definition of derivative work for
software.
As an introductory matter, it is important to note that literal copying of
a significant portion of source code is not always sufficient to establish
that a second work is a derivative work of an original
program. Conversely, a second work can be a derivative work of an original
program even though absolutely no copying of the literal source code of
the original program has been made. This is the case because copyright
protection does not always extend to all portions of a program’s code,
while, at the same time, it can extend beyond the literal code of a
program to its non-literal aspects, such as its architecture, structure,
sequence, organization, operational modules, and computer-user interface.
\section{The Copyright Act}
The copyright act is of little, if any, help in determining the definition
of a derivative work of software. However, the applicable provisions do
provide some, albeit quite cursory, guidance. Section 101 of the Copyright
Act sets forth the following definitions:
\begin{quotation}
A ``computer program'' is a set of statements or instructions to be used
directly or indirectly in a computer in order to bring about a certain
result.
A ``derivative work'' is a work based upon one or more preexisting works,
such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a work
may be recast, transformed, or adapted. A work consisting of editorial
revisions, annotations, elaborations, or other modifications which, as a
whole, represent an original work of authorship, is a ``derivative work''.
These are the only provisions in the Copyright Act relevant to the
determination of what constitutes a derivative work of a computer
program. Another provision of the Copyright Act that is also relevant to
the definition of derivative work is \S 102(b), which reads as follows:
In no case does copyright protection for an original work of authorship
extend to any idea, procedure, process, system, method of operation,
concept, principle, or discovery, regardless of the form in which it is
described, explained, illustrated, or embodied in such work.
Therefore, before a court can ask whether one program is a derivative work
of another program, it must be careful not to extend copyright protection
to any ideas, procedures, processes, systems, methods of operation,
concepts, principles, or discoveries contained in the original program. It
is the implementation of this requirement to ``strip out'' unprotectable
elements that serves as the most frequent issue over which courts
disagree.
\section{Abstraction, Filtration, Comparison Test}
As mentioned above, the AFC test for determining whether a computer
@@ -1020,48 +1033,49 @@ and macros were protectable under copyright law because they were either
in the public domain or required by functional demands on the
program. With respect to the handful of parameter lists and macros that
did qualify for copyright protection, after performing the comparison step
of the AFC test, it was reasonable for the district court to conclude that
they did not warrant a finding of infringement given their relative minor
contribution to the program as a whole. Likewise, the similarity between
the organizational charts of the two programs was not substantial enough
to support a finding of infringement because they were too simple and
obvious to contain any original expression.
Perhaps not surprisingly, there have been few cases involving a highly
detailed software derivative work analysis. Most often, cases involve
clearer basis for decision, including frequent bad faith on the part of
the defendant or over aggressiveness on the part of the plaintiff.
However, no cases involving free software licensing have ever gone to
court. As free software becomes an ever increasingly important part of
the economy, it remains to be seen whether or not battle lines will be
drawn over whether particular programs infringe the rights of free
software developers or whether the entire community, including industry,
adopts norms avoiding such risk.
\chapter{Modified Source and Binary Distribution}
\label{source-and-binary}
In this chapter, we discuss the two core sections that define the rights
and obligations for those who modify, improve, and/or redistribute GPL'd
software. These sections, \SS 2--3, define the central core rights and
requirements of GPL\@.
\section{GPL \S 2: Share and Share Alike}
For many, this is where the ``magic'' happens that defends software
freedom along the distribution chain. \S 2 is the only place in the GPL
that governs the modification controls of copyright law. If someone
modifies a GPL'd program, she is bound in the making those changes by \S
2. The goal here is to ensure that the body of GPL'd software, as it
continues and develops, remains Free as in freedom.
To achieve that goal, \S 2 first sets forth that the rights of
redistribution of modified versions are the same as those for verbatim
copying, as presented in \S 1. Therefore, the details of charging,
keeping copyright notices intact, and other \S 1 provisions are in tact
here as well. However, there are three additional requirements.
The first (\S 2(a)) requires that modified files carry ``prominent
notices'' explaining what changes were made and the date of such changes.
The goal here is not to put forward some specific way of marking changes,
@@ -1475,91 +1489,92 @@ This theory comports well with the idea of free software, whereby software
is distributed amongst many entities within the community for the purpose
of constant evolution and improvement. In this way, the law of implied
patent license used by the GPL ensures that the community mutually
benefits from the licensing of patents to any single community member.
Note that simply because GPL'd software has an implied patent license does
not mean that any patents held by a distributor of GPL'd code become
worthless. To the contrary, the patents are still valid and enforceable
against either:
\begin{enumerate}
\renewcommand{\theenumi}{\alph{enumi}}
\renewcommand{\labelenumi}{\textup{(\theenumi)}}
\item any software other than that licensed under the GPL by the patent
holder, and
\item any party that does not comply with the GPL
with respect to the licensed software.
\end{enumerate}
\newcommand{\compB}{$\mathcal{B}$}
\newcommand{\compA}{$\mathcal{A}$}
For example, if Company \compA has a patent on advanced web browsing, but
For example, if Company \compA{} has a patent on advanced web browsing, but
also licenses a web browsing software program under the GPL, then it
cannot assert the patent against any party that takes a license to its
program under the GPL. However, if a party uses that program without
complying with the GPL, then Company \compA can assert, not just copyright
complying with the GPL, then Company \compA{} can assert, not just copyright
infringement claims against the non-GPL-compliant party, but also
infringement of the patent, because the implied patent license only
extends to use of the software in accordance with the GPL. Further, if
Company \compB distributes a competitive advanced web browsing program,
Company \compA is free to assert its patent against any user or
Company \compB{} distributes a competitive advanced web browsing program,
Company \compA{} is free to assert its patent against any user or
distributor of that product. It is irrelevant whether Company \compB's
program is distributed under the GPL, as Company \compB can not grant
program is distributed under the GPL, as Company \compB{} can not grant
implied licenses to Company \compA's patent.
This result also reassures companies that they need not fear loosing their
proprietary value in patents to competitors through the GPL implied patent
license, as only those competitors who adopt and comply with the GPL's
terms can benefit from the implied patent license. To continue the
example above, Company \compB does not receive a free ride on Company
\compA's patent, as Company \compB has not licensed-in and then
example above, Company \compB{} does not receive a free ride on Company
\compA's patent, as Company \compB{} has not licensed-in and then
redistributed Company A's advanced web browser under the GPL. If Company
\compB does do that, however, Company \compA still has not lost
competitive advantage against Company \compB, as Company \compB must then,
\compB{} does do that, however, Company \compA{} still has not lost
competitive advantage against Company \compB{}, as Company \compB{} must then,
when it re-distributes Company \compA's program, grant an implied license
to any of its patents that cover the program. Further, if Company \compB
to any of its patents that cover the program. Further, if Company \compB{}
relicenses an improved version of Company A's program, it must do so under
the GPL, meaning that any patents it holds that cover the improved version
are impliedly licensed to any licensee. As such, the only way Company
\compB can benefit from Company \compA's implied patent license, is if it,
\compB{} can benefit from Company \compA's implied patent license, is if it,
itself, distributes Company \compA's software program and grants an
implied patent license to any of its patents that cover that program.
\chapter{Defending Freedom On Many Fronts}
The last chapter presented the core freedom-defending provisions of GPL\@,
which are in \S\S 0--3. \S\S 4--7 of the GPL are designed to ensure that
\S\S 0--3 are not infringed, are enforceable, are kept to the confines of
copyright law and are not trumped by other copyright agreements or
components of other entirely separate legal systems. In short, while \S\S
0--3 are the parts of the license that defend the freedoms of users and
programmers, \S\S 4--7 are the parts of the license that keep the playing
field clear so that \S\S 0--3 can do their jobs.
Chapters~\ref{run-and-verbatim} and ~\ref{source-and-binary} presented the
core freedom-defending provisions of GPL\@, which are in \S\S 0--3. \S\S
4--7 of the GPL are designed to ensure that \S\S 0--3 are not infringed,
are enforceable, are kept to the confines of copyright law and are not
trumped by other copyright agreements or components of other entirely
separate legal systems. In short, while \S\S 0--3 are the parts of the
license that defend the freedoms of users and programmers, \S\S 4--7 are
the parts of the license that keep the playing field clear so that \S\S
0--3 can do their jobs.
\section{GPL \S 4: Termination on Violation}
\label{GPLs4}
\S 4 is GPL's termination clause. Upon first examination, it seems
strange for a license that has the goal of defending users and programmers
freedoms for perpetuity in an irrevocable way would have such a clause.
However, upon further examination, the difference between irrevocability
and this termination clause becomes clear.
The GPL is irrevocable in the sense that once a copyright holder grants
rights for someone to copy, modify and redistribute the software under
terms of the GPL, they cannot later revoke that grant. Since the GPL has
no provision allowing the copyright holder to take such a prerogative, the
license is granted as long as the copyright remains in effect\footnote{In
the USA, due to unfortunate legislation, the length of copyright is
nearly perpetual, even though the Constitution forbids perpetual
copyright.}. The copyright holder has the right to relicense the same
work under different licenses (see Section~\ref{Proprietary Relicensing}
of this tutorial), or to stop distributing the GPL'd version (assuming \S
3(b) was never used), but the she may not revoke the rights under GPL
already granted.
In fact, when an entity looses their right to copy, modify and distribute
@@ -1570,54 +1585,54 @@ termination occurs (if ever), the actions of the licensee does.
Under copyright law, the GPL has granted various rights and freedoms to
the licensee to perform specific types of copying, modification, and
redistribution. By default, all other types of copying, modification, and
redistribution are prohibited. \S 4 says that if you undertake any of
those other types (e.g., redistributing binary-only in violation of \S 3),
then all rights under the license --- even those otherwise permitted for
those who have not violated --- terminate automatically.
\S 4 gives GPL teeth. If licensees fail to adhere to the license, then
they are stuck. They must to completely cease and desist from all
copying, modification and distribution of that GPL'd software.
At that point, violating licensees must gain the forgiveness of the
copyright holder to have their rights restored. Alternatively, they could
negotiate another agreement, separate from GPL, with the copyright
holder. Both are common practice.
At FSF, it is part of the mission to spread software freedom. When FSF
enforces GPL, the goal is to bring the violator back into compliance as
quickly as possible, and redress the damage caused by the violation.
That is FSF's steadfast position in a violation negotiation --- comply
with the license and respect freedom.
However, other entities who do not share the full ethos of software
freedom as institutionalized by FSF pursue GPL violations differently. MySQL
AB, a company that produces the GPL'd MySQL database, upon discovering
GPL violations typically negotiates a proprietary software license
separately for a fee. While this practice is not one that FSF would ever
consider undertaking or even endorsing, it is a legal way for copyright
holders to proceed.
freedom as institutionalized by FSF pursue GPL violations differently.
MySQL AB, a company that produces the GPL'd MySQL database, upon
discovering GPL violations typically negotiates a proprietary software
license separately for a fee. While this practice is not one that FSF
would ever consider undertaking or even endorsing, it is a legal way for
copyright holders to proceed.
\section{GPL \S 5: Acceptance, Copyright Style}
\label{GPLs5}
\S 5 brings us to perhaps the most fundamental misconception and common
confusion about GPL\@. Because of the prevalence of proprietary software,
most users, programmers, and lawyers alike tend to be more familiar with
EULAs. EULAs are believed by their authors to be contracts, requiring
formal agreement between the licensee and the software distributor to be
valid. This has led to mechanisms like ``shrink-wrap'' and ``click-wrap''
as mechanisms to perform acceptance ceremonies with EULAs.
The GPL does not need contract law to ``transfer rights''. No rights are
transfered between parties. By contrast, the GPL is permission slip to
undertake activities that would otherwise been prohibited by copyright law.
As such, it needs no acceptance ceremony; the licensee is not even
required to accept the license.
However, without the GPL, the activities of copying, modifying and
distributing the software would have otherwise been prohibited. So, the
GPL says that you only accepted the license by undertaking activities that
you would have otherwise been prohibited without your license under GPL\@.
This is a certainly subtle point, and requires a mindset quite different
from the contractual approach taken by EULA authors.
@@ -1767,139 +1782,137 @@ warranties that cannot legally be disclaimed in a particular jurisdiction.
Again, some have argued the GPL is unenforceable in some jurisdictions
because its limitation of liability is impermissibly broad. However, \S
12, just like its sister, \S 11, contains a jurisdictional savings
provision, which states that it is to be interpreted only as broadly as
allowed by applicable law. As stated above, such a provision ensures that
both \S 12, and the entire GPL, is enforceable in any jurisdiction,
regardless of any particular law regarding the permissibility of limiting
liability.
So ends the terms and conditions of the GNU General Public License.
\chapter{The Lesser GPL}
As we have seen in our consideration of the GPL, its text is specifically
designed to cover all possible derivative works under copyright law. Our
goal in designing GPL was to make sure that any derivative work of GPL'd
software was itself released under GPL when distributed. Reaching as far
as copyright law will allow is the most direct way to reach that goal.
However, while the strategic goal is to bring as much Free Software into
the world as possible, particular tactical situations of software freedom
dictate different means. Extending the copyleft effect as far as
copyright law allows is not always the most prudent course to 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 that goal. The GNU Lesser General Public
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.
\section{The First LGPL'd Program}
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
be (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
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 GNU 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
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 Library, 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
in modern GNU/Linux systems, which all use the GNU C Library).
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 GPL were
somewhat different. Applications released under GPL would never
themselves become part of proprietary software. However, if glibc were
released under GPL, it would require that any application distributed for
the GNU/Linux platform be released under GPL.
the GNU/Linux platform be released under 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 derivative 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 derivative 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 C libraries on GNU/Linux would likely become not
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 C libraries on GNU/Linux would likely be not
glibc, but the most popular proprietary one.
Meanwhile, the actual goal of releasing glibc under 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 glibc.
be users of a proprietary C library, not the Free glibc.
The Lesser GPL was first conceived to handle this scenario. It was clear
that the existence of proprietary applications for GNU/Linux was
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 GPL would not stop that tide. However, if the new C library
were released under a license that (a) permitted proprietary applications
to link with it, but (b) 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 was able to ensure 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\@.
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 GPL because they are looking
for a ``compromise'' between the GPL and the X11-style liberal licensing
that does not reserve any rights to ensure the future freedom of the
software. However, understanding FSF's reasoning behind the creation of
the LGPL is helpful when studying the license.
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.
\section{What's the Same?}
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 change of changing the word ``Program''
to ``Library''.
identical, or that have the minor modifications of changing the word
``Program'' to ``Library''.
First, \S 1 of LGPL, the rules for verbatim copying of source, are
equivalent to those in GPL's \S 1.
Second, \S 8 of LGPL is equivalent \S 4 of GPL\@. In both licenses, this
section handles termination in precisely the same manner.
\S 9 in LGPL is equivalent to \S 5 in GPL\@. Both sections assert that
the license is a copyright license, and handle the acceptance of those
copyright terms.
LGPL's \S 10 is equivalent to GPL's \S 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.
LGPL's \S 11 is GPL's \S 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.
LGPL's \S 12 adds the same features as GPL's \S 8. These sections are
@@ -2004,56 +2017,56 @@ the library'', works as follows:
\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
of \lplusi{}. In fact, this is what LGPL does.
We will talk about the specific restrictions LGPL places on ``works that
use the library'' in detail in Section~\ref{FIXME}. For now, focus on the
logic related to how the LGPL 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
combining otherwise separate and independent works with GPL'd code.
Effectively, what LGPL is doing is saying 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''.
use the library'' in detail in Section~\ref{lgpl-section-6}. For now,
focus on the logic related to how the LGPL 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 LGPL is doing is saying 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 LGPL 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 LGPL'd software (\workl{}).
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:
\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{}?
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
@@ -2101,151 +2114,151 @@ software that was not clearly one or the other; the line is quite bright.
At times, though, we have seen cases where it almost appeared as such ---
that 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.
\section{Subtleties in Works that Use the Library}
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 forth 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 understand 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, which we discussed in Section~\ref{FIXME}. 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 a a full program when those modules
are {\em assembled\/} into a full binary executable.
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 a full program
when those modules are {\em assembled\/} 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.
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 a
``work based on the library''. It is not FSF's intent that a mere
compilation idiosyncrasy changes the requirements on the users of the
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 were 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.
\section{LGPL \S 6: Distributing Works that Use the Library}
\label{lgpl-section-6}
Now that we have a 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
the freedom to modify that library source the users. We will first
consider the option given by \S 6(b), which describes the most common way
that is currently used for LGPL compliance on a ``work that uses the
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 that is 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
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 use 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 ``worked
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 additions, and 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.
provided by GPL \S 3. There are some additional options, and 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.
\section{Distribution of Works Based on the Library}
Essential, ``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.
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:
\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, and
\item creating aggregates of libraries that are not derivative works of
each other, and distributing them as a unit (in LGPL \S 7).
Due to time constraints, we cannot cover these additional terms in detail,
but they are mostly straightforward. The key to understanding LGPL 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 LGPL is close enough to GPL that the concepts discussed in
our more extensive GPL unit can be directly applied.
@@ -3379,27 +3392,28 @@ along with this library; if not, write to the Free Software Foundation,
Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Also add information on how to contact you by electronic and paper mail.
You should also get your employer (if you work as a programmer) or your
school, if any, to sign a ``copyright disclaimer'' for the library, if
necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program \\
`Gnomovision' (which makes passes at compilers) written by James Hacker. \\
signature of Ty Coon, 1 April 1990 \\
Ty Coon, President of Vice
That's all there is to it!
\end{document}
% LocalWords: proprietarize redistributors sublicense yyyy Gnomovision EULAs
% LocalWords: Yoyodyne FrontPage improvers Berne copyrightable Stallman's GPLs
% LocalWords: Lessig Lessig's UCITA pre PDAs CDs reshifts GPL's Gentoo glibc
% LocalWords: TrollTech administrivia LGPL's MontaVista OpenTV Mitek Arce
% LocalWords: unprotectable protectable Unfreedonia chipset CodeSourcery
% LocalWords: impermissibly
% LocalWords: TrollTech administrivia LGPL's MontaVista OpenTV Mitek Arce DVD
% LocalWords: unprotectable protectable Unfreedonia chipset CodeSourcery Iqtel
% LocalWords: impermissibly Bateman faire minimis Borland uncopyrightable Mgmt
% LocalWords: franca downloadable