--- Leo Simons <[EMAIL PROTECTED]> wrote: ...snip... > > Scenario: > > A project (Project A) is set up on Source Forge by > > individuals as the only legal entities. Project A > is > > setup under the Apache License V2. What would > Project > > A need to do beforehand to ensure that all code > > committed to Project A's SVN is available for an > > existing ASF project to incorporate into it's code > > base in the following scenarios: > > > > 1) ASF committer incorporates code from Project A > > directly into the ASF project > > 2) Member of Project A submits a patch file to the > > JIRA of the ASF project > > 3) Non Member of Project A submits patch file from > > Project A to the JIRA of the ASF project. > > IANAL, but am pretty sure I'm right :) > > #2 is fine in any and all cases, as far as the ASF > is concerned -- > for #2, the responsibility is on the member of > Project A to ensure he > can contribute the patch (ie, normally, any IP > rights on the patch > should be his only, and he asserts so by > contributing). Our jira > config requires this for any attachment. It is best > if this member of > Project A contributes the patch under a CLA. The ASF > project doesn't > need to do anything special. Note this should only > be done for small > patches.
The purpose of the other project is to be a sort of impromptu venue for collaboration of things related to the ASF project. The ASF project in question (The Apache Open for Business Project - OFBiz), has a history of being relatively stable in SVN. So generally, contributions that get put back into the project _work. Following the one contributor per JIRA patch approach makes it difficult for people in the community to share their works in progress. Since the goal is to share their works in progress to get them "inclusion worthy" anything that moves from Project A to OFBiz will by design have more than one contributor. > > #1 and #3 are scenarios that are hairy, complicated, > harder to audit, > and, hence, discouraged. > > Instead, it is better to follow one of these two > scenarios: > > 4) Project A releases a source and binary > distribution (probably as > a .jar) which can be used directly from the ASF > project. The ASF > project adds information in the LICENSE file about > the dependency, > and doesn't need to do anything else. Project A > releases early and > often and incorporates patches from the ASF > project's committers > promptly. > Most of the contributions that come from Project A will be derivative of OFBiz, so jars end up creating redundant code or make it difficult to incorporate. > 5) an ASF project does not want to do #4, so all the > developers on > Project A sign a CLA and a code grant for a sizeable > chunk of the > Project A source. The ASF project follows the > incubator's "IP > clearance" process. > While I see #5 being the front runner approach, this does put quite a burden on the ASF project. In work that is to be contributed from Project A to the ASF project the temporary "partnership" wants to collectively and individually grant the ASF the license as in #2, but has no mechanism to provide that grant collectively. Thanks for taking the time to ponder this for me, Chris P.S. I never thought it would be this hard to give stuff away for free :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
