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.
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).
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.
To some degree this commit moves the Corresponding Source definition a
bit further away from the GPLv3 definition and back towards the GPLv2
definition.
The reference to interface definition files is moved up (similar to
GPLv2) and the term 'associated' (found in GPLv2) replaces 'relevant'.
A more significant change is the replacement of "all scripts,
instructions and information known to you necessary for a skilled
developer to build, compile, generate and modify the Covered Work"
with "all scripts, instructions and similar information that were used
to build such Source Code". "Similar" is added to avoid a potential
open-ended reading of unmodified "information". "Known to you" is
deleted to avoid arguments about what sort of knowledge is meant
(e.g., in an organizational context). Instead of referring to what is
objectively necessary for a skilled developer to compile and modify,
we revert to a GPLv2-like approach of speaking of what was actually
used to generate the binary. Which of these approaches is better may
still be debatable; it seems to be a basic policy question that should
be informed by practical experiences in GPL enforcement. A side-effect
of this change is that the 'expansive set of verbs' definitional
approach associated with GPLv3, which admittedly has some benefits, is
now gone.
bkuhn's 'list requirement', a novel addition to the definition, is
retained with some greater conciseness.
Finally, I have decided to delete the GPLv3-derived "Source Code of
shared libraries that the Covered Work is specifically designed to
require, such as by intimate data communication or control flow
between those libraries and parts of the Covered Work". I do this with
significant regret and reluctance, as I like that phrase in the GPLv3
definition for multiple reasons. On the copyleft-next mailing list,
Ted Ts'o suggests it, or part of it, may suffer from vagueness. My
question is whether, if it should be preserved, should it not be
better placed in the definition of Covered Work (or Derived Work) (in
which case it would by implication be caught by the definition of
Corresponding Source)? One value of this language is that it
demonstrates that simplistic views of FSF strong copyleft doctrine are
incorrect. However, the FSF handled this matter well in the pre-GPLv3
era through public commentary. I am vaguely concerned that, in
copyleft-next, there is some logical problem with its placement in the
Corresponding Source definition. I cannot quite articulate that well
without some discussion from someone (e.g. Bradley?) who might wish to
argue for its retention. (I am not at all so concerned that the
meaning of 'intimate' (also used in the FSF GNU Licenses FAQ) may be
argued by some to be insufficiently clear; I find it helpfully
suggestive as legal language.)
Essentially, I wish to understand what this language accomplishes that
is frustrated by its removal.
If I distribute object code Foo, and there is some shared library Bar
that Foo is specifically designed to require, then perhaps I should be
required to include the Source Code of Bar in some cases, but why
shouldn't that be a clarification to the definition of Covered
Work/Derived Work? If I am already distributing Bar with (in some
sense) Foo, why isn't it already captured by the existing definitions?
If I am not distributing Bar, why does strong copyleft policy care
whether I provide its Source Code? (This is not a rhetorical question;
there may be a good answer.) It seems best to start over with this
one, sadly.
See:
https://lists.fedorahosted.org/pipermail/copyleft-next/2012-November/000276.html
The concern expressed here is that "install and run" could be read as
an anti-lockdown requirement. Note that those verbs are used in
GPLv3's Corresponding Source definition, yet GPLv3 explicitly limits
the Installation Information requirements to 'User Products'.
Perhaps there is an alternative change that would keep 'install and
run' but add the clarification that this does not imply a GPLv3-style
anti-lockdown Installation Information requirement.
This change is intended to clarify that in any instance of licensing
permission to 'relicense' under later versions is coming from the
relevant licensor.
I don't think this change would break anything, because, given a
Received Work, all the upstream 'We's' need not to explicitly remove
permission to relicense in order for 'you' to have such permission.
