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/>[0] 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.[1] 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. Footnotes: [0] IANAL, but I'm on pretty firm ground on this one. [1] 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 System_ series.