Ability to change CLA text (revisions, versioning) about clahub HOT 7 OPEN

+1 from the Heroku internal talk I gave today.

from clahub.

Updating the issue title to narrow the focus.

What should the semantics be for updating a CLA text? Specifically I'm curious about the relationship of a text update to the revocation (or deprecation, whatever the right word would be) of a user's signature.

• Should the user's signature automatically be obsoleted when the text is updated?
• Should that be a checkbox during the text update process (e.g. this is a substantiative change vs cosmetic change)?
• Should the signature revocation be a separate manual process initiated by the maintainer?
• When a contributor's signature becomes outdated, who is notified? Do we email the contributor? (If so, we need to ensure we collect email addresses... a good idea anyway #18).
• When a contributor's signature becomes outdated, does this affect the status of open pull requests? E.g. say I have an open pull on your project, not yet merged. I previously signed your CLA, so my pull request is green. You update the CLA text. Is my signature still valid for this pull? I wrote the code and submitted it while I had a valid signature, but is authorship/contribution the important act, or must my "valid agreement time range" also overlap the merge action?

I'd really appreciate feedback on the above questions from people who have managed CLAs in the past.

from clahub.

@jasonm Here are my thoughts

• Should the user's signature automatically be obsoleted when the text is updated?

Absolutely, the CLA's need to be versioned for this very reason. Agreements will change over time and an contributor will need to "re-agree" if you will to the new terms and conditions. At least they can now chose to accept or reject the new terms and conditions.

• Should that be a checkbox during the text update process (e.g. this is a substantiative change vs cosmetic change)?

I'm not really sure from whose perspective you're asking in regards to this.

• Should the signature revocation be a separate manual process initiated by the maintainer?

If possible both parties should be able to revoke a signature.

• When a contributor's signature becomes outdated, who is notified? Do we email the contributor? (If so, we need to ensure we collect email addresses... a good idea anyway #18).

Email is one way, I haven't looked into the GH API that much but if there's a new CLA would a contributor be notified or does it just show that he's already signed?

• When a contributor's signature becomes outdated, does this affect the status of open pull requests? E.g. say I have an open pull on your project, not yet merged. I previously signed your CLA, so my pull request is green. You update the CLA text. Is my signature still valid for this pull? I wrote the code and submitted it while I had a valid signature, but is authorship/contribution the important act, or must my "valid agreement time range" also overlap the merge action?

I would imagine that if the pull request was initiated prior to a CLA bump then it would still be valid.

from clahub.

• Should that be a checkbox during the text update process (e.g. this is
  a substantiative change vs cosmetic change)?

I'm not really sure from whose perspective you're asking in regards to
this.

When you update text, should you be able to distinguish between "it's a
typo fix, leave signatures intact" vs "it's a substantiative change,
require new signatures." ?
On Tuesday, January 22, 2013, Tony Guntharp wrote:

@jasonm https://github.com/jasonm Here are my thoughts

• Should the user's signature automatically be obsoleted when the text
  is updated?

  Absolutely, the CLA's need to be versioned for this very reason.
  Agreements will change over time and an contributor will need to "re-agree"
  if you will to the new terms and conditions. At least they can now chose to
  accept or reject the new terms and conditions.

• Should that be a checkbox during the text update process (e.g. this
  is a substantiative change vs cosmetic change)?

  I'm not really sure from whose perspective you're asking in regards to
  this.

• Should the signature revocation be a separate manual process
  initiated by the maintainer?

  If possible both parties should be able to revoke a signature.

  • When a contributor's signature becomes outdated, who is notified? Do
    we email the contributor? (If so, we need to ensure we collect email
    addresses... a good idea anyway #18https://github.com/jasonm/clahub/issues/18
    ).

  Email is one way, I haven't looked into the GH API that much but if
  there's a new CLA would a contributor be notified or does it just show that
  he's already signed?

• When a contributor's signature becomes outdated, does this affect
  the status of open pull requests? E.g. say I have an open pull on your
  project, not yet merged. I previously signed your CLA, so my pull request
  is green. You update the CLA text. Is my signature still valid for this
  pull? I wrote the code and submitted it while I had a valid signature, but
  is authorship/contribution the important act, or must my "valid agreement
  time range" also overlap the merge action?

  I would imagine that if the pull request was initiated prior to a CLA
  bump then it would still be valid.

—
Reply to this email directly or view it on GitHubhttps://github.com/jasonm/clahub/issues/10#issuecomment-12577592.

Jason Morrison
415.297.6376
@jayunit http://twitter.com/jayunit
skype:jason.p.morrison

from clahub.

IANAL but to provide the broadest form of protection for project owners I'd require new signatures.

from clahub.

@jasonm wrote (see #19) "@AJ-Acevedo - using SemVer on CLA text is an interesting thought experiment. I'm not well-versed enough with the typical legal constructs to know what would constitute major/minor/tiny, but would love to hear any thoughts you folks have on it?"

I'm no lawyer but here are just my thoughts:

Versioning

CLA can be numbered with the following format:

<major>.<minor>.<patch>

And constructed with the following guidelines:

• New additions to the CLA terms bumps the major (and resets the minor and patch)
• Removal of, or modification of an existing term bumps the minor (and resets the patch)
• Typographical error fixes, grammar, and/or formatting changes bumps the patch

For more information on SemVer, please visit http://semver.org/.

+1 for a checkbox during the text update process that requests user's to agree to the updated terms. Also this checkbox should be checked by default.

from clahub.

👍

from clahub.