Copyleft/guide
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

* Added a lot of material on LGPL

Browse source
This commit is contained in:
Bradley M. Kuhn 2004-01-14 19:04:11 +00:00 committed by Bradley M. Kuhn
parent e6d0bfa9f8
commit 02819d4d97
1 changed files with 469 additions and 49 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

518
gpl-lgpl.tex
View file

@ -88,7 +88,7 @@ any medium, provided this notice is preserved.
This one-day course gives a section-by-section explanation of the most
popular Free Software copyright license, the GNU General Public License
(GNU GPL), and teaches lawyers, software developers, managers and business
people how to use the GPL (and GPL'ed software) successfully in a new Free
people how to use the GPL (and GPL'd software) successfully in a new Free
Software business and in existing, successful enterprises.
Attendees should have a general familiarity with software development
@ -96,7 +96,7 @@ processes. A vague understanding of how copyright law applies to software
is also helpful. The tutorial is of most interest to lawyers, software
developers and managers who run software businesses that modify and/or
redistribute software under terms of the GNU GPL (or who wish to do so in
the future), and those who wish to make use of existing GPL'ed software in
the future), and those who wish to make use of existing GPL'd software in
their enterprise.
Upon completion of the tutorial, successful attendees can expect to have
@ -108,7 +108,7 @@ learned the following:
\item the redistribution options under the GPL.
\item the obligations when modifying GPL'ed software.
\item the obligations when modifying GPL'd software.
\item how to build a plan for proper and successful compliance with the GPL.
@ -116,7 +116,7 @@ learned the following:
\item the most common business models used in conjunction with the GPL.
\item how existing GPL'ed software can be used in existing enterprises.
\item how existing GPL'd software can be used in existing enterprises.
\item the basics of the LGPL and how it differs from GPL.
@ -450,11 +450,11 @@ business and non-commercial users.
\subsection{The Non-Commercial Ecosystem}
A GPL'ed code base becomes a center of a vibrant development and user
A GPL'd code base becomes a center of a vibrant development and user
community. Traditionally, volunteers, operating non-commercially out of
keen interest or ``scratch an itch'' motivations, produce initial versions
of a GPL'ed system. Because of the efficient distribution channels of the
Internet, any useful GPL'ed system is adopted quickly by non-commercial
of a GPL'd system. Because of the efficient distribution channels of the
Internet, any useful GPL'd system is adopted quickly by non-commercial
users.
Fundamentally, the early release and quick distribution of the software
@ -467,14 +467,14 @@ Developers know that the users cannot redistribute their software without
passing along the rights granted by GPL, so they are assured that every
one of their users is treated equally.
Because of the symmetry and fairness inherent in GPL'ed distribution,
nearly every GPL'ed package in existence has a vibrant non-commercial user
Because of the symmetry and fairness inherent in GPL'd distribution,
nearly every GPL'd package in existence has a vibrant non-commercial user
and developer base.
\subsection{The Commercial Ecosystem}
By the same token, nearly all established GPL'ed software systems have a
vibrant commercial community. Nearly every GPL'ed system that has gained
By the same token, nearly all established GPL'd software systems have a
vibrant commercial community. Nearly every GPL'd system that has gained
wide adoption from non-commercial users and developers eventually begins
to fuel a commercial system around that software.
@ -491,7 +491,7 @@ the first people hired to do such work were those same two graduate
students who originally developed the software.
The non-commercial users, however, were not concerned when these two
fellows began collecting paychecks off of their GPL'ed work. They knew
fellows began collecting paychecks off of their GPL'd work. They knew
that because of the nature of the GPL that improvements that were
distributed in the commercial environment could easily be folded back into
the standard version. Companies are not permitted to proprietarize
@ -717,8 +717,8 @@ on making a profit from Free Software redistribution.)
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'ed program, she is bound in the making those changes by \S
2. The goal here is to ensure that the body of GPL'ed software, as it
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
@ -751,7 +751,7 @@ the effort to carefully understand what each clause is saying, because \S
In considering \S 2(b), first note the qualifier: it only applies to
derivative works that ``you distribute or publish''. Despite years of
education efforts by FSF on this matter, many still believe that modifiers
of GPL'ed software are required by the license to publish or otherwise
of GPL'd software are required by the license to publish or otherwise
share their changes. On the contrary, \S 2(b) {\bf does not apply if} the
changes are never distributed. Indeed, the freedom to make private,
personal, unshared changes to software for personal use only should be
@ -769,7 +769,7 @@ following text:
\end{quote}
Again, the GPL relies here on what the copyright law says is a derivative
work. If, under copyright law, the modified version ``contains or is
derived from'' the GPL'ed software, then the requirements of \S 2(b)
derived from'' the GPL'd software, then the requirements of \S 2(b)
apply. The GPL invokes its control as a copyright license over the
modification of the work in combination with its control over distribution
of the work.
@ -799,8 +799,10 @@ affects the license of the new whole derivative work.
\newcommand{\worki}{$\mathcal{I}$}
\newcommand{\workg}{$\mathcal{G}$}
\label{separate-and-independent}
It is certainly possible to take an existing independent work (called
\worki{}) and combine it with a GPL'ed program (called \workg{}). The
\worki{}) and combine it with a GPL'd program (called \workg{}). The
license of \worki{}, when it is distributed as a separate and independent
work, remains the prerogative of the copyright holder of \worki{}.
However, when \worki{} is combined with \workg{}, it produces a new work
@ -828,13 +830,13 @@ The next phrase of note in \S 2(b) is ``licensed ... at no charge''. This
is a source of great confusion to many. Not a month goes by that FSF does
not receive an email that claims to point out ``a contradiction in GPL''
because \S 2 says that redistributors cannot charge for modified versions
of GPL'ed software, but \S 1 says that they can. The ``at no charge''
of GPL'd software, but \S 1 says that they can. The ``at no charge''
means not that redistributors cannot charge for performing the acts
governed by copyright law\footnote{Recall that you could by default charge
for any acts not governed by copyright law, because the license controls
are confined by copyright.}, but rather that they cannot charge a fee
for the \emph{license itself}. In other words, redistributors of
(modified and unmodified) GPL'ed works may charge any amount they choose
(modified and unmodified) GPL'd works may charge any amount they choose
for performing the modifications on contract or the act of transferring
the copy to the customer, but they may not charge a separate licensing fee
for the software.
@ -853,7 +855,7 @@ copy of the software.
In summary, \S 2(b) says what terms under which the third parties must
receive this no-charge license. Namely, they receive it ``under the terms
of this License'', the GPL. When an entity \emph{chooses} to redistribute
a derivative work of GPL'ed software, the license of that whole derivative
a derivative work of GPL'd software, the license of that whole derivative
work must be GPL and only GPL\@. In this manner, \S 2(b) dovetails nicely
with \S 6 (as discussed in Section~\ref{GPLs6} of this tutorial).
@ -867,16 +869,16 @@ give a one-stop CD or URL for a complete operating system with necessary
applications. The GPL very clearly permits such ``mere aggregation'' with
programs under any license. Despite what you hear from its critics, the
GPL is nothing like a virus, not only because the GPL is good for you and
a virus is bad for you, but also because simple contact with a GPL'ed
a virus is bad for you, but also because simple contact with a GPL'd
code-base does not impact the license of other programs. Actual effort
must be expended by a programmer to cause a work to fall under the terms
of the GPL. Redistributors are always welcome to simply ship GPL'ed
of the GPL. Redistributors are always welcome to simply ship GPL'd
software alongside proprietary software or other unrelated Free Software,
as long as the terms of GPL are adhered to for those packages that are
truly GPL'ed.
truly GPL'd.
\section{GPL \S 3: Producing Binaries}
\label{GPL-Section-3}
% FIXME: need name of a novelist who writes very obscurely and obliquely.
Software is a strange beast when compared to other copyrightable works.
@ -901,7 +903,7 @@ derivative works of the source code. Applying a systematic process (i.e.,
code is now a new work of expression fixed in the tangible medium of
electronic file storage.
Therefore, for GPL'ed software to be useful, the GPL, since it governs the
Therefore, for GPL'd software to be useful, the GPL, since it governs the
rules for creation of derivative works, must grant permission for the
generation of binaries. Furthermore, notwithstanding the relative
popularity of source-based GNU/Linux distributions like Gentoo, users find
@ -944,7 +946,7 @@ actually directly derived from the version received.
Furthermore, \S 3 is defending against a tactic that has in fact been seen
in FSF's GPL enforcement. Under GPL, if you pay a high price for a copy
of GPL'ed binaries (which comes with corresponding source, of course), you
of GPL'd binaries (which comes with corresponding source, of course), you
have the freedom to redistribute that work at any fee you choose, or not
at all. Sometimes, companies attempt a GPL-violating cozenage whereby
they produce very specialized binaries (perhaps for an obscure
@ -959,7 +961,7 @@ derivative works from the sources provided.
FSF (as authors of GPL) realizes that software distribution comes in many
forms. Embedded manufacturers, for example, have the freedom to put
GPL'ed software into their PDAs with very tight memory and space
GPL'd software into their PDAs with very tight memory and space
constraints. In such cases, putting the source right alongside the
binaries on the machine itself might not be an option. While it is
recommended that this be the default way that people comply with GPL, the
@ -1000,7 +1002,7 @@ As is shown above, Under \S 3(a), embedded manufacturers can put the
binaries on the device and ship the source code along on a CD\@. However,
sometimes this turns out to be too costly. Including a CD with every
device could prove too costly, and may practically (although not legally)
prohibit using GPL'ed software. For this situation and others like it, \S
prohibit using GPL'd software. For this situation and others like it, \S
3(b) is available.
\S 3(b) allows a distributor of binaries to instead provide a written
@ -1102,12 +1104,12 @@ license is granted as long as the copyright remains in effect\footnote{In
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'ed version (assuming \S
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
GPL'ed software, it is because of their \emph{own actions}, not that of
GPL'd software, it is because of their \emph{own actions}, not that of
the copyright holder. The copyright holder does not decided when \S 4
termination occurs (if ever), the actions of the licensee does.
@ -1121,7 +1123,7 @@ 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'ed software.
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
@ -1136,7 +1138,7 @@ 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'ed MySQL database, upon discovering
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
@ -1217,10 +1219,10 @@ their full rights under GPL, then distribution is prohibited.
Originally, this was designed as the title of this section suggests --- as
a last ditch effort to make sure that freedom was upheld. However, in
modern times, it has come to give much more. Now that the body of GPL'ed
modern times, it has come to give much more. Now that the body of GPL'd
software is so large, patent holders who would want to be distributors of
GPL'ed software have a tough choice. They must choose between avoiding
distribution of GPL'ed software that exercises the teachings of their
GPL'd software have a tough choice. They must choose between avoiding
distribution of GPL'd software that exercises the teachings of their
patents, or grant a royalty-free, irrevocable, non-exclusive license to
those patents. Many companies, including IBM, the largest patent holder
in the world, have chosen the latter.
@ -1235,7 +1237,7 @@ freedom-defending way that they share their copyrighted works.
\S 8 is rarely used by copyright holders. Its intention is that, if
particular country, say Unfreedonia, grant particular patents or allow
copyrighted interfaces (no country to our knowledge even permits those
yet), that the GPL'ed software can continue in free and unabated
yet), that the GPL'd software can continue in free and unabated
distribution in the countries where such controls do not exist.
It is a partial ``out'' from \S 7. Without \S 8, if a copyright holder
@ -1259,7 +1261,7 @@ liability.
FSF reserves the exclusive right to publish future versions of the GPL\@;
\S 9 expresses this. While the stewardship of the copyrights on the body
of GPL'ed software around the world is shared among thousands of
of GPL'd software around the world is shared among thousands of
individuals and organizations, the license itself needs a single steward.
Forking of the code is often regrettable but basically innocuous. Forking
of licensing is disastrous.
@ -1305,14 +1307,425 @@ warranties that cannot legally be disclaimed in a particular jurisdiction.
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 deriviative works under copyright law. Our
goal in desiging 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 tatical 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
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 linga 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 langauge 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 existance 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).
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.
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 exellent 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
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.
The Lesser GPL was first 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 existance, 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 propreitary 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\@.
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.
\section{What's the Same?}
Much of the text of the LGPL is identitcal 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''.
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
judgements, 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
used to allow original copyright holders to forbid distribution in
countries with draconian laws that would otherwise contridict these
licenses.
LGPL's \S 13 sets up FSF as the steward of the LGPL, just as GPL's \S 9
does so for GPL. Meanwhile, LGPL's \S 14 reminds licensees that copyright
holders can grant exceptions to the terms of LGPL, just as GPL's \S 10
reminds licensees of the same thing.
Finally, the assertions of no warranty and limitations of liability are
identical; thus LGPL's \S 15 and \S 16 are the same as GPL's \S 11 and \S
12.
Thus, as we see, the entire latter half of the license is identical.
The parts which set up the legal boundries and meta-rules for the license
are the same. It is our intent that the two licenses operate under the
same legal meachanisms and are enforced precisely the same way.
We strike a difference only in the early portions of the license.
Namely, we go into deeper detail of granting various permissions to
create derivative works, so the redistributors 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 dervative 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 LGPL's Preamble is identical, but the last seven paragraphs
introduce the concepts and reasoning behind creation of the license,
persenting a more generalized and briefer version of the story with which
we began our consideration of LGPL\@.
In short, FSF designed 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 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}
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 against such libraries have full freedoms with
respect to that library. They should have the ability to upgrade to 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 uses
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.
\section{A Work that Uses the Library}
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 uses 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 controled by the terms of the license (in GPL
\S 3), and distributors of such binary derivatives must release full
correesponding source under terms of GPL\@.
In the case of LGPL, these are preceisely the types of derivative works
we wish to permit. This scenario, defined in LGPL as ``a work that uses
the library'', works as follows:
\begin{itemize}
\newcommand{\workl}{$\mathcal{L}$}
\newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$}
\item A new copyright holder creates a separate and independant 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
indepedant 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.
\end{itemize}
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 explination
and that in Section~\ref{separate-and-independent}, which discussed the
combining otherwise separate and independant works with GPL'd code.
Effectively, what LGPL is doing is saying that when a new work is
otherwise separate and independant, but has interface calls out to an
LGPL'ed 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 independant 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:
\begin{emumerate}
\item Is the source code of the new copyrighted work, \worki{}, a
completely independant 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{emumerate}
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{A Work Based on the Library}
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
modifing 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 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 independantly 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.
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 intermmediate step between source
and final binary --- is a derivative work created by copying verbatim code
from the LGPL'd software.
For effeciency, 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 independant work. In the normal
scenario, the derivative would not be created until final assembly and
linking of the executible occured. However, when the compiler does this
effeciency 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 independant 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
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 clarifing 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}
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 udpate the library can do so.
LGPL \S 6 lists five choices
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Integrating the GPL into Business Practices}
Since GPL'ed software is now extremely prevalent through the industry, it
is useful to has some basic knowledge about using GPL'ed software in
business and how to build business models around GPL'ed software.
Since GPL'd software is now extremely prevalent through the industry, it
is useful to has some basic knowledge about using GPL'd software in
business and how to build business models around GPL'd software.
\section{Using GPL'ed Software In-House}
\section{Using GPL'd Software In-House}
A discussed in Sections~\ref{GPLs0} and~\ref{GPLs5} of this tutorial, the
GPL only governs the activities of copying, modifying and distributing the
@ -1342,7 +1755,7 @@ model. IBM primarily chooses this model because they have found that for
higher-end hardware, the cost of the profit made from proprietary software
licensing fees is negligible. The real profit is in the hardware, but it is
essential that software be stable, reliable and dependable, and the users
be allowed to have unfettered access to it. Free Software, and GPL'ed
be allowed to have unfettered access to it. Free Software, and GPL'd
software in particular (because IBM can be assured that proprietary
versions of the same software will not exists to compete on their
hardware) is the right choice.
@ -1357,7 +1770,7 @@ a free license as well) and the Free Software system it documents.
\medskip
However, custom support, service, and software improvement contracts are
the most widely used models for GPL'ed software. The GPL is central to
the most widely used models for GPL'd software. The GPL is central to
their success, because it ensure that the code base remains common, and
that large and small companies are on equal footing for access to the
technology. Consider, for example, the GNU Compiler Collection (GCC).
@ -1381,19 +1794,19 @@ versions, and those forks that exist remain freely available.
\label{Proprietary Relicensing}
A final common business model that is perhaps the most controversial is
proprietary relicensing of a GPL'ed code base. This is only an option for
proprietary relicensing of a GPL'd code base. This is only an option for
software in which a particular entity is the sole copyright holder. As
discussed earlier in this tutorial, a copyright holder is permitted under
copyright law to license a software system under her copyright as many
different ways as she likes to as many different parties as she wishes.
Some companies, such as MySQL AB and TrollTech, use this to their
financial advantage with regard to a GPL'ed code base. The standard
financial advantage with regard to a GPL'd code base. The standard
version is available from the company under the terms of the GPL\@.
However, parties can purchase separate proprietary software licensing for
a fee.
This business model is problematic because it means that the GPL'ed code
This business model is problematic because it means that the GPL'd code
base must be developed in a somewhat monolithic way, because volunteer
Free Software developers may be reluctant to assign their copyrights to
the company because it will not promise to always and forever license the
@ -1410,14 +1823,14 @@ complying with the GPL from a users' perspective gives substantially fewer
headaches than proprietary license compliance.
For those who go into the business of distributing or distributing
modified versions of GPL'ed software, the burden is a bit higher, but not
modified versions of GPL'd software, the burden is a bit higher, but not
by much. The glib answer that is that it is always easy to comply with
the GPL by releasing the whole product as Free Software. However,
admittedly to the dismay of FSF, many modern and complex software systems
are built using both proprietary and GPL'ed components that are not
are built using both proprietary and GPL'd components that are not
legally derivative works of each other. Usually, in product development
with Free Software tools, sometimes it is easier simply to improve
existing GPL'ed application than to start from scratch. In exchange for
existing GPL'd application than to start from scratch. In exchange for
that benefit, the license requires that the modifier give back to the
commons that made the work easier. It is a reasonable trade-off, and it
is a way to help build a better world while also making a profit.
@ -1426,6 +1839,13 @@ Note that FSF does provide services to assist companies who need
assistance in complying with the GPL. You can contact FSF's GPL
Compliance Labs at $<$compliance@fsf.org$>$.
If you are particularly interested in matters of GPL compliance, we
recommend the second course in this series, {\em GPL Compliance Case
Studies and Legal Ethics in Free Software Licensing\/}, in which we
discuss some real GPL violation cases that FSF has worked to resolve.
Consideration of such cases can help give insight on how to handle GPL
compliance in new situations.
\appendix
\chapter{The GNU General Public License}