Revise Proprietary Relicensing poison pill.
authorRichard Fontana <fontana@sharpeleven.org>
Sat, 29 Dec 2012 20:52:28 +0000 (15:52 -0500)
committerRichard Fontana <fontana@sharpeleven.org>
Sat, 29 Dec 2012 20:52:28 +0000 (15:52 -0500)
commit021eb728c70b81ffb73ff3dc9a6dadfcc43603f1
tree1bbd9d3885c6dca60b04786f04601facedb1436b
parent35d9e80b833fcea678ff97d458dd90aee46e3186
Revise Proprietary Relicensing poison pill.

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.
Drafts/copyleft-next