compliance.}

\section{Evaluate License Applicability}

\label{derivative-works}

Political discussion about the GPL often centers around the ``copyleft''

requirements of the license.  Indeed, the license was designed primarily

to embody this licensing feature.  Most companies adding non-trivial

features (beyond mere porting and bug-fixing) to GPL'd software (and

thereby invoking these requirements) are already well aware of their

more complex obligations under the license.\footnote{There has been much legal

  discussion regarding copyleft and derivative works.  In practical

  reality, this issue is not relevant to the vast majority of companies

  distributing GPL'd software.  Those interested in this issue should study

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

However, experienced  GPL enforcers find that few redistributors'

compliance challenges relate directly to combined work issues in copyleft.

Instead, the distributions of GPL'd

systems most often encountered typically consist of a full operating system

including components under the GPL (e.g., Linux, BusyBox) and components

under the LGPL (e.g., the GNU C Library).  Sometimes, these programs have

been patched or slightly improved by direct modification of their sources,

companies often distribute fully independent, proprietary programs,

developed from scratch, which are designed to run on the Free Software operating

system but do not combine with, link to, modify, derive from, or otherwise

create a combined work with

the GPL'd components.\footnote{However, these programs do often combine

  with LGPL'd libraries. This is discussed in detail in \S~\ref{lgpl}.}

In the latter case, where the work is unquestionably a separate work of

creative expression, no copyleft provisions are invoked.

The core compliance issue faced, thus, in such a situation, is not an discussion of what is or is not a

conveyance of binary works based on GPL'd source, but without Complete,

Corresponding Source.  This tutorial therefore focuses primarily on that issue.

Admittedly, a tiny

situations are so rare, and the details from situation to situation differ

greatly.  Thus, such situations require a highly

fact-dependent analysis and cannot be addressed in a general-purpose

document such as this one.

\medskip

Most companies accused of violations lack a basic understanding

of how to comply even in the straightforward scenario.  This document

provides those companies with the fundamental and generally applicable prerequisite knowledge.

For answers to rarer and more complicated legal questions, such as whether

your software is a derivative or combined work of some copylefted software, consult

with an attorney.\footnote{If you would like more information on the

  application of derivative works doctrine to software, a detailed legal

  discussion is presented in our colleague Dan Ravicher's article,

  \textit{Software Derivative Work: A Circuit Dependent Determination} and in

  \tutorialpartsplit{\textit{Detailed Analysis of the GNU GPL and Related

      Licenses}'s Section on derivative works}{\S~\ref{derivative-works} of

    this tutorial}.}

This discussion thus assumes that you have already identified the

``work'' covered by the license, and that any components not under the GPL

(e.g., applications written entirely by your developers that merely happen

to run on a Linux-based operating system) distributed in conjunction with

of consumer electronic devices.

\section{Facts}

One of Bortez's key products is a Software Development Kit (``SDK'')

designed to assist developers building software for a specific class of

consumer electronics devices.

FSF received a report that the SDK may be based on the GNU Compiler

Collection (which is an FSF-copyrighted collection of tools for software

development in C, C++ and other popular languages). FSF investigated the

claim, but was unable to confirm the violation. The violation reporter

was unresponsive to follow-up requests for more information.

Since FSF was unable to confirm the violation, we did not pursue it any

further. Bogus reports do happen, and we do not want to burden companies

with specious GPL violation complaints. FSF shelved the matter until

more evidence was discovered.

FSF was later able to confirm the violation when two additional reports

surfaced from other violation reporters, both of whom had used the SDK

professionally and noticed clear similarities to FSF's GNU GCC\@. FSF's

Compliance Engineer asked the reporters to run standard tests to confirm

the violation, and it was confirmed that Bortez's SDK was indeed a

of features, including support for a specific consumer device chipset and

additional features to aid in the linking process (``LP'') for those

specific devices. FSF explained the rights that the GPL afforded these

customers and pointed out, for example, that Bortez only needed to provide

source to those in possession of the binaries, and that the users may need

to request that source (if \S 3(b) was exercised). The violators

confirmed that such requests were not answered.

FSF brought the matter to the attention of Bortez, who immediately

escalated the matter to their attorneys. After a long negotiation,

GCC\@. Bortez released most of the source, but some disagreement

FSF inquiries, Bortez reaudited the source to discover that FSF's

analysis was correct. Bortez determined that LP included a number of

source files copied from the GCC code-base.

\label{davrik-build-problems}

Once the full software release was made available, FSF asked the violation

reporters if it addressed the problem. Reports came back that the source

did not properly build. FSF asked Bortez to provide better build

instructions with the software, and such build instructions were

incorporated into the next software release.

At FSF's request as well, Bortez informed customers who had previously

purchased the product that the source was now available by announcing

the availability on its Web site and via a customer newsletter.

Bortez did have some concerns regarding patents. They wished to include a

statement with the software release that made sure they were not granting

any patent permission other than what was absolutely required by the GPL\@.

They understood that their patent assertions could not trump any rights

granted by the GPL\@. The following language was negotiated into the release:

\begin{quotation}

Subject to the qualifications stated below, Bortez, on behalf of itself

and its Subsidiaries, agrees not to assert the Claims against you for your

where no such restrictions occurred, but Vigorien argued that the problem

was insoluble because they operated primarily in the USA\@.

The deadlock on the second issue was resolved when those cryptographic

export restrictions were lifted shortly thereafter, and FSF again raised

the matter with Vigorien. At that point, they dropped the first claim and

agreed to release the remaining source module to their customers. They

did so, and the violation was resolved.

\section{Lessons Learned}

\begin{enumerate}

\item {\bf Removing the GPL'd portion of the product is always an

  option.}  Many violators' first response is to simply refuse to

  release the source code as the GPL requires. FSF offers the option to

  simply remove the GPL'd portions from the product and continue along

  without them. Every case where this has been suggested has led to

  the same conclusion. Like Vigorien, the violator argues that the

  product cannot function without the GPL'd components, and they

  cannot effectively replace them.

  Such an outcome is simply further evidence that the combined work in

  If the other components cannot stand on their own and be useful without

  the GPL'd portions, then one cannot effectively argue that the work as a

\item {\bf The whole product is not always covered.}  In this case,

  Vigorien had additional works aggregated. The backup system was a suite

  of utilities, some of which were the GPL and some of which were not. While

  the cryptographic routines were tightly coupled with GNU tar and clearly

  independent works merely aggregated with the distribution of the

  GNU-tar-based product.

\item {\bf ``Security'' concerns do not exonerate a distributor from GPL

  obligations, and ``security through obscurity'' does not work anyway.}

  The argument that ``this is security software, so it cannot be released

  in source form'' is not a valid defense for explaining why the terms of

  the GPL are ignored. If companies do not want to release source code

  for some reason, then they should not base the work on GPL'd software.

  No external argument for noncompliance can hold weight if the work as

  The ``security concerns'' argument is often floated as a reason to keep

  software proprietary, but the computer security community has on

  numerous occasions confirmed that such arguments are entirely specious.

  Security experts have found --- since the beginnings of the field of

  cryptography in the ancient world --- that sharing results about systems

  and having such systems withstand peer review and scrutiny builds the

  most secure systems. While full disclosure may help some who wish to

  compromise security, it helps those who want to fix problems even more

  by identifying them early.

\item {\bf External regulatory problems can be difficult to resolve.}

  The GPL, though grounded in copyright law, does not have the power to trump

  regulations like export controls. While Vigorien's ``security

  concerns'' were specious, their export control concerns were not. It is

  indeed a difficult problem that FSF acknowledges. We want compliance

  with the GPL and respect for users' freedoms, but we certainly do not expect

  companies to commit criminal offenses for the sake of compliance. We

  will see more about this issue in our next case study.

\end{enumerate}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Haxil, Polgara, and Thesulac: Mergers, Upstream Providers and Radio Devices}

