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.
Section 9 of GPLv3 originated as a provision titled "Not a
Contract". The mere title resulted in some objections by some European
lawyers and at least bemusement on the part of some American
lawyers. Curiously, though, the GPLv3 provision and its GPLv2
predecessor deal with acceptance, which is a contract law concept.
I believe the ancient "license vs. contract" debates concerning the
GPL were characterized by great confusion on all sides. There are some
interesting legal issues related to this which may be worth further
exploration. At this time, however, I accept the idea that the GPL
should have some sort of acceptance clause (as indeed many proprietary
software licenses and some free software licenses do), if only for
reasons of tradition, and that the FSF may intend for it to serve some
legal purpose that has nothing to do with acceptance in the contract
sense (or perhaps really does wish it to have some contract law
effect, traditional insistence that the GPL is "not a contract"
notwithstanding). What I have done here is simplified the title to
"Acceptance" and reduced the content of the provision to simply state
that modification or propagation are deemed to signify acceptance by
the licensee. I have kept the policy but trimmed the language to the
bare essentials.
This commit simplifies the way the automatic termination clause is
worded in GPLv3 (and GPLv2). The use of "attempt" and "void" was never
necessary and arguably makes the clause less clear.
This commit simplifies the heading of section 3 to reduce it from
political chargedness to descriptiveness (without affecting the
content of the provision).
Historically, section 3 of GPLv3 was called "Digital Restrictions
Management", the FSF's reexpansion of DRM. Over time the provision,
once quite broad in scope, came to focus entirely on
anti-circumvention law.
This commit deletes a sentence/paragraph in the definition of
"Corresponding Source" that was only needed because of the entity
transactions provision, which itself is now deleted.
This commit deletes from section 6 the following paragraph:
A separable portion of the object code, whose source code is
excluded from the Corresponding Source as a System Library, need not
be included in conveying the object code work.
I do not recall the reason for inclusion of this clause, though it may
have been a response to a stet comment. It is a bit strange in that
(the first half of) section 6 is concerned with the requirement to
convey Corresponding Source triggered by the action of conveying an
object code version of a work, yet this clause reads like a
clarification of a requirement to convey the object code. Of course
there is no requirement to convey object code.
What I suppose this clause must be saying is that where the
distributor ordinarily would not be conveying the System Library with
its object code work, the fact that one is required to convey
Corresponding Source (modulo System Libraries) does not somehow then
imply a requirement to convey the object code System Library. I can't
see how anyone would reasonbly think this could possibly be a
requirement in a provision that says nothing otherwise about a
requirement to provide object code.
This commit makes two small changes. First, the explicit definition of
"License" is deleted as *probably* unnecessary. In GPLv2 the general
understanding has been that "License" obviously means GPLv2. Now I
recall that adding an explicit definition of "License" in GPLv3 (which
I believe was my idea) did serve some purpose other than
hyperlegalism. I believe it may have been thought desirable to clarify
that in *any* version of the GNU GPL "this License" cannot mean "some
or all versions of the GNU GPL" except in the special case of the
"revised versions" provision. (As a concrete example, consider the
meaning of GPLv2 section 2 for a "GPLv2 only" program: if "this
License" could mean "any version of the GPL", it would frustrate the
expectations of the licensors of the GPLv2-only program that modified
versions be licensed only under GPLv2 and not GPLv3 or some other
version.) Perhaps this should be revisited, but there is essentially
no basis in real-world experience that justifies the specific fear
that would motivate this clarification.
Admittedly, the GNU GPL family is unusual as a copyleft license that
does not have a built-in "or later" clause, and perhaps this feature
or non-feature (clearly important to many GPL licensors of existing
projects, such as the Linux kernel) justifies the clarification about
what "this License" means. Nevertheless in five years of experience of
GPLv2 no one has attempted to argue that because "License" is
undefined in GPLv2 one can license out a modified version of a
GPLv2-only program under GPLv3. (The counterargument to that may be
that GPLv3 retroactively provides that clarification for GPLv2.)
The second change in this commit is deletion of the following
paragraph from the definition of Corresponding Source:
The Corresponding Source need not include anything that users can
regenerate automatically from other parts of the Corresponding
Source.
This must have been added for a reason, but I do not believe there is
any record of it. I do not believe I was involved in discussing or
drafting it (it seems likely that it was triggered by a stet
comment). I'm sure there is some technical circumstance in which this
sentence will provide some marginally desirable clarification of the
limits of the Corresponding Source requirement but it is not obvious
to me what such a circumstance would be. The definition of
Corresponding Source is already complex enough. GPLv2 has gotten by
without this clarification. In my post-2007 experience of GPLv3 I have
never been aware of any issue triggering this clause. In the interest
of brevity and simplification I have decided to delete it. If someone
would like to explain what it is aimed at and why explicit inclusion
of the clause is more helpful than hurtful (in making the
Corresponding Source definition more complex) I'm all ears.
This is a small but significant change and may deserve more expanded
explanation, but here's a quick one.
The GPL has a "UI legal notice" provision (often ignored by licensors
and licensees, the subject of some past controversy in some quarters,
and the basis of Bradley Kuhn's hack for the original AGPL to boot).
One of the late changes made to GPLv3 was a modification of section 7
to make GPL-compatible additional terms requiring preservation of
author attributions not just in source code but in the UI legal notice
displayed by the running program. This change was the result of
lobbying by Larry Augustin and John Roberts (the SugarCRM founder, not
the person who later became Chief Justice of the United States). Those
familiar with free software legal history will recall that around this
time there was considerable controversy over the so-called
"attribution licenses" in use by companies like SugarCRM and
Socialtext. These licenses, labeled "badgeware licenses" by their
critics, typically required the licensee to preserve a prominent
display of the logo of the original commercial licensor even where the
licensee had made modifications (and even in contexts where compliance
with such a requirement would not be possible).
The late change made to GPLv3, accompanied by a factored-out
definition of "Appropriate Legal Notices", was not intended to allow
badgeware as then practiced, but rather a lesser form of badgeware:
for example, preservation of a "powered by" logo (with a requirement
to link back to the original licensor's website), to the extent it was
a reasonable author attribution requirement, could be a
GPLv3-compatible condition, though the FSF never intended to authorize
licensors to limit discretion over how the licensee might opt to
comply with the Appropriate Legal Notices requirement, including any
permitted lesser badgeware requirement.
A number of companies took advantage of this feature of GPLv3 (and
AGPLv3). It is now clear that it was a policy error to authorize
limited badgeware. It is my impression that companies have tended to
abuse this feature, imposing requirements more restrictive than I
believe the FSF ever intended, and it is not even entirely clear that
the logo preservation requirements are truly reasonable author
attribution requirements.
The minimum change made here is to remove the explicit authorization
of additional requirements to preserve author attributions in
Appropriate Legal Notices.
This commit explicitly leaves "License Steward" undefined rather than
making it refer, with seeming and unintended egomaniacism, to Richard
Fontana. Whether it is even necessary to use the "License Steward"
vehicle is something that should be revisited, but for now it is a
placeholder that replaces the stewardship role given to the FSF in the
GNU GPL.
This commit deletes the sentence, originating in some interim GPLv3
draft at the request of one (or possibly more than one) commercial
entity, clarifying that licensees can be individuals or
organizations. No other mainstream free software license, to my
knowledge, has seen the need to make this obvious point. Of course a
licensee can be organizational. Moreover, I have never encountered any
misconception in the real world to the effect that somehow GPL
licensees can only be natural persons. Indeed, any license that
prohibited organizations from being licensees would not be a free
software (or open source) license.
What is now section 12 of GPLv3 (the successor to GPLv2 section 7)
bore the heading "Liberty or Death for the Program" in the initial
public draft of GPLv3. The heading was, I believe, devised by
RMS. This wonderful title was, I think, thought to be too
radical-sounding or something (perhaps a vendor or commercial user
raised such a concern early on during the GPLv3 drafting process), and
so the drafters changed it to "No Surrender of Others' Freedom". The
original heading is clearly superior. I have myself taken to calling
this provision the "liberty-or-death clause" and such terminology has
to some degree caught on with others.
In fairness, I recall that RMS also made the point that under this
provision the Program does not actually "die"; rather, particular
copies of it may become nondistributable. Thus the heading was never
truly accurate. But the principal reason for this change was
lamentable primness.
I have therefore restored the original heading.
In 2006 lawyers for Sun Microsystems suggested adding an explicit
definition of "copyright" that would encompass not just conventional
copyright law but also laws like the US Semiconductor Chip Protection
Act (which is something of a hybrid of copyright and patent law). The
application of the GNU GPLv3 to semiconductor integrated circuit
layouts proved to be an unimportant use case. No other
widely-encountered free software license attempts explicitly to apply
its provisions beyond copyright to such "copyright-like laws". In the
interest of brevity I have therefore deleted this definition.
I have deleted the middle paragraph of section 10, the "entity
transactions" provision. This originated in a provision drafted by
Eben Moglen as an alternative to a suggestion by Mark Radcliffe that
GPLv3 have an explicit assignability provision to address a concern
believed by some lawyers to arise in corporate acquisitions involving
GPL-licensed software assets. I am currently inclined to regard Mark's
concern as not being a real-world problem, and perhaps unnecessary
given the automatic licensing feature of the GPL but at any rate I
consider a simple conventional assignability provision preferable to
the existing entity transactions provision, which seems more complex
than necessary. It is not clear how the "right to possession of the
Corresponding Source" is to be enforced (it might be simpler to say
that an entity transaction is a form of conveying, and in fact I seem
to recall some interim GPLv3 draft language taking such an
approach). In any case, this is yet another provision that finds no
counterpart in other major free software licenses. In the interest of
greater brevity it should be deleted, but the issue of assignment in
the M&A context should perhaps be revisited at a later time.
I deleted the Preamble of the GNU GPLv3. This was necessary because
the FSF has stated this as a requirement for permission to create
derivatives of the GNU GPL. I could write an alternative Preamble, but
for the moment I am inclined to think that GPL.next does not need
one.
The GNU GPL Preamble (in its various versions) is an inspiring and
important political statement and also functions a bit similarly to
the so-called "human-readable code" counterparts to Creative Commons
licenses in providing a basic summary description of the license (or
at any rate that is one intention behind the GNU GPL
Preamble). However, even if one thinks a license summary is valuable,
it may be better as a separate document (the Creative Commons
approach).
As for the political aspect of the Preamble, there is something
problematic about this in that it expresses the viewpoint of the FSF
and its sympathizers, but most likely does not quite speak for a
substantial number (perhaps the majority) of GPL licensors (and
licensees). Developers who disagree with the FSF on certain policy
issues (but who favor or potentially favor, strong copyleft) may find
a Preamble-less GPL less alienating.
The FSF also requires GNU GPL derivatives to reword the "How to Apply"
appendix and remove references to GNU, if the appendix is preserved at
all. I decided simply to delete it, particularly in view of the length
of the license document. Instructions on how to apply the license may
be useful but they need not be a part of the license document. Certain
interim public drafts of the GNU GPLv3 removed the appendix for this
reason, though it was later restored.
Section 13 of the GNU GPLv3 and a corresponding paragraph in section
13 of the GNU AGPLv3 provide for cross-compatibility of these two
licenses. I have replaced this section with a quickly-drafted sentence
that says that GPL.next can be relicensed under any version of the GNU
GPL or GNU AGPL (thus making it GNU GPL-compatible, which addresses
one of the FSF's stated concerns regarding GPL derivatives).
I substituted "License Steward" for the references to the FSF in
section 14, and (awkwardly, I later decided) declared myself to be the
License Steward "for the time being".
