and final binary --- is a derivative work created by copying verbatim code

from the LGPL'd software.

For efficiency, when a compiler turns source code into object code, it

sometimes places literal portions of the copyrighted library code into the

object code for an otherwise separate independent work. In the normal

scenario, the derivative would not be created until final assembly and

linking of the executable occurred. However, when the compiler does this

efficiency optimization, at the intermediate object code step, a

derivative work is created.

LGPLv2.1~\S5\P4 is designed to handle this specific case. The intent of

the license is clearly that simply compiling software to ``make use'' of

the library does not in itself cause the compiled work to be a ``work

based on the library.''  However, since the compiler copies verbatim,

copyrighted portions of the library into the object code for the otherwise

separate and independent work, it would actually cause that object file to be a

``work based on the library.''  It is not FSF's intent that a mere

compilation idiosyncrasy would change the requirements on the users of the

LGPLv2.1'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 was worried about

this edge condition. The intent of clarifying this edge condition is

primarily to quell the worries of software engineers who understand the

level of verbatim code copying that a compiler often does, and to help

them understand that the full implications of LGPLv2.1 are the same regardless

of the details of the compilation progress.

\section{LGPLv2.1~\S6 \& LGPLv2.1~\S5: Combining the Works}

\label{lgpl-section-6}

Now that we have 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

LGPLv2.1~\S6\@. LGPLv2.1~\S6 is much like GPLv2~\S3, 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 LGPLv2.1~\S6 to make sure

that a user who wishes to modify or update the library can do so.

LGPLv2.1~\S6 lists five choices with regard to supplying library source

and granting the freedom to modify that library source to users. We

will first consider the option given by \S~6(b), which describes the

most common way currently used for LGPLv2.1 compliance on a ``work that

uses the library.''

