Here we delete the clause derived from GNU GPLv3 section 7 which
clarifies that additional terms under that section can either take the
form of an integral license text or a sort of one-off exception or
extra condition. This no longer seems worth pointing out (indeed there
may be a justification for not doing so, as it is probably good policy
not to go out of our way to encourage tacking on of nonstandard
standalone GNU-GPL-compatible conditions to GNU GPL-licensed software).
In addition to some minor changes, mostly in the
no-further-restrictions section, this commit deletes the
cleverly-conceived clause of GNU GPLv3 section 7 which authorizes the
licensee to remove additional terms that are "further restrictions".
The rationale for this clause is made clear in historical
documents. See, e.g. GPLv3 Third Discussion Draft Rationale, section
4.2:
We have also clarified two clauses in section 7 that concern the
consequences of placement of a non-allowed additional requirement
on a work. Draft 2 introduced a clause that authorizes recipients
to remove a non-allowed additional requirement that the work
purports to impose. The kind of case contemplated by this clause is
that of a program that explicitly purports to be licensed under the
GPL along with a supplementary restriction, such as a prohibition
on commercial use.
To my knowledge, in the real world of GNU GPLv3/GNU AGPLv3 experience,
this invitation to remove incompatible additional terms has generally
not been (explicitly) taken advantage of in situations where it ought
to have been applicable.
Perhaps a better approach to dealing with the legitimate problem
addressed by this provision is to attempt to reason with the licensor,
or to shun the licensor's software altogether.
Title changed to reflect that the section takes over role played by
GNU GPLv3 in articulating theory of (inbound) license compatibility.
The Apache-style patent-termination-triggering-patent-litigation
language is preserved, even though one might argue with other changes
it is not necessary, since an explicit patent termination clause has
become de rigeur. Might be better to make this more clearly tied to
the termination provision; the fact that GNU GPLv3 has Apache-like
patent termination (though broader in that copyright licenses can be
terminated as well as patent licenses) is something that has on
occasion had to be spelled out to those trying to understand the
license.
But the third paragraph takes a rather different approach to
articulating inbound license compatibility theory than GNU
GPLv3. Instead of trying to codify GNU GPLv2 interpretive tradition
with formulations of generalized categories (along with the extra
stuff, notably the addition of a category modeled on Apache License
2.0 section 9 upstream indemnification and the limited-badgeware
detail), we do something rather simpler: list a few licenses everyone
agrees are (or in the case of Apache License 2.0, should be)
GPL-compatible, and let that explicitly-illustrative list guide
interpretation. We may wish to add one or more additional licenses to
this list. It would seem that no copyleft license could be included
here without careful examination.
This commit makes an initial attempt to reduce the prolixity of
section 6, but with care to preserve what specific features seem
essential. Some policy changes are made. For example, the distributor
of a physical product can comply by providing notice of a network
location from which the Corresponding Source may be obtained, instead
of being limited to either use of the offer or providing Corresponding
Source along with the product. The simplified language of the option
for network distribution of binaries is influenced by my historical
research into clarifications made by RMS regarding how the
corresponding GNU GPLv2 provision mapped to use of FTP in
circumstances that were present in the early 1990s. Much of the detail
in this part of the section, not present in GNU GPLv2 but having some
basis in (I believe) pre-GNU GPLv3 versions of the GNU license FAQ, is
really not essential.
The offer option is not limited to cases where the distributor is
shipping object code in a physical product (cf. GNU GPLv2 section 3).
I have deleted entirely the "pass on a copy of the written offer to
your friend" provision. It is clear from a comparison of the
counterpart clauses in GNU GPLv2 and GNU GPLv3 that the FSF wished to
narrow the scope of this provision somewhat. I question whether it is
necessary at all (given, e.g., the likely scope of 'distribution' or
the equivalent under applicable copyright law and likely enforcement
patterns). It is not unreasonable to impose upon licensees who might
fall under the GNU GPLv3 counterpart provision the burden of either
satisfying section 6 in some other way or of taking on the risk that
the upstream licensors are unlikely to police such activity.
These changes to section 6 will require further refinement, and debate
over the policy decisions I have made here is welcomed.
This commit deletes the Legal Notices definition (which I now think is
broader than necessary, and is now only used in one clause
anyway). The requirement to "keep intact notices" is made a bit
narrower (though consistent with how the corresponding requirement in
GNU GPLv2/GPLv3 should be understood, I think). Previously I believe I
was thinking also of notice preservation requirements resulting from
inclusion of code under other license terms, but it ought not be
necessary to deal with that explicitly here.
There is still an argument for a broader "preserve legal notices"
requirement, but that can be revisited (perhaps addressed in the
no-further-restrictions section).
I have also modified section 5 so that it no longer is specific to
source code distribution. This is not inconsistent with the
traditional approach taken in GNU GPL (where a distributor of a binary
has permission to distribute "under the terms of" the source code
distribution sections, along with additional conditions).
I remove the requirement of including prominent notice of modification
in the case of Derivative Works. This decision can be debated, but it
reflects common practice. It may be a good example of an aspirational
or normative rule that shouldn't necessarily be stated as a copyright
condition.
Finally a few editorial changes are made to the heading and beginning
of section 6.
This change avoids the ambiguity of verb "license". In addition, the
clause is now triggered only by the Contributor "commercially"
offering the Covered Work under Proprietary Terms. A noncommercial
offering either seems nonproblematic from a policy standpoint, or
unrealistic with respect to the particular problem this clause
addresses, or both.
One can imagine a situation not involving "license notices" (an
example that comes to mind is a trademark legend) where it may be
necessary to remove the notice. Perhaps that specific example is
better addressed by narrowing the definition of Legal Notices. This
may require further refinement.
No mainstream FLOSS license other than GNU GPLv3 attempts to clarify
this matter (I believe the concern only arose because of the FSF's
helpful attempts to provide interpretive guidance for GNU GPLv2 in its
FAQ, though I'm not sure). Licensees concerned about this issue have
the freedom under copyleft-next to relicense under GNU GPLv3. The
policy issue can be reexamined if others consider inclusion of this
clarification important.
My assumption is that under this clarified definition, compiled object
code would be a Derivative Work of the source code from which it was
generated. There are policy consequences of this clarification which
will need to be examined further.
Given that the additional terms section no longer addresses additional
permissions, it is an elaboration on no-further-restrictions, as
indeed is liberty-or-death which was merged with
no-further-restrictions in an earlier commit. In theory it seems
sensible to try to combine them all in one section. The current
combination is quite undesirably lengthy, however.
The sentence in GNU GPLv3 "All other non-permissive additional terms
are considered “further restrictions” within the meaning of section
10" now seems unnecessarily confining, and perhaps should not be taken
too literally. Interpretation of "further restriction" should be
allowed to evolve based on experience (as happened under GNU GPLv2).
'Contribution' has been renamed 'Inbound Contribution' to reduce the
potential for confusion now that 'Contributor' is being (re)used to
mean something that is generally distinct, though a licensee bound by
the inbound=outbound clause could subsequently become a part of what
'Contributor' means.
Moreover, previously a 'Contribution' had to be 'modification to the
Covered Work'. An issue here is that Covered Work now ==
{Program|Derivative Work by the licensee}. The revised definition is
more general, stating that an Inbound Contribution is a 'work
... intended for inclusion in a modified or successor version'. I have
considered whether 'Derivative Work' should be a more generalized
concept (Derivative Work by upstream as well as by 'You') and have
already had, in some earlier versions, additional defined terms
attempting to get at that idea.
Separately, the inbound=outbound rule is clarified so that the
exceptional case (where the licensee-contributor indicates other
terms) must be made at the time of submission of the upstream
contribution.
"We" is potentially confusing given that we may have just one licensor.
There continues to be a drafting complexity here because I've been
restructuring the license in a way that attempts to clarify the
licensor-licensee relationship. However a given 'Program' received by
'You' may be the result of a multitude of different ancestral
'Programs' licensed under copyleft-next.
The solution here (for now) is influenced particularly by CC BY-SA
3.0. The important automatic (direct) licensing provision of the GNU
GPL has a counterpart in at least that particular CC license. Where
the GNU GPL speaks of an automatic license to the 'Program' flowing
from possibly-remote upstream copyright holders, CC BY-SA says that
the automatic licensing of recipients of 'Adaptations' is a license to
the original Work. That approach is taken in this commit in the change
to the automatic licensing clause.
A separate change made in this commit is to move the 'Contractor
Transfer' reference from a carveout of the Distribution definition to
a carveout of the "further restrictions" concept.
There could be extraordinary situations where private (or more
private) communication will be necessary, advisable or
appropriate. However, it should be the exception rather than the rule.
This surely needs more thought, but the idea here is that one of these
two copyleft-next "Supps", corresponding to GNU AGPLv3 and the
anti-lockdown provisions of GNU GPLv3 section 6, can only be imposed
by the original upstream licensor. This is *essentially* the way GNU
AGPLv3 works today, only GNU AGPLv3 is presented as a separate sibling
license to GNU GPLv3 (and there are special cross-compatibility
clauses).
In earlier public drafts of GNU GPLv, there was no "Affero clause" as
such; rather, a description of a category of licenses with Affero-ish
provisions was among the several kinds of compatible additional
requirements listed today in section 7. I recall that someone once
proposed that the FSF prepare canonical license texts for the allowed
additional requirements, which for the most part would not have been
sensible, but in essence this is what was done for GNU AGPLv3 --
except that GNU AGPLv3 was written as a whole new license, mostly
identical to GNU GPLv3.
Cf. also the long-forgotten GNU GPLv2 section 8, which explicitly
legitimized the ability of the "original copyright holder" to "add an
explicit geographical distribution limitation", which, if exercised,
might not be regarded as FLOSS today. (I know of only one historical
case where this was exercised, in a context that was quite
problematic, but the possibility for abuse doesn't seem relevant to
WS-Supp and AL-Supp.)
This is not the way the anti-lockdown provisions of GNU GPLv3 work
today. There is, in fact, no entirely mandatory way to achieve what I
have currently done with AL-Supp in GNU GPLv3 today. The original
licensor can place an additional permission allowing licensees to
ignore the anti-lockdown requirements, but additional permissions can
be removed by licensees. This is the inverse, as it were.
Perhaps we need to clarify that (or whether) one can, with appropriate
copyright permission, dual-license code under copyleft-next-vanilla
and copyleft-next-AL-Supp [etc.]. This raises an important policy
question which I am deferring for now. As a related matter, I have not
addressed in copyleft-next itself the issue of compatibility of
validly "Supp"-covered material with vanilla copyleft-next
material.
The text is similar to AGPLv3 section 13 but includes changes
reflecting changes in copyleft-next relative to GNU GPLv3. The second
paragraph of AGPLv3 section 13 will probably be made unnecessary by a
future commit.
