This was a descendant of the "Aggregate" definition in the final
paragraph of GPLv3 section 5. I do not believe it is necessary.
The effect of the GPLv3 'Aggregate' definition carveout is that in
cases where copyleft scope is cut off at the Aggregate boundary, the
cut-off is removed if one is conveying an aggregation under a
compilation license that "limit[s] the access or legal rights of the
compilation's users beyond what the individual works permit". As I
believe I noted in an earlier commit, this arguably goes further than
is necessary. If one supposes a copyrightable compilation C containing
works A and B, where A is copyleft-next and B is under some other
license (free or proprietary), and C meets the definition of 'Mere
Aggregation' (without the carveout), and C is governed by a license
covering the components of the compilation under terms more
restrictive than either GPLv3 or the B license, we shouldn't care (as
a policy matter for purposes of what the license of *A* should ) that
use of B is being restricted further than it was under the B
license. We should care about the effects of the C license on A. But
that already violates copyleft-next section 7, by imposing further
restrictions.
I don't see what the point is of expressing the policy in terms of
copyleft scope. Under the version of the Mere Aggregation definition
existing prior to this commit, if the idea were that the restrictive
nature of the C license justifies a broadening of copyleft scope, the
effect is that there is a violation of the copyleft requirement to
license Derived Works under copyleft-next. But we already achieve that
by the prohibition against imposition of further restrictions. The
only casualty of this change seems to be the case of the
copyleft-next-compatible subset of Bs, which could become part of a
broadened copyleft scope free of any free software license clash. But
copyleft-next does not have as its mission to save non-copyleft-next
free software from the intentionally-drafted features of their
different licenses.
Revisit if I'm missing something here, or misunderstanding the point
of GPLv3 section 5 last paragraph.
Previously, the Proprietary Relicensing section stated that sections 4
through 11 would not apply upon trigger. However, there seems to be no
reason to state that section 10 won't apply (since the resulting
permissive license is (A)GPL-compatible anyway). As for section 11, I
can see how some might criticize the elimination of the patent peace
provision merely because the Proprietary Relicensing provision has
been activated.
Previously, the Proprietary Relicensing section stated that sections 4
through 11 would not apply upon trigger. However, there seems to be no
reason to state that section 11 won't apply (since the resulting
permissive licene is (A)GPL-compatible anyway). As for section 10, I
can see how some might criticize the elimination of the patent peace
provision merely because the Proprietary Relicensing provision has
been activated.
The GPLv3-derived language "for the duration of ... copyright" is more
succinctly expressed by the standard "perpetual"; it is appropriate to
specify this for the patent license as well as the copyright
license. I made "terms" "terms and conditions" (which I believe was in
a much earlier revision) as a bit of drafting paranoia. The
termination provision might not be a "condition" as such, but there
may be some value in mentioning "conditions" explicitly to make
sufficiently clear that irrevocability assumes compliance with the
license's conditions.
The date 1 January 2013 is arbitrary (another option might be to use
the date of publication of a given released version of
copyleft-next). The point is to fix the set of OSI-approved licenses
to guard against the possibility of pathological future OSI license
approval decisions (however unlikely or remote that may be).
The Proprietary Relicensing provision should also apply in
circumstances where 'We' (perhaps including licensors downstream from
the original licensor) offer to forgive past or future noncompliance
with respect to a work 'We' do not distribute (e.g., what would be a
downstream Derived Work but which is created by someone lateral to
'you') through purchase of a proprietary license.
There is some evidence that some purported GPL licensors are engaging
in such behavior (rather than the more familiar case of announcing at
the outset that proprietary licenses are available for the
GPL-licensed work distributed by the licensor, or some enhanced
version of it).
This change returns the 'Product Distribution' section a bit closer to
GPLv2, as the deleted language originates in a change introduced in
GPLv3. My admittedly-vague justification for this change is that, for
shipment of a given Product, there could be significant variance in
the offering of support or spare parts across Product
instances. Consider restoring this after further analysis.
The previous term, "direct licensing", was one I learned from Till
Jaeger and Axel Metzger in the GPLv3 process. GPLv3 itself uses
"automatic licensing" in the title of section 10. I have heard at
least one US lawyer refer to the automatic licensing provision of GPL
as a "pass through" and I have decided to adopt such terminology in
the title.
Previously, there was a parenthetical indicating that notice
preservation applied to Derived Works only to the extent they remain
pertinent. The wording f the clause might seem to sggest that this
"pertinence clarification" applies only to "legal notices" and not
also "textual author attributions".
This text originates in the final sentence of GPLv3 section 11.
I believe it is either unnecessary belt-and-suspenders drafting or
else merits some further legal research before re-inclusion (or both).
This is a further refinement to some language bkuhn had added in
recently. The main change is deleting "and contributors" from the
phrase "developers and contributors". To me this suggested that
contributors [of code] are not developers, which does not seem
right. If the intention was to sweep in non-developer contributors,
however, or if it is important to specifically mention such
contributors here, we can improve on this.
Some of this is just fixes to the previous commit, but I have
reintroduced the "skilled developer" into category (ii).
I am bothered by the asymmetry between (ii) and (iii), but I'm not
sure yet if I should be. If only bkuhn would help out with drafting
this definition!
The main change here is the deletion of the reference to "interface
definition files", introduced in GNU GPLv2. See the discussion in the
thread "Fwd: Re: Modify Corresponding Source definition, mainly to
delete 'install and run'. (14249c2)" on the copyleft-mailing list,
e.g., this helpful posting by Ted Ts'o:
https://lists.fedorahosted.org/pipermail/copyleft-next/2012-December/000344.html
Whatever was meant to be captured by adding in the "interface
definition files" reference is, I believe, adequately addressed by
category (ii) of the Corresponding Source definition as changed by
this commit.
The immediately preceding version would have activated the trigger for
Distribution under the current version of copyleft-next.
The awkwardness of "later versions of copyleft-next" (when at the
outset "this License" is indicated to be a synonym of copyleft-next)
is noted. Similar problems exist in the GNU GPL, including GPLv3
despite the introduction in that license of a definition aimed at
eliminating the issue.
This commit changes the characterization of the poison pill trigger
(though there is no actual intention to change the underlying policy
or intended effect of the provision).
Previously, the licensor commits itself to a one-year limit during
which it may offer closely-related works under a proprietary
license. This was characterized as offering the closely related work
"in a manner that fails to satisfy" the (present-day) FSD. Note that
this (intentionally) went beyond formal licensing, so that even
nominal distribution of a binary under the GPL with failure to provide
Corresponding Source would trigger the poison pill.
One problem with that approach is the degree of uncertainty over
whether one is inside or outside the zone of "a manner that fails to
satisfy" the FSD. One could instead (with, arguably, some arguable
relaxation of the poison pill) focus on the nominal license. This has
the benefit of matching how we ordinarily look at the matter. We see a
company offering, say, a 'Community Edition' under the GPL, and an
'Enterprise Edition' under a proprietary license. We see the fact of a
license difference as sufficient information to conclude we are in
what Bradley Kuhn would call a circumstance of "proprietary
relicensing".
To focus on the nominal license, however, calls into question the
usefulness of relying on the FSD. The situation might be different if
the FSF saw itself, or was seen as, taking on the role of
comprehensively categorizing the set of known FSD-compliant licenses
and maintaining a set of commonly-encountered non-FSD-compliant
borderland licenses. The FSF has not taken on such a role.
The OSI takes on the role of approving or certifying OSD-compliant
licenses in a way that has no FSF FSD counterpart.
If the poison pill trigger is going to be based on nominal license
(which may make the provision more effective in one sense), we need to
carve out earlier versions of copyleft-next (I think), later versions
of copyleft-next, and also GPLv2+/AGPLv3+ outbound relicensing. We
also wish to carve out legitimate FLOSS licenses not in those
sets. One way to do this, however painfully suboptimal for so many
reasons, is to reference the set of OSI-approved licenses. There are
some OSI-approved licenses that I believe were approved in error, but
these have not seen much use, and even these do not really rise to the
level of the sort of proprietary licensing practices that this
provision reacts to. (Indeed, the undesirable OSI-approved licenses
have typically been used as the 'open source' side of mechanisms to
implement a proprietary relicensing business strategy.) So the risks
of abuse in referencing the OSI list seem small. There are other
reasons to lament the referencing of the OSI list, such as "air of
cluelessness" that will result, not to mention the offense the FSF is
likely to take (should the FSF even care about copyleft-next at all,
and it is hoped that it will care). Nevertheless, I can't think of a
better approach at the moment.
It occurs to me that this Proprietary Relicensing provision is the one
part of copyleft-next that is in danger of taking on certain GPLv3-ish
stylistic qualities that are undesirable generally for
copyleft-next. I am not sure how to solve that without making the
provision significantly longer or removing it from copyleft-next. I
don't like either of those options.
The concern here is for the company that begins with a proprietary
product and decides to release it as free software under
copyleft-next. It is likely that in such cases the company would have
triggered the earlier version of this provision, as it would have
continued to offer the proprietary version.
