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

* Finished initial writing on LGPL

Browse source
This commit is contained in:
Bradley M. Kuhn 2004-01-14 19:41:06 +00:00
parent 17d924e3ba
commit 1d71dbc290
1 changed files with 107 additions and 44 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

151
GPL-LGPL/gpl-lgpl.tex
View file

@ -1311,13 +1311,13 @@ 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
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 tatical situations of software freedom
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
@ -1330,16 +1330,16 @@ License (``GNU LGPL'') was designed as a solution for such situations.
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
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 langauge other than C\@. Effectively,
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 existance from a variety of vendors.
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
@ -1368,7 +1368,7 @@ 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
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
glibc, but the most popular proprietary one.
@ -1380,7 +1380,7 @@ 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
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,
@ -1390,7 +1390,7 @@ 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
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
@ -1406,7 +1406,7 @@ 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
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''.
@ -1429,13 +1429,13 @@ 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
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
used to allow original copyright holders to forbid distribution in
countries with draconian laws that would otherwise contridict these
countries with draconian laws that would otherwise contradict these
licenses.
LGPL's \S 13 sets up FSF as the steward of the LGPL, just as GPL's \S 9
@ -1448,16 +1448,16 @@ 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
The parts which set up the legal boundaries and meta-rules for the license
are the same. It is our intent that the two licenses operate under the
same legal meachanisms and are enforced precisely the same way.
same legal mechanisms 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
under the same terms, we must go further to explain which derivative works
we will allow to be proprietary. Thus, we'll see that the front matter
of the LGPL is a bit more wordy and detailed with regards to the
permissions granted to those who modify or redistribute the software.
@ -1466,7 +1466,7 @@ permissions granted to those who modify or redistribute the software.
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
presenting 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
@ -1522,24 +1522,24 @@ 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
binary derivative works are controlled 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\@.
corresponding source under terms of GPL\@.
In the case of LGPL, these are preceisely the types of derivative works
In the case of LGPL, these are precisely the types of derivative works
we wish to permit. This scenario, defined in LGPL as ``a work that uses
the library'', works as follows:
\begin{itemize}
\newcommand{\workl}{$\mathcal{L}$}
\newcommand{\lplusi}{$\mathcal{L\!\!+\!\!I}$}
\item A new copyright holder creates a separate and independant work,
\begin{itemize}
\item A new copyright holder creates a separate and independent work,
\worki{}, that makes interface calls (e.g., function calls) to the
LGPL'd work, called \workl{}, whose copyright is held by some other
party. Note that since \worki{} and \workl{} are separate and
indepedant works, there is no copyright obligation on this new copyright
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.
@ -1558,16 +1558,16 @@ the library'', works as follows:
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
\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 independant works with GPL'd code.
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 independant, but has interface calls out to an
LGPL'ed library, then it is considered a ``work that uses the library''.
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 independant works. Namely, such controls exist
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{}).
@ -1575,16 +1575,16 @@ 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}
\begin{enumerate}
\item Is the source code of the new copyrighted work, \worki{}, a
completely independant work that stands by itself, and includes no
completely independent work that stands by itself, and includes no
source code from \workl{}?
\item When the source code is compiled, does it create a derivative work
by combining with \workl{}, either by static (compile-time) or dynamic
(runtime) linking, to create a new binary work, \lplusi{}?
\end{emumerate}
\end{enumerate}
If the answers to both questions are ``yes'', then \worki{} is most likely
a ``work that uses the library''. If the answer to the first question
@ -1604,7 +1604,7 @@ 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
modifying the source of the library. Such a work could also be created by
tightly integrating new software with the library. The lines are no doubt
fuzzy, just as they are with GPL'd works, since copyright law gives us no
litmus test for derivative works of a software program.
@ -1637,7 +1637,7 @@ 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.
considered independently and the LGPL applied to each work as prescribed.
\section{Subtleties in Works that Use the Library}
@ -1666,16 +1666,16 @@ 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
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 effeciency, when a compiler turns source code into object code, it
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 independant work. In the normal
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 executible occured. However, when the compiler does this
effeciency optimization, at the intermediate object code step, a
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
@ -1683,7 +1683,7 @@ 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
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
LGPL'd software. This paragraph removes that restriction, allowing the
@ -1694,7 +1694,7 @@ 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
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
@ -1712,11 +1712,74 @@ 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.
that a user who wishes to modify or update the library can do so.
LGPL \S 6 lists five choices
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
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.
\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.
\section{And the Rest}
The remaining variations between LGPL and GPL cover the following
conditions:
\begin{itemize}
\item allowing a licensing ``upgrade'' from LGPL to GPL\@ (in LGPL \S 3),
\item binary distribution of the library only, covered in LGPL \S 4,
which is effectively equivalent to LGPL \S 3, and
\item creating aggregates of libraries that are not derivative works of
each other, and distributing them as a unit (in LGPL \S 7).
\end{itemize}
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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Integrating the GPL into Business Practices}
@ -2869,5 +2932,5 @@ That's all there is to it!
% 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
% LocalWords: TrollTech
% LocalWords: Lessig Lessig's UCITA pre PDAs CDs reshifts GPL's Gentoo glibc
% LocalWords: TrollTech administrivia LGPL's MontaVista OpenTV