@@ -3020,194 +3020,193 @@ encapsulate the judicial and administrative principles established over the
past three decades in the USA concerning the Magnuson-Moss consumer product
definition. First, it states that doubtful cases are resolved in favor of
coverage under the definition. Second, it indicate that the words ``normally
used'' in the consumer product definition refer to a typical or common use of
a class of product, and not the status of a particular user or expected or
actual uses by a particular user. Third, it clearly states that the
existence of substantial non-consumer uses of a product does not negate a
determination that it is a consumer product, unless such non-consumer uses
represent the only significant mode of use of that product.
It should be clear from these added sentences that it is the general mode of
use of a product that determines objectively whether or not it is a consumer
product. One could not escape the effects of the User Products provisions by
labeling what is demonstrably a consumer product in ways that suggest it is
``for professionals'', for example.
\subsubsection{Installation Information}
With the User Products definition complete, The ``Installation Information''
definition uses that to define what those receiving object code inside a User
Product must receive.
Installation Information is information that is ``required to install and
execute modified versions of a covered work \dots from a modified version of
its'' CCS, in the same User Product for which the covered work is conveyed.
GPLv3 provides 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 keys, or other information''.
Note that GPLv3 does not define ``continued functioning'' further. However,
GPLv3 does provide some additional guidance concerning the scope of
GPLv3-compliant action or inaction that distributors of
technically-restricted User Products can take with respect to a downstream
recipient who replaces the conveyed object code with a modified version.
First of all, GPLv3 makes clear that GPLv3 implies no obligation ``to
continue to provide support service, warranty, or updates'' for such a work.
Second, most technically-restricted User Products are designed to communicate
across networks. It is important for both users and network providers to
know when denial of network access to devices running modified versions
becomes a GPL violation. GPLv3 permits denial of access in two cases: ``when
the modification itself materially and adversely affects the operation of the
network,'' and when the modification itself ``violates the rules and
protocols for communication across the network''. The second case is
deliberately drawn in general terms, and it serves as a foundation for
reasonable enforcement policies that respect recipients' right to modify
while recognizing the legitimate interests of network providers.
Note that GPLv3 permits the practice of conveying object code in a mode not
practically susceptible to modification by any party, such as code burned in
ROM or embedded in silicon. The goal of the Installation Information
requirement is to ensure the downstream licensee receives the real right to
modify when the device manufacturer or some other party retains that right.
Accordingly, GPLv3\S6's ante-penultimate paragraph states that the
requirement to provide Installation Information ``does not apply if neither
you nor any third party retains the ability to install modified object code
on the User Product''.
Finally, GPLv3\S6 makes it clear that there is also no requirement to
provide warranty or support for the User Product itself.
\subsection{GPLv3~\S7: Additional Permissions}
\label{GPLv3s7}
The GPL is a statement of permissions, some of which have conditions.
Additional terms --- terms that supplement those of the GPL --- may come to be
placed on, or removed from, GPL-covered code in certain common ways.
Copyleft licensing theorists have generally called
those added terms ``additional permissions'' if they grant
exceptions from the conditions of the GPL, and ``additional requirements'' if
they add conditions to the basic permissions of the GPL\@. The treatment of
additional permissions and additional requirements under GPLv3 is necessarily
asymmetrical, because they do not raise the same interpretive
issues; in particular, additional requirements, if allowed without careful
limitation, could transform a GPL'd program into a non-free one.
With these principles in the background, GPLv3~\S7 answers the following
questions:
\begin{enumerate}
\item How do the presence of additional terms on all or part of a GPL'd program
affect users' rights?
\item When and how may a licensee add terms to code being
distributed under the GPL?
\item When may a licensee remove additional terms?
\end{enumerate}
Additional permissions present the easier case. Since the mid-1990s,
permissive exceptions often appeared alongside GPLv2 with permissive
exceptions to allow combination
permissive exceptions often appeared alongside GPLv2 to allow combination
with certain non-free code. Typically, downstream
stream recipients could remove those exceptions and operate under pure GPLv2.
Similarly, LGPLv2.1 is in essence a permissive variant of GPLv2,
and it permits relicensing under the GPL\@.
These practices are now generalized via GPLv3~\S7.
A licensee may remove any additional permission from
a covered work, whether it was placed by the original author or by an
upstream distributor. A licensee may also add any kind of additional
permission to any part of a work for which the licensee has, or can give,
appropriate copyright permission. For example, if the licensee has written
that part, the licensee is the copyright holder for that part and can
therefore give additional permissions that are applicable to it.
Alternatively, the part may have been written by someone else and licensed,
with the additional permissions, to that licensee. Any additional
permissions on that part are, in turn, removable by downstream recipients.
As GPLv3~\S7\P1 explains, the effect of an additional permission depends on
whether the permission applies to the whole work or a part.
% FIXME-LATER: LGPLv3 will have its own section
Indeed, LGPLv3 is itself simply a list of additional permissions supplementing the
terms of GPLv3. GPLv3\S7 has thus provided the basis for recasting a
formally complex license as an elegant set of added terms, without changing
any of the fundamental features of the existing LGPL\@. LGPLv3 is thus a model for developers wishing to license their works under the
GPL with permissive exceptions. The removability of additional permissions
under GPLv3\S7 does not alter any existing behavior of the LGPL since the LGPL
has always allowed relicensing under the ordinary GPL\@.
\section{GPLv3~\S7: Understanding License Compatibility}
\label{license-compatibility}
A challenge that faced the Free Software community heavily through out the
early 2000s was the proliferation of incompatible Free Software licenses. Of
course, the GPL cannot possibly be compatible with all such licenses.
However, GPLv3
contains provisions that are designed to reduce license incompatibility by
making it easier for developers to combine code carrying non-GPL terms with
GPL'd code.
This license compatibility issue arises for
three reasons. First, the GPL is a strong copyleft license, requiring
modified versions to be distributed under the GPL\@. Second, the GPL states
that no further restrictions may be placed on the rights of recipients.
Third, all other software freedom respecting licenses in common use contain certain
requirements, many of which are not conditions made by the GPL\@. Thus, when
GPL'd code is modified by combination with code covered by another formal
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.
GPLv3 took a new approach to the issue of combining GPL'd code with
code governed by the terms of other software freedom licenses. Traditional
GPLv2 license compatibility theory (which was not explicitly stated in GPLv2
itself, but treated as a license interpretation matter by the FSF) held 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, the FSF historically supplemented that policy with a structure of
exceptions for certain kinds of combinations.
GPLv3~\S7 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.
GPLv3~\S7 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.
As discussed in the previous section of this tutorial, GPLv3~\S7 first and foremost explicitly allows added parts covered by terms with
additional permissions to be combined with GPL'd code. This codifies the
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, GPLv3\S7
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 GPLv3\S7. There
are, of course, limits on the acceptable additional requirements, which to
ensures that enhanced license compatibility does not
defeat the broader software-freedom-defending terms of 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 only in the
pathological case\footnote{Theoretically, a user could collect copyright
assignment from all known contributors and then do this, but this would
indeed be the pathological case.} would a user have the right to do so.
% FIXME-LATER: It would be good to have detailed info on each of 7a-f.
% Here's some commented-out text that might be useful for 7a-b
%% 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