This commit introduces two changes. First, the definition of
"Appropriate Legal Notices" in section 0 is deleted. To my
recollection this factored-out definition originated with the
introduction of limited badgeware compatibility in late drafts of GNU
GPLv3. It is made unnecessary by the second change in this commit.
The predecessor GNU GPL versions of 5d were somewhat controversial in
some quarters because of their tension with the fundamental right of
modification. The rewording here attempts to recast it in way that is
intended to minimize the burdens on licensees who modify and
distribute. (There is a separate policy issue, which I do not consider
here, regarding whether any such requirement ought to be in the
license.) Particularly new here is the sentence calling for
construction in favor of the licensee's right to modify.
A subtler change here places further barriers to would-be badgeware
licensors. Replacing the ALN definition in section 0, a limited
category of "Legal Notices" is defined, which includes *textual*
author attributions. Thus requirements to preserve a graphical
"Powered by" logo (or worse) can no longer be grounded in the 5d
clause.
In section 0, "modified version" [of the Program] is defined
synonymously to "work based on the Program". The latter term was used
in GNU GPLv2 (though, curiously, it was defined more broadly). At
least in Copyleft.next at this point, the only place where "based on"
is used is at the beginning of section 5. I have replaced it with the
shorter "Modified Version", used conventional initial-capitalization
for "Modified Version", and, for clarity, have used "Modified Version"
where this section goes on to speak of the modified version as "the
work". Some other minor clarifications were made.
This commit also simplifies and clarifies the 5d "Appropriate Legal
Notices" clause.
Finally, the defined term "aggregate" in the last paragraph gets
conventional initial-capitalization.
The paragraph in question began its life in public GNU GPLv3 drafts as
a simple but broad "downstream shielding" requirement which had
implications for the scope of liberty-or-death. It was narrowed
substantially as a result of discussions with vendors during the GNU
GPLv3 drafting process.
The provision seems to state a kind of safe harbor in relation to
liberty-or-death. Therefore, it is sensible to include it as a
qualification to that section. If there is some further policy goal
worth exploring here it should be done through clarification of the
scope of liberty-or-death.
The deleted paragraph is a relatively complex and narrowly drawn
provision which was introduced in GNU GPLv3 in response to the
Novell-Microsoft deal of late 2006. Oversimplifying a bit here, the
intent of the provision was to prospectively make it a violation of
the license to distribute pursuant to a deal with perceived similar
characteristics (for example, the granting of limited patent
nonasserts by a non-NPE third party to customers of the
distributor). The provision was necessarily drafted with only limited
knowledge of the details of the deal to which it was a response. The
provision was drafted with intentional narrowness out of concern that
it might reach varieties of vendor behavior unrelated to the issues
that motivated it.
This one calls for a return to the drawing board. One must first
soberly ascertain the proper scope of liberty-or-death to determine
whether this provision is even necessary or desirable even at a highly
general level. The narrowness of the provision makes its nonpolitical
value highly dubious. Moreover, if there is some flaw in
liberty-or-death, the clear solution is to amend liberty-or-death
directly.
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.
