[cle-release-team] [sakai-pmc] Managing CLA's with new contributions

[Anthony Whyte]

> Is there a privacy issue in having a public list of people that have CLAs on file? I dont see why there woukld be, I would consider it the same as the list of members of the PMC.

None that I am aware.  In any case, our commit stream is public [1], our Ohloh stats are public [2] and soon our Github personas will track against Sakai.  In each case it requires minimal effort to associate the tracked email address or account holder with the contributor behind it.  

> The list doesn't need to show the actual CLA, just that they have one, maybe the expiry date (if there is one?)

A public list of committers and contributors with signed CLAs on record would prove useful--so long as a commitment is made to keep the list up-to-date.  But what we really need is an automated mechanism for checks patches against a known set of CLAs -- for Github the Eclipse guys have created a web hook that validates pull requests against a list of committers. [3]   I think this approach far preferable to manual scans of a list of committers and contributors who have signed CLAs.  


Cheers,

Anth


[1] http://collab.sakaiproject.org/pipermail/source/
[2] http://www.ohloh.net/p/sakai/contributors/summary
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=415164; https://github.com/eclipse/eclipse-webhook


anthony whyte | its and mlibrary | university of michigan | arwhyte at umich.edu | 517-980-0228


On Mar 12, 2014, at 9:47 PM, Steve Swinsburg wrote:

> Is there a privacy issue in having a public list of people that have CLAs on file? I dont see why there woukld be, I would consider it the same as the list of members of the PMC.
> The list doesn't need to show the actual CLA, just that they have one, maybe the expiry date (if there is one?)
> 
> Then people could check that without being slowed down via emails to licensing etc.
> 
> 
> On Thu, Mar 13, 2014 at 12:09 PM, Neal Caidin <neal.caidin at apereo.org> wrote:
> How about something like this strawperson (as in, intended to generate discussion if you don't like it) procedure:
> 
> 1. If a developer sees a patch has significant IP and he is not sure if there is a CLA, write to licensing at apereo.org to ask.
> 
> 2. If the response is affirmative, then done. If response is negative, I'm on the licensing group and can follow up to get the CLA(s). 
> 
> 3. I'll comment on the ticket when the CLA(s) are on file, or provide an update if they are taking some time.
> 
> This only falls down if I happen not to be available (I keep the TCC chair informed of my schedule). 
> 
> -- Neal
> 
> 
>> 	Aaron Zeckoski	March 12, 2014 at 5:12 PM
>> How would I know if someone has a CLA or not when I am reviewing and
>> applying a patch from them?
>> -AZ
>> 
>> 
>> 
>> 
>> 	Sam Ottenhoff	March 12, 2014 at 4:45 PM
>> > and that it is up to those who have commit privileges to
>> > make sure not to commit something large from a person that does not have
>> > a CCLA.  Does everyone agree with this characterization?
>> 
>> Yeah more or less, but I'd like to see our community coordinator role stay up to date on large patches and to contact institutions and individuals that don't have CLAs signed.  If there is no contact back from the individual or institutional rep, the community coordinator should leave a note on the JIRA.  
>> 	Neal Caidin	March 12, 2014 at 4:32 PM
>> [Sakai PMC and Sakai Core Team] 
>> 
>> Howdy folks, 
>> 
>> I've been trying to get my brain wrapped around how to best manage incoming contributions and CLAs. From talking (virtually) with the Apereo Licensing group and based on the Apereo licensing documentation [1] , it seems that the spirit or intention is that small fixes do not need CLA's but larger and more complex contributions do need CLA's (corporate Contributor License Agreements - CCLA's ; and individual Contributor Licenses - iCLA's). 
>> 
>> One suggestion from Dr. Chuck is that at some point a "patch" becomes a contribution when it includes new significant IP rather than just fixing a bug or glitch and that it is up to those who have commit privileges to make sure not to commit something large from a person that does not have a CCLA.  Does everyone agree with this characterization? 
>> 
>> [1] Apereo licensing documentation - http://www.apereo.org/licensing 
>> 
>> Thanks, 
>> Neal 
>> 
>> 
> 
> -- 
> Neal Caidin
> Sakai Community Coordinator
> Apereo Foundation
> neal.caidin at apereo.org
> Skype me! (but let me know in advance for the first interaction) - nealkdin
> 
> 
> _______________________________________________
> sakai-pmc mailing list
> sakai-pmc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-pmc
> 
> 
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140312/bdda7fdf/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1247 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140312/bdda7fdf/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1265 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140312/bdda7fdf/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140312/bdda7fdf/attachment-0005.jpg