issues on behalf of itself and the Free Software community at large.

Polgara pointed out that the software distribution they used was mostly

contributed by an upstream provider, Thesulac, and Haxil's changes to that

code base were minimal. Polgara negotiated with Thesulac to obtain the

source, although the issue moved very slowly in the channels between

Polgara and Thesulac.

FSF encouraged a round-table meeting so that high bandwidth communication

could occur between FSF, Polgara and Thesulac. Polgara and Thesulac

agreed, and that discussion began. Thesulac provided nearly complete

sources to Polgara, and Polgara made a full software release on their

Web site. At the time of writing, that software still has some build

problems (similar to those that occurred with Bortez, as described in

Section~\ref{davrik-build-problems}). FSF continues to negotiate with

Polgara and Thesulac to resolve these problems, which have a clear path to

a solution and are expected to resolve.

Similar to the Vigorien case, Thesulac has regulatory concerns. In this

case, it is not export controls --- an issue that has since been resolved

--- but radio spectrum regulation. Since this consumer electronic device

contains a software-programmable radio transmitter, regulations in (at

least) the USA and Japan prohibit release of those portions of the code

that operate the device. Since this is a low-level programming issue, the

Linux.  A decade later, this situation remains largely unresolved.

\section{Lessons Learned}

\begin{enumerate}

