Changeset - d0821c856b5d
[Not reviewed]
0 1 0
Bradley Kuhn (bkuhn) - 10 years ago 2014-03-21 02:09:36
bkuhn@ebb.org
Various formatting fixes.
1 file changed with 2 insertions and 2 deletions:
0 comments (0 inline, 0 general)
gpl-lgpl.tex
Show inline comments
...
 
@@ -2328,325 +2328,325 @@ 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.
 

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

	
 
\subsection{Propagate}
 

	
 
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 GPL imposes conditions on and the kinds of uses that GPL does not
 
(for the most part) impose conditions on.
 

	
 
Second, ``propagate'' helps globalize GPL in its wording and effect.  When a
 
work is GPL'd, 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.  Yet, 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 never necessarily intended the specific
 
meaning of ``distribution'' that exists under USA (or any other country's)
 
copyright law.
 

	
 
Indeed, 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, comments
 
during GPLv3's drafting process indicated 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.
 
Meanwhile, the copyright laws of many countries, as well as certain
 
international copyright treaties, recognize ``making available to the
 
public'' or ``communication to the public'' as one of the exclusive rights of
 
copyright holders.
 

	
 
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.
 

	
 
Thus, propagation is defined by behavior, and not by categories drawn from
 
some particular national copyright statute.  This helps not only with
 
internationalization, but also factually-based terminology aids in
 
developers' and users' understanding of GPL\@.
 

	
 
\subsection{Convey}
 

	
 
Further to this point, a subset of propagate --- ``convey'' --- is defined.
 
Conveying includes activities that constitute propagation of copies to
 
others.  As with the definition of propagate, GPLv3 thus addresses transfers
 
of copies of software in behavioral rather than statutory terms.  
 

	
 
\subsection{Appropriate Legal Notices}
 

	
 
GPLv2 used the term ``appropriate copyright notice and disclaimer of
 
warranty'' in two places, which is a rather bulk term.  Also, experience with
 
GPLv2 and other licenses that grant software freedom showed throughout the
 
1990s that the scope of types of notices that need preservation upon
 
conveyance were more broad that merely the copyright notices.  The
 
Appropriate Legal Notice definition consolidates the material that GPLv2
 
traditionally required preserved into one definition.
 

	
 
\subsection{Other Defined Terms}
 

	
 
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, and GPLv3~\S1
 
contains those definitions focused on source code.  In this tutorial, those
 
defined terms are discussed in the section where they are defined and/or
 
used.
 

	
 
\section{GPLv3~\S1: Understanding CCS}
 
\label{GPLv3s1}
 

	
 
Ensuring that users have the source code to the software they receive and the
 
freedom to modify remains the paramount right embodied in the Free Software
 
Definition (found in \S~\ref{Free Software Definition} of this tutorial).  As
 
such, GPLv3~\S1 is likely one of the most important sections of GPLv3, as it
 
contains all the defined terms related to this important software freedom.
 

	
 
\subsection{Source Code Definition}
 

	
 
First, GPLv3\~S1 retains GPLv2's definition of ``source code'' and adds an
 
First, 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
 
understood broadly to include 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.
 

	
 
\subsection{CCS Definition}
 

	
 
The definition of CCS\footnote{Note that the preferred term for those who
 
  work regularly 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 called this defined term ``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'' in GPLv3~\S1\P4 is possibly the most complex
 
definition in the license.
 

	
 
The CCS definition is broad so as to protect users' exercise of their rights
 
under the GPL\@.  The definition includes with particular examples to remove
 
any doubt that they are to be considered CCS\@.  GPLv3 seeks to make it
 
completely clear that a licensee cannot avoid complying with the requirements
 
of the GPL by dynamically linking a subprogram component to the original
 
version of a program.  The example also clarifies that the shared libraries
 
and dynamically linked subprograms that are included in Corresponding Source
 
are those that the work is ``specifically'' designed to require, which
 
clarifies that they do not include libraries invoked by the work that can be
 
readily substituted by other existing implementations.  While copyleft
 
advocates never doubted this was required under GPLv2's definition of CCS,
 
making it abundantly clear with an extra example.
 

	
 
GPL, as always, seeks to ensure users are truly in a position to install and
 
run their modified versions of the program; the CCS definition is designed to
 
be expansive to ensure this software freedom.  However, although the
 
definition of CCS 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 be locked-down and restricted.  The
 
requirements in GPLv3~\S6 (discussed in Section~\ref{GPLv3s6} of this
 
tutorial) handle that issue.  (Early drafts of GPLv3 included those
 
requirements in the definition of CCS; however, given that the lock-down
 
issue only comes up in distribution of object code, it is more logical to
 
place those requirements with the parts of GPLv3 dealing directly with object
 
code distribution).
 

	
 
The penultimate paragraph in GPLv3\S2 notes that GPLv3's CCS definition does
 
not require source that can be automatically generated.  Many code
 
generators, preprocessors and take source code as input and sometimes even
 
have output that is still source code.  Source code should always be whatever
 
the original programmer preferred to modify.
 

	
 
GPLv3\S1's final paragraph removes any ambiguity about what should be done on
 
source-only distributions.  Specifically, the right to convey source code
 
that does not compile, does not work, or otherwise is experimental
 
in-progress work is fully permitted, \textit{provided that} no object code
 
form is conveyed as well.  Indeed, when combined with the permissions in
 
GPLv3\S~5, it is clear that if one conveys \textit{only} source code, one can
 
never be required to provide more than that.  One always has the right to
 
modify a source code work by deleting any part of it, and there can be no
 
requirement that free software source code be a whole functioning program.
 

	
 
\subsection{The System Library Exception}
 

	
 
The previous section skipped over one part of the CCS definition, the
 
so-called system library exception.  The ``System Libraries'' definition (and
 
the ``Standard Interface'' and ``Major Component'' definitions, which it
 
includes) are designed as part
 

	
 
to permit certain distribution arrangements that are considered reasonable by
 
copyleft advocates.  The system library exception is designed to allow
 
copylefted software to link with these libraries when such linking would hurt
 
software freedom more than it would hurt proprietary software.
 

	
 
The system library exception has two parts.  Part (a) rewords the GPLv2
 
exception for clarity replaces GPLv2's words ``unless that component itself
 
accompanies the executable'' with ``which is not part of the Major
 
Component''.  The goal here is to not require disclosure of source code of
 
certain libraries, such as necessary Microsoft Windows DLLs (which aren't
 
part of Windows' kernel but accompany it) that are required for functioning
 
of copylefted programs compiled for Windows.
 

	
 
However, in isolation, (a) would be too permissive, as it would sometimes
 
allowing distributors to evade important GPL requirements.  Part (b) reigns
 
in (a).  Specifically, (b) specifies only a few functionalities that a the
 
system library may provide and still qualify for the exception.  The goal is
 
to ensure system libraries are truly adjunct to a major essential operating
 
system component, compiler, or interpreter.  The more low-level the
 
functionality provided by the library, the more likely it is to be qualified
 
for this exception.
 

	
 
Admittedly, the system library exception is a frequently discussed topic of
 
obsessed GPL theorists.  The amount that has been written on the system
 
library exception (both the GPLv2 and GPLv3 versions of it), if included
 
herein,  could easily increase this section of the tutorial to a length
 
greater than all the others.
 

	
 
Like any exception to the copyleft requirements of GPL, would-be GPL
 
violators frequently look to the system library exception as a potential
 
software freedom circumvention technique.  When considering whether or not a
 
library qualifies for the system library exception, here is a pragmatic
 
thesis to consider, based on the combined decades of experience in GPL
 
interpretation of this tutorial's authors: the harder and more strained the
 
reader must study and read the system library exception, the more likely it
 
is that the library in question does not qualify for it.
 

	
 
\section{GPLv3~\S2: Basic Permissions}
 

	
 
GPLv3~\S2 can roughly be considered as an equivalent to GPLv2~\S0 (discussed
 
in \S~\ref{GPLv2s0} of this tutorial).  However, the usual style of
 
improvements found in GPLv3 are found here as well.  For example, the first
 
sentence of GPLv3~\S2 furthers the goal internationalization.  Under the
 
copyright laws of some countries, it may be necessary for a copyright license
 
to include an explicit provision setting forth the duration of the rights
 
being granted. In other countries, including the USA, such a provision is
 
unnecessary but permissible.
 

	
 
GPLv3~\S2\P1 also acknowledges that licensees under the GPL enjoy rights of
 
copyright fair use, or the equivalent under applicable law.  These rights are
 
compatible with, and not in conflict with, the freedoms that the GPL seeks to
 
protect, and the GPL cannot and should not restrict them.
 

	
 
However, note that (sadly to some copyleft advocates) the unlimited freedom
 
to run is confined to the \textit{unmodified} Program.  This confinement is
 
unfortunately necessary since Programs that do not qualify as a User Product
 
in GPLv3~\S6 (see \S~\ref{user-product} in this tutorial) might have certain
 
unfortunate restrictions on the freedom to run\footnote{See
 
  \S~ref{freedom-to-run} of this tutorial for the details on ``the freedom to
 
  \S~\ref{freedom-to-run} of this tutorial for the details on ``the freedom to
 
  run''.}
 

	
 
GPLv3~\S2\P2 distinguishes between activities of a licensee that are
 
permitted without limitation and activities that trigger additional
 
requirements.  Specifically, GPLv3~\S2\P2 guarantees the basic freedoms of
 
privately modifying and running the program.
 

	
 
Also, GPLv3~\S2\P2 gives an explicit permission for a client to provide a
 
copy of its modified software to a contractor exclusively for that contractor
 
to modify it further, or run it, on behalf of the client.  However, the
 
client can \textit{only} exercise this control over its own copyrighted
 
changes to the GPL-covered program.  The parts of the program it obtained
 
from other contributors must be provided to the contractor with the usual GPL
 
freedoms.  Thus, GPLv3 permits users to convey covered works to contractors
 
operating exclusively on the users' behalf, under the users' direction and
 
control, and to require the contractors to keep the users' copyrighted
 
changes confidential, but \textit{only if} the contractor is limited to acting
 
on the users' behalf (just as the users' employees would have to act).
 

	
 
The strict conditions in this ``contractors provision'' are needed so that it
 
cannot be twisted to fit other activities, such as making a program available
 
to downstream users or customers.  By making the limits on this provision
 
very narrow, GPLv3 ensures that, in all other cases, contractors gets the
 
full freedoms of the GPL that they deserve.
 

	
 
The FSF was specifically asked to add this ``contractors provisions'' by
 
large enterprise users of Free Software, who often contract with non-employee
 
developers, working offsite, to make modifications intended for the user's
 
private or internal use, and often arrange with other companies to operate
 
their data centers.  Whether GPLv2 permits these activities is not clear and
 
may depend on variations in copyright law in different jurisdictions.  The
 
practices seem basically harmless, so FSF decided to make it clear they are
 
permitted.
 

	
 
GPLv3~\S2's final paragraph includes an explicit prohibition of sublicensing.
 
This provision ensures that GPL enforcement is always by the copyright
 
holder.  Usually, sublicensing is regarded as a practical convenience or
 
necessity for the licensee, to avoid having to negotiate a license with each
 
licensor in a chain of distribution.  The GPL solves this problem in another
 
way --- through its automatic licensing provision found in GPLv3\~S10 (which
 
is discussed in more detail in \S\~ref{GPLv3s10} of this tutorial).
 

	
 
\section{GPLv3's views on DRM and Device Lock-Down}
 
\label{GPLv3-drm}
 

	
 
The issues of DRM, device lock-down and encryption key disclosure were the
 
most hotly debated during the GPLv3 process.  FSF's views on this were sadly
 
frequently misunderstood and, comparing the provisions related to these
 
issues in the earliest drafts of GPLv3 to  the final version of GPLv3 shows
 
the FSF's willingness to compromise on tactical issues to reach the larger
 
goal of software freedom.
 

	
 
Specifically, GPLv3 introduced provisions that respond to the growing
 
practice of distributing GPL-covered programs in devices that employ
 
technical means to restrict users from installing and running modified
 
versions.  This practice thwarts the expectations of developers and users
 
alike, because the right to modify is one of the core freedoms the GPL is
 
designed to secure.
 

	
 
Technological measures to defeat users' rights.  These measures are often
 
described by such Orwellian phrases, such as ``digital rights management,''
 
which actually means limitation or outright destruction of users' legal
 
rights, or ``trusted computing,'' which actually means selling people
 
computers they cannot trust.  However, these measures are alike in one basic
 
respect.  They all employ technical means to turn the system of copyright law
 
(where the powers of the copyright holder are limited exceptions to general
 
freedom) into a virtual prison, where everything not specifically permitted
 
is utterly forbidden.  This system of ``para-copyright'' was created well
 
after GPLv2 was written --- initially through legislation in the USA and the
 
EU, and later in other jurisdictions as well.  This legislation creates
 
serious civil or even criminal penalties to escape from these restrictions
 
(commonly and aptly called ``jail-breaking a device''), even where the
 
purpose in doing so is to restore the users' legal rights that the technology
 
wrongfully prevents them from exercising.
 

	
 
GPLv2 did not address the use of technical measures to take back the rights
 
that the GPL granted, because such measures did not exist in 1991, and would
 
have been irrelevant to the forms in which software was then delivered to
 
users.  GPLv3 addresses these issues, particularly because copylefted
 
software is ever more widely embedded in devices that impose technical
 
limitations on the user's freedom to change it.
 

	
 
However, FSF always made a clear distinction to avoid conflating these
 
``lock-down'' measures with legitimate applications that give users control,
 
as by enabling them to choose higher levels of system or data security within
 
their networks, or by allowing them to protect the security of their
 
communications using keys they can generate or copy to other devices for
 
sending or receiving messages.  Such technologies present no obstacles to
 
software freedom and the goals of copyleft.
 

	
 
The public GPLv3 drafting process sought to balance these positions of
 
copyleft advocates with various desperate views of the larger
 
Free-Software-using community.  Ultimately, FSF compromised to the GPLv3\S3
 
and GPLv3\S6 provisions that, taken together, are a minimalist set of terms
 
sufficient to protect the software freedom against the threat of invasive
 
para-copyright.
0 comments (0 inline, 0 general)