GNU GPLv3 section 11 (minus the MS coupon paragraph which was
previously deleted in GPL.next) is concerned with two distinct topics,
patent licenses granted explicitly or by implication from upstream
participants, and third-party patent licenses/covenants granted to
distributors or their customers. GNU GPLv3 sec. 11 has occasionally
been criticized by lawyers for starting out with the grant of a patent
license and then proceeding to define "patent license" for purposes of
subsequent paragraphs.
The main motivation of splitting the section up is to make it easier
to reason about and make changes to each part.
This change follows the deletion of GNU GPLv3 7f and achieves
compatibility of the Apache License 2.0 with GPL.next through an
explicit clarification to the "no further restrictions" clause.
GNU GPLv3 7f was added as a principled, nominally-license-neutral
effort to achieve Apache License 2.0 compatibility (following the
"discovery" that the upstream indemnification clause of the Apache
License 2.0 could not be considered GPL-compatible based on any
distillation of principle from FSF interpretive tradition).
I now believe the more sensible approach, where a principled basis for
GPL compatibility is in serious doubt based on interpretive tradition,
is simply to designate privileged licenses and state that they are
deemed compatible.
This of course has the effect of rewarding relatively powerful or
influential organzations/communities associated with the privileged
licenses, which may be problematic. But this was the political reality
behind the effort to create a principled formal basis for Apache 2.0
license compatibility in GNU GPLv3 anyway.
This change is also motivated by concerns that GNU GPLv3 7f could have
undesirable unintended consequences, though admittedly I have not
encountered any in the past 5 years. There is continuing uncertainty
(in my mind at least) over the degree to which indemnification clauses
are consistent with normative understandings of free software, which
supports the approach I am suggesting here.
This change also has the effect of treating licenses very similar to
the Apache License 2.0 differently from the Apache License 2.0. This
can be justified on the basis of prevailing FLOSS policies against
"license proliferation".
With this change, the Apache License 2.0 is incompatible with
GPL.next, but further changes will fix that.
Splitting section 6 into two sections is justified by its length. I
also anticipate later exploring whether the anti-lockdown provision
(and perhaps other provisions) should be made subject to licensor
opt-in.
The revised-versions section of the GNU GPL, particularly GNU GPLv3,
is necessarily complicated by the FSF's policy decision to leave
authorization to use later versions to the licensor's discretion.
I am not settled on built-in "or later" as a desired policy. I respect
the concerns of GNU GPL licensors who take care both to specify a
version and to deny downstream authorization to use later versions. On
the other hand, most other copyleft licenses have a built-in "or
later" feature. Perhaps "or later" should be a default, but some
authorization for licensor opt-out should be formalized. But already
at least one person who is following GPL.next development has
criticized such a proposal.
For the time being I am proceeding with built-in or-later, modeled
closely on the MPL 2.0 approach. This allows significant
simplification of the revised-versions section.
A different feature of the GNU GPL revised-versions section is its
effort to deal with the possibility of uses of the GNU GPL without
specification of a version. This is quite common in the real world,
but it is of course an academic issue for GPL.next.
Among the more notable changes introduced in GNU GPLv3 is its
replacement of "copy" and "distribute" terminology of GNU GPLv2 with
the exotic defined terms "propagate" and "convey", which make
reference to local copyright law. The use of these terms has been
described as having achieved a greater degree of
"internationalization" of the GNU GPL.
The drafters of GNU GPLv3 assumed there was something sufficiently
problematic about the use in GNU GPLv2 of terms matching those of the
US Copyright Act (copy, distribute, derivative work) that a systematic
approach was taken to avoid reference to such terms. The
propagate/convey scheme was one aspect of this.
This continues to be a worthwhile and interesting experiment. In the
past 5 years of experience of software licensed under GNU GPLv3 the
use of these defined terms has not resulted in any particular problem
or difficulty, nor has it hindered adoption of the license so far as I
can tell.
Nevertheless, for GPL.next I propose that the propagate/convey scheme
be abandoned, because, while harmless and interesting, at the end of
the day it adds a layer of unnecessary marginal interpretive
complexity that appears unjustified by any possible benefit it might
provide.
As a practical matter, it is not really possible to apply "propagate"
and "convey" in typical free software contexts in the way that may
have been envisioned. Since free software development and distribution
involves effectively unquantifiable aggregations of
cross-jurisdictional transfers of software copies, it would seem that
in a typical case it would be quite difficult to pin down which local
law to apply. Of course this "problem", if it is really a problem,
arises under free software licenses using more conventional
terminology too. So nothing is gained by what ultimately appears to be
a superficial attempt to internationalize the terminology (except in a
purely political sense).
Indeed, it is a curious thing that when reasoning about free software
licenses it is practically necessary to hypothesize a harmonized
international system of exclusive copyright rights with equivalent
boundaries. This is so whether one uses an otherwise undefined term
that happens to find some use in one or more English-language local
copyright regimes (e.g. "distribute") or whether one attempts to map
GNU GPLv3 "convey" to some determined local law definition.
A choice of law clause (mainly a contract law concept) is the
traditional way to minimize some of this sort of complexity in other
contexts. The FSF, interestingly, has at times stated the view that
choice of law clauses in free software licenses are GPL-incompatible,
and I consider this to be GNU GPL interpretive orthodoxy. I believe
the historical concern (perhaps justified in some cases) was that of
selection of a jurisdiction that had laws markedly unfriendly to free
software.
For most individuals operating within the universe of GNU GPL-licensed
software and contemplating the differences in terminology between v2
and v3, it will be natural to assume that "propagate" and "convey" are
synonymous to v2's "copy" and "distribute", respectively.
In GNU GPLv3 the "propagate" definition is used mainly to provide the
basis for the "convey" definition. The counterpart term to "convey" in
GNU GPLv2, "distribute", is used in most other widely-used free
software licenses today. I believe it may even be used in some free
software licenses written from a European law perspective (though have
not checked that). True, some of these free software licenses have
choice of law clauses, but most don't. None of this has caused any
difficulty. We are left, then, with the conclusion that the main
benefit of the propagate/convey scheme is a political one. This is not
a good enough reason to keep it.
The definition of "System Libraries" in GPLv3 (used in the
Corresponding Source definition) is unnecessarily complex and
difficult to parse and understand. This commit replaces it with a
definition based on the GPLv2 system library exception but with a few
changes adapted from the version of the system library exception in
the first dicussion draft of GPLv3.
Further work on this definition is necessary; this version can be seen
as something of a placeholder.
Some of this is stylistic, but one notable change is the addition of
an explicit disclaimer of the implied warranty of noninfringement. The
"constitutes an essential part of this license" language appears in a
good deal of warranty disclaimer boilerplate I see in the wild, and so
is *presumably* included for good reason.
I am not sure what the fate of this provision should be; it is already
quite narrowly drawn, particularly in light of its GPLv3 drafting
history. One small change that ought to be noncontroversial is
elimination of the second option for satisfying the provision if
Corresponding Source is not already available: "arrange to deprive
yourself of the benefit of the patent license". The idea that any
licensee would choose this option is preposterous.
Substantially the same sentence is at the end of section 6 of
GPLv2. This sentence seems pointless; who could reasonably argue that,
as a condition of the copyright license, the licensee is responsible
for enforcing compliance? (It would be interesting to research the
early history of this sentence, if possible.)
"The Program" is unmodified by definition from the standpoint of "You"
(a point made even clearer in the redefinition of "The Program") so
"unmodified" is superfluous.
initial sentence of section 5.
This text presumably refers to a conventional patch. If conveying such
a patch is not conveying a "work based on the Program", I cannot see
the basis for binding the licensee to this requirement. Therefore this
text seems superfluous.
now capitalized in accordance with typical legal practice.
Regarding the clarified definition of "the Program", this is motivated
by a concern raised not long after the final release of GPLv3 by,
separately, TI and Sun. The concern was that "the Program" could
somehow be read to mean "all possible GPLv3-licensed works in
existence" (which in turn raised fears about unbounded scope of
certain patent-related provisions). (The noted textual ambiguity has
counterparts in other free software licenses, and is probably
unavoidable on some level owing to limitations on the precision of
English.)
The FSF addressed this issue publicly in this document:
http://www.gnu.org/licenses/gplv3-the-program.html
The use of "particular" in my redefinition here reinforces this
reasonable interpretation.
I don't see what purpose this paragraph serves. If a licensee having
discretion to place additional terms on a work, or a portion of a
work, fails to do so, then there are no additional terms. If a
licensee having discretion to place additional terms on a work/portion
wishes to do so, the licensee will naturally be expected to provide
some customary notice of the applicability of such additional
terms. This is just unnecessary clutter.
lowercase.
The initial public draft of GPLv3 changed the all-caps disclaimers of
GPLv3 to lowercase (more precisely mixed-case) out of concern that
there was no good reason for "shouting". Subsequently, some US lawyers
pointed out the requirement under the Uniform Commercial Code (where
it is applicable) for at least portions of such disclaimers to be
"conspicuous". As noted in the GPLv3 Discussion Draft 3 Rationale:
There is authority under United States law suggesting that effective
warranty disclaimers must be “conspicuous,” and that conspicuousness
can be established by capitalization and is absent when a disclaimer
has the same typeface as the terms surrounding it (see Stevenson
v. TRW, Inc., 987 F.2d 288, 296 (5th Cir. 1993)). We have reason to
doubt that such authority would apply to copyright licenses like the
GPL. Nevertheless, pending further research, we have cautiously
decided to restore the capitalization of both the warranty
disclaimer and the liability limitation in Draft 3.
As noted by @fmarier, MPL 2.0 apparently found less annoying ways of
meeting the conspicuousness requirement. The irony (long noted by
Bradley Kuhn, as I recall) is that putting provisions in all caps
makes them less easy to read. I propose that we not worry about making
such provisions be "conspicuous" while GPL.next remains a draft
license, as this will simply make it harder to develop the content of
the provisions, but the questions of the extent to which the
conspicuousness requirement applies at all, and how it can be met,
should be explored.
It is a common legal practice to capitalize the initial letters of defined terms in a contract or contractlike legal instrument. GPLv3 has occasionally been criticized for using defined terms without conventional capitalization.
This commit deletes a late change to GPLv3, the final section, which
had been drafted in response to arguments made by Axel Metzger
concerning the effects of the US-style warranty and liability
disclaimers under German law. While I like this provision, I must
wonder why it is necessary given that GPLv2 and other widely-used free
software licenses have gotten along fine without anything like it
(similar issues must arise with proprietary software licenses). It
should also be noted that Metzger's concerns may have resonance in US
law. Perhaps the better approach is to attempt improvement of the
disclaimers themselves, and/or to reconsider the idea, rejected early
on in the drafting of GPLv3, of a general severability clause.
This commit simplifies and clarifies the final sentence/paragraph of
section 7. The concern here was uncertainty over the extent to which
the section 7 "allowed additional requirements" went beyond the
limited setting of compatibility with discrete free software
licenses. For example, section 7 notes that it is not a violation of
section 10 to supplement GPLv3 with a differently-worded warranty
disclaimer. The final sentence makes clear that this not only ratifies
the compatibility of differently-worded warranty disclaimers in
licenses traditionally treated as GPL-compatible, but also authorizes
an informal supplementation of the GPLv3 warranty disclaimer.
I changed "or stated as exceptions" to "or stated as exceptions to or
qualifications of", because the term "exception" in GPL contexts has
generally referred only to additional permissions, and application of
the term "exception" to an additional restriction seems confusing, at
least in light of this terminology tradition. (Cf. the original
license of Liberation Fonts.)
This commit deletes the paragraph in section 11 which was intended, as
a hack on a feature of the Microsoft/Novell deal of 2006, to cause
Microsoft patent licenses/covenants granted to Novell customers to be
"automatically extended" to all downstream recipients of the software
associated with the SLES certificates distributed by Microsoft
pursuant to the deal.
Historical evidence shows that this provision was taken somewhat
seriously, and its cleverness and creativity are to be
appreciated. However, it must be admitted that it has served no valid
purpose in the past five years. To my knowledge no one has ever
attempted to invoke the provision (or had need to invoke it) to argue
for the existence of a patent license or covenant, and it would be
exceedingly strange for anyone to have done so. The provision is
worded generally, but it is tied to one deal between two specific
companies and is intended to punish one particular company. Whatever
its political value was in early 2007, the provision today is either a
no-op or serves to intensify anti-GPLv3 FUD. It needs to go.
One can view this provision as a sort of odd exception to the
historical narrowing of the general patent license grant now contained
in paragraphs 1-3 of section 11. Early public drafts of GPLv3 had
featured a "pure distribution" approach to patent licensing. Whether
that narrowing of the patent license grant was good policy or not is
an open question, but it is worth noting that this anti-Microsoft
provision would have been pointless had a pure-distribution patent
licensing policy been retained.
