Re: Software Grants for GitHub Projects...
Matt, you're saying the same thing, except it's not one individual but two [1] (spmallette + okram) , who own the vast majority of the IP. They also claim to be in the possession of CLAs from the other contributors. The problem was not insufficient data to substantiate claims, but TMI. Secretary@ pushed back for that clear reason, the proposal for resubmission addressed that. If secretary@ will have additional concerns (including forwarding to legal@), we'll address them as they come. Hadrian [1] https://github.com/tinkerpop/tinkerpop3/graphs/contributors On 02/02/2015 09:53 AM, Matt Franklin wrote: On Mon Feb 02 2015 at 8:09:43 AM Hadrian Zbarcea hzbar...@gmail.com wrote: On 02/01/2015 03:19 PM, Benson Margulies wrote: On Sun, Feb 1, 2015 at 2:12 PM, John D. Ament johndam...@apache.org wrote: On Sun Feb 01 2015 at 1:05:10 AM Alex Harui aha...@adobe.com wrote: On 1/31/15, 9:09 AM, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Just curious, what if the code was under AL but not at Apache? The license is pretty clear about this: *5. Submission of Contributions*. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. So basically, anything you contribute back is assumed to be under the Apache license, unless you (the author) say otherwise or there's some other license in play (The apache license doesn't supersede other licenses). Of course you should consult with legal counsel before making any contributions though. I think to Benson's point, The ASF requires that any incoming code was put in under that license agreement or there's a SGA stating the prior license can be converted. Note the phrase, intentionally submitted for inclusion in the Work by You _to the Licensor_. Who is the licensor for a body of work not at Apache? The process has to start with a clear ownership of copyright -- the licensor. The purpose of the SGA, I think, is to get a clear answer to that question. You might be able to argue that a particular github repo is made up of an initial work with a single owner, and then contributions to it under the terms of the AL. In which case, you'd just need an SGA from that original single owner. IANAL. My understanding is that the Licensor is whomever claims to be 'it'. As long ans the claimant produces documentation to substantiate the claim that we can accept, we should be good. I don't see a need/requirement for the Licensor to necessarily be a legal organization. That is if it's not one single owner but a small group of contributors/owners, that should be ok too. My understanding is that the licensor must be able to own the copyright, thus a legal entity (company or individual). IMO, we should either take the acceptance of Tinkerpop as a Licensor to legal@ or we just ask anyone who has contributed signifiant IP to sign an ICLA with new copyright assignment. IANAL, $0.02, Hadrian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
On Mon, Feb 2, 2015 at 4:19 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: Matt, you're saying the same thing, except it's not one individual but two [1] (spmallette + okram) , who own the vast majority of the IP. They also claim to be in the possession of CLAs from the other contributors. The problem was not insufficient data to substantiate claims, but TMI. Secretary@ pushed back for that clear reason, the proposal for resubmission addressed that. If secretary@ will have additional concerns (including forwarding to legal@), we'll address them as they come. Well, the situation you describe here is about 180 degrees removed from the hypothetical that started this thread. So just about nothing written on this thread is relevant. If two people can make in conscience fill out an SGA, that's that. Hadrian [1] https://github.com/tinkerpop/tinkerpop3/graphs/contributors On 02/02/2015 09:53 AM, Matt Franklin wrote: On Mon Feb 02 2015 at 8:09:43 AM Hadrian Zbarcea hzbar...@gmail.com wrote: On 02/01/2015 03:19 PM, Benson Margulies wrote: On Sun, Feb 1, 2015 at 2:12 PM, John D. Ament johndam...@apache.org wrote: On Sun Feb 01 2015 at 1:05:10 AM Alex Harui aha...@adobe.com wrote: On 1/31/15, 9:09 AM, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Just curious, what if the code was under AL but not at Apache? The license is pretty clear about this: *5. Submission of Contributions*. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. So basically, anything you contribute back is assumed to be under the Apache license, unless you (the author) say otherwise or there's some other license in play (The apache license doesn't supersede other licenses). Of course you should consult with legal counsel before making any contributions though. I think to Benson's point, The ASF requires that any incoming code was put in under that license agreement or there's a SGA stating the prior license can be converted. Note the phrase, intentionally submitted for inclusion in the Work by You _to the Licensor_. Who is the licensor for a body of work not at Apache? The process has to start with a clear ownership of copyright -- the licensor. The purpose of the SGA, I think, is to get a clear answer to that question. You might be able to argue that a particular github repo is made up of an initial work with a single owner, and then contributions to it under the terms of the AL. In which case, you'd just need an SGA from that original single owner. IANAL. My understanding is that the Licensor is whomever claims to be 'it'. As long ans the claimant produces documentation to substantiate the claim that we can accept, we should be good. I don't see a need/requirement for the Licensor to necessarily be a legal organization. That is if it's not one single owner but a small group of contributors/owners, that should be ok too. My understanding is that the licensor must be able to own the copyright, thus a legal entity (company or individual). IMO, we should either take the acceptance of Tinkerpop as a Licensor to legal@ or we just ask anyone who has contributed signifiant IP to sign an ICLA with new copyright assignment. IANAL, $0.02, Hadrian
Re: Practical next steps for pTLP experiment
On Mon, Feb 2, 2015 at 5:38 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I missed a few important points in this thread last week, with which I disagree: On Tue, Jan 27, 2015 at 7:28 PM, Greg Stein gst...@gmail.com wrote: ...1) Draft a template resolution. Starting in the wiki is fine, but you'll want to involve board@ when you have your first draft done IMO board members have more important things to do than work on draft resolutions for new projects, and it's also important for drafts of new projects to be discussed in public. If only to allow new people and mentors to jump in. I strongly suggest discussing such draft resolutions on this list. Even if the Incubator PMC is not formally involved in managing those pTLPs, this list is where the know-how about creating new projects resides, I see no reason to move that work elsewhere. ...2) Create a ComDev page discussing what it means to be a provisional TLP I don't understand why people want these things to move to comdev - did you even ask the comdev PMC about this? It sounds like people want to send a bunch of tasks their way, without even asking. Three possible models: 1: 'comdev will do it'. I agree with you that this is wrong. 2: 'let's go over to comdev and volunteer to build some documentation for an alternative launch mechanism'. This experiments with expanding comdev in the direction. 3: 'build the doc at the existing incubator.' The momentary impulse is (2). You might find it tolerable. I see no reason for the pTLP process definition to happen outside of the Incubator, which is the PMC tasked with bringing new projects to the ASF. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Practical next steps for pTLP experiment
Hi, On Mon, Feb 2, 2015 at 1:41 PM, Benson Margulies bimargul...@gmail.com wrote: ...2: 'let's go over to comdev and volunteer to build some documentation for an alternative launch mechanism'. This experiments with expanding comdev in the direction The momentary impulse is (2). You might find it tolerable. Yes, as long as it's done and discussed openly on the comdev list. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
On 02/01/2015 03:19 PM, Benson Margulies wrote: On Sun, Feb 1, 2015 at 2:12 PM, John D. Ament johndam...@apache.org wrote: On Sun Feb 01 2015 at 1:05:10 AM Alex Harui aha...@adobe.com wrote: On 1/31/15, 9:09 AM, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Just curious, what if the code was under AL but not at Apache? The license is pretty clear about this: *5. Submission of Contributions*. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. So basically, anything you contribute back is assumed to be under the Apache license, unless you (the author) say otherwise or there's some other license in play (The apache license doesn't supersede other licenses). Of course you should consult with legal counsel before making any contributions though. I think to Benson's point, The ASF requires that any incoming code was put in under that license agreement or there's a SGA stating the prior license can be converted. Note the phrase, intentionally submitted for inclusion in the Work by You _to the Licensor_. Who is the licensor for a body of work not at Apache? The process has to start with a clear ownership of copyright -- the licensor. The purpose of the SGA, I think, is to get a clear answer to that question. You might be able to argue that a particular github repo is made up of an initial work with a single owner, and then contributions to it under the terms of the AL. In which case, you'd just need an SGA from that original single owner. IANAL. My understanding is that the Licensor is whomever claims to be 'it'. As long ans the claimant produces documentation to substantiate the claim that we can accept, we should be good. I don't see a need/requirement for the Licensor to necessarily be a legal organization. That is if it's not one single owner but a small group of contributors/owners, that should be ok too. IANAL, $0.02, Hadrian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Solicitation for IPMC Chair nomination
Last call for [self-]nominations! It has been a week since the original email and I'd like to keep the thread going for a day or two and then start the official vote so we wrap it up in time for this months board resolution. Thanks, Roman. On Mon, Jan 26, 2015 at 10:45 AM, Roman Shaposhnik r...@apache.org wrote: Hi! after making sure that there's still an Incubator to be managed for the next 6-12 months, I'd like to open up a discussion thread on soliciting nominations for the next IPMC Chair. Feel free to self-nominate or nominate folks who you know. Provide a summary of your 'program' or not. At this point, we want as much feedback and discussion as possible. The VOTE thread will come in a few weeks. Things to keep in mind while thinking about nominating yourself or others: 1. This is a 6-12 months commitment that, based on my personal experience, would require you to allocate 7-10 hours per week. 2. This is a rotating Chair and you would be expected to start a similar thread in 12 months. 3. From where I sit, the most important job for the new Chair for the next few months would be to help shape the incremental, actionable plan for improving the mentoring situation in the Incubator. 4. The situation around 'professional student' podlings is not improving nearly quick enough (4 years without a single release? really?). Anybody who has actionable ideas on how to improve it would get my support. Now, to get the ball rolling, here are the two folks I'd like to suggest as future IPMC Chairs: * Ted Dunning * Henry Saputra In my view, both have demonstrated an exceptional understanding of the 'Apache Way', dedication to mentoring podlings they are responsible for and enthusiasm around bringing new communities into the ASF family. On top of that, both have exercised a remarkable skill in conducting public discussions and driving towards consensus. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Practical next steps for pTLP experiment
Hi, I missed a few important points in this thread last week, with which I disagree: On Tue, Jan 27, 2015 at 7:28 PM, Greg Stein gst...@gmail.com wrote: ...1) Draft a template resolution. Starting in the wiki is fine, but you'll want to involve board@ when you have your first draft done IMO board members have more important things to do than work on draft resolutions for new projects, and it's also important for drafts of new projects to be discussed in public. If only to allow new people and mentors to jump in. I strongly suggest discussing such draft resolutions on this list. Even if the Incubator PMC is not formally involved in managing those pTLPs, this list is where the know-how about creating new projects resides, I see no reason to move that work elsewhere. ...2) Create a ComDev page discussing what it means to be a provisional TLP I don't understand why people want these things to move to comdev - did you even ask the comdev PMC about this? It sounds like people want to send a bunch of tasks their way, without even asking. I see no reason for the pTLP process definition to happen outside of the Incubator, which is the PMC tasked with bringing new projects to the ASF. -Bertrand - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Software Grants for GitHub Projects...
On Mon Feb 02 2015 at 8:09:43 AM Hadrian Zbarcea hzbar...@gmail.com wrote: On 02/01/2015 03:19 PM, Benson Margulies wrote: On Sun, Feb 1, 2015 at 2:12 PM, John D. Ament johndam...@apache.org wrote: On Sun Feb 01 2015 at 1:05:10 AM Alex Harui aha...@adobe.com wrote: On 1/31/15, 9:09 AM, Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 11:32 AM, Matt Franklin m.ben.frank...@gmail.com wrote: On Sat Jan 31 2015 at 11:22:15 AM Benson Margulies bimargul...@gmail.com wrote: On Sat, Jan 31, 2015 at 10:55 AM, James Carman ja...@carmanconsulting.com wrote: Are there guidelines for these usual considerations? For all the small stuff, the safe path is to get an ICLA from each committer, and an email message positively stating an intent to donate the code. Yes, this is the safest approach; but, may not be necessary for changes that do not represent significant IP. For instance, our projects accept minor contributions through JIRA, without an ICLA. There's a critical distinction here. Once you have released a product under the Apache license, people can contribute new things to it under the terms of the license. The license has very specific language: if you take code from us, and then send us a contribution (email, JIRA, github PR, carrier pigeon) that is a derivative of what you took, you are granting the code to the Foundation. That doesn't help with the initial import of a project from github or bitbucket or Jupiter or Mars; none of those contributions met the criteria in the license of sending a contribution back to the Foundation, because the code wasn't here in the first place. Just curious, what if the code was under AL but not at Apache? The license is pretty clear about this: *5. Submission of Contributions*. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. So basically, anything you contribute back is assumed to be under the Apache license, unless you (the author) say otherwise or there's some other license in play (The apache license doesn't supersede other licenses). Of course you should consult with legal counsel before making any contributions though. I think to Benson's point, The ASF requires that any incoming code was put in under that license agreement or there's a SGA stating the prior license can be converted. Note the phrase, intentionally submitted for inclusion in the Work by You _to the Licensor_. Who is the licensor for a body of work not at Apache? The process has to start with a clear ownership of copyright -- the licensor. The purpose of the SGA, I think, is to get a clear answer to that question. You might be able to argue that a particular github repo is made up of an initial work with a single owner, and then contributions to it under the terms of the AL. In which case, you'd just need an SGA from that original single owner. IANAL. My understanding is that the Licensor is whomever claims to be 'it'. As long ans the claimant produces documentation to substantiate the claim that we can accept, we should be good. I don't see a need/requirement for the Licensor to necessarily be a legal organization. That is if it's not one single owner but a small group of contributors/owners, that should be ok too. My understanding is that the licensor must be able to own the copyright, thus a legal entity (company or individual). IMO, we should either take the acceptance of Tinkerpop as a Licensor to legal@ or we just ask anyone who has contributed signifiant IP to sign an ICLA with new copyright assignment. IANAL, $0.02, Hadrian - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Twill-0.4.1.-incubating
NOTICE file needs to have year updated but not blocker and JIRA is filed: TWILL-114 LICENCE file looks good DISCLAIMER file looks good Hash files look good Signature file look good No 3rd party executable in source artifact +1 (binding) - Henry On Mon, Feb 2, 2015 at 10:18 AM, Terence Yim cht...@apache.org wrote: Hi all, This is to call for a vote for releasing twill-0.4.1-incubating. This is the fifth release for Twill. Vote on twill-dev: http://s.apache.org/HKb Result on vote on twill-dev: http://s.apache.org/921 The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/incubator/twill/0.4.1-incubating-rc3/src The tag to be voted upon is v0.4.1-incubating: https://git-wip-us.apache.org/repos/asf?p=incubator-twill.git;a=shortlog;h=refs/tags/v0.4.1-incubating The release hash is d2bebf3f016e77e6fb12bf8297053c7b081e92a5 https://git-wip-us.apache.org/repos/asf?p=incubator-twill.git;a=commit;h=d2bebf3f016e77e6fb12bf8297053c7b081e92a5 The Nexus Staging URL: https://repository.apache.org/content/repositories/orgapachetwill-1011 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/chtyim.asc KEYS file available here: https://dist.apache.org/repos/dist/dev/incubator/twill/KEYS For information about the contents of this release see: https://dist.apache.org/repos/dist/dev/incubator/twill/0.4.1-incubating-rc3/CHANGES.txt Please vote on releasing this package as Apache Twill 0.4.1-incubating The vote will be open for 72 hours. [ ] +1 Release this package as Apache Twill 0.4.1-incubating [ ] +0 no opinion [ ] -1 Do not release this package because ... Thanks, The Apache Twill Team - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Streams version 0.1-incubating (rc3)
Justin, Most likely the problem you ran into in streams-provider-twitter was caused by jar artifacts in your local maven repo from the prior release candidate you built. Same thing happened to me. I've made a note of your feedback re. MAVEN_OPTS: https://issues.apache.org/jira/browse/STREAMS-271 The project is already tracking the NOTICE file issue: https://issues.apache.org/jira/browse/STREAMS-270 Thanks, Steve Blackmon sblack...@apache.org On Thu, Jan 29, 2015 at 11:36 PM, Justin Mclean jus...@classsoftware.com wrote: Hi, +1 (binding) I checked: - signatures correct - incubating in source package name - DISCLAIMER exists - NOTICE and LICENSE correct - all source file have Apache header - no unexpected binary files in release - can compile from source - couldn't get all tests to pass (streams-provider-twitter failed) but that may be my setup. You may want to look into this. Minor issues: - Year wrong in NOTICE file - can you fix this for the next release please. - Update readme to include recommend MAVEN_OPTS so you don't run out of memory when compiling Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Release Apache Twill-0.4.1.-incubating
Hi all, This is to call for a vote for releasing twill-0.4.1-incubating. This is the fifth release for Twill. Vote on twill-dev: http://s.apache.org/HKb Result on vote on twill-dev: http://s.apache.org/921 The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/incubator/twill/0.4.1-incubating-rc3/src The tag to be voted upon is v0.4.1-incubating: https://git-wip-us.apache.org/repos/asf?p=incubator-twill.git;a=shortlog;h=refs/tags/v0.4.1-incubating The release hash is d2bebf3f016e77e6fb12bf8297053c7b081e92a5 https://git-wip-us.apache.org/repos/asf?p=incubator-twill.git;a=commit;h=d2bebf3f016e77e6fb12bf8297053c7b081e92a5 The Nexus Staging URL: https://repository.apache.org/content/repositories/orgapachetwill-1011 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/chtyim.asc KEYS file available here: https://dist.apache.org/repos/dist/dev/incubator/twill/KEYS For information about the contents of this release see: https://dist.apache.org/repos/dist/dev/incubator/twill/0.4.1-incubating-rc3/CHANGES.txt Please vote on releasing this package as Apache Twill 0.4.1-incubating The vote will be open for 72 hours. [ ] +1 Release this package as Apache Twill 0.4.1-incubating [ ] +0 no opinion [ ] -1 Do not release this package because ... Thanks, The Apache Twill Team - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
