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

Berg, Alan A.M.Berg at uva.nl
Sun Mar 16 08:29:26 PDT 2014 

Hi Neal,

>We are thinking about asking folks who already have a CLA on-file under the Sakai Foundation (which AFAIK is still perfectly valid)

Prefer not see developers signing a second time if their first signing is still valid.

Regards,
           Alan


Alan Berg

Innovation working group
On the use of ICT in Education & Research
University of Amsterdam
Postbus 1025 / 1000 BA Amsterdam
Weesperzijde 190 / 1097 DZ Amsterdam
________________________________
From: sakai-pmc-bounces at collab.sakaiproject.org [sakai-pmc-bounces at collab.sakaiproject.org] on behalf of Neal Caidin [neal.caidin at apereo.org]
Sent: 16 March 2014 15:05
To: Anthony Whyte
Cc: sakai-pmc at collab.sakaiproject.org; cle-release-team at collab.sakaiproject.org
Subject: Re: [sakai-pmc] [cle-release-team] Managing CLA's with new contributions



> so long as a commitment is made to keep the list up-to-date

I don't mind keeping the list up-to-date, it is GETTING the list up-to-date, since we just started such a list under the Apereo licensing process, so we only have a handful of entries.

We are thinking about asking folks who already have a CLA on-file under the Sakai Foundation (which AFAIK is still perfectly valid), if they would mind signing a new one under the Apereo Foundation and submit it through our new process. That will provide us a trigger to do the database entry (Google form/spreadsheet).

I'm not sure if this makes sense to do, but it could be a relatively easy effort if we have the forms available at the Open Apereo conference. It would cover probably most of the people we need, and I could follow up with the rest.

Not sure if this makes sense but it might be one way to work towards an up-to-date list, which like I said, I don't mind keeping up to date.

Thanks,
Neal


[cid:part1.04040708.09020902 at apereo.org]
Anthony Whyte<mailto:arwhyte at umich.edu>
March 12, 2014 at 10:33 PM

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<mailto: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<mailto: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<mailto: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


[cid:part2.01010402.07090703 at apereo.org]
Aaron Zeckoski<mailto:azeckoski at unicon.net>
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




[cid:part3.00080509.06020107 at apereo.org]
Sam Ottenhoff<mailto:ottenhoff at longsight.com>
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.
[cid:part4.05070906.00020606 at apereo.org]
Neal Caidin<mailto:neal.caidin at apereo.org>
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<mailto: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<mailto: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<mailto:cle-release-team at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

[cid:part5.06070708.05060603 at apereo.org]
Steve Swinsburg<mailto:steve.swinsburg at gmail.com>
March 12, 2014 at 9:47 PM
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.



[cid:part6.04070008.08060200 at apereo.org]
Neal Caidin<mailto:neal.caidin at apereo.org>
March 12, 2014 at 9:09 PM
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<mailto: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



[cid:part7.00000307.02030400 at apereo.org]
Aaron Zeckoski<mailto:azeckoski at unicon.net>
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




[cid:part8.08010201.09060005 at apereo.org]
Sam Ottenhoff<mailto:ottenhoff at longsight.com>
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
Sakai Community Coordinator
Apereo Foundation
neal.caidin at apereo.org<mailto:neal.caidin at apereo.org>
Skype me! (but let me know in advance for the first interaction) - nealkdin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 992 bytes
Desc: postbox-contact.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0008.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 1248 bytes
Desc: image.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0009.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 1265 bytes
Desc: image.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0010.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.jpg
Type: image/jpeg
Size: 886 bytes
Desc: image.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0011.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1251 bytes
Desc: postbox-contact.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0012.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: compose-unknown-contact.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0013.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1247 bytes
Desc: postbox-contact.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0014.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1265 bytes
Desc: postbox-contact.jpg
Url : http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20140316/ff1efc72/attachment-0015.jpg

More information about the cle-release-team mailing list