\item {\bf Community outrage, while justified, can often make negotiation

  more difficult.}  FSF has a strong policy never to publicize names of

  GPL violators if they are negotiating in a friendly way and operating in

  good faith toward compliance. Most violations are honest mistakes, and

  FSF sees no reason to publicly admonish violators who genuinely want to

  come into compliance with the GPL and to work hard staying in compliance.

  This case was so public in the Free Software community that both Haxil's

  and Polgara's representatives were nearly shell-shocked by the time FSF

  began negotiations. There was much work required to diffuse the

  situation. We empathize with our community and their outrage about GPL

  violations, but we also want to follow a path that leads expediently

  to compliance. In our experience, public outcry works best as a last

  resort, not the first.

\item {\bf For software companies, GPL compliance belongs on a corporate

  acquisition checklist. }  Polgara was truly amazed that Haxil had used

  GPL'd software in a major new product line but never informed Polgara

many users.  An example of unregulated use is reading a printout of the

program's source code like an instruction book for the purpose of learning

how to be a better programmer.  The right to read something that you have

access to is and should remain unregulated and unrestricted.

\medskip

Thus, the GPLv2 protects users' fair and unregulated use rights precisely by

not attempting to cover them.  Furthermore, the GPLv2 ensures the freedom

to run specifically by stating the following:

\begin{quote}

''The act of running the Program is not restricted.''

\end{quote}

Thus, users are explicitly given the freedom to run by GPLv2~\S0.

\medskip

The bulk of GPLv2~\S0 not yet discussed gives definitions for other terms used

throughout.  The only one worth discussing in detail is ``work based on

the Program''.  The reason this definition is particularly interesting is

not for the definition itself, which is rather straightforward, but

because it clears up a common misconception about the GPL\@.

The GPL is often mistakenly criticized because it fails to give a

\section{GPLv2~\S1: Verbatim Copying}

\label{GPLv2s1}

GPLv2~\S1 covers the matter of redistributing the source code of a program

exactly as it was received. This section is quite straightforward.

However, there are a few details worth noting here.

The phrase ``in any medium'' is important.  This, for example, gives the

freedom to publish a book that is the printed copy of the program's source

code.  It also allows for changes in the medium of distribution.  Some

vendors may ship Free Software on a CD, but others may place it right on

the hard drive of a pre-installed computer.  Any such redistribution media

is allowed.

