(such as by enabling electronic access to a network server), the distributor

must merely offer equivalent access to copy the source code ``in the same way

through the same place''.  This wording also permits a distributor to offer a

third party access to both object code and source code on a single network

portal or web page, even though the access may include links to different

physical servers.  For example, a downstream distributor may provide a link

to an upstream distributor's server and arrange with the operator of that

server to keep the source code available for copying for as long as the

downstream distributor enables access to the object code.  This codifies

formally the typical historical interpretation of GPLv2.

% FIXME-LATER: perhaps in enforcement section, but maybe here, note about

% ``slow down'' on source downloads being a compliance problem. 

Furthermore, under GPLv3~\S6(d), distributors may charge for the conveyed

object code; however, those who pay to obtain the object code must be given

equivalent and gratis access to obtain the CCS.  (If distributors convey the

object code gratis, distributors must likewise make CCS available without

charge.)  Those who do not obtain the object code from that distributors

(perhaps because they choose not to pay the fee for object code) are outside

the scope of the provision; distributors are under no specific obligation to

give CCS to someone who has not purchased an object code download under

GPLv3~\S6(d).  (Note: this does not change nor impact any obligations under

GPLv3~\S6(b)(2); GPLv3~\S6(d) is a wholly different provision.)

\subsection{GPLv3~\S6(e): Peer-to-Peer Sharing Networks}

Certain decentralized forms of peer-to-peer file sharing present a challenge

to the unidirectional view of distribution that is implicit in GPLv2 and

Draft 1 of GPLv3.  Identification of an upstream/downstream link in

BitTorrent distribution is neither straightforward nor reasonable; such

distribution is multidirectional, cooperative and anonymous.  In peer-to-peer

distribution systems, participants act both as transmitters and recipients of

blocks of a particular file, but they perceive the experience merely as users

and receivers, and not as distributors in any conventional sense.  At any

given moment of time, most peers will not have the complete file.

Meanwhile, GPLv3~\S6(d) permits distribution of a work in object code form

over a network, provided that the distributor offers equivalent access to

copy the Corresponding Source Code ``in the same way through the same

place''.  This wording might be interpreted to permit peer-to-peer

distribution of binaries \textit{if} they are packaged together with the CCS,

but such packaging is impractical, for at least three reasons.  First, even if

the CCS is packaged with the object code, it will only be available to a

non-seeding peer at the end of the distribution process, but the peer will

already have been providing parts of the binary to others in the network.

Second, in practice, peer-to-peer forms of transmission are poorly suited

means for distributing CCS.  In large distributions, packaging CCS with the

object code may result in a substantial increase in file size and

transmission time.  Third, in current practice, CCS packages themselves tend

\textit{not} to be transmitted through BitTorrent --- owing to reduced demand

-- thus, there generally will be too few participants downloading the same

source package at the same time to enable effective seeding and distribution.

GPLv3~\S6(e) addresses these issues.  If a licensee conveys such a work of

object code using peer-to-peer transmission, that licensee is in compliance

with GPLv3~\S6 if the licensee informs other peers where the object code and

its CCS are publicly available at no charge under subsection GPLv3~\S6(d).

The CCS therefore need not be provided through the peer-to-peer system that

was used for providing the binary.

Second, GPLv3\S9 also clarifies that ancillary propagation of a covered work

that occurs as part of the process of peer-to-peer file transmission does not

require acceptance, just as mere receipt and execution of the Program does

not require acceptance.  Such ancillary propagation is permitted without

limitation or further obligation.

% FIXME-LATER: Would be nice to explain much more about interactions between

% the various options of GPLv3~\S6(a-e), which might all be in play at once!

\subsection{User Products, Installation Information and Device Lock-Down}

As discussed in \S~\ref{GPLv3-drm} of this tutorial, GPLv3 seeks to thwart

technical measures such as signature checks in hardware to prevent

modification of GPL'd software on a device.

To address this issue, GPLv3~\S6 requires that parties distributing object

code provide recipients with the source code through certain means.  When

those distributors pass on the CCS, they are also required to pass on any

information or data necessary to install modified software on the particular

device that included it.  (This strategy is not unlike that used in LGPLv2.1

to enable users to link proprietary programs to modified libraries.)

% FIXME-LATER: LGPLv2.1 section should talk about this explicitly and this

%              should be a forward reference here

\subsubsection{User Products}

\label{user-product}

The scope of these requirements is narrow.  GPLv3~\S6 introduces the concept

of a ``User Product'', which includes devices that are sold for personal,

family, or household use.  Distributors are only required to provide

Installation Information when they convey object code in a User Product.

In brief, the right to convey object code in a defined class of ``User

modified version.

This was a compromise that was difficult for the FSF to agree to during the

GPLv3 drafting process.  However, companies and governments that use

specialized or enterprise-level computer facilities reported that they

actually \textit{want} their systems not to be under their own control.

Rather than agreeing to this as a concession, or bowing to pressure, they ask

