@@ -2618,192 +2618,242 @@ license that specifies other requirements, and that modified code is then
distributed to others, the freedom of recipients may be burdened by
additional requirements in violation of the GPL. It can be seen that
additional permissions in other licenses do not raise any problems of license
compatibility.
% FIXME: minor rewrites needed
Section 7 relaxes the prohibition on further restrictions slightly by
enumerating, in subsection 7b, a limited list of categories of additional
requirements that may be placed on code without violating GPLv3. The list
includes the items that were listed in Draft 1, though rewritten for clarity.
It also includes a new catchall category for terms that might not obviously
fall within one of the other categories but which are precisely equivalent to
GPLv3 conditions, or which deny permission for activities clearly not
permitted by GPLv3. We have carefully considered but rejected proposals to
expand this list further. We have also rejected suggestions, made by some
discussion committee members, that the Affero clause requirement (7d in Draft
1 and 7b4 in Draft 2) be removed, though we have revised it in response to
certain comments. We are unwavering in our view that the Affero requirement
is a legitimate one, and we are committed to achieving compatibility of the
Affero GPL with GPLv3.
A GPL licensee may place an additional requirement on code for which the
licensee has or can give appropriate copyright permission, but only if that
requirement falls within the list given in subsection 7b. Placement of any
other kind of additional requirement continues to be a violation of the
license. Additional requirements that are in the 7b list may not be removed,
but if a user receives GPL'd code that purports to include an additional
requirement not in the 7b list, the user may remove that requirement. Here
we were particularly concerned to address the problem of program authors who
purport to license their works in a misleading and possibly
self-contradictory fashion, using the GPL together with unacceptable added
restrictions that would make those works non-free software.
\section{GPLv3~\S7: Explicit Compatibility}
% FIXME: probably mostly still right, needs some updates, though.
In GPLv3 we take a new approach to the issue of combining GPL'd code with
code governed by the terms of other free software licenses. Our view, though
it was not explicitly stated in GPLv2 itself, was that GPLv2 allowed such
combinations only if the non-GPL licensing terms permitted distribution under
the GPL and imposed no restrictions on the code that were not also imposed by
the GPL. In practice, we supplemented this policy with a structure of
exceptions for certain kinds of combinations.
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.
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
efforts to enter into compliance and may request that the copyright holder
agree not exercise the right of termination; the copyright holder may choose
to grant or refuse this request.
If a licensee who is in violation of GPLv3 acts to correct the violation and
enter into compliance, and the licensee receives no notice of the past
violation within 60 days, then the licensee need not worry about termination
of rights under the license.
\section{GPLv3~\S9: Acceptance}
% FIXME
\section{GPLv3~\S10: Explicit Downstream License}
\section{GPLv3~\S11: Explicit Patent Licensing}
\label{GPLv3s11}
% FIXME: probably needs a lot of work, these provisions changed over time.
GPLv3 adds a new section on licensing of patents. GPLv2 relies on an implied
patent license. The doctrine of implied license is one that is recognized
under United States patent law but may not be recognized in other
jurisdictions. We have therefore decided to make the patent license grant
explicit in GPLv3. Under section 11, a redistributor of a GPL'd work
automatically grants a nonexclusive, royalty-free and worldwide license for
any patent claims held by the redistributor, if those claims would be
infringed by the work or a reasonably contemplated use of the work.
The patent license is granted both to recipients of the redistributed work
and to any other users who have received any version of the work. Section 11
therefore ensures that downstream users of GPL'd code and works derived from
GPL'd code are protected from the threat of patent infringement allegations
made by upstream distributors, regardless of which country's laws are held to
apply to any particular aspect of the distribution or licensing of the GPL'd
code.
A redistributor of GPL'd code may benefit from a patent license that has been
granted by a third party, where the third party otherwise could bring a
patent infringement lawsuit against the redistributor based on the