Preservation of copyright notice and license notifications are mentioned

specifically in GPLv2~\S1.  These are in some ways the most important part of

the redistribution, which is why they are mentioned by name.  GPL

always strives to make it abundantly clear to anyone who receives the

software what its license is.  The goal is to make sure users know their

rights and freedoms under GPL, and to leave no reason that users might be

surprised the software is GPL'd. Thus

throughout the GPL, there are specific references to the importance of

notifying others down the distribution chain that they have rights under

The first (GPLv2~\S2(a)) requires that modified files carry ``prominent

notices'' explaining what changes were made and the date of such

changes. This section does not prescribe some specific way of

marking changes nor does it control the process of how changes are made.

Primarily, GPLv2~\S2(a) seeks to ensure that those receiving modified

versions know the history of changes to the software.  For some users,

it is important to know that they are using the standard version of

program, because while there are many advantages to using a fork,

there are a few disadvantages.  Users should be informed about the

historical context of the software version they use, so that they can

make proper support choices.  Finally, GPLv2~\S2(a) serves an academic

purpose --- ensuring that future developers can use a diachronic

approach to understand the software.

\medskip

The second requirement (GPLv2~\S2(b)) contains the four short lines that embody

the legal details of ``share and share alike''.  These 46 words are

considered by some to be the most worthy of careful scrutiny because

GPLv2~\S2(b), and they

can be a source of great confusion when not properly understood.

In considering GPLv2~\S2(b), first note the qualifier: it \textit{only} applies to

education efforts on this matter, many still believe that modifiers

of GPL'd software \textit{must} publish or otherwise

