[Python-Dev] Deciding against the CLA
Stephen J. Turnbull
stephen at xemacs.org
Mon Apr 15 12:05:32 CEST 2013
Ben Finney writes:
> As it currently stands, the Contributor Agreement grants special
> legal privilege in the work (the power to unilaterally re-license
> the work) to the PSF.
"I hate to disagree, Sir, but that turns out to be incorrect."<wink/>
First, it's not the Contributor Agreement, it's the approved Initial
Licenses that grant the power to sublicense (the technical term in US
law for the kind of "re-licensing" being discussed here). The AFL
does so explicitly. I'm not sure about the Apache license, but it does
so at least implicitly. (That's the main feature of a "permissive
license".) I agree the wording is a little vague, but in fact the
Contributor Agreement simply affirms that the Initial License has been
granted and that it provides for sublicensing. It then *takes away*
power from the PSF, by requiring it to use an open source license,
which the Initial Licenses (AFL and Apache) do not.
Second, although in theory the PSF might change its license, at the
moment the current PSF license also (implicitly) permits some form of
"re-licensing" because it requires only preservation of copyright
notice (clause 2) and a list of changes (clause 3). In particular it
implicitly grants the right to use a proprietary license for works
derived from the contribution, which is denied to the PSF under the
Contributor Agreement. I think that is very unlikely to change.
So the PSF Contributor Agreement grants no special privileges to the
PSF not available in practice to any Python user.
 IANAL, but I'm on pretty firm ground on this one.
 Technically speaking, that proprietary license may not apply to
the portion of code copied from Python. In practice, to the extent
that proprietary original code is mixed with PSF Python, it can
effectively prevent copying any part of the derived work. Cf. the
infamous "non-permission" statement on O'Reilly's _The X Window
More information about the Python-Dev