due to (in some cases) mere laziness and (in other cases) policy preference

for some of GPLv2's terms and/or policy opposition to GPLv3's terms.

Given this ``two GPLs world'' is reality, 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 a better

copyleft in the spirit of past GPL's.  Obsession for concision should never

trump software freedom.

The FSF had many different, important goals in seeking to upgrade to GPLv3.

However, one important goal that is often lost in the discussion of policy

minutia is a rather simple but important issue.  Namely, FSF sought to assure

that GPLv3 was more easily internationalized than GPLv2.  In particular, the

FSF sought to ease interpretation of GPL in other countries by replacement of

USA-centric\footnote{See Section~\ref{non-usa-copyright} of this tutorial for

  a brief discussion about non-USA copyright systems.}  copyright phrases and

wording with neutral terminology rooted in description of behavior rather

than specific statue.  As can be seen in the section-by-section discussion of

GPLv3 that follows, nearly every section had changes related to issues of

internationalization.

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

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

GPLv2: ``modify'' ``covered work'', ``propagate'', ``convey'', and

``Appropriate Legal Notices''. 

\subsection{Modify and the Work Based on the Program}

GPLv2 included a defined term, ``work based on the Program'', but also used

the term ``modify'' and ``based on'' throughout the license.  GPLv2's ``work

based on the Program'' definition made use of a legal term of art,

``derivative work'', which is peculiar to USA copyright law.  However,

ironically, the most criticism of USA-specific legal terminology in GPLv2's

``work based on the Program'' definition historically came not primarily from

readers outside the USA, but from those within it\footnote{The FSF noted in

  that it did not generally agree with these views, and expressed puzzlement

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

  other, more difficult legal issues implicated by the GPL.  Nevertheless,

  the FSF argued that it made sense to eliminate usage of local copyright

  terminology to good effect.}.  Admittedly, even though differently-labeled

concepts corresponding to the derivative work are recognized in all copyright

law systems, these counterpart concepts might differ to some degree in scope

and breadth from the USA derivative work.

The goal and intention of GPLv2 was always to cover all rights governed by

relevant copyright law, in the USA and elsewhere.  GPLv3 therefore takes the

task of internationalizing the license further by removing references to

derivative works and by providing a more globally useful definition.  The new

definition returns to 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.  GPLv3 operates to grant this right to

successive generations of users (particularly through the copyleft conditions

set forth in GPLv3~\S5, as described later in this tutorial in its

\S~\ref{GPLv3s5}).  Here in GPLv3~\S0, ``modify'' refers to basic copyright

rights, and then this definition of ``modify'' is used to define ``modified

version of'' and ``work based on,'' as synonyms.

\section{The Covered Work}

GPLv3 uses a common license drafting technique of building upon simpler

definitions to make complex ones.  The Program is a defined term found

throughout GPLv2, and the word ``covered'' and the phrase ``covered by this

license'' are used in tandem with the Program in GPLv2, but not as part of a

definition.  GPLv3 offers a single term ``covered work'', which enables some

of the wording in GPLv3 to be simpler and clearer than its GPLv2

counterparts.

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

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

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

public'' in jurisdictions outside the USA by adding it as a specific example

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.

% FIXME: Appropriate Legal Notices

Note finally that not all defined terms in GPLv3 appear in GPLv3~\S0.

Specifically, those defined terms that are confined in use to a single

section are defined in the section in which they are used.

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

  (sometimes, ``C\&CS'') was so widespread among GPL enforcers that its use

  continues even though GPLv3-focused experts tend to say just the defined

  term of ``Corresponding Source''.}, or, as GPLv3 officially calls it,

``Corresponding Source'', is given in GPLv3~\S1\P4.  This definition is as

broad as necessary to protect users' exercise of their rights under the

GPL\@.  We follow the definition with particular examples to remove any doubt

that they are to be considered Complete Corresponding Source Code.  We wish to

make completely clear that a licensee cannot avoid complying with the

requirements of the GPL by dynamically linking an add-on component to the

original version of a program.

%FIXME: Merge this in with previous paragarph

The definition of Corresponding Source (``Complete Corresponding Source

Code'' in Draft1) is the most complex definition in the license.

% FIXME: This needs work

Though the definition of Complete Corresponding Source Code in the

second paragraph of section 1 is expansive, it is not sufficient to

protect users' freedoms in many circumstances.  For example, a GPL'd

program, or a modified version of such a program, might need to be

signed with a key or authorized with a code in order for it to run on

a particular machine and function properly. Similarly, a program that

produces digitally-restricted files might require a decryption code in

order to read the output.  

% FIXME: FSF third person, and verify it still matches GPLv3 text.

We clarify that the shared libraries and dynamically linked subprograms that

are included in Corresponding Source are those that the work is

``specifically'' designed to require, making it clearer that they do not

include libraries invoked by the work that can be readily substituted by

other existing implementations.

%  FIXME: merge in with a forward-reference to Installation Information.

s long as users are truly in a position to install and run

their modified versions of the program

In our earlier drafts we devoted much care to devising a detailed technical

definition of the cryptographic information that would enable GPL licensees

to install functioning modified versions, without affecting legitimate uses

of encryption.  The result was a provision that some found too complex and

difficult to understand, while others continued to raise concerns about

overinclusion.  In fact, the complexity and its resultant problems were never

necessary, since our underlying goal was quite simple.

In Draft 3 we instead use a definition of ``Installation Information'' in

section 6 that is as simple and clear as that goal.  Installation Information

is information that is ``required to install and execute modified versions of

a covered work \dots from a modified version of its Corresponding Source,''

in the same User Product for which the covered work is conveyed.  We provide

guidance concerning how much information must be provided: it ``must suffice

to ensure that the continued functioning of the modified object code is in no

case prevented or interfered with solely because modification has been

made.''  For example, the information provided would be insufficient if it

enabled a modified version to run only in a disabled fashion, solely because

of the fact of modification (regardless of the actual nature of the

modification).  The information need not consist of cryptographic keys;

Installation Information may be ``any methods, procedures, authorization