@@ -303,118 +303,118 @@ 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 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.
Copyright is not a natural state, it is a legal construction. In the US, the
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 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
\defn{disclaim} their copyright (for example, under US copyright law
\defn{disclaim} their copyright (for example, under USA copyright law
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
@@ -2204,212 +2204,212 @@ preferred license. GPLv3 has gained major adoption by many projects, old and
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
term of art, ``derivative work,'' peculiar to US copyright law, we did not
term of art, ``derivative work,'' peculiar to USA copyright law, we did not
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
scope and breadth from the US derivative work was simply a consequence of
scope and breadth from the USA derivative work was simply a consequence of
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
US-specific legal terminology in the ``work based on the Program''
definition has come not primarily from readers outside the US, but
USA-specific legal terminology in the ``work based on the Program''
definition has come not primarily from readers outside the USA, but
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
US law, and they have contended that it attempts, by indirect means,
USA law, and they have contended that it attempts, by indirect means,
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,
to be neatly disjoint under US law.
to be neatly disjoint under USA law.
% 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
to the generalized notion of distribution that exists under US law.
to the generalized notion of distribution that exists under USA law.
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
public'' in jurisdictions outside the US by adding it as a specific example
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.
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''