share their changes.  On the contrary, GPLv2~\S2(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

protected and defended.\footnote{Most Free Software enthusiasts believe there is a {\bf

    moral} obligation to redistribute changes that are generally useful,

  and they often encourage companies and individuals to do so.  However, there

  is a clear distinction between what one {\bf ought} to do and what one

  {\bf must} do.}

Next, we again encounter the same matter that appears in GPLv2~\S0, in the

following text:

\begin{quote}

``...that in whole or part contains or is derived from the Program or any part thereof.''

\end{quote}

derived from'' the GPL'd software, then the requirements of GPLv2~\S2(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.

\begin{quote}

[The work must] be licensed as a whole at no charge to all third parties

under the terms of this License.

\end{quote}

That is probably the most tightly-packed phrase in all of the GPL\@.

Consider each subpart carefully.

The work ``as a whole'' is what is to be licensed. This is an important

point that GPLv2~\S2 spends an entire paragraph explaining; thus this phrase is

worthy of a lengthy discussion here.  As a programmer modifies a software

program, she generates new copyrighted material --- fixing expressions of

ideas into the tangible medium of electronic file storage.  That

programmer is indeed the copyright holder of those new changes.  However,

those changes are part and parcel to the original work distributed to

the programmer under GPL\@. Thus, the license of the original work

% {\cal I}

\newcommand{\gplusi}{$\mathcal{G\!\!+\!\!I}$}

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

that is the combination of the two (called \gplusi{}). The copyright of

this combined work, \gplusi{}, is held by the original copyright

holder of each of the two works.

In this case, GPLv2~\S2 lays out the terms by which \gplusi{} may be

distributed and copied.  By default, under copyright law, the copyright

holder of \worki{} would not have been permitted to distribute \gplusi{};

copyright law forbids it without the expressed permission of the copyright

holder of \workg{}. (Imagine, for a moment, if \workg{} were a proprietary

product --- would its copyright holders  give you permission to create and distribute

\gplusi{} without paying them a hefty sum?)  The license of \workg{}, the

GPL, states the  options for the copyright holder of \worki{}

who may want to create and distribute \gplusi{}. The  GPL's pre-granted

of the GPL are upheld, goes far above and beyond the permissions that one

would get with a typical work not covered by a copyleft license.  (Thus, to

say that this condition is any way unreasonable is simply ludicrous.)

\medskip

\label{GPLv2s2-at-no-charge}

The next phrase of note in GPLv2~\S2(b) is ``licensed \ldots at no charge.''

This phrase  confuses many.  The sloppy reader points out this as ``a

contradiction in GPL'' because (in their confused view) that clause of GPLv2~\S2 says that re-distributors cannot

charge for modified versions of GPL'd software, but GPLv2~\S1 says that

they can.  Avoid this confusion: the ``at no charge'' \textbf{does not} prohibit re-distributors from

charging when 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'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.

GPLv2~\S2(b) further states that the software must ``be licensed \ldots to all

third parties.''  This too yields some confusion, and feeds the

misconception mentioned earlier --- that all modified versions must be made

available to the public at large.  However, the text here does not say

that.  Instead, it says that the licensing under terms of the GPL must

extend to anyone who might, through the distribution chain, receive a copy

of the software.  Distribution to all third parties is not mandated here,

a way that extends to all third parties who may ultimately receive a

copy of the software.

In summary, GPLv2\ 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 GPLv2.  When an entity \emph{chooses} to redistribute

work must be GPL and only GPL\@.  In this manner, GPLv2~\S2(b) dovetails nicely

with GPLv2~\S6 (as discussed in Section~\ref{GPLv2s6} of this tutorial).

\medskip

The final paragraph of GPLv2~\S2 is worth special mention.  It is possible and

quite common to aggregate various software programs together on one

distribution medium.  Computer manufacturers do this when they ship a

pre-installed hard drive, and GNU/Linux distribution vendors do this to

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'd

code-base does not impact the license of other programs.  A programmer must

expend actual effort  to cause a work to fall under the terms

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'd.

\subsection{Right to Private Modification} 

\label{gplv2-private-modification}

This issue is one of many where GPLv3 clarifies in explicit text the implicit

policy and intent that was solidified via long-standing interpretation of

GPLv2.

\section{GPLv2~\S3: Producing Binaries}

\label{GPLv2s3}

Software is a strange beast when compared to other copyrightable works.

It is currently impossible to make a film or a book that can be truly

obscured.  Ultimately, the full text of a novel, even one written by

William Faulkner, must be presented to the reader as words in some

human-readable language so that they can enjoy the work.  A film, even one

directed by David Lynch, must be perceptible by human eyes and ears to

have any value.

Software is not so.  While the source code --- the human-readable

representation of software --- is of keen interest to programmers, users and

programmers alike cannot make the proper use of software in that

human-readable form.  Binary code --- the ones and zeros that the computer

can understand --- must be predicable and attainable for the software to

be fully useful.  Without the binaries, be they in object or executable

form, the software serves only the didactic purposes of computer science.

Under copyright law, binary representations of the software are simply

``compilation''\footnote{``Compilation'' in this context refers to the

  automated computing process of converting source code into binaries.  It

  has absolutely nothing to do with the term ``compilation'' in copyright statues.}) to a work of source code yields binary code. The binary

code is now a new work of expression fixed in the tangible medium of

electronic file storage.

Therefore, for GPL'd software to be useful, the GPL, since it governs the

generation of binaries.  Furthermore, notwithstanding the relative

popularity of source-based GNU/Linux distributions like Gentoo, users find

it extremely convenient to receive distribution of binary software.  Such

source code.  GPLv2~\S3 addresses the matter of creation and distribution of

binary versions.

Under GPLv2~\S3, binary versions may be created and distributed under the

terms of GPLv2~\S1--2, so all the material previously discussed applies

here.  However, GPLv2~\S3 must go a bit further.  Access to the software's

source code is an incontestable prerequisite for the exercise of the

fundamental freedoms to modify and improve the software.  Making even

the most trivial changes to a software program at the binary level is

effectively impossible.  GPLv2~\S3 must ensure that the binaries are never

