@@ -2666,96 +2666,146 @@ exceptions for certain kinds of combinations.
% FIXME: probably mostly still right, needs some updates, though.
Section 7 of GPLv3 implements a more explicit policy on license
compatibility. It formalizes the circumstances under which a licensee may
release a covered work that includes an added part carrying non-GPL terms. We
distinguish between terms that provide additional permissions, and terms that
place additional requirements on the code, relative to the permissions and
requirements established by applying the GPL to the code.
Section 7 first explicitly allows added parts covered by terms with
additional permissions to be combined with GPL'd code. This codifies our
existing practice of regarding such licensing terms as compatible with the
GPL. A downstream user of a combined GPL'd work who modifies such an added
part may remove the additional permissions, in which case the broader
permissions no longer apply to the modified version, and only the terms of
the GPL apply to it.
In its treatment of terms that impose additional requirements, section 7
extends the range of licensing terms with which the GPL is compatible. An
added part carrying additional requirements may be combined with GPL'd code,
but only if those requirements belong to an set enumerated in section 7. We
must, of course, place some limit on the kinds of additional requirements
that we will accept, to ensure that enhanced license compatibility does not
defeat the broader freedoms advanced by the GPL. Unlike terms that grant
additional permissions, terms that impose additional requirements cannot be
removed by a downstream user of the combined GPL'd work, because no such user
would have the right to do so.
Under subsections 7a and 7b, the requirements may include preservation of
copyright notices, information about the origins of the code or alterations
of the code, and different warranty disclaimers. Under subsection 7c, the
requirements may include limitations on the use of names of contributors and
on the use of trademarks for publicity purposes. In general, we permit these
requirements in added terms because many free software licenses include them
and we consider them to be unobjectionable. Because we support trademark fair
use, the limitations on the use of trademarks may seek to enforce only what
is required by trademark law, and may not prohibit what would constitute fair
use.
% FIXME: 7d-f
\section{GPLv3~\S7(e): Peer-to-Peer Sharing Networks}
% FIXME: rewrite a bit, maybe drop reference to bitorrent?
Certain decentralized forms of peer-to-peer file sharing present a challenge
to the unidirectional view of distribution that is implicit in GPLv2 and
Draft 1 of GPLv3. It is neither straightforward nor reasonable to identify
an upstream/downstream link in BitTorrent distribution; such distribution is
multidirectional, cooperative and anonymous. In systems like BitTorrent,
participants act both as transmitters and recipients of blocks of a
particular file, but they see themselves as users and receivers, and not as
distributors in any conventional sense. At any given moment of time, most
peers will not have the complete file.
% FIXME: rewrite a bit.
The GPL permits distribution of a work in object code form over a network,
provided that the distributor offers equivalent access to copy the
Corresponding Source Code ``in the same way through the same place.'' This
wording might be interpreted to permit BitTorrent distribution of binaries if
they are packaged together with the source code, but this impractical, for at
least two reasons. First, even if the source code is packaged with the
binary, it will only be available to a non-seeding peer at the end of the
distribution process, but the peer will already have been providing parts of
the binary to others in the network, functioning rather like a router or a
cache proxy. Second, in practice BitTorrent and similar peer-to-peer forms
of transmission have been less suitable means for distributing source code.
In large distributions, packaging source code with the binary may result in a
substantial increase in file size and transmission time. Source code
packages themselves tend not to be transmitted through BitTorrent owing to
reduced demand. There generally will be too few participants downloading the
same source package at the same time to enable effective seeding and
distribution.
We have made two changes that recognize and facilitate distribution of
covered works in object code form using BitTorrent or similar peer-to-peer
methods. First, under new subsection 6e, if a licensee conveys such a work
using peer-to-peer transmission, that licensee is in compliance with section
6 so long as the licensee knows, and informs other peers where, the object
code and its Corresponding Source are publicly available at no charge under
subsection 6d. The Corresponding Source therefore need not be provided
through the peer-to-peer system that was used for providing the binary.
Second, we have revised section 9 to make clear that ancillary propagation of
a covered work that occurs as part of the process of peer-to-peer file
transmission does not require acceptance, just as mere receipt and execution
of the Program does not require acceptance. Such ancillary propagation is
permitted without limitation or further obligation.
% FIXME: removing additional restrictions
Section 7 requires a downstream user of a covered work to preserve the
non-GPL terms covering the added parts just as they must preserve the GPL, as
long as any substantial portion of those parts is present in the user's
version.
% FIXME: minor rewrites needed
Section 7 points out that GPLv3 itself makes no assertion that an additional
requirement is enforceable by the copyright holder. However, section 7 makes
clear that enforcement of such requirements is expected to be by the
termination procedure given in section 8 of GPLv3.
% FIXME: better context, etc.
Some have questioned whether section 7 is needed, and some have suggested
that it creates complexity that did not previously exist. We point out to
those readers that there is already GPLv2-licensed code that carries
additional terms. One of the objectives of section 7 is to rationalize
existing practices of program authors and modifiers by setting clear
guidelines regarding the removal and addition of such terms. With its
carefully limited list of allowed additional requirements, section 7
accomplishes additional objectives, permitting the expansion of the base of
code available for GPL developers, while also encouraging useful
experimentation with requirements we do not include in the GPL itself.
\section{GPLv3~\S8: A Lighter Termination}
GPLv2 provided for automatic termination of the rights of a person who
copied, modified, sublicensed, or distributed a work in violation of the
license. Automatic termination can be too harsh for those who have committed
an inadvertent violation, particularly in cases involving distribution of
large collections of software having numerous copyright holders. A violator
who resumes compliance with GPLv2 would need to obtain forgiveness from all
copyright holders, but even to contact them all might be impossible.
% FIXME: needs to be updated to describe more complex termination
Section 8 of GPLv3 replaces automatic termination with a non-automatic
termination process. Any copyright holder for the licensed work may opt to
terminate the rights of a violator of the license, provided that the
copyright holder has first given notice of the violation within 60 days of
its most recent occurrence. A violator who has been given notice may make