Introducing Electronic Contributor Agreements
The full announcement is at http://blog.python.org/2013/03/introducing-electronic-contributor.html, but a summary follows. We've now moved to an electronic Contributor License Agreement form at http://www.python.org/psf/contrib/contrib-form/ which will hopefully ease the signing and sending of forms for our potential contributors. The form shows the required fields whether you're signing as an individual or a representative of an organization, and removes the need to print, scan, fax, etc. When a new contributor fills in the form, they are emailed a copy of the form and asked to confirm the email address that they used (and received that copy at). Upon confirming, the signed form is sent to the PSF Administrator and filed away. The signature can either be generated from your typed name, or you can draw or upload your actual written signature if you choose.
On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin <brian@python.org> wrote:
With this in place I would like to propose that all patches submitted to bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA).
On 3/4/2013 11:36 AM, Brett Cannon wrote:
Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. -- Terry Jan Reedy
On 3/4/2013 3:46 PM, Antoine Pitrou wrote:
While I regard CLAs as partly being a form of legal theater, I regard our participation as necessary, both to make explicit to contributors what should be implicit in the act of submission *and* to show to copyright holders a good-faith effort to not improperly incorporate their code. Note: no one expected the Linux copyright challenge, nor our European trademark challenge, but they happened. I expect there will be more challenges to open source projects, perhaps some legitimate as the number of contributors increases.
Limit the popup to files with .diff or .patch extension. Reviewers can check for '*' for the occasionally patch lacking that. -- Terry Jan Reedy
On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence <breamoreboy@yahoo.co.uk>wrote:
Depends on your paranoia. If you're worried about accidentally lifting IP merely by reading someone's source code, then you wouldn't want to touch code without the CLA signed. Now I'm not that paranoid, but I'm still not about to commit someone's code now without the CLA signed to make sure we are legally covered for the patch. If someone chooses not to contribute because of the CLA that's fine, but since we have already told at least Anatoly that we won't accept patches from him until he signs the CLA I'm not going to start acting differently towards others. I view legally covering our ass by having someone fill in a form is worth the potential loss of some contribution in the grand scheme of things.
On 04/03/2013 22:08, Brett Cannon wrote:
Who's talking source code, you're previously mentioned *ALL* patches needing a CLA. Does this mean you have to sign a CLA for a one line documentation patch? What is the definition of a patch, an actual patch file or a proposal for a change that is given within a bug tracker message? -- Cheers. Mark Lawrence
On 3/4/2013 7:51 PM, Mark Lawrence wrote:
It it is a one char typo, I would not bother downloading the patch, or adding a person to ACKS. If the patch is big enough to download and apply, then I want a CLA. If a person is sophisticated enough to submit a respository file diff, they are likely to submit more, and I want them to feel encouraged to do so by already having done the CLA. If we do not get it with the first submission, then when? Who keeps track of cumulative lines?
What is the definition of a patch, an actual patch file
Usually.
or a proposal for a change that is given within a bug tracker message?
I view a proposal for a change as just an idea. Such usually get re-written by whoever creates an actual patch. I would like the link to the e-form to be accessible somewhere on the tracker so I can refer people to it easily. -- Terry Jan Reedy
Steven D'Aprano writes:
Pardon my ignorance, but how does a CLA protect us in the event of an IP violation?
By licensing the content to the PSF, the contributor implicitly claims that he has the right to do so (I think the AFL even has an explicit provenance clause). This protects the PSF against criminal infringement and statutory damages for copyright violation (which require wilful infringement). I don't know it if helps for patent infringement.
On 3/6/2013 3:06 PM, Steven D'Aprano wrote:
The penalty for willful copyright violation (possible punitive damages) is higher than for inadvertent violation (typically, remove the offending code). In the CLA, contributors affirm that they will only contribute code they have a legal right to contribute. This makes it clear that PSF only wants legal code. We do not grab 3rd party code without author participation even if the license would seem to make it legal to do so. Good repository software, including svn and hg, can trace every line to a specific commit. Commit messages typically have an issue number and credit (blame) any patch author other than the one making the commit. So any line should be traceable to a specific person and we should have a CLA for that person. -- Terry Jan Reedy
Mark Lawrence writes:
People already use the bug tracker as an excuse not to contribute, wouldn't this requirement make the situation worse?
A failure to sign the CLA is already a decision not to contribute to the distribution, no matter how noisy they are on the tracker and list. I think that pretty much any upload is potential content for inclusion in Python. For example, uploading a log of an interactive session reproducing a bug could easily evolve into contribution of a doctest. Since the proposed page only triggers on uploads, I think we're in "yes, we really do want this person's CLA" territory. The procedure is actually rather cool. As Eli says, the tough part is finding your user name, but OpenID or browser memory makes that reasonably close to trivial for many people. It's true that people upload "one-line documentation patches," and these don't require a CLA under even the most paranoid interpretation of US law. The FSF's guideline is 16 lines, I believe. However, the FSF's guideline also says those 16 lines are lifetime cumulative (per copyrighted work, but we're only talking about one, Python). In my experience (with a different project, so FWIW) somebody who goes to the trouble of uploading a doc typo patch is likely to be a repeat offender, whereas "drive-by" contributors who just need that one feature so their web2.0 app works as desired are often going to be in 16-line territory anyway. This argument doesn't catch 100% of those who might be deterred by the popup, but it's definitely enough to make the popup worthwhile. IANAL-but-I-like-a-good-license-flamewar-as-much-as-the-next-guy-ly y'rs,
Le 05/03/2013 04:13, Stephen J. Turnbull a écrit :
my 2 cents as an occasional contributor of minor patches: I understand that the scarce resource is reviewer time, so I would definitely accept to sign the CLA with my next contribution before a reviewer invests his time in it. However, please don't make the popup too pushy. I abhor websites which push people into entering legally binding agreements "with one click" without the opportunity to study them carefully (personnally, this would not be a problem as I already know what the CLA is about, but other contributors might not). Also, please keep the possibility to use the old paper-based signing procedure. I for one don't consider so-called "electronic signatures" based on email address verification (as opposed to real crypto) to be as good as a handwritten signature, and I don't want to legitimize them by using them. Cheers, Baptiste
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
As someone who cannot in good faith sign the CLA, that characterisation is far from accurate: I would very much like to contribute to the Python distribution, and so have not decided as you describe. Rather, I leave the matter of contribution undecided, while advocating (when opportunity arises) against the CLA. The decision that the current terms are unacceptable does not entail a decision not to contribute. (aside: good sigmonster, have a treat.) -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__) later?” —http://www.achewood.com/ | Ben Finney
On Sat, Apr 13, 2013 at 6:30 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
Stephen said that it's a choice not to contribute and not that one wouldn't _like_ to contribute if the CLA wasn't there. Those are both distinctive choices to make. A desire to help is independent of whether you are willing to take the necessary step of signing the CLA in order to change that desire into an actual act of contributing (which is obviously fine; if you have moral issues with the CLA no one will hold it against you, we just can't legally risk accepting code without it). -Brett
Steven D'Aprano <steve@pearwood.info> writes:
Because software freedom in a work is undermined when any recipient is granted special legal privilege in the work. 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. By “special privilege”, I mean that this power is granted specially to some but denied to all other recipients of the work. Hence to sign the Contributor Agreement as it currently stands is to undermine software freedom in the resulting work. -- \ “Choose mnemonic identifiers. If you can't remember what | `\ mnemonic means, you've got a problem.” —Larry Wall | _o__) | Ben Finney
On 4/15/2013 12:15 AM, Ben Finney wrote:
Easily curable by granting that right to all recipients of the contributions you make to PSF, no? Of course, the contributor's agreement has no particular need to include such a clause, but you can include it in a separately published version of the contributions, to keep freedom free...
Ben Finney writes:
"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.
Can we get this discussion off python-dev? It's not going to change, and this is not the forum to express your disagreement. On Mon, Apr 15, 2013 at 12:15 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
-- --Guido van Rossum (python.org/~guido)
Ben Finney writes:
Whatever. In fact, the consequence of your failure to sign the CLA is that your code doesn't get distributed with any of the current Python releases, is that correct? Back in context, I don't see how placing a reminder to sign the CLA on the page makes your decision at that instant harder. I suppose it might deter you from submitting code that by policy shouldn't be included in the distribution, but might be useful to third parties. Whether such deterrence is a good thing or a bad thing would depend on how likely it was to be independently invented by some who is willing to contribute code, and whether you would try to enforce your copyright in the event that it resembled your code (in which case there would be an obvious case for infringement, with the burden of proof on the individual who is willing to sign the CLA). (By the way, what is your problem of conscience with the PSF CLA? Are you afraid that the PSF's obligation to use an "open source license" is not enforceable? You don't like the choice of Initial Licenses? Something else?)
Hi, On Mon, Mar 4, 2013 at 10:46 PM, Terry Reedy <tjreedy@udel.edu> wrote:
http://psf.upfronthosting.co.za/roundup/meta/issue461 Best Regards, Ezio Melotti
-- Terry Jan Reedy
On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin <brian@python.org> wrote:
Brian, Do you want old-timers like me who have a wet-signed fax gathering dust in a box at PSF World Headquarters to execute the electronic contributor agreement? While not strictly necessary, I suspect it might be nice for you to have all agreements in a common form. Skip
On Tue, Mar 5, 2013 at 3:30 AM, Brian Curtin <brian@python.org> wrote:
I had been procrastinating on filling in the paper version, but having this means no excuse. The process was very simple and straight forward. (The only difficult part was actually working out my python bugs username). Thanks for taking the administrative effort to get this all in place. Cheers, Benno
On Mon, Mar 4, 2013 at 11:30 AM, Brian Curtin <brian@python.org> wrote:
With this in place I would like to propose that all patches submitted to bugs.python.org must come from someone who has signed the CLA before we consider committing it (if you want to be truly paranoid we could say that we won't even look at the code w/o a CLA).
On 3/4/2013 11:36 AM, Brett Cannon wrote:
Either policy could be facilitated by tracker changes. In order to see the file upload box, one must login and the tracker knows who has a CLA on file (as indicated by a * suffix on the name). If a file is uploaded by someone without, a box could popup with the link to the e-form and a message that a CLA is required. -- Terry Jan Reedy
On 3/4/2013 3:46 PM, Antoine Pitrou wrote:
While I regard CLAs as partly being a form of legal theater, I regard our participation as necessary, both to make explicit to contributors what should be implicit in the act of submission *and* to show to copyright holders a good-faith effort to not improperly incorporate their code. Note: no one expected the Linux copyright challenge, nor our European trademark challenge, but they happened. I expect there will be more challenges to open source projects, perhaps some legitimate as the number of contributors increases.
Limit the popup to files with .diff or .patch extension. Reviewers can check for '*' for the occasionally patch lacking that. -- Terry Jan Reedy
On Mon, Mar 4, 2013 at 4:33 PM, Mark Lawrence <breamoreboy@yahoo.co.uk>wrote:
Depends on your paranoia. If you're worried about accidentally lifting IP merely by reading someone's source code, then you wouldn't want to touch code without the CLA signed. Now I'm not that paranoid, but I'm still not about to commit someone's code now without the CLA signed to make sure we are legally covered for the patch. If someone chooses not to contribute because of the CLA that's fine, but since we have already told at least Anatoly that we won't accept patches from him until he signs the CLA I'm not going to start acting differently towards others. I view legally covering our ass by having someone fill in a form is worth the potential loss of some contribution in the grand scheme of things.
On 04/03/2013 22:08, Brett Cannon wrote:
Who's talking source code, you're previously mentioned *ALL* patches needing a CLA. Does this mean you have to sign a CLA for a one line documentation patch? What is the definition of a patch, an actual patch file or a proposal for a change that is given within a bug tracker message? -- Cheers. Mark Lawrence
On 3/4/2013 7:51 PM, Mark Lawrence wrote:
It it is a one char typo, I would not bother downloading the patch, or adding a person to ACKS. If the patch is big enough to download and apply, then I want a CLA. If a person is sophisticated enough to submit a respository file diff, they are likely to submit more, and I want them to feel encouraged to do so by already having done the CLA. If we do not get it with the first submission, then when? Who keeps track of cumulative lines?
What is the definition of a patch, an actual patch file
Usually.
or a proposal for a change that is given within a bug tracker message?
I view a proposal for a change as just an idea. Such usually get re-written by whoever creates an actual patch. I would like the link to the e-form to be accessible somewhere on the tracker so I can refer people to it easily. -- Terry Jan Reedy
Steven D'Aprano writes:
Pardon my ignorance, but how does a CLA protect us in the event of an IP violation?
By licensing the content to the PSF, the contributor implicitly claims that he has the right to do so (I think the AFL even has an explicit provenance clause). This protects the PSF against criminal infringement and statutory damages for copyright violation (which require wilful infringement). I don't know it if helps for patent infringement.
On 3/6/2013 3:06 PM, Steven D'Aprano wrote:
The penalty for willful copyright violation (possible punitive damages) is higher than for inadvertent violation (typically, remove the offending code). In the CLA, contributors affirm that they will only contribute code they have a legal right to contribute. This makes it clear that PSF only wants legal code. We do not grab 3rd party code without author participation even if the license would seem to make it legal to do so. Good repository software, including svn and hg, can trace every line to a specific commit. Commit messages typically have an issue number and credit (blame) any patch author other than the one making the commit. So any line should be traceable to a specific person and we should have a CLA for that person. -- Terry Jan Reedy
Mark Lawrence writes:
People already use the bug tracker as an excuse not to contribute, wouldn't this requirement make the situation worse?
A failure to sign the CLA is already a decision not to contribute to the distribution, no matter how noisy they are on the tracker and list. I think that pretty much any upload is potential content for inclusion in Python. For example, uploading a log of an interactive session reproducing a bug could easily evolve into contribution of a doctest. Since the proposed page only triggers on uploads, I think we're in "yes, we really do want this person's CLA" territory. The procedure is actually rather cool. As Eli says, the tough part is finding your user name, but OpenID or browser memory makes that reasonably close to trivial for many people. It's true that people upload "one-line documentation patches," and these don't require a CLA under even the most paranoid interpretation of US law. The FSF's guideline is 16 lines, I believe. However, the FSF's guideline also says those 16 lines are lifetime cumulative (per copyrighted work, but we're only talking about one, Python). In my experience (with a different project, so FWIW) somebody who goes to the trouble of uploading a doc typo patch is likely to be a repeat offender, whereas "drive-by" contributors who just need that one feature so their web2.0 app works as desired are often going to be in 16-line territory anyway. This argument doesn't catch 100% of those who might be deterred by the popup, but it's definitely enough to make the popup worthwhile. IANAL-but-I-like-a-good-license-flamewar-as-much-as-the-next-guy-ly y'rs,
Le 05/03/2013 04:13, Stephen J. Turnbull a écrit :
my 2 cents as an occasional contributor of minor patches: I understand that the scarce resource is reviewer time, so I would definitely accept to sign the CLA with my next contribution before a reviewer invests his time in it. However, please don't make the popup too pushy. I abhor websites which push people into entering legally binding agreements "with one click" without the opportunity to study them carefully (personnally, this would not be a problem as I already know what the CLA is about, but other contributors might not). Also, please keep the possibility to use the old paper-based signing procedure. I for one don't consider so-called "electronic signatures" based on email address verification (as opposed to real crypto) to be as good as a handwritten signature, and I don't want to legitimize them by using them. Cheers, Baptiste
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
As someone who cannot in good faith sign the CLA, that characterisation is far from accurate: I would very much like to contribute to the Python distribution, and so have not decided as you describe. Rather, I leave the matter of contribution undecided, while advocating (when opportunity arises) against the CLA. The decision that the current terms are unacceptable does not entail a decision not to contribute. (aside: good sigmonster, have a treat.) -- \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” | `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it | _o__) later?” —http://www.achewood.com/ | Ben Finney
On Sat, Apr 13, 2013 at 6:30 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
Stephen said that it's a choice not to contribute and not that one wouldn't _like_ to contribute if the CLA wasn't there. Those are both distinctive choices to make. A desire to help is independent of whether you are willing to take the necessary step of signing the CLA in order to change that desire into an actual act of contributing (which is obviously fine; if you have moral issues with the CLA no one will hold it against you, we just can't legally risk accepting code without it). -Brett
Steven D'Aprano <steve@pearwood.info> writes:
Because software freedom in a work is undermined when any recipient is granted special legal privilege in the work. 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. By “special privilege”, I mean that this power is granted specially to some but denied to all other recipients of the work. Hence to sign the Contributor Agreement as it currently stands is to undermine software freedom in the resulting work. -- \ “Choose mnemonic identifiers. If you can't remember what | `\ mnemonic means, you've got a problem.” —Larry Wall | _o__) | Ben Finney
On 4/15/2013 12:15 AM, Ben Finney wrote:
Easily curable by granting that right to all recipients of the contributions you make to PSF, no? Of course, the contributor's agreement has no particular need to include such a clause, but you can include it in a separately published version of the contributions, to keep freedom free...
Ben Finney writes:
"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.
Can we get this discussion off python-dev? It's not going to change, and this is not the forum to express your disagreement. On Mon, Apr 15, 2013 at 12:15 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
-- --Guido van Rossum (python.org/~guido)
Ben Finney writes:
Whatever. In fact, the consequence of your failure to sign the CLA is that your code doesn't get distributed with any of the current Python releases, is that correct? Back in context, I don't see how placing a reminder to sign the CLA on the page makes your decision at that instant harder. I suppose it might deter you from submitting code that by policy shouldn't be included in the distribution, but might be useful to third parties. Whether such deterrence is a good thing or a bad thing would depend on how likely it was to be independently invented by some who is willing to contribute code, and whether you would try to enforce your copyright in the event that it resembled your code (in which case there would be an obvious case for infringement, with the burden of proof on the individual who is willing to sign the CLA). (By the way, what is your problem of conscience with the PSF CLA? Are you afraid that the PSF's obligation to use an "open source license" is not enforceable? You don't like the choice of Initial Licenses? Something else?)
Hi, On Mon, Mar 4, 2013 at 10:46 PM, Terry Reedy <tjreedy@udel.edu> wrote:
http://psf.upfronthosting.co.za/roundup/meta/issue461 Best Regards, Ezio Melotti
-- Terry Jan Reedy
On Mon, Mar 4, 2013 at 10:30 AM, Brian Curtin <brian@python.org> wrote:
Brian, Do you want old-timers like me who have a wet-signed fax gathering dust in a box at PSF World Headquarters to execute the electronic contributor agreement? While not strictly necessary, I suspect it might be nice for you to have all agreements in a common form. Skip
On Tue, Mar 5, 2013 at 3:30 AM, Brian Curtin <brian@python.org> wrote:
I had been procrastinating on filling in the paper version, but having this means no excuse. The process was very simple and straight forward. (The only difficult part was actually working out my python bugs username). Thanks for taking the administrative effort to get this all in place. Cheers, Benno
participants (15)
-
Antoine Pitrou -
Baptiste Carvello -
Ben Finney -
Ben Leslie -
Brett Cannon -
Brian Curtin -
Ezio Melotti -
Glenn Linderman -
Guido van Rossum -
Mark Lawrence -
R. David Murray -
Skip Montanaro -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy