* Added a lot of material on LGPL

gpl-lgpl.tex

@@ -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
+of a GPL'd system.  Because of the efficient distribution channels of the
-Internet, any useful GPL'ed system is adopted quickly by non-commercial
+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,
+Because of the symmetry and fairness inherent in GPL'd distribution,
-nearly every GPL'ed package in existence has a vibrant non-commercial user
+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
+By the same token, nearly all established GPL'd software systems have a
-vibrant commercial community.  Nearly every GPL'ed system that has gained
+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
+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'ed software, as it
+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
+GPL'd software have a tough choice.  They must choose between avoiding
-distribution of GPL'ed software that exercises the teachings of their
+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
+Since GPL'd software is now extremely prevalent through the industry, it
-is useful to has some basic knowledge about using GPL'ed software in
+is useful to has some basic knowledge about using GPL'd software in
-business and how to build business models around GPL'ed software.
+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}