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

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

it is possible for a copyright holder to engage in conduct resulting

in abandonment of copyright).  If copyright is disclaimed, the software is

effectively no longer restricted by copyright law.   Software not restricted 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

new, but many projects have not upgraded due to (in some cases) mere laziness

and (in other cases) policy preference for some of GPLv2's terms.

Given this ``two GPLs'' world is the one we all live in, it makes sense to

consider GPLv3 in terms of how it differs from GPLv2.  Also, most of the best

GPL experts in the world must deal regularly with both licenses, and

admittedly have decades of experience of GPLv2 while the most experience with

GPLv3 that's possible is by default less than a decade.

These two factors usually cause even new students of GPL to start with GPLv2

and move on to GPLv3, and this tutorial follows that pattern.

Overall, the changes made in GPLv3 admittedly \textit{increased} the

complexity of the license.  The FSF stated at the start of the GPLv3 process

that they would have liked to oblige those who have asked for a simpler and

shorter GPL\@.  Ultimately, the FSF gave priority to making GPLv3 do the job

that needs to be done to build a better copyleft.  Obsession for concision

should never trump software freedom.

\section{GPLv3~\S0: Giving In On ``Defined Terms''}

One of lawyers' most common complaints about GPLv2 is that defined terms in

the document appear throughout.  Most licenses define terms up-front.

However, GPL was always designed both as a document that should be easily

understood both by lawyers and by software developers: it is a document

designed to give freedom to software developers and users, and therefore it

should be comprehensible to that constituency.

Interestingly enough, one coauthor of this tutorial who is both a lawyer and

a developer pointed out that in law school, she understood defined terms more

quickly than other law students precisely because of her programming

background.  For developers, having \verb0#define0 (in the C programming

language) or other types of constants and/or macros that automatically expand

in the place where they are used is second nature.  As such, adding a defined

terms section was not terribly problematic for developers, and thus GPLv3

adds one.  Most of these defined terms are somewhat straightforward and bring

forward better worded definitions from GPLv2.  Herein, this tutorial

discusses a few of the new ones.

% FIXME: it's now five, ``Modify''

GPLv3~\S0 includes definitions of four new terms not found in any form in

GPLv2: ``covered work'', ``propagate'', ``convey'', and ``Appropriate Legal

Notices''.

% FIXME: Transition, GPLv2 ref needed.

Although the definition of ``work based on the Program'' made use of a legal

believe that this presented difficulties as significant as those associated

with the use of the term ``distribution.''  After all, differently-labeled

concepts corresponding to the derivative work are recognized in all copyright

law systems.  That these counterpart concepts might differ to some degree in

varying national treatment of the right of altering a copyrighted work.

%FIXME: should we keep this? maybe a footnote?

Ironically, the criticism we have received regarding the use of

from those within it, and particularly from members of the technology

licensing bar.  They have argued that the definition of ``work based

on the Program'' effectively misstates what a derivative work is under

to extend the scope of copyleft in ways they consider undesirable.

They have also asserted that it confounds the concepts of derivative

and collective works, two terms of art that they assume, questionably,

% FIXME: As above

We do not agree with these views, and we were long puzzled by the

energy with which they were expressed, given the existence of many

other, more difficult legal issues implicated by the GPL.

Nevertheless, we realized that here, too, we can eliminate usage of

local copyright terminology to good effect.  Discussion of GPLv3 will

be improved by the avoidance of parochial debates over the

construction of terms in one imperfectly-drafted copyright statute.

Interpretation of the license in all countries will be made easier by

replacement of those terms with neutral terminology rooted in

description of behavior.

%FIXME: GPLv3, reword a bit.

Draft 2 therefore takes the task of internationalizing the license

further by removing references to derivative works and by providing a

more globally useful definition of a work ``based on'' another work.

We return to the basic principles of users' freedom and the common

elements of copyright law.  Copyright holders of works of software

have the exclusive right to form new works by modification of the

original, a right that may be expressed in various ways in different

legal systems.  The GPL operates to grant this right to successive

generations of users, particularly through the copyleft conditions set

forth in section 5 of GPLv3, which applies to the conveying of works

based on the Program.  In section 0 we simply define a work based on

another work to mean ``any modified version for which permission is

necessary under applicable copyright law,'' without further qualifying

the nature of that permission, though we make clear that modification

includes the addition of material.\footnote{We have also removed the

paragraph in section 5 that makes reference to ``derivative or

collective works based on the Program.''}

%FIXME: transition

While ``covered by this license'' is a phrase found in GPLv2, defining it

more complete in a single as ``covered work'' enables some of the wording in

GPLv3 to be simpler and clearer than its GPLv2 counterparts.

