% gpl-lgpl.tex                                                  -*- LaTeX -*-

%      Tutorial Text for the Detailed Study and Analysis of GPL and LGPL course

%

% Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.

% Copyright (C) 2014                   Bradley M. Kuhn

% License: CC-By-SA-4.0

% The copyright holders hereby grant the freedom to copy, modify, convey,

% Adapt, and/or redistribute this work under the terms of the Creative

% Commons Attribution Share Alike 4.0 International License.

% This text is distributed in the hope that it will be useful, but

% WITHOUT ANY WARRANTY; without even the implied warranty of

% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% You should have received a copy of the license with this document in

% a file called 'CC-By-SA-4.0.txt'.  If not, please visit

% https://creativecommons.org/licenses/by-sa/4.0/legalcode to receive

% the license text.

\newcommand{\defn}[1]{\emph{#1}}

\part{Detailed Analysis of the GNU GPL and Related Licenses}

\begin{center}

{\parindent 0in

\tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{This part} is: \\

\begin{tabbing}

Copyright \= \copyright{} 2003, 2004, 2005, 2006 \= \hspace{.2in} Free Software Foundation, Inc. \\

Copyright \= \copyright{} 2014 \= \hspace{.2in} Bradley M. Kuhn \\

Copyright \= \copyright{} 2014 \= \hspace{.2in} Anthony K. Sebro, Jr. \\

\end{tabbing}

Authors of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} are: \\

Free Software Foundation, Inc. \\

Bradley M. Kuhn \\

David ``Novalis'' Turner \\

Daniel B. Ravicher \\

Tony Sebro \\

John Sullivan

\vspace{.3in}

The copyright holders of \tutorialpartsplit{``Detailed Analysis of the GNU GPL and Related Licenses''}{this part} hereby grant the freedom to copy, modify,

convey, Adapt, and/or redistribute this work under the terms of the Creative

Commons Attribution Share Alike 4.0 International License.  A copy of that

license is available at

\verb=https://creativecommons.org/licenses/by-sa/4.0/legalcode=.  }

\end{center}

\bigskip

\bigskip

\tutorialpartsplit{This tutorial}{This part of the tutorial} gives a

comprehensive explanation of the most popular Free Software copyright

license, the GNU General Public License (``GNU GPL'', or sometimes just

``GPL'') -- both version 2 (``GPLv2'') and version 3 (``GPLv3'') -- and

teaches lawyers, software developers, managers and business people how to use

the GPL (and GPL'd software) successfully both as a community-building

``Constitution'' for a software project, or to incorporate copylefted

software into a new Free Software business and in existing, successful

enterprises.

To successfully benefit of from this part of the tutorial, readers should

have a general familiarity with software development processes.  A vague

understanding of how copyright law applies to software is also helpful.  The

tutorial is of most interest to lawyers, software developers and managers who

run or advise software businesses that modify and/or redistribute software

under terms of the GNU GPL (or who wish to do so in the future), and those

who wish to make use of existing GPL'd software in their enterprise.

Upon completion of this part of the tutorial, successful students can expect

to have learned the following:

\begin{itemize}

  \item The freedom-defending purpose of each term of the GNU GPLv2 and GPLv3.

  \item The differences between GPLv2 and GPLv3.

  \item The redistribution options under the GPLv2 and GPLv3.

  \item The obligations when modifying GPLv2'd or GPLv3'd software.

  \item How to build a plan for proper and successful compliance with the GPL.

  \item The business advantages that the GPL provides.

  \item The most common business models used in conjunction with the GPL.

  \item How existing GPL'd software can be used in existing enterprises.

  \item The basics of the Lesser GPLv2.1 and Lesser GPLv3, and how they

    differs from the GPLv2 and GPLv3, respectively.

  \item The basics to begin understanding the complexities regarding

    derivative and combined works of software.

\end{itemize}

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

% END OF ABSTRACTS SECTION

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

% START OF DAY ONE COURSE

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

\chapter{What Is Software Freedom?}

Study of the GNU General Public License (herein, abbreviated as \defn{GNU

  GPL} or just \defn{GPL}) must begin by first considering the broader world

of software freedom. The GPL was not created from a void, rather, it was

created to embody and defend a set of principles that were set forth at the

founding of the GNU project and the Free Software Foundation (FSF) -- the

organization that upholds, defends and promotes the philosophy of software

freedom. A prerequisite for understanding both of the popular versions of GPL

(GPLv2 and GPLv3) and their terms and conditions is a basic understanding of

the principles behind it.  The GPL family of licenses are unlike almost all

other software licenses in that they are designed to defend and uphold these

principles.

\section{The Free Software Definition}

\label{Free Software Definition}

The Free Software Definition is set forth in full on FSF's website at

\verb0http://fsf.org/0 \verb0philosophy/free-sw.html0. This section presents

an abbreviated version that will focus on the parts that are most pertinent

to the GPL\@.

A particular program grants software freedom to a particular user if that

user is granted the following freedoms:

\begin{itemize}

\item The freedom to run the program, for any purpose.

\item The freedom to study how the program works, and modify it

\item The freedom to redistribute copies.

\item The freedom to distribute copies of  modified versions to others.

\end{itemize}

The focus on ``a particular user'' is particularly pertinent here.  It is not

uncommon for the same version of a specific program to grant these freedoms

to some subset of its user base, while others have none or only some of these

freedoms.  Section~\ref{Proprietary Relicensing} talks in detail about how

this can unfortunately happen even if a program is released under the GPL\@.

Many people refer to software that gives these freedoms as ``Open Source.''

Besides having a different political focus than those who call it Free

Software,\footnote{The political differences between the Free Software

  Movement and the Open Source Movement are documented on FSF's Web site at

  {\tt http://www.fsf.org/licensing/essays/free-software-for-freedom.html}.}

those who call the software ``Open Source'' are often focused on a side

issue.  Specifically, user access to the source code of a program is a

prerequisite to make use of the freedom to modify.  However, the important

issue is what freedoms are granted in the license of that source code.

Software freedom is only complete when no restrictions are imposed on how

these freedoms are exercised.  Specifically, users and programmers can

exercise these freedoms noncommercially or commercially.  Licenses that grant

these freedoms for noncommercial activities but prohibit them for commercial

activities are considered non-free.  Even the Open Source Initiative

(\defn{OSI}) (the arbiter of what is considered ``Open Source'') also rules

such licenses not in fitting with their ``Open Source Definition''.

In general, software for which most or all of these freedoms are

restricted in any way is called ``non-Free Software.''  Typically, the

term ``proprietary software'' is used more or less interchangeably with

``non-Free Software.''  Personally, I tend to use the term ``non-Free

Software'' to refer to noncommercial software that restricts freedom

(such as ``shareware'') and ``proprietary software'' to refer to

commercial software that restricts freedom (such as nearly all of

Microsoft's and Oracle's offerings).

Keep in mind that the none of the terms ``software freedom'', ``open source''

and ``free software'' are not known to be trademarked by any organization in

any jurisdiction.  As such, it's quite common that these terms are abused and

misused by parties who wish to bank on the popularity of software freedom.

When one considers using, modifying or redistributing a software package that

purports to be Open Source or Free Software, one \textbf{must} verify that

the license grants software freedom

Furthermore, throughout this text, we generally prefer the term ``software

freedom'', as this is the least ambiguous term available to describe software

that meets the Free Software Definition.  For example, it is well known and

often discussed that the adjective ``free'' has two unrelated meanings in

English: ``free as in freedom'' and ``free as in price''.  Meanwhile, the

term ``open source'' is even more confusing, because it refers only to the

``freedom to study'', which is merely a subset of one of the four freedoms.

The remainder of this section considers each of each component of software

freedom in detail.

\subsection{The Freedom to Run}

The first tenant of software freedom is the user's fully unfettered right to

run the program.  The software's license must permit any conceivable use of

the software.  Perhaps, for example, the user has discovered an innovative

use for a particular program, one that the programmer never could have

predicted.  Such a use must not be restricted.

It was once rare that this freedom was restricted by even proprietary

software; but such is quite common today. Most End User Licensing Agreements

(EULAs) that cover most proprietary software typically restrict some types of

uses.  Such restrictions of any kind are an unacceptable restriction on

software freedom.

\subsection{The Freedom to Change and Modify}

Perhaps the most useful right of software freedom is the users' right to

change, modify and adapt the software to suit their needs.  Access to the

source code and related build and installation scripts are an essential part

of this freedom.  Without the source code, and the ability to build and

install the binary applications from that source, users cannot effectively

exercise this freedom.

Programmers take direct benefit from this freedom.  However, this freedom

remains important to users who are not programmers.  While it may seem

counterintuitive at first, non-programmer users often exercise this freedom

indirectly in both commercial and noncommercial settings.  For example, users

often seek noncommercial help with the software on email lists and in users

groups.  To make use of such help they must either have the freedom to

recruit programmers who might altruistically assist them to modify their

software, or to at least follow rote instructions to make basic modifications

themselves.

More commonly, users also exercise this freedom commercially.  Each user, or

group of users, may hire anyone they wish in a competitive free market to

modify and change the software.  This means that companies have a right to

hire anyone they wish to modify their Free Software.  Additionally, such

companies may contract with other companies to commission software

modification.

\subsection{The Freedom to Copy and Share}

Users share Free Software in a variety of ways. Software freedom advocates

work to eliminate a fundamental ethical dilemma of the software age: choosing

between obeying a software license and friendship (by giving away a copy of a

program to your friend who likes the software you are using). Licenses that

respect software freedom, therefore, permit altruistic sharing of software

among friends.

The commercial environment also benefits of this freedom.  Commercial sharing

includes selling copies of Free Software: Free Software can be sold at any

price to anyone.  Those who redistribute Free Software commercially also have

the freedom to selectively distribute (i.e., you can pick your customers) and

to set prices at any level that redistributor sees fit.

Of course, most people get copies of Free Software very cheaply (and

sometimes without charge).  The competitive free market of Free Software

tends to keep prices low and reasonable.  However, if someone is willing to

pay billions of dollars for one copy of the GNU Compiler Collection, such a

sale is completely permitted.

Another common instance of commercial sharing is service-oriented

distribution.  For example, some distribution vendors provide immediate

security and upgrade distribution via a special network service.  Such

distribution is not necessarily contradictory with software freedom.

(Section~\ref{Business Models} of this tutorial talks in detail about some

common Free Software business models that take advantage of the freedom to

share commercially.)

\subsection{The Freedom to Share Improvements}

The freedom to modify and improve is somewhat empty without the freedom to

share those improvements.  The Software freedom community is built on the

pillar of altruistic sharing of improved Free Software. Inevitably, a

Free Software project sprouts a mailing list where improvements are shared

freely among members of the development community.  Such noncommercial

sharing is the primary reason that Free Software thrives.

Commercial sharing of modified Free Software is equally important.

For commercial support to exist in a competitive free market, all

developers -- from single-person contractors to large software

companies -- must have the freedom to market their services as

improvers of Free Software.  All forms of such service marketing must

be equally available to all.

For example, selling support services for Free Software is fully

permitted. Companies and individuals can offer themselves as ``the place

to call'' when software fails or does not function properly.  For such a

service to be meaningful, the entity offering that service needs the

right to modify and improve the software for the customer to correct any

problems that are beyond mere user error.

Software freedom licenses also permit any entity to distribute modified

versions of Free Software.  Most Free Software programs have a ``standard

version'' that is made available from the primary developers of the software.

However, all who have the software have the ``freedom to fork'' -- that is,

make available nontrivial modified versions of the software on a permanent or

semi-permanent basis.  Such freedom is central to vibrant developer and user

interaction.

Companies and individuals have the right to make true value-added versions

of Free Software.  They may use freedom to share improvements to

distribute distinct versions of Free Software with different functionality

and features.  Furthermore, this freedom can be exercised to serve a

disenfranchised subset of the user community.  If the developers of the

standard version refuse to serve the needs of some of the software's

users, other entities have the right to create a long- or short-lived fork

to serve that sub-community.

\section{How Does Software Become Free?}

The previous section set forth key freedoms and rights that are referred to

as ``software freedom''.  This section discusses the licensing mechanisms

used to enable software freedom.  These licensing mechanism were ultimately

created as a community-oriented ``answer'' to the existing proprietary

software licensing mechanisms.  Thus, first, consider carefully why

proprietary software exists in the first place.

Proprietary software exists at all only because it is governed by copyright

law.\footnote{This statement is admittedly an oversimplification. Patents and

  trade secrets can cover software and make it effectively non-Free, and one

  can contract away their rights and freedoms regarding software, or source

  code can be practically obscured in binary-only distribution without

  reliance on any legal system.  However, the primary control mechanism for

  software is copyright, and therefore this section focuses on how copyright

  restrictions make software proprietary.} Copyright law, with respect to

software, typically governs copying, modifying, and redistributing that

software (For details of this in the USA, see

\href{http://www.copyright.gov/title17/92chap1.html#106}{\S~106} and

\href{http://www.copyright.gov/title17/92chap1.html#117}{\S~117} of

\href{http://www.law.cornell.edu/uscode/text/17}{Title 17} of the

\textit{United States Code}).\footnote{Copyright law in general also governs

  ``public performance'' of copyrighted works. There is no generally agreed

  definition for public performance of software and both GPLv2 and GPLv3 do

  not govern public performance.} By law (in the USA and in most other

jurisdictions), the copyright holder (most typically, the author) of the work controls

how others may copy, modify and/or distribute the work. For proprietary

software, these controls are used to prohibit these activities. In addition,

proprietary software distributors further impede modification in a practical

sense by distributing only binary code and keeping the source code of the

software secret.

Copyright is not a natural state, it is a legal construction. In the USA, the

Constitution permits, but does not require, the creation of copyright law as

federal legislation.  Software, since it is ``an original works of authorship

fixed in any tangible medium of expression ...  from which they can be

perceived, reproduced, or otherwise communicated, either directly or with the

aid of a machine or device'' (as stated in

\href{http://www.law.cornell.edu/uscode/text/17/102}{17 USC \S~102}), is thus

covered by the statues, and is copyrighted by default.

However, software, in its natural state without copyright, is Free

Software. In an imaginary world with no copyright, the rules would be

different. In this world, when you received a copy of a program's source

code, there would be no default legal system to restrict you from sharing it

with others, making modifications, or redistributing those modified

versions.\footnote{Note that this is again an oversimplification; the

  complexities with this argument are discussed in

  Section~\ref{software-and-non-copyright}.}

Software in the real world is copyrighted by default and is automatically

covered by that legal system.  However, it is possible to move software out

of the domain of the copyright system.  A copyright holder can often

\defn{disclaim} their copyright.  If copyright is disclaimed, the software is

not governed by copyright law.   Software not governed by copyright is in the

``public domain.''

\subsection{Public Domain Software}

Theoretically, an author can create public domain software by disclaiming all

copyright interest on the work. In the USA and other countries that have

signed the Berne convention on copyright, software is copyrighted

automatically by the author when she ``fixes the software into a tangible

medium.''  In the software world, this usually means typing the source code

of the software into a file.

Imagine if authors could truly disclaim those default control of copyright

law.  If so, the software is in the public domain -- no longer covered by

copyright.  Since copyright law is the construction allowing for most

restrictions on software (i.e., prohibition of copying, modification, and

redistribution), removing the software from the copyright system usually

yields software freedom for its users.

Carefully note that software in the public domain is \emph{not} licensed

in any way. It is nonsensical to say software is ``licensed for the

public domain,'' or any phrase that implies the copyright holder gave

expressed permission to take actions governed by copyright law.

By contrast, the copyright holders instead renounced copyright controls on

the work.  The law gave the copyright holder exclusive controls over the

work, and they chose to waive those controls.  Software in the public domain

is absent copyright and absent a license. The software freedoms discussed in

Section~\ref{Free Software Definition} are all granted because there is no

legal system in play to take them away.

Admittedly, a discussion of public domain software is an oversimplified

example.  First, disclaimer of copyright is actually difficult in practice.

Because copyright controls are usually automatically granted and because, in

some jurisdictions, some copyright controls cannot be waived (See

Section~\ref{non-usa-copyright} for further discussion), many copyright

holders sometimes incorrectly believe a work has been placed in the public

domain.  Second, due to aggressive lobbying by the entertainment industry,

the ``exclusive Right'' of copyright, that was supposed to only exist for

``Limited Times'' according to the USA Constitution, appears to be infinite:

simply purchased on the installment plan rather than in whole.  Thus, we must

assume no works of software will fall into the public domain merely due to

the passage of time.

The best example of software known to be in the public domain is software

that is published exclusively produced by the USA government.  Under

\href{http://www.law.cornell.edu/uscode/text/17/105}{17 USC 101 \S~105}, all

works published by the USA Government are not copyrightable.

\subsection{Why Copyright Free Software?}

If simply disclaiming copyright on software yields Free Software, then it

stands to reason that putting software into the public domain is the

easiest and most straightforward way to produce Free Software. Indeed,

some major Free Software projects have chosen this method for making their

software Free. However, most of the Free Software in existence \emph{is}

copyrighted. In most cases (particularly in those of FSF and the GNU

Project), this was done due to very careful planning.

Software released into the public domain does grant freedom to those users

who receive the standard versions on which the original author disclaimed

copyright. However, since the work is not copyrighted, any nontrivial

modification made to the work is fully copyrightable.

Free Software released into the public domain initially is Free, and

perhaps some who modify the software choose to place their work into the

public domain as well. However, over time, some entities will choose to

proprietarize their modified versions. The public domain body of software

feeds the proprietary software. The public commons disappears, because

fewer and fewer entities have an incentive to contribute back to the

commons. They know that any of their competitors can proprietarize their

enhancements. Over time, almost no interesting work is left in the public

domain, because nearly all new work is done by proprietarization.

A legal mechanism is needed to redress this problem. FSF was in fact

originally created primarily as a legal entity to defend software freedom,

and that work of defending software freedom is a substantial part of

its work today. Specifically because of this ``embrace, proprietarize and

extend'' cycle, FSF made a conscious choice to copyright its Free Software,

and then license it under ``copyleft'' terms. Many, including the

developers of the kernel named Linux, have chosen to follow this paradigm.

\label{copyleft-definition}

Copyleft is a legal strategy and mechanism to defend, uphold and propagate software

freedom. The basic technique of copyleft is as follows: copyright the

software, license it under terms that give all the software freedoms, but

use the copyright law controls to ensure that all who receive a copy of

the software have equal rights and freedom. In essence, copyleft grants

freedom, but forbids others to forbid that freedom to anyone else along

the distribution and modification chains.

Copyleft is a general concept. Much like ideas for what a computer might

do must be \emph{implemented} by a program that actually does the job, so

too must copyleft be implemented in some concrete legal structure.

``Share and share alike'' is a phrase that is used often enough to explain the

concept behind copyleft, but to actually make it work in the real world, a

true implementation in legal text must exist. The GPL is the primary

implementation of copyleft in copyright licensing language.

\subsection{Software and Non-Copyright Legal Regimes}

\label{software-and-non-copyright}

The use, modification and distribution of software, like many endeavors,

simultaneously interacts with multiple different legal regimes.  As was noted

early via footnotes, copyright is merely the \textit{most common way} to

restrict users' rights to copy, share, modify and/or redistribute software.

However, proprietary software licenses typically use every mechanism

available to subjugate users.  For example:

\begin{itemize}

\item Unfortunately, despite much effort by many in the software freedom

  community to end patents that read on software (i.e., patents on

  computational ideas), they still ultimately exist.  As such, a software

  program might otherwise be seemly unrestricted, but a patent might read on

  the software and ruin everything for its users.\footnote{See

  \S\S~\ref{gpl-implied-patent-grant},~\ref{GPLv2s7},~\ref{GPLv3s11} for more

  discussion on how the patent system interacts with copyleft, and read

  Richard M.~Stallman's essay,

  \href{http://www.wired.com/opinion/2012/11/richard-stallman-software-patents/}{\textit{Let’s

      Limit the Effect of Software Patents, Since We Can’t Eliminate Them}}

  for more information on the problems these patents present to society.}

\item Digital Restrictions Management (usually called \defn{DRM}) is often

  used to impose technological restrictions on users' ability to exercise

  software freedom that they might otherwise be granted\footnote{See

    \S~\ref{GPLv3s3} for more information on how GPL deals with this issue.}.

  The simplest (and perhaps oldest) form of DRM, of course, is separating

  software source code (read by humans), from their compiled binaries (read

  only by computers).  Furthermore,

  \href{http://www.law.cornell.edu/uscode/text/17/1201}{17 USC 1201} often

  prohibits users legally from circumventing some of these DRM systems.

\item Most EULAs also include a contractual agreement that bind users further

  by forcing them to agree to a contractual, prohibitive software license

  before ever even using the software.

\end{itemize}

Thus, most proprietary software restricts users via multiple interlocking

legal and technological means.  Any license that truly respect the software

freedom of all users must not only grant appropriate copyright permissions,

but also \textit{prevent} restrictions from other legal and technological

means like those listed above.

\subsection{Non-USA Copyright Regimes}

\label{non-usa-copyright}

Generally speaking, copyright law operates similarly enough in countries that

have signed the Berne Convention on Copyright, and software freedom licenses

have generally taken advantage of this international standardization of

copyright law.  However, copyright law does differ from country to country,

and commonly, software freedom licenses like GPL must be considered under the

copyright law in the jurisdiction where any licensing dispute occurs.

Those who are most familiar with the USA's system of copyright often are

surprised to learn that there are certain copyright controls that cannot be

waived nor disclaimed.  Specifically, many copyright regimes outside the USA

recognize a concept of moral rights of authors.  Typically, moral rights are

fully compatible with respecting software freedom, as they are usually

centered around controls that software freedom licenses generally respect,

such as the right of an authors to require proper attribution for their work.

\section{A Community of Equality}

The previous section described the principles of software freedom, a brief

introduction to mechanisms that typically block these freedoms, and the

simplest ways that copyright holders might grant those freedoms to their

users for their copyrighted works of software.  The previous section also

introduced the idea of \textit{copyleft}: a licensing mechanism to use

copyright to not only grant software freedom to users, but also to uphold

those rights against those who might seek to curtail them.

Copyleft, as defined in \S~\ref{copyleft-definition}, is a general term this

mechanism.  The remainder of this text will discuss details of various

real-world implementations of copyleft -- most notably, the GPL\@.

This discussion begins first with some general explanation of what the GPL is

able to do in software development communities.  After that brief discussion

in this section, deeper discussion of how GPL accomplishes this in practice

follows in the next chapter.

Simply put, though, the GPL ultimately creates an community of equality for

both business and noncommercial users.

\subsection{The Noncommercial Community}

A GPL'd code base becomes a center of a vibrant development and user

community.  Traditionally, volunteers, operating noncommercially out of

keen interest or ``scratch an itch'' motivations, produce initial versions

of a GPL'd system.  Because of the efficient distribution channels of the

Internet, any useful GPL'd system is adopted quickly by noncommercial

users.

Fundamentally, the early release and quick distribution of the software

gives birth to a thriving noncommercial community.  Users and developers

begin sharing bug reports and bug fixes across a shared intellectual

commons.  Users can trust the developers, because they know that if the

developers fail to address their needs or abandon the project, the GPL

ensures that someone else has the right to pick up development.

Developers know that the users cannot redistribute their software without

passing along the rights granted by GPL, so they are assured that every

one of their users is treated equally.

Because of the symmetry and fairness inherent in GPL'd distribution,

nearly every GPL'd package in existence has a vibrant noncommercial user

and developer base.

\subsection{The Commercial Community}

By the same token, nearly all established GPL'd software systems have a

vibrant commercial community.  Nearly every GPL'd system that has gained

wide adoption from noncommercial users and developers eventually begins

to fuel a commercial system around that software.

For example, consider the Samba file server system that allows Unix-like

systems (including GNU/Linux) to serve files to Microsoft Windows systems.

Two graduate students originally developed Samba in their spare time and

it was deployed noncommercially in academic environments\footnote{See

  \href{http://turtle.ee.ncku.edu.tw/docs/samba/history}{Andrew Tridgell's

    ``A bit of history and a bit of fun''}}.  However, very

soon for-profit companies discovered that the software could work for them

as well, and their system administrators began to use it in place of

Microsoft Windows NT file-servers.  This served to lower the cost of

running such servers by orders of magnitude. There was suddenly room in

Windows file-server budgets to hire contractors to improve Samba.  Some of

the first people hired to do such work were those same two graduate

students who originally developed the software.

The noncommercial users, however, were not concerned when these two

fellows began collecting paychecks off of their GPL'd work.  They knew

that because of the nature of the GPL that improvements that were

distributed in the commercial environment could easily be folded back into

the standard version.  Companies are not permitted to proprietarize

Samba, so the noncommercial users, and even other commercial users are

safe in the knowledge that the software freedom ensured by GPL will remain

protected.

Commercial developers also work in concert with noncommercial

developers.  Those two now-long-since graduated students continue to

contribute to Samba altruistically, but also get paid work doing it.

Priorities change when a client is in the mix, but all the code is

contributed back to the standard version.  Meanwhile, many other

individuals have gotten involved noncommercially as developers,

because they want to ``cut their teeth on Free Software,'' or because

the problems interest them.  When they get good at it, perhaps they

will move on to another project, or perhaps they will become

commercial developers of the software themselves.

No party is a threat to another in the GPL software scenario because

everyone is on equal ground.  The GPL protects rights of the commercial

and noncommercial contributors and users equally. The GPL creates trust,

because it is a level playing field for all.

\subsection{Law Analogy}

In his introduction to Stallman's \emph{Free Software, Free Society},

Lawrence Lessig draws an interesting analogy between the law and Free

Software. He argues that the laws of a free society must be protected

much like the GPL protects software.  So that I might do true justice to

Lessig's argument, I quote it verbatim:

\begin{quotation}

A ``free society'' is regulated by law. But there are limits that any free

society places on this regulation through law: No society that kept its

laws secret could ever be called free.  No government that hid its

regulations from the regulated could ever stand in our tradition. Law

controls.  But it does so justly only when visibly.  And law is visible

only when its terms are knowable and controllable by those it regulates,

or by the agents of those it regulates (lawyers, legislatures).

This condition on law extends beyond the work of a legislature.  Think

about the practice of law in American courts.  Lawyers are hired by their

clients to advance their clients' interests.  Sometimes that interest is

advanced through litigation. In the course of this litigation, lawyers

write briefs. These briefs in turn affect opinions written by judges.

These opinions decide who wins a particular case, or whether a certain law

can stand consistently with a constitution.

All the material in this process is free in the sense that Stallman means.

Legal briefs are open and free for others to use.  The arguments are

transparent (which is different from saying they are good), and the

reasoning can be taken without the permission of the original lawyers.

The opinions they produce can be quoted in later briefs.  They can be

copied and integrated into another brief or opinion.  The ``source code''

for American law is by design, and by principle, open and free for anyone

to take. And take lawyers do---for it is a measure of a great brief that

it achieves its creativity through the reuse of what happened before.  The

source is free; creativity and an economy is built upon it.

This economy of free code (and here I mean free legal code) doesn't starve

lawyers.  Law firms have enough incentive to produce great briefs even

though the stuff they build can be taken and copied by anyone else.  The

lawyer is a craftsman; his or her product is public.  Yet the crafting is

not charity. Lawyers get paid; the public doesn't demand such work

without price.  Instead this economy flourishes, with later work added to

the earlier.

We could imagine a legal practice that was different --- briefs and

arguments that were kept secret; rulings that announced a result but not

the reasoning. Laws that were kept by the police but published to no one

else. Regulation that operated without explaining its rule.

We could imagine this society, but we could not imagine calling it

``free.''  Whether or not the incentives in such a society would be better

or more efficiently allocated, such a society could not be known as free.

The ideals of freedom, of life within a free society, demand more than

efficient application.  Instead, openness and transparency are the

constraints within which a legal system gets built, not options to be

added if convenient to the leaders.  Life governed by software code should

be no less.

Code writing is not litigation.  It is better, richer, more

productive.  But the law is an obvious instance of how creativity and

incentives do not depend upon perfect control over the products

created.  Like jazz, or novels, or architecture, the law gets built

upon the work that went before. This adding and changing is what

creativity always is.  And a free society is one that assures that its

most important resources remain free in just this sense.\footnote{This

quotation is Copyright \copyright{} 2002, Lawrence Lessig. It is

licensed under the terms of

\href{http://creativecommons.org/licenses/by/1.0/}{the ``Attribution

License'' version 1.0} or any later version as published by Creative

Commons.}

\end{quotation}

In essence, lawyers are paid to service the shared commons of legal

infrastructure.  Few citizens defend themselves in court or write their

own briefs (even though they are legally permitted to do so) because

everyone would prefer to have an expert do that job.

The Free Software economy is a market ripe for experts.  It

functions similarly to other well established professional fields like the

law. The GPL, in turn, serves as the legal scaffolding that permits the

creation of this vibrant commercial and noncommercial Free Software

economy.

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

\chapter{A Tale of Two Copyleft Licenses}

\label{tale-of-two-copylefts}

While determining the proper methodology and criteria to yield an accurate

count remains difficult, the GPL is generally considered one of the most

widely used Free Software licenses.  For most of its history --- for 16 years

from June 1991 to June 2007 --- there was really only one version of the GPL,

version 2.

However, the GPL had both earlier versions before version 2, and, more well

known, a revision to version 3. 

\section{Historical Motivations for the General Public License}

The earliest license to grant software freedom was likely the Berkeley

Software Distribution (``BSD'') license.  This license is typical of what are

often called lax, highly permissive licenses.  Not unlike software in the

public domain, these non-copyleft licenses (usually) grant software freedom

to users, but they do not go to any effort to uphold that software freedom

for users.  The so-called ``downstream'' (those who receive the software and

then build new things based on that software) can restrict the software and

distribute further.

The GNU's Not Unix (``GNU'') project, which Richard M.~Stallman (``RMS'')

founded in 1984 to make a complete Unix-compatible operating system

implementation that assured software freedom for all.  However, RMS saw that

using a license that gave but did not assure software freedom would be

counter to the goals of the GNU project.  RMS invented ``copyleft'' as an

answer to that problem, and began using various copyleft licenses for the

early GNU project programs\footnote{RMS writes more fully about this topic in

  his essay entitled simply

  \href{http://www.gnu.org/gnu/thegnuproject.html}{\textit{The GNU Project}}.

    For those who want to hear the story in his own voice,

    \href{http://audio-video.gnu.org/audio/}{speech recordings} of his talk,

    \textit{The Free Software Movement and the GNU/Linux Operating System}

    are also widely available}.

\section{Proto-GPLs And Their Impact}

The earliest copyleft licenses were specific to various GNU programs.  For

example, \href{http://www.free-soft.org/gpl_history/emacs_gpl.html}{The Emacs

  General Public License} was likely the first copyleft license ever

published.  Interesting to note that even this earliest copyleft license

contains a version of the well-known GPL copyleft clause:

\begin{quotation}

You may modify your copy or copies of GNU Emacs \ldots provided that you also

\ldots cause the whole of any work that you distribute or publish, that in

whole or in part contains or is a derivative of GNU Emacs or any part

thereof, to be licensed at no charge to all third parties on terms identical

to those contained in this License Agreement.

\end{quotation}

This simply stated clause is the fundamental innovation of copyleft.

Specifically, copyleft \textit{uses} the copyright holders' controls on

permission to modify the work to add a conditional requirement.  Namely,

downstream users may only have permission to modify  the work if they pass

along the same permissions on the modified version that came originally to

them.

These original program-specific proto-GPLs give an interesting window into

the central ideas and development of copyleft.  In particular, reviewing them

shows how the text of the GPL we know has evolved to address more of the

issues discussed earlier in \S~\ref{software-and-non-copyright}.

\section{The GNU General Public License, Version 1}

\label{GPLv1}

In January 1989, the FSF announced that the GPL had been converted into a

``subroutine'' that could be reused not just for all FSF-copyrighted

programs, but also by anyone else.  As the FSF claimed in its announcement of

the GPLv1\footnote{The announcement of GPLv1 was published in the

  \href{http://www.gnu.org/bulletins/bull6.html\#SEC8}{GNU'S Bulletin, vol 1,

    number 6 dated January 1989}.  (Thanks very much to Andy Tai for his

  \href{http://www.free-soft.org/gpl_history/}{consolidation of research on

    the history of the pre-v1 GPL's}.)}:

\begin{quotation}

To make it easier to copyleft programs, we have been improving on the

legalbol architecture of the General Public License to produce a new version

that serves as a general-purpose subroutine: it can apply to any program

without modification, no matter who is publishing it.

\end{quotation}

This, like many inventive ideas, seems somewhat obvious in retrospect.  But,

the FSF had some bright people and access to good lawyers when it started.

It took almost five years from the first copyleft licenses to get to a

generalized, reusable GPLv1.  In the context and mindset of the 1980s, this

is not surprising.  The idea of reusable licensing infrastructure was not

only uncommon, it was virtually nonexistent!  Even the early BSD licenses

were simply copied and rewritten slightly for each new use\footnote{It

  remains an interesting accident of history that the early BSD problematic

  ``advertising clause'' (discussion of which is somewhat beyond the scope of

  this tutorial) lives on into current day, simply because while the

  University of California at Berkeley gave unilateral permission to remove

  the clause from \textit{its} copyrighted works, others who adapted the BSD

  license with their own names in place of UC-Berkeley's never have.}.  The

GPLv1's innovation of reuable licensing infrastructure, an obvious fact

today, was indeed a novel invention for its day\footnote{We're all just

  grateful that the FSF also opposes business method patents, since the FSF's

  patent on a ``method for reusable licensing infrastructure'' would have

  not expired until 2006!}.

\section{The GNU General Public License, Version 2}

The GPLv2 was released two and a half years after GPLv1, and over the

following sixteen years, it became the standard for copyleft licensing until

the release of GPLv3 in 2007 (discussed in more detail in the next section).

While this tutorial does not discuss the terms of GPLv1 in detail, it is

worth noting below the three key changes that GPLv2 brought:

\begin{itemize}

\item Software patents and their danger are explicitly mentioned, inspiring

  (in part) the addition of GPLv2~\S\S5--7.  (These sections are discussed in

  detail in \S~\ref{GPLv2s5}, \S~\ref{GPLv2s6} and \S~\ref{GPLv2s7} of this

  tutorial.)

\item GPLv2~\S2's copyleft terms are expanded to more explicitly discuss the

  issue of combined works.  (GPLv2~\S2 is discussed in detail in

  \S~\ref{GPLv2s2} in this tutorial).

\item GPLv2~\S3 includes more detailed requirements, including the phrase

 ``the scripts used to control compilation and installation of the

  executable'', which is a central component of current GPLv2 enforcement

  .  (GPLv2~\S3 is discussed in detail in

  \S~\ref{GPLv2s3} in this tutorial).

\end{itemize}

The next chapter discusses GPLv2 in full detail, and readers who wish to dive

into the section-by-section discussion of the GPL should jump ahead now to

that chapter.  However, the most interesting fact to note here is how GPLv2

was published with little fanfare and limited commentary.  This contrasts

greatly with the creation of GPLv3.

\section{The GNU General Public License, Version 3}

RMS began drafting GPLv2.2 in mid-2002, and FSF ran a few discussion groups

during that era about new text of that license.  However, rampant violations

of the GPL required more immediate attention of FSF's licensing staff, and as

such, much of the early 2000's was spent doing GPL enforcement

work\footnote{More on GPL enforcement is discussed in \tutorialpartsplit{a

    companion tutorial, \texit{A Practical Guide to GPL

      Compliance}}{Part~\ref{gpl-compliance-guide} of this tutorial}.}.  In

2006, FSF began in earnest drafting work for GPLv3.

The GPLv3 process began in earnest in January 2006.  It became clear that

many provisions of the GPL could benefit from modification to fit new

circumstances and to reflect what the entire community learned from

experience with version 2.  Given the scale of revision it seems proper to

approach the work through public discussion in a transparent and accessible

manner.

The GPLv3 process continued through June 2007, culminating in publication of

GPLv3 and LGPLv3 on 29 June 2007, AGPLv3 on 19 November 2007, and the GCC

Runtime Library Exception on 27 January 2009.

All told, four discussion drafts of GPLv3, two discussion drafts of LGPLv3

and two discussion drafts of AGPLv3 were published and discussed.

Ultimately, FSF remained the final arbiter and publisher of the licenses, and

RMS himself their primary author, but input was sought from many parties, and

these licenses do admittedly look and read more like legislation as a result.

Nevertheless, all of the ``v3'' group are substantially better and improved

licenses.

GPLv3 and its terms are discussed in detail in Chapter\~ref{GPLv3}.

\section{The Innovation of Optional ``Or Any Later'' Version}

An interesting fact of all GPL licenses is that the are ultimate multiple

choices for use of the license.  The FSF is the primary steward of GPL (as

discussed later in \S~\ref{GPLv2s9} and \S~\ref{GPLv2s14}).  However, those

who wish to license works under GPL are not required to automatically accept