On Fri, Oct 22, 2010 at 11:30 AM, Jeff King <peff@xxxxxxxx> wrote: > There is one slight caveat, which is that JGit was not accepted, due to > the complexity of their ties with the Eclipse Foundation. Yup. Anytime you say "Eclipse Foundation", make sure you put "complexity" into the same sentence. Its required to make the sentence accurate. :-) > In practice, I > don't think this will matter much at all. The only way that Git operates > in any legal capacity as a group is when we do Summer of Code. This > could impact us, e.g., if were to have a JGit-specific SoC project. We had a GSoC project, but through the Eclipse Foundation participation in GSoC, not Git. So the Eclipse Foundation received our mentor stipend for us, and will spend it in some way that is unknown to me. Yay? The decision to do JGit GSoC through Eclipse and not through Git this year wasn't really mine. I just didn't disagree loud enough to change things. > Probably the money that goes to the organization for such a project > should _not_ go through the SFC, and would have to be handled > separately. Which is no worse than JGit has it today; they just can't > receive the SFC services as regular git can. This is fine with the JGit folks, for now anyway. We may revisit this and have JGit join SFC at some point in the future. We might not. > Basically what we need to decide on before signing is: > > 1. Who should sign? These people are basically speaking for git as a > community. Related to (2) below. The people listed in 2 as the leadership structure of git. > 2. What is the leadership structure of git as a legal entity? In other > words, if we get some money that goes to the SFC (from SoC or from > donations), who should have authority to tell the SFC to do > something with it? > > The obvious choices (to me) are: > > a. Junio as benevolent dictator^W maintainer. > > b. Somebody else as benevolent SFC liaison. > > c. Some committee of core people (I'd say no more than 3-5) who > would all need to agree (or perhaps some majority). ... > Personally, I favor a small group which can approve new people to > join, and which can leave at will. Having more than one person > avoids hit-by-bus problems (or even just dropped-off-net problems). > There is little enough power in such a position that I'm not too > worried about some crazed egomaniac becoming the Git-SFC liaison. I agree. I think a committee of at least 3 people and at most 5, any of whom can be a benevolent SFC liasion, is fine. As far as selection goes, the committee can elect or remove a member through a majority vote, and should base its decisions based on surviving contributions to the code base, but shouldn't be tied to that (just in case someone contributes a lot of good code and then becomes a jerk). But as you point out, there isn't much power involved here, so there isn't a lot of concern of it being abused. The important thing (the copyright on the code) is still held by individual contributors, so there is very little value involved (just the handful of GSoC dollars each year). > 3. How much money should we give to the SFC? > > A big chunk of their budget comes from taking a percentage of > member project money. As a project, we set the percentage we give > them. So we can give them nothing if we want. But they do provide > useful services, and even without direct benefit to git, the SFC is > promoting free software. So probably it makes sense to choose some > non-zero number. I agree, a non-zero number. 2-5%? Any idea what is typical? -- Shawn. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html