LGPLv2.1~\S6(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 uses the library.''  However, all modern shared

library mechanisms function as such, and thus LGPLv2.1~\S6(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.

LGPLv2.1~\S6(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 ``work

based on the library,'' so that the user can relink the application and

build a new binary.

The remaining options in LGPLv2.1~\S6 are very similar to the other choices

provided by GPLv2~\S3. There are some additional options, but time does

not permit us in this course to go into those additional options. In

almost all cases of distribution under LGPL, either LGPLv2.1~\S6(a) or LGPLv2.1~\S6(b) are

exercised.

\section{Distribution of the Combined Works}

Essentially, ``works based on the library'' must be distributed under the

same conditions as works under full GPL\@. In fact, we note that 

LGPLv2.1~\S2 is nearly identical in its terms and requirements to GPLv2~\S2.

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 the LGPL and the GPL cover the following

conditions:

\begin{itemize}

\item Allowing a licensing ``upgrade'' from the LGPL to the GPL\@ (in LGPLv2.1~\S3)

\item Binary distribution of the library only, covered in LGPLv2.1~\S4,

  which is effectively equivalent to LGPLv2.1~\S3

\item Creating aggregates of libraries that are not derivative works of

  each other, and distributing them as a unit (in LGPLv2.1~\S7)

\end{itemize}

Due to time constraints, we cannot cover these additional terms in detail,

but they are mostly straightforward. The key to understanding LGPLv2.1 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 LGPLv2.1 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}

Since GPL'd software is now extremely prevalent through the industry, it

is useful to have some basic knowledge about using GPL'd software in

business and how to build business models around GPL'd software.

\section{Using GPL'd Software In-House}

As discussed in Sections~\ref{GPLv2s0} and~\ref{GPLv2s5} of this tutorial,

the GPL only governs the activities of copying, modifying and

distributing software programs that are not governed by the license.

Thus, in FSF's view, simply installing the software on a machine and

using it is not controlled or limited in any way by the GPL\@. Using Free

Software in general requires substantially fewer agreements and less

license compliance activity than any known proprietary software.

Even if a company engages heavily in copying the software throughout the

enterprise, such copying is not only permitted by GPLv2~\S\S1 and 3, but it is

encouraged!  If the company simply deploys unmodified (or even modified)

Free Software throughout the organization for its employees to use, the

obligations under the license are very minimal. Using Free Software has a

substantially lower cost of ownership --- both in licensing fees and in

licensing checking and handling -- than the proprietary software

equivalents.

\section{Business Models}

\label{Business Models}

Using Free Software in house is certainly helpful, but a thriving

market for Free Software-oriented business models also exists. There is the

traditional model of selling copies of Free Software distributions.

Many companies make substantial revenue

from this model. Some choose this model because they have

found that for higher-end hardware, 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'd software in particular (because IBM can be assured that proprietary

versions of the same software will not exist to compete on their hardware)

is the right choice.

For example, charging a ``convenience fee'' for Free Software,

when set at a reasonable price (around \$60 or so), can produce some

profit. Even though Red Hat's system is fully downloadable on their

Web site, people still go to local computer stores and buy copies of their

box set, which is simply a printed version of the manual (available under

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'd software. The GPL is

central to their success, because it ensures 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). Cygnus Solutions, a company started in the

early 1990s, was able to grow steadily simply by providing services

for GCC --- mostly consisting of new ports of GCC to different or new,

embedded targets. Eventually, Cygnus was so successful that

it was purchased by Red Hat where it remains a profitable division.

However, there are very small companies that compete in

this space. Because the code-base is protected by the GPL, it creates and

demands industry trust. Companies can cooperate on the software and

improve it for everyone. Meanwhile, companies who rely on GCC for their

work are happy to pay for improvements, and for ports to new target

platforms. Nearly all the changes fold back into the standard

versions, and those forks that exist remain freely available.

\medskip

\label{Proprietary Relicensing}

A final common business model that is perhaps the most controversial is

proprietary relicensing of a GPL'd code base. This is only an option for

Some companies use this to their

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 at best problematic and at worst predatory 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

software as Free Software. Indeed, the company will surely use such code

contributions in proprietary versions licensed for fees.

\section{Ongoing Compliance}

GPL compliance is in fact a very simple matter --- much simpler than

typical proprietary software agreements and EULAs. Usually, the most

difficult hurdle is changing from a proprietary software mindset to one

that seeks to foster a community of sharing and mutual support. Certainly

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 {\em modified}

versions of GPL'd software, the burden is a bit higher, but not by

much. The glib answer is that by releasing the whole product as Free

Software, it is always easy to comply with the GPL. However,

admittedly to the dismay of FSF, many modern and complex software

systems are built using both proprietary and GPL'd components that are

not legally derivative works of each other. Sometimes, it is easier simply to

improve existing GPL'd application than to start from scratch. In

exchange for that benefit, the license requires that the modifier gives

back to the commons that made the work easier in the first place. It is a

reasonable trade-off and a way to help build a better world while also

making a profit.

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 $<$licensing@fsf.org$>$.

%FIXME-LATER: should have \tutorialpart

If you are particularly interested in matters of GPL compliance, we

recommend the next two parts, which include both recommendations on good

compliance and compliance case studies.

% =====================================================================

% END OF FIRST DAY SEMINAR SECTION

% =====================================================================

%%  LocalWords:  Sebro Novalis Ravicher GPLv GPL'd copylefted LGPLv OSI USC

%%  LocalWords:  noncommercially counterintuitive Berne copyrightable DRM UC

%%  LocalWords:  proprietarize proprietarization Stallman's Tridgell's RMS

%%  LocalWords:  Lessig Lessig's Stallman Proto GPLs proto Tai pre GPL's ful

%%  LocalWords:  legalbol AGPLv Runtime licensor licensors relicense UCITA

%%  LocalWords:  unprotectable Intl nd th Kepner Tregoe Bando Indust Mitel

%%  LocalWords:  Iqtel Bateman Mitek Arce protectable hoc faire de minimis

%%  LocalWords:  Borland Int'l uncopyrightable LLC APIs Ent Connectix DVD's

%%  LocalWords:  redistributor diachronic unshared subpart redistributors

%%  LocalWords:  CDs userbase reshifts licensor's distributee impliedly Mgmt

%%  LocalWords:  patentee  relicenses irrevocability Jacobsen Katzer TRW CCS

%%  LocalWords:  Unfreedonia administrivia Relicensing impermissibly centric

%%  LocalWords:  permissibility firehose bytecode minified Javascript DLLs

%%  LocalWords:  preprocessors functionalities offsite sublicensing DMCA CFR

%%  LocalWords:  anticircumvention WIPO BitTorrent multidirectional Magnuson

%%  LocalWords:  subdefinition Dryvit Stroebner Tandy TRS superset LGPL SLES

%%  LocalWords:  cryptographic relicensing removability sublicensed Novell

%%  LocalWords:  anticompetitive administrability sublicensable licensable

%%  LocalWords:  sublicense sublicensees sublicenses affixation Novell's

%%  LocalWords:  severability Affero LGPL'd lingua franca glibc facto LGPL's

%%  LocalWords:  relicensed runtime subunits relink downloadable MontaVista

%%  LocalWords:  CodeSourcery OpenTV MySQL TrollTech