% FIXME: does propagate  definition still work the same way in final draft?

The term ``propagate'' serves two purposes.  First, ``propagate'' provides a

simple and convenient means for distinguishing between the kinds of uses of a

work that the GPL imposes conditions on and the kinds of uses that the GPL

does not (for the most part) impose conditions on.

Second, ``propagate'' furthers our goal of making the license as global as

possible in its wording and effect.  When a work is licensed under the GPL,

the copyright law of some particular country will govern certain legal issues

arising under the license.  A term like ``distribute'' or its equivalent in

languages other than English, is used in several national copyright statutes.

Practical experience with GPLv2 revealed the awkwardness of using the

term ``distribution'' in a license intended for global use.  

The scope of ``distribution'' in the copyright context can differ from

country to country.  The GPL does not seek to necessarily use the specific

meaning of ``distribution'' that exists under United States copyright law or

any other country's copyright law.

%FIXME: rewrite, FSF third person,e tc.

Even within a single country and language, the term distribution may be

ambiguous; as a legal term of art, distribution varies significantly in

meaning among those countries that recognize it.  For example, we have been

told that in at least one country distribution may not include network

transfers of software but may include interdepartmental transfers of physical

copies within an organization.  In many countries the term ``making available

to the public'' or ``communicating to the public'' is the closest counterpart

Therefore, the GPL defines the term ``propagate'' by reference to activities

that require permission under ``applicable copyright law'', but excludes

execution and private modification from the definition.  GPLv3's definition

also gives examples of activities that may be included within ``propagation''

but it also makes clear that, under the copyright laws of a given country,

``propagation'' may include other activities as well.

% FIXME: probably merge this in

Propagation is defined by behavior, and not by categories drawn from some

particular national copyright statute.  We believe that such factually-based

terminology has the added advantage of being easily understood and applied by

individual developers and users.

% FIXME: transition here to convey definition, maybe with \subsection {},

%        also maybe with: Similar is true with the term ``convey''.

we have further internationalized the license by removing references to

distribution and replacing them with a new factually-based term,

``conveying.'' Conveying is defined to include activities that constitute

propagation of copies to others.  With these changes, GPLv3 addresses

transfers of copies of software in behavioral rather than statutory terms.

At the same time, we have acknowledged the use of ``making available to the

in the definition of ``propagate.'' We decided to leave the precise

definition of an organizational licensee, and the line drawn between

licensees and other parties, for determination under local law.

% FIXME: paragraph number change , and more on Convey once definition comes.

The third paragraph of section 2 represents another effort to compensate for

variation in national copyright law.  We distinguish between propagation that

enables parties other than the licensee to make or receive copies, and other

forms of propagation.  As noted above, the meaning of ``distribution'' under

copyright law varies from country to country, including with respect to

whether making copies available to other parties (such as related public or

corporate entities) is ``distribution.'' ``Propagation,'' however, is a term

not tied to any statutory language.  Propagation that does not enable other

parties to make or receive copies --- for example, making private copies or

privately viewing the program --- is permitted unconditionally.  Propagation

that does enable other parties to make or receive copies is permitted as

``distribution,'' subject to the conditions set forth in sections 4--6.

% FIXME: Appropriate Legal Notices

\section{GPLv3~\S1: Understanding CCS}

% FIXME: Talk briefly about importance of CCS and reference compliance guide

% FIXME: verify this still matches final GPLv3 text.

% FIXME:  link to GPLv2 tutorial sections if possible and where appropriate.

GPLv3\~S1 retains GPLv2's definition of ``source code'' and adds an explicit

definition of ``object code'' as ``any non-source version of a work''.

Object code is not restricted to a narrow technical meaning and is to be

understood broadly as including any form of the work other than the preferred

form for making modifications to it.  Object code therefore includes any kind

of transformed version of source code, such as bytecode or minified

Javascript.  The definition of object code also ensures that licensees cannot

escape their obligations under the GPL by resorting to shrouded source or

obfuscated programming.

% FIXME: CCS Coresponding Source updated to newer definition in later drafts

Keeping with the desire to ``round up'' definitions that were spread

throughout the text of GPLv2, the definition of CCS\footnote{Note that the

  preferred term by those who work with both GPLv2 and GPLv3 is ``Complete

  Corresponding Source'', abbreviated to ``CCS''.  Admittedly, the word

  ``complete'' no longer appears in GPLv3 (which uses the word ``all''

  instead).  However, both GPLv2 and the early drafts of GPLv3 itself used

  the word complete, and early GPLv3 drafts even included the phrase

  ``Complete Corresponding Source''.  Meanwhile, use of the acronym ``CCS''