distributed without the source code, so that these freedoms are passed

through the distribution chain.

GPLv2~\S3 permits distribution of binaries, and then offers three options for

distribution of source code along with binaries. The most common and the

least complicated is the option given under GPLv2~\S3(a).

GPLv2~\S3(a) offers the option to directly accompany the source code alongside

the distribution of the binaries.  This is by far the most convenient

option for most distributors, because it means that the source-code

provision obligations are fully completed at the time of binary

distribution (more on that later).

Under GPLv2~\S3(a), the source code provided must be the ``corresponding source

code.''  Here ``corresponding'' primarily means that the source code

provided must be that code used to produce the binaries being distributed.

That source code must also be ``complete''.   GPLv2~\S3's penultimate paragraph

explains in detail what is meant by ``complete''.  In essence, it is all

the material that a programmer of average skill would need to actually use

the source code to produce the binaries she has received.  Complete source

is required so that, if the licensee chooses, she should be able to

exercise her freedoms to modify and redistribute changes.  Without the

complete source, it would not be possible to make changes that were

actually directly derived from the version received.

Furthermore, GPLv2~\S3 is defending against a tactic that has in fact been

seen in GPL enforcement.  Under GPL, if you pay a high price for

a copy 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 architecture).  They then give source code that does

correspond, but withhold the ``incantations'' and build plans they

used to make that source compile into the specialized binaries.

Therefore, GPLv2~\S3 requires that the source code include ``meta-material'' like

scripts, interface definitions, and other material that is used to

``control compilation and installation'' of the binaries.  In this

manner, those further down the distribution chain are assured that

from the sources provided.

Software distribution comes in many

forms.  Embedded manufacturers, for example, have the freedom to put

GPL'd software into mobile devices 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

GPL does provide options when such distribution is unfeasible.

\label{GPLv2s3-medium-customarily}

GPLv2~\S3, therefore, allows source code to be provided on any physical

``medium customarily used for software interchange.''  By design, this

phrase covers a broad spectrum --- the phrase seeks to pre-adapt to

changes in  technology.  When GPLv2 was first published in June

1991, distribution on magnetic tape was still common, and CD was

relatively new.  By 2002, CD was the default.  By 2007, DVD's were the

default.  Now, it's common to give software on USB drives and SD cards.  This

language in the license must adapt with changing technology.

Meanwhile, the binding created by the word ``customarily'' is key.  Many

incorrectly believe that distributing binary on CD and source on the

Internet is acceptable.  In the corporate world in industrialized countries, it is indeed customary to

simply download a CDs' worth of data quickly.  However, even today in the USA, many computer users are not connected to the Internet, and most people connected

Of course, Free Software is licensed, not sold, and there are indeed

restrictions placed on the licensee, but those differences are not likely

to prevent the application of the implied license doctrine to Free

Software, because software licensed under the GPL grants the licensee the

right to make, use, and sell the software, each of which are exclusive

rights of a patent holder. Therefore, although the GPLv2 does not expressly

grant the licensee the right to do those things under any patents the

licensor may have that cover the software or its reasonably contemplated

uses, by licensing the software under the GPLv2, the distributor impliedly

licenses those patents to the GPLv2 licensee with respect to the GPLv2'd

software.

An interesting issue regarding this implied patent license of GPLv2'd

software is what would be considered ``uses of the [software] to which

the parties might reasonably contemplate the product will be put.'' A

clever advocate may argue that the implied license granted by GPLv2 is

larger in scope than the express license in other Free Software

licenses with express patent grants, in that the patent license

clause of many of those other Free  Software licenses are specifically 

limited to the patent claims covered by the code as licensed by the patentee.

In contrast, a GPLv2 licensee, under the doctrine of implied patent license, 

is free to practice any patent claims held by the licensor that cover 

``reasonably contemplated uses'' of the GPL'd code, which may very well 

under which the patented code is distributed, expressly permits such activity.

Further supporting this result is the Federal Circuit's pronouncement that

the recipient of a patented article has, not only an implied license to

make, use, and sell the article, but also an implied patent license to

repair the article to enable it to function properly, Bottom Line Mgmt.,

Inc. v. Pan Man, Inc., 228 F.3d 1352 (Fed. Cir. 2000). Additionally, the

Federal Circuit extended that rule to include any future recipients of the

patented article, not just the direct recipient from the distributor.

This theory comports well with the idea of Free Software, whereby software

is distributed among many entities within the community for the purpose

of constant evolution and improvement. In this way, the law of implied

patent license used by the GPLv2 ensures that the community mutually

benefits from the licensing of patents to any single community member.

Note that simply because GPLv2'd software has an implied patent license does

not mean that any patents held by a distributor of GPLv2'd code become

worthless. To the contrary, the patents are still valid and enforceable

against either:

\begin{enumerate}

 \renewcommand{\theenumi}{\alph{enumi}}

 \renewcommand{\labelenumi}{\textup{(\theenumi)}}

\item any software other than that licensed under the GPLv2 by the patent

  holder, and

\item any party that does not comply with the GPLv2

with respect to the licensed software.

\end{enumerate}

\newcommand{\compB}{$\mathcal{B}$}

\newcommand{\compA}{$\mathcal{A}$}

For example, if Company \compA{} has a patent on advanced Web browsing, but

also licenses a Web browsing program under the GPLv2, then it

cannot assert the patent against any party based on that party's use of 

Company \compA{}'s GPL'ed Web browsing software program, or on that party's

party uses that program without

complying with the GPLv2, then Company \compA{} can assert both copyright

infringement claims against the non-GPLv2-compliant party and

infringement of the patent, because the implied patent license only

extends to use of the software in accordance with the GPLv2. Further, if

Company \compB{} distributes a competitive advanced Web browsing program 

program, Company \compA{} is free to assert its patent against any user or

distributor of that product. It is irrelevant whether Company \compB's

program is also distributed under the GPLv2, as Company \compB{} can not grant

implied licenses to Company \compA's patent.

This result also reassures companies that they need not fear losing their

proprietary value in patents to competitors through the GPLv2 implied patent

license, as only those competitors who adopt and comply with the GPLv2's

terms can benefit from the implied patent license. To continue the

example above, Company \compB{} does not receive a free ride on Company

\compA's patent, as Company \compB{} has not licensed-in and then

redistributed Company A's advanced Web browser under the GPLv2. If Company

\compB{} does do that, however, Company \compA{} still has not lost

competitive advantage against Company \compB{}, as Company \compB{} must then,

when it re-distributes Company \compA's program, grant an implied license

to any of its patents that cover the program. Further, if Company \compB{}

relicenses an improved version of Company A's program, it must do so under

the GPLv2, meaning that any patents it holds that cover the improved version

are impliedly licensed to any licensee. As such, the only way Company

\compB{} can benefit from Company \compA's implied patent license, is if it,

itself, distributes Company \compA's software program and grants an

implied patent license to any of its patents that cover that program.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%% software are created by combination and extension.  There is also the

%% real danger that a choice of law clause will specify a jurisdiction

%% that is hostile to free software principles.

%% % FIXME-LATER: reword into tutorial, \ref to section 7.

%% Our revised version of section 7 makes explicit our view that the

%% inclusion of a choice of law clause by a licensee is the imposition of

%% an additional requirement in violation of the GPL.  Moreover, if a

%% program author or copyright holder purports to supplement the GPL with

%% a choice of law clause, section 7 now permits any licensee to remove

%% that clause.

% FIXME-LATER: does this need to be a section, describing how it was out then in

% then out then in? :)

Finally, the FSF shortened the section on ``How to Apply These

Terms to Your New Programs'' to just the bare essentials.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{The Lesser GPL}