for this as a \textit{preference}.  It is not clear that the GPL should interfere

here, since the main problem lies elsewhere.

While imposing technical barriers to modification is wrong regardless of

circumstances, the areas where restricted devices are of the greatest

practical concern today fall within the User Product definition.  Most, if

not all, technically-restricted devices running GPL-covered programs are

consumer electronics devices.  Moreover, the disparity in clout between the

manufacturers and these users makes it difficult for the users to reject

technical restrictions through their weak and unorganized market power.  Even

limited to User Products, this provision addresses the fundamental problem.

% FIXME-LATER: link \href to USC 2301

The core of the User Product definition is a subdefinition of ``consumer

product'' adapted from the Magnuson-Moss Warranty Act, a federal

consumer protection law in the USA found in 15~USC~\S2301: ``any tangible

personal property which is normally used for personal, family, or household

purposes.''  The USA has had three decades of experience of liberal

judicial and administrative interpretation of this definition in a manner

favorable to consumer rights.\footnote{The Magnuson-Moss consumer product

  definition itself has been influential in the USA and Canada, having been

  adopted in several state and provincial consumer protection laws.}

Ideally, this body of interpretation\footnote{The FSF, however, was very

  clear that incorporation of such legal interpretation was in no way

  intended to work as a general choice of USA law for GPLv3.} will guide

interpretation of the consumer product subdefinition in GPLv3~\S6, and this

will hopefully provide a degree of legal certainty advantageous to device

manufacturers and downstream licensees alike.

One well-established interpretive principle under Magnuson-Moss is that

ambiguities are resolved in favor of coverage.  That is, in cases where

it is not clear whether a product falls under the definition of consumer

product, the product will be treated as a consumer product.\footnote{16

CFR~\S\ 700.1(a); \textit{McFadden v.~Dryvit Systems, Inc.}, 54

UCC~Rep.~Serv.2d 934 (D.~Ore.~2004).}  Moreover, for a given product,

``normally used'' is understood to refer to the typical use of that type

of product, rather than a particular use by a particular buyer.

Products that are commonly used for personal as well as commercial

purposes are consumer products, even if the person invoking rights is a

commercial entity intending to use the product for commercial

purposes.\footnote{16 CFR \S \ 700.1(a).  Numerous court decisions

interpreting Magnuson-Moss are in accord; see, e.g., \textit{Stroebner

Motors, Inc.~v.~Automobili Lamborghini S.p.A.}, 459 F.~Supp.2d 1028,

1033 (D.~Hawaii 2006).}  Even a small amount of ``normal'' personal use

is enough to cause an entire product line to be treated as a consumer

product under Magnuson-Moss\footnote{\textit{Tandy Corp.~v.~Marymac

Industries, Inc.}, 213 U.S.P.Q.~702 (S.D.~Tex.~1981). In this case, the

court concluded that TRS-80 microcomputers were consumer products, where

such computers were designed and advertised for a variety of users,

including small businesses and schools, and had only recently been

promoted for use in the home.}.

However, Magnuson-Moss is not a perfect fit because in the area of components

of dwellings, the settled interpretation under Magnuson-Moss is under-inclusive.

Depending on how such components are manufactured or sold, they may or may

not be considered Magnuson-Moss consumer products.\footnote{Building

  materials that are purchased directly by a consumer from a retailer, for

  improving or modifying an existing dwelling, are consumer products under

  Magnuson-Moss, but building materials that are integral component parts of

  the structure of a dwelling at the time that the consumer buys the dwelling

  are not consumer products. 16 C.F.R.~\S\S~700.1(c)--(f); Federal Trade

  Commission, Final Action Concerning Review of Interpretations of

  Magnuson-Moss Warranty Act, 64 Fed.~Reg.~19,700 (April 22, 1999); see also,

  e.g., \textit{McFadden}, 54 U.C.C.~Rep.~Serv.2d at 934.}  Therefore, GPLv3

defines User Products as a superset of consumer products that also includes

``anything designed or sold for incorporation into a dwelling.''

Thus, the three sentences in the center of GPLv3's User Product definition

encapsulate the judicial and administrative principles established over the

past three decades in the USA concerning the Magnuson-Moss consumer product

definition.  First, it states that doubtful cases are resolved in favor of

coverage under the definition.  Second, it indicate that the words ``normally

used'' in the consumer product definition refer to a typical or common use of

a class of product, and not the status of a particular user or expected or

actual uses by a particular user.  Third, it clearly states that the

existence of substantial non-consumer uses of a product does not negate a

determination that it is a consumer product, unless such non-consumer uses

represent the only significant mode of use of that product.

It should be clear from these added sentences that it is the general mode of

use of a product that determines objectively whether or not it is a consumer

product.  One could not escape the effects of the User Products provisions by

labeling what is demonstrably a consumer product in ways that suggest it is

``for professionals'', for example.

\subsubsection{Installation Information}

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

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

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