As we have seen in our consideration of the GPL, its text is specifically

into the world as possible, particular tactical considerations

regarding software freedom dictate different means. Extending the

copyleft effect as far as copyright law allows is not always the most

prudent course in reaching the goal. In particular situations, even

those of us with the goal of building a world where all published

software is Free Software realize that full copyleft does not best

serve us. The GNU Lesser General Public License (``GNU LGPL'') was

designed as a solution for such situations.

\section{The First LGPL'd Program}

The first example that FSF encountered where such altered tactics were

needed was when work began on the GNU C Library. The GNU C Library would

become (and today, now is) a drop-in replacement for existing C libraries.

On a Unix-like operating system, C is the lingua franca and the C library

is an essential component for all programs. It is extremely difficult to

construct a program that will run with ease on a Unix-like operating

system without making use of services provided by the C library --- even

if the program is written in a language other than C\@. Effectively, all

user application programs that run on any modern Unix-like system must

make use of the C library.

By the time work began on the GNU implementation of the C libraries, there

were already many C libraries in existence from a variety of vendors.

Every proprietary Unix vendor had one, and many third parties produced

smaller versions for special purpose use. However, our goal was to create

a C library that would provide equivalent functionality to these other C

libraries on a Free Software operating system (which in fact happens today

on modern GNU/Linux systems, which all use the GNU C Library).

Unlike existing GNU application software, however, the licensing

implications of releasing the GNU C Library (``glibc'') under the GPL were

somewhat different. Applications released under the GPL would never

themselves become part of proprietary software. However, if glibc were

released under the GPL, it would require that any application distributed for

the GNU/Linux platform be released under the 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

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

glibc.

At first glance, such an outcome seems like a windfall for Free Software

advocates, since it stops all proprietary software development on

GNU/Linux systems. However, the outcome is a bit more subtle. In a world

where many C libraries already exist, many of which could easily be ported

to GNU/Linux, a GPL'd glibc would be unlikely to succeed. Proprietary

vendors would see the excellent opportunity to license their C libraries

to anyone who wished to write proprietary software for GNU/Linux systems.

The de-facto standard for the C library on GNU/Linux would likely be not

glibc, but the most popular proprietary one.

Meanwhile, the actual goal of releasing glibc under the 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 the Free glibc.

The Lesser GPL was initially conceived to handle this scenario. It was

clear that the existence of proprietary applications for GNU/Linux was

inevitable. Since there were so many C libraries already in existence, a

new one under the GPL would not stop that tide. However, if the new C library

were released under a license that permitted proprietary applications

to link with it, but made sure that the library itself remained Free,

an ancillary goal could be met. Users of proprietary applications, while

licenses, and requires that distribution be halted if such a trump is

known to exist.

LGPLv2.1~\S12 adds the same features as GPLv2~\S8. These sections are

used to allow original copyright holders to forbid distribution in

countries with draconian laws that would otherwise contradict these

licenses.

LGPLv2.1~\S13 sets up the FSF as the steward of the LGPL, just as GPLv2~\S9

does for GPL. Meanwhile, LGPLv2.1~\S14 reminds licensees that copyright

holders can grant exceptions to the terms of LGPL, just as GPLv2~\S10

reminds licensees of the same thing.

Finally, the assertions of no warranty and limitations of liability are

identical; thus LGPLv2.1~\S15 and LGPLv2.1~\S16 are the same as GPLv2~\S11 and \S

12.

As we see, the entire latter half of the license is identical.

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 mechanisms and are enforced precisely the same way.

We strike a difference only in the early portions of the license.

Namely, in the LGPL we go into deeper detail of granting various permissions to

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 the LGPL's Preamble is identical, but the last seven paragraphs

introduce the concepts and reasoning behind creation of the license,

presenting a more generalized and briefer version of the story with which

we began our consideration of the LGPL\@.

In short, FSF designed the LGPL for those edge cases where the freedom of the