{"thread":{"id":"25528","subject":"git as an sfc member project","startedAt":"2010-10-22T18:30:28Z","lastAt":"2010-11-02T23:03:55Z","messageCount":21,"participants":["Jeff King","Shawn Pearce","Sverre Rabbelier","Junio C Hamano","Brandon Casey","Ævar Arnfjörð Bjarmason","A Large Angry SCM","Tait","Bradley M. Kuhn"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"154179","messageId":"20101022183027.GA12124@sigill.intra.peff.net","threadId":"25528","inReplyTo":null,"subject":"git as an sfc member project","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-22T18:30:28Z","receivedAt":"2010-10-22T18:30:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"It's been a while since I last sent an update; the reason is that\nnothing was happening. :) The SFC didn't have a board meeting to vote on\nnew projects until September, and then spent a few weeks getting\npaperwork together. But now we have official word: git has been accepted\nas a member project.\n\nBasically, the utility of this is that the Software Freedom Conservancy\nwill handle any money that goes to the project, especially with respect\nto tax implications (the SFC is a registered non-profit and has actual\naccountants and such). In the past, the only money has ever been Summer\nof Code money, and some unlucky soul had to handle the money (and tax\nimplications) each year by themselves. Joining the SFC will also make it\neasier for people to give tax-deductible donations to the project. Of\ncourse I have no idea what we would spend such money on, but that is a\nproblem we can perhaps deal with later.\n\nThere is one slight caveat, which is that JGit was not accepted, due to\nthe complexity of their ties with the Eclipse Foundation. In practice, I\ndon't think this will matter much at all. The only way that Git operates\nin any legal capacity as a group is when we do Summer of Code. This\ncould impact us, e.g., if were to have a JGit-specific SoC project.\nProbably the money that goes to the organization for such a project\nshould _not_ go through the SFC, and would have to be handled\nseparately. Which is no worse than JGit has it today; they just can't\nreceive the SFC services as regular git can.\n\nNote that we're not officially a member project yet, as nothing has been\nsigned. So if people have objections, it's not too late to say\nsomething. If we do want to go ahead, we need to fill in some details\nthat will go in the agreement.\n\nThe draft agreement is here:\n\n  http://peff.net/git-sponsorship-agreement.pdf\n\nApologies for not simply attaching it, but it is larger than vger's 100K\nmessage limit.\n\nBradley Kuhn also provided a some discussion of the various points in\nthe agreement, including deciphering the legalese and explaining the\nmotivation for each paragraph. I'll include it at the end of this email.\n\nBasically what we need to decide on before signing is:\n\n  1. Who should sign? These people are basically speaking for git as a\n     community. Related to (2) below.\n\n  2. What is the leadership structure of git as a legal entity? In other\n     words, if we get some money that goes to the SFC (from SoC or from\n     donations), who should have authority to tell the SFC to do\n     something with it?\n\n     The obvious choices (to me) are:\n\n       a. Junio as benevolent dictator^W maintainer.\n\n       b. Somebody else as benevolent SFC liaison.\n\n       c. Some committee of core people (I'd say no more than 3-5) who\n          would all need to agree (or perhaps some majority).\n\n     For (b) and (c), we would need to figure out who the somebody or\n     somebodies would be, and perhaps more importantly, the process for\n     selecting them. As time goes on, core people may leave, and new\n     core people may replace them.\n\n     We could go as complicated as having elections, or as simple as\n     \"liaison appoints successor\".\n\n     Personally, I favor a small group which can approve new people to\n     join, and which can leave at will. Having more than one person\n     avoids hit-by-bus problems (or even just dropped-off-net problems).\n     There is little enough power in such a position that I'm not too\n     worried about some crazed egomaniac becoming the Git-SFC liaison.\n\n  3. How much money should we give to the SFC?\n\n     A big chunk of their budget comes from taking a percentage of\n     member project money. As a project, we set the percentage we give\n     them. So we can give them nothing if we want. But they do provide\n     useful services, and even without direct benefit to git, the SFC is\n     promoting free software. So probably it makes sense to choose some\n     non-zero number.\n\nMore details are in the agreement linked above, or in Bradley's\nexplanation below.\n\n-Peff\n\n-- >8 --\nI'm glad that you are considering joining the Conservancy and I am\npleased to extend an invitation to Git.  Attached is a draft of the\nfiscal sponsorship agreement that representatives of Git will need to\nsign in order to join the Conservancy.  (Both LaTeX source and PDF are\nincluded.) Please read this agreement and share and discuss it with all\nof the key people involved in Git.\n\nAs mentioned in my previous email, generally, we leave it for the Git\ncommunity to decide how you'd like to discuss the document, as signing\nsuch an agreement is a big step for the project and you should consider\nthe agreement in whatever forum is most appropriate for your community.\nI'm happy to answer questions from the community as you consider the\ndocument, and you should feel comfortable cc'ing me on any threads you\nthink I should comment on.  (However, before doing so, please make sure\nI can post back to any lists included in the Cc without being formally\nsubscribed.)  Meanwhile, you are also welcome to batch questions into\none group as well and email them to me directly, and just repost my\nresponses.  Basically, whatever works well for you works fine for me.\n\nI strongly suggest that you share the agreement draft as wide as\npossible throughout the community, and make sure anyone who has ever\nbeen a serious contributor to the project in the past or currently is\nmade aware of your plans to join Conservancy.  We very much rely on you\nto make sure that your entire community is in agreement with joining\nConservancy, so please make efforts to be sure everyone has had their\nsay.\n\n\nRegarding the agreement, some of the more complex provisions of the\nagreement reflect the special considerations necessary to support the\nConservancy's tax exempt status.  However, on the whole, I believe that\nthis agreement fairly and clearly sets out an advantageous relationship\nfor the Conservancy's member projects.  As some of the paragraphs\nspecifically indicate, the agreement can be tailored to reflect Git's\nparticular needs.  To help you in your review, below is a\nsection-by-section walk through, giving an explanation of the\nsignificance of each provision.  If there are any sections that seem\nconfusing or that you feel should be changed to reflect Git's needs,\nplease let me know and we can discuss them.\n\n\nIntroductory Paragraph\n\nThis paragraph identifies the parties to the contract.  It's more\nthoroughly explained in paragraph 6, but the point of this paragraph is\nto name the people who sign the agreement.\n\nRecitals (the \"WHEREAS\" section)\n\nThese paragraphs set forth the basic understandings of the parties.\nSimilar to the \"preamble\" found in the GPL and other Free Software\nlicenses, these are *not* operative provisions of the document.\nInstead, they give the context of the agreement.\n\nIn this specific case, the key points of understanding are that the\npurpose of Git is to forward Free, Libre and Open Source Software\n(FLOSS) and that both the Conservancy and Git want Git to join the\nConservancy.  The Conservancy's mission (and charitable purpose) is to\nadvance only FLOSS development, documentation, and usage, so it is\nimportant that this context be stated clearly.\n\nParagraph 1 - Term of Agreement\n\nThis paragraph says that Git is part of the Conservancy as of the\nsigning date of the agreement.  It cross references the terminations\nprovisions in paragraph 7 (which is explained in greater detail below).\nNote, though, that Git can choose to leave the Conservancy at any time.\n\nParagraph 2 - Project Management and Activities\n\na) Both parties agree that Git will be FLOSS.  As noted above, this is\n   the fundamental goal and charitable purpose of the Conservancy.  The\n   Conservancy will not and cannot sponsor proprietary projects.\n\nb) This clearly sets out the limits of the Conservancy's management over\n   Git.  Due to requirements connected to Conservancy's tax exempt\n   status, the ultimate legal control of the projects must be with the\n   Conservancy.  From the IRS's perspective, the projects are part of\n   the Conservancy, and the purpose of its tax exemption is to forward\n   the FLOSS mission of those projects.\n\n   However, the Conservancy does not want to interfere with the\n   successful software development, documentation and advocacy work\n   already underway in member projects; such activity should continue\n   after the agreement without interruption or interference.  This\n   paragraph delegates some of Conservancy's legal authority back to the\n   developers, so that Git can run itself in day-to-day matters.\n\n   The only limitations that we must place are to prevent Git from\n   producing non-free software (as per Conservancy's charitable purpose)\n   and from spending money or conducting activities that would\n   jeopardize the Conservancy's tax exempt status.  All the ordinary\n   activities of FLOSS projects come well within these limitations.\n   Some specific activities that are restricted include lobbying\n   activities and spending money in ways other than consistent with the\n   charitable purposes of the Conservancy (i.e., forwarding FOSS).\n\n   Note that developers of Git in their capacity as individuals (when\n   not representing Git still may engage in for-profit service\n   businesses related to their FLOSS work.  The work of Git itself must\n   fit the guidelines, but individuals are free to act in their own\n   capacity in other endeavors, as long as they clearly state that they\n   are not acting on behalf of the project when they do so.\n\n   If you are ever concerned that a particular activity -- be it one\n   carried out for Git or one that an individual developer engaged in\n   independently -- might be a problem, you can always ask the\n   Conservancy for clarification.\n\nc) As discussed above in (b), this section describes the corporate\n   relationship of the project and the Conservancy.  For clarity, it\n   refers to section (b), which delegates the actual management of Git\n   to the relevant developers.  Conservancy, when acting as a fiscal\n   sponsor, must have the legal authority to manage Git even though\n   section (b) delegates the day-to-day operations to the developers.\n\nd) This section clarifies that Git can't represent the Conservancy\n   without getting written authorization first.  If you'd like to\n   represent the Conservancy at a conference or other such event, you\n   can always talk to us about it.\n\nParagraph 3 - No Fees\n\nIt's just as it sounds.  The Conservancy provides services to projects\nto benefit the FLOSS community and does demand member projects to bear\nthe overhead costs.  Projects are encouraged to make donations to the\nConservancy as a percentage of their funds to assist the Conservancy\nwith its operating expenses.  Please note, though, that Conservancy is\nonly able to provide its services to member projects because there is a\nreasonably healthy general fund available.  Donations from our member\nprojects are not the only source of general fund revenue, but it is a\nsubstantial component in Conservancy' sustainability plan.\n\nTherefore, if you choose to do so, this section provides suggested\nwording in brackets for donating a percentage of the Project's income to\nbe used towards keeping the Conservancy up and running (10% is a very\ncommon rate that many umbrella organizations require for their fiscal\nsponsorship services).\n\nParagraph 4 - Project Fund/Variance Power\n\nThis sets out the financial structure in connection with the\nrelationship described above in paragraph 2. Conservancy will separately\naccount for Git's revenue (and Git will have its own bank account at the\nConservancy once its balance reaches $3,500).  For tax purposes,\nConservancy will report all of the income to Git in its IRS and state\nfilings.  Git therefore will not need to file any separate tax documents\nwith the IRS.  Conservancy will keep the financial books for Git,\nsending periodic reports to the project's developers.\n\nThe developers will direct the Conservancy to spend the money on behalf\nof Git within the limitations imposed by the tax laws and Conservancy's\n501(c)(3) mission.  Conservancy will receive any checks on behalf of\nGit, and it will also write checks on behalf of Git.\n\nParagraph 5 - Project Fund Management/Performance of Charitable Purposes\n\nThis paragraph clarifies that all assets will be devoted to the\nproject's purposes, as those purposes are a subset of the Conservancy's\npurposes.  Assets cannot be used in connection with activities that\nwould jeopardize the Conservancy's tax exempt status.  As discussed\nabove, in practice, most typical expenses of FLOSS projects will come\nwell within these limitations.  Activities that are restricted include\nlobbying activities and spending money in ways other than consistent\nwith the charitable purposes of Conservancy (i.e., forwarding FLOSS).\n\nParagraph 6 - Representation of the Project in the Conservancy\n\nAs the note in this section indicates, we understand that each project\nwill have its own management structure that it has developed to reflect\nits size and community.  This paragraph requires that certain\nrepresentatives be named as the individuals that can officially\ncommunicate decisions on behalf of Git.  This can be a single\nmaintainer, a committee of developers or a few specified\nrepresentatives.\n\nTo the extent that it makes sense for Git to have a committee of\nrepresentatives, we should indicate how decisions can be made by that\ncommittee.  For example, should all decisions be communicated to the\nConservancy by all members of the committee or would a simple majority\nsuffice?  Can any one representative communicate official decisions on\nbehalf of all?  Git should also consider adding a mechanism here for\nadding and removing representatives over time.  We're happy to discuss\nmethods that have worked for other projects with you to help you select\nthe solution that is right for you.\n\nWe generally find this is the most difficult provisions for projects to\nwork out, as it does require that your project consider the form and\ntype of leadership structure it wants to have, and that structure will\nbe legally formalized in this document for perpetuity.\n\nParagraph 7 - Outstanding Liabilities\n\nIn this section, Git confirms that it has told the Conservancy about any\nliabilities that might be outstanding prior to joining the Conservancy.\nThis gives the Conservancy some assurance that its due diligence process\nhas been complete and that the Conservancy's Board received all of the\ninformation it needed to properly evaluate the project.  Liabilities\ninclude, for example, financial obligations, such as any debts or\noutstanding bills, or any legal claims that could be outstanding against\nGit.\n\nIf you believe some liabilities exist, or that something may be a\nliability and aren't sure, please err on the side of letting Conservancy\nknow about it.\n\nParagraph 8 - Termination\n\nProjects can leave Conservancy at will.  This section sets out the\nmechanisms for termination to make sure that when a project leaves the\nConservancy it does so without jeopardizing the tax exempt status of the\nConservancy (and, consequently, the status of all of the other projects\nin the Conservancy).\n\nThere is a 60 day notice requirement so that a new tax exempt non-profit\ncan be found for Git to join.  If there isn't another fiscal sponsor or\nother tax exempt non-profit to take over Git, Git can incorporate as a\nseparate entity and apply for tax exemption recognition.  If there is no\nseparate entity -- for example if a project loses momentum and has been\nabandoned by its developers -- the Conservancy must be left with the\nassets for use by the Conservancy for other FLOSS-related charitable\nwork.\n\nThese restrictions would also apply to any separate tax exempt entity,\nso if Git were to incorporate and achieve tax exemption outside of\nConservancy, it would have to deal with the same considerations upon any\nwind-up or distribution of assets.  Members of the Conservancy's board\nare familiar with non-profit wind-down situations, and can assist in the\nunlikely event that this unfortunate outcome occurs.\n\nParagraph 9 - Miscellaneous\n\nThese provisions are standard agreement boilerplate - they clarify the\nenforceability of separate provisions, specify that the contract be\ngoverned by New York Law and state that any amendments to this agreement\nneed to be agreed to in writing by all of the parties.\n\nParagraph 10 - Counterparts/Facsimile\n\nAlthough it's good to have original signatures in the corporate records,\nthis allows you to simply scan a copy for the contract to take effect.\n\n\nWe hope this explanation document has made it clear why the agreement is\nstructured in this way.  If any provisions seem problematic to you, let\nus know and we'll work with you to try to build an agreement that works\nfor both of us.  We look forward to Git joining the Conservancy!\n"},{"id":"154193","messageId":"AANLkTi=6tvmTAfdyL-sKBsq+4OpFaQpZWT66ANESNapj@mail.gmail.com","threadId":"25528","inReplyTo":"20101022183027.GA12124@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-10-22T19:19:00Z","receivedAt":"2010-10-22T19:19:00Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Fri, Oct 22, 2010 at 11:30 AM, Jeff King <peff@peff.net> wrote:\n> There is one slight caveat, which is that JGit was not accepted, due to\n> the complexity of their ties with the Eclipse Foundation.\n\nYup.  Anytime you say \"Eclipse Foundation\", make sure you put\n\"complexity\" into the same sentence.  Its required to make the\nsentence accurate.  :-)\n\n> In practice, I\n> don't think this will matter much at all. The only way that Git operates\n> in any legal capacity as a group is when we do Summer of Code. This\n> could impact us, e.g., if were to have a JGit-specific SoC project.\n\nWe had a GSoC project, but through the Eclipse Foundation\nparticipation in GSoC, not Git.  So the Eclipse Foundation received\nour mentor stipend for us, and will spend it in some way that is\nunknown to me.  Yay?\n\nThe decision to do JGit GSoC through Eclipse and not through Git this\nyear wasn't really mine.  I just didn't disagree loud enough to change\nthings.\n\n> Probably the money that goes to the organization for such a project\n> should _not_ go through the SFC, and would have to be handled\n> separately. Which is no worse than JGit has it today; they just can't\n> receive the SFC services as regular git can.\n\nThis is fine with the JGit folks, for now anyway.  We may revisit this\nand have JGit join SFC at some point in the future.  We might not.\n\n> Basically what we need to decide on before signing is:\n>\n>  1. Who should sign? These people are basically speaking for git as a\n>     community. Related to (2) below.\n\nThe people listed in 2 as the leadership structure of git.\n\n>  2. What is the leadership structure of git as a legal entity? In other\n>     words, if we get some money that goes to the SFC (from SoC or from\n>     donations), who should have authority to tell the SFC to do\n>     something with it?\n>\n>     The obvious choices (to me) are:\n>\n>       a. Junio as benevolent dictator^W maintainer.\n>\n>       b. Somebody else as benevolent SFC liaison.\n>\n>       c. Some committee of core people (I'd say no more than 3-5) who\n>          would all need to agree (or perhaps some majority).\n...\n>     Personally, I favor a small group which can approve new people to\n>     join, and which can leave at will. Having more than one person\n>     avoids hit-by-bus problems (or even just dropped-off-net problems).\n>     There is little enough power in such a position that I'm not too\n>     worried about some crazed egomaniac becoming the Git-SFC liaison.\n\nI agree.\n\nI think a committee of at least 3 people and at most 5, any of whom\ncan be a benevolent SFC liasion, is fine.  As far as selection goes,\nthe committee can elect or remove a member through a majority vote,\nand should base its decisions based on surviving contributions to the\ncode base, but shouldn't be tied to that (just in case someone\ncontributes a lot of good code and then becomes a jerk).\n\nBut as you point out, there isn't much power involved here, so there\nisn't a lot of concern of it being abused.  The important thing (the\ncopyright on the code) is still held by individual contributors, so\nthere is very little value involved (just the handful of GSoC dollars\neach year).\n\n>  3. How much money should we give to the SFC?\n>\n>     A big chunk of their budget comes from taking a percentage of\n>     member project money. As a project, we set the percentage we give\n>     them. So we can give them nothing if we want. But they do provide\n>     useful services, and even without direct benefit to git, the SFC is\n>     promoting free software. So probably it makes sense to choose some\n>     non-zero number.\n\nI agree, a non-zero number.  2-5%?  Any idea what is typical?\n\n-- \nShawn.\n"},{"id":"154196","messageId":"20101022193512.GB13059@sigill.intra.peff.net","threadId":"25528","inReplyTo":"AANLkTi=6tvmTAfdyL-sKBsq+4OpFaQpZWT66ANESNapj@mail.gmail.com","subject":"Re: git as an sfc member project","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-22T19:35:12Z","receivedAt":"2010-10-22T19:35:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 22, 2010 at 12:19:00PM -0700, Shawn O. Pearce wrote:\n\n> > Probably the money that goes to the organization for such a project\n> > should _not_ go through the SFC, and would have to be handled\n> > separately. Which is no worse than JGit has it today; they just can't\n> > receive the SFC services as regular git can.\n> \n> This is fine with the JGit folks, for now anyway.  We may revisit this\n> and have JGit join SFC at some point in the future.  We might not.\n\nYeah, what I should have said to be more clear in my original email is:\nJGit can do what they like with SFC, but there is no reason for this\ncaveat to prevent _Git_ from joining the SFC.  The JGit folks are no\nworse off, and things are much better for Git.\n\nI think it would be great if JGit could join SFC in the long run.\n\n> > Basically what we need to decide on before signing is:\n> >\n> >  1. Who should sign? These people are basically speaking for git as a\n> >     community. Related to (2) below.\n> \n> The people listed in 2 as the leadership structure of git.\n\nAgreed (I should have written point (2) first. ;) ).\n\n> I think a committee of at least 3 people and at most 5, any of whom\n> can be a benevolent SFC liasion, is fine.  As far as selection goes,\n> the committee can elect or remove a member through a majority vote,\n> and should base its decisions based on surviving contributions to the\n> code base, but shouldn't be tied to that (just in case someone\n> contributes a lot of good code and then becomes a jerk).\n\nThat sounds reasonable to me. I'm not sure what documentation, if any,\nwe need for such a structure. I guess we have to outline it in the\nagreement with the SFC, so that may be sufficient. We can ask Bradley\nabout it, too.\n\n> But as you point out, there isn't much power involved here, so there\n> isn't a lot of concern of it being abused.  The important thing (the\n> copyright on the code) is still held by individual contributors, so\n> there is very little value involved (just the handful of GSoC dollars\n> each year).\n\nYeah. I don't see any need to tie any decision on SFC interaction into\nany other part of how git is run. It should have nothing to do with how\nactual coding or release management works. I'm sure there will be some\noverlap in who is prominent in both areas, but it doesn't need to be so.\n\n> >  3. How much money should we give to the SFC?\n> [...]\n> I agree, a non-zero number.  2-5%?  Any idea what is typical?\n\nEither in the draft agreement or in the notes the number 10% is thrown\nout as a common value for umbrella organizations to charge. That sounds\nreasonable to me, as they are probably saving us at least that much in\ntaxes by being a proper non-profit.\n\n-Peff\n"},{"id":"154200","messageId":"AANLkTim0EH0Qvwe6NHMBt831jHZV85=TSAx8k2ABnTdd@mail.gmail.com","threadId":"25528","inReplyTo":"20101022193512.GB13059@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-10-22T20:06:22Z","receivedAt":"2010-10-22T20:06:22Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Fri, Oct 22, 2010 at 12:35 PM, Jeff King <peff@peff.net> wrote:\n>> >  3. How much money should we give to the SFC?\n>> [...]\n>> I agree, a non-zero number.  2-5%?  Any idea what is typical?\n>\n> Either in the draft agreement or in the notes the number 10% is thrown\n> out as a common value for umbrella organizations to charge. That sounds\n> reasonable to me, as they are probably saving us at least that much in\n> taxes by being a proper non-profit.\n\nOK, 10% does seem reasonable given they are saving us the taxes... or more.  :-)\n\n-- \nShawn.\n"},{"id":"154205","messageId":"AANLkTim7gC6ckrN-yFGyT4KgPz2v9B+UqLBZj7GzaMpK@mail.gmail.com","threadId":"25528","inReplyTo":"AANLkTim0EH0Qvwe6NHMBt831jHZV85=TSAx8k2ABnTdd@mail.gmail.com","subject":"Re: git as an sfc member project","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-10-22T20:59:37Z","receivedAt":"2010-10-22T20:59:37Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Fri, Oct 22, 2010 at 12:19, Shawn Pearce <spearce@spearce.org> wrote:\n> I think a committee of at least 3 people and at most 5, any of whom\n> can be a benevolent SFC liasion, is fine.  As far as selection goes,\n> the committee can elect or remove a member through a majority vote,\n> and should base its decisions based on surviving contributions to the\n> code base, but shouldn't be tied to that (just in case someone\n> contributes a lot of good code and then becomes a jerk).\n\nSounds good. Something like Junio (Duh), Shawn (based on commit\ncount), Peff (Handled GSoC money last year), and Jonathan Nieder\n(based on list activity)?\n\nOn Fri, Oct 22, 2010 at 13:06, Shawn Pearce <spearce@spearce.org> wrote:\n> OK, 10% does seem reasonable given they are saving us the taxes... or more.  :-)\n\nLGTM.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"154212","messageId":"7vd3r1lx0m.fsf@alter.siamese.dyndns.org","threadId":"25528","inReplyTo":"AANLkTi=6tvmTAfdyL-sKBsq+4OpFaQpZWT66ANESNapj@mail.gmail.com","subject":"Re: git as an sfc member project","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-22T21:48:09Z","receivedAt":"2010-10-22T21:48:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> The people listed in 2 as the leadership structure of git.\n> ...\n>>     Personally, I favor a small group which can approve new people to\n>>     join, and which can leave at will. Having more than one person\n>>     avoids hit-by-bus problems (or even just dropped-off-net problems).\n>>     There is little enough power in such a position that I'm not too\n>>     worried about some crazed egomaniac becoming the Git-SFC liaison.\n>\n> I agree.\n>\n> I think a committee of at least 3 people and at most 5, any of whom\n> can be a benevolent SFC liasion, is fine.  As far as selection goes,\n> the committee can elect or remove a member through a majority vote,\n> and should base its decisions based on surviving contributions to the\n> code base, but shouldn't be tied to that (just in case someone\n> contributes a lot of good code and then becomes a jerk).\n\nSmall group like 3 to 5 to avoid bus factor sounds reasonable to me.\n\nBecause my involvement in the project does not relate to monetizing git, I\ncan safely be included in them, I think.  If people do not mind me being\nthat jerk you meantioned, that is ;-)\n\n>>  3. How much money should we give to the SFC?\n>>\n>>     A big chunk of their budget comes from taking a percentage of\n>>     member project money. As a project, we set the percentage we give\n>>     them. So we can give them nothing if we want. But they do provide\n>>     useful services, and even without direct benefit to git, the SFC is\n>>     promoting free software. So probably it makes sense to choose some\n>>     non-zero number.\n>\n> I agree, a non-zero number.  2-5%?  Any idea what is typical?\n\nAs you two agreed 10% sounds fair to me.\n"},{"id":"154218","messageId":"7vocalkf53.fsf@alter.siamese.dyndns.org","threadId":"25528","inReplyTo":"AANLkTi=6tvmTAfdyL-sKBsq+4OpFaQpZWT66ANESNapj@mail.gmail.com","subject":"Re: git as an sfc member project","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-22T22:59:36Z","receivedAt":"2010-10-22T22:59:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> I think a committee of at least 3 people and at most 5, any of whom\n> can be a benevolent SFC liasion, is fine.  As far as selection goes,\n> the committee can elect or remove a member through a majority vote,\n> and should base its decisions based on surviving contributions to the\n> code base, but shouldn't be tied to that (just in case someone\n> contributes a lot of good code and then becomes a jerk).\n\nJust a datapoint from quick \"blame -C -C -w\" run as of 1.7.3.2, counting\nsurviving lines, 7 top from each area, excluding Documentation/RelNotes.\n\n\n** Everything else **\n\n77212        Junio C Hamano\n41388        Shawn O. Pearce\n32676        Linus Torvalds\n28618        Johannes Schindelin\n22120        Ævar Arnfjörð Bjarmason\n20190        Paul Mackerras\n15518        Marius Storm-Olsen\n\n\n** t/ **\n\n59572        Junio C Hamano\n9646         Johannes Schindelin\n7606         Eric Wong\n7342         Jonathan Nieder\n5733         Jeff King\n4978         Shawn O. Pearce\n4828         Johan Herland\n\n\n** Documentation/ **\n\n22092        Junio C Hamano\n10830        J. Bruce Fields\n5566         Christian Couder\n3904         Shawn O. Pearce\n3664         Thomas Rast\n3388         Johannes Schindelin\n2888         David Greaves\n\n\n** contrib/ **\n\n7180         Junio C Hamano\n3960         Shawn O. Pearce\n3378         Alexandre Julliard\n2948         Marius Storm-Olsen\n2668         Aneesh Kumar K.V\n2624         Simon Hausmann\n1254         Matthias Urlichs\n"},{"id":"154219","messageId":"20101022231820.GB25520@sigill.intra.peff.net","threadId":"25528","inReplyTo":"7vocalkf53.fsf@alter.siamese.dyndns.org","subject":"Re: git as an sfc member project","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-22T23:18:20Z","receivedAt":"2010-10-22T23:18:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 22, 2010 at 03:59:36PM -0700, Junio C Hamano wrote:\n\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > I think a committee of at least 3 people and at most 5, any of whom\n> > can be a benevolent SFC liasion, is fine.  As far as selection goes,\n> > the committee can elect or remove a member through a majority vote,\n> > and should base its decisions based on surviving contributions to the\n> > code base, but shouldn't be tied to that (just in case someone\n> > contributes a lot of good code and then becomes a jerk).\n> \n> Just a datapoint from quick \"blame -C -C -w\" run as of 1.7.3.2, counting\n> surviving lines, 7 top from each area, excluding Documentation/RelNotes.\n> \n> \n> ** Everything else **\n> \n> 77212        Junio C Hamano\n> 41388        Shawn O. Pearce\n> 32676        Linus Torvalds\n> 28618        Johannes Schindelin\n> 22120        Ævar Arnfjörð Bjarmason\n> 20190        Paul Mackerras\n> 15518        Marius Storm-Olsen\n\nHow did you calculate this? I don't see how it could be right. For\nexample, Ævar's contribution, while being impressively large lately, is\nonly 12877 lines total over all commits, let alone surviving lines:\n\n  $ git log --pretty=format: --numstat --author=Bjarmason |\n    perl -ne '/^\\d+/ and $total += $&; END { print \"$total\\n\"; }'\n  12877\n\n-Peff\n"},{"id":"154220","messageId":"S3I346LWUOykFBiCrFLgbfYptyYvHyj1Jcdo6EHe-2fWosEUh4Va3g@cipher.nrlssc.navy.mil","threadId":"25528","inReplyTo":"20101022231820.GB25520@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2010-10-22T23:21:46Z","receivedAt":"2010-10-22T23:21:46Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"On 10/22/2010 06:18 PM, Jeff King wrote:\n> On Fri, Oct 22, 2010 at 03:59:36PM -0700, Junio C Hamano wrote:\n> \n>> Shawn Pearce <spearce@spearce.org> writes:\n>>\n>>> I think a committee of at least 3 people and at most 5, any of whom\n>>> can be a benevolent SFC liasion, is fine.  As far as selection goes,\n>>> the committee can elect or remove a member through a majority vote,\n>>> and should base its decisions based on surviving contributions to the\n>>> code base, but shouldn't be tied to that (just in case someone\n>>> contributes a lot of good code and then becomes a jerk).\n>>\n>> Just a datapoint from quick \"blame -C -C -w\" run as of 1.7.3.2, counting\n>> surviving lines, 7 top from each area, excluding Documentation/RelNotes.\n>>\n>>\n>> ** Everything else **\n>>\n>> 77212        Junio C Hamano\n>> 41388        Shawn O. Pearce\n>> 32676        Linus Torvalds\n>> 28618        Johannes Schindelin\n>> 22120        Ævar Arnfjörð Bjarmason\n>> 20190        Paul Mackerras\n>> 15518        Marius Storm-Olsen\n> \n> How did you calculate this? I don't see how it could be right. For\n> example, Ævar's contribution, while being impressively large lately, is\n> only 12877 lines total over all commits, let alone surviving lines:\n> \n>   $ git log --pretty=format: --numstat --author=Bjarmason |\n>     perl -ne '/^\\d+/ and $total += $&; END { print \"$total\\n\"; }'\n>   12877\n\nI was just going to craft a reply too.  I think Junio's number are\nall doubled.\n\nHere are Junio's numbers for contrib/:\n\n7180         Junio C Hamano\n3960         Shawn O. Pearce\n3378         Alexandre Julliard\n2948         Marius Storm-Olsen\n2668         Aneesh Kumar K.V\n2624         Simon Hausmann\n1254         Matthias Urlichs\n\nand here's what I get for contrib/:\n\n3590         Junio C Hamano\n1980         Shawn O. Pearce\n1689         Alexandre Julliard\n1473         Marius Storm-Olsen\n1334         Aneesh Kumar K.V\n1312         Simon Hausmann\n627          Matthias Urlichs\n\n-Brandon\n"},{"id":"154221","messageId":"7vk4l9ke3o.fsf@alter.siamese.dyndns.org","threadId":"25528","inReplyTo":"20101022231820.GB25520@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-22T23:22:03Z","receivedAt":"2010-10-22T23:22:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> How did you calculate this? I don't see how it could be right. For\n> example, Ævar's contribution, while being impressively large lately, is\n> only 12877 lines total over all commits, let alone surviving lines:\n\nYeah, there seems to be something fishy in my math, adding up numbers from\nblame output.\n"},{"id":"154222","messageId":"7vd3r1kdvy.fsf@alter.siamese.dyndns.org","threadId":"25528","inReplyTo":"S3I346LWUOykFBiCrFLgbfYptyYvHyj1Jcdo6EHe-2fWosEUh4Va3g@cipher.nrlssc.navy.mil","subject":"Re: git as an sfc member project","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-10-22T23:26:41Z","receivedAt":"2010-10-22T23:26:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:\n\n> ...  I think Junio's number are\n> all doubled.\n\nYeah, I think you are right.\n"},{"id":"154223","messageId":"7KKnonc5d5_rj_95MtHHlpKzcnmvDte62cL2vYgfQQkHguIG9qjT2A@cipher.nrlssc.navy.mil","threadId":"25528","inReplyTo":"hh0bQq8TcM0saDTuJo6qVdOMgn-14aysvhF_S70syB678Of7zQOsY9jLajG2WpeGXid8jtG4kVA@cipher.nrlssc.navy.mil","subject":"Re: git as an sfc member project","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2010-10-23T00:09:08Z","receivedAt":"2010-10-23T00:09:08Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"\nI was curious about something like this earlier this week,\nand I wrote this little hack.\n\nGot anything better?\n\n---- >8 ----\n#!/usr/bin/perl -w\n\nuse lib (split(/:/, $ENV{GITPERLLIB} || \"/your/git/installation/lib/perl5/site_perl/5.8.8\"));\n\nuse strict;\nuse Git;\n\nuse Getopt::Std;\n$Getopt::Std::STANDARD_HELP_VERSION = 1;\n\n$main::VERSION = 0.1;\n\nsub usage {\n\tmy $name;\n\n\teval {\n\t\trequire File::Basename;\n\t\t$name = File::Basename::basename($0);\n\t} or do {\n\t\t$name = substr $0, rindex($0, '/') + 1;\n\t};\n\n\tprint \"Usage: $name [--help] [-flstv] <tree-ish> [paths...]\\n\";\n}\n\nsub main::HELP_MESSAGE {\n\n\tusage;\n\n\tprint \"\\nOPTIONS\\n\\n\",\n\t      \" -f  use file centric view\\n\",\n\t      \" -l  use longer format\\n\",\n\t      \" -s  use short format\\n\",\n\t      \" Both -l and -s produce an even longer format\\n\",\n\t      \" -t  print total lines at the end\\n\",\n\t      \" -v  print more information while processing\\n\",\n\t      \"\\n\";\n}\n\nsub new_parser {\n\tmy $fh = shift;\n\tmy $ctx = shift;\n\treturn { FH => $fh, CTX => $ctx, buf => ''};\n}\n\nsub get_next_line {\n\tmy $obj = shift;\n\tmy $fh = $obj->{'FH'};\n\n\tdefined($obj->{'buf'} = <$fh>);\n}\n\nsub parse_blame_entry {\n\tmy $obj = shift;\n\n\treturn () unless get_next_line $obj;\n\t$_ = $obj->{'buf'};\n\tchomp;\n\n\tmy ($sha1, $sourceline, $resultline, $num_lines) = split ' ', $_, 4;\n\n\treturn () unless defined $num_lines;\n\n\tmy %h = ( sha1 => $sha1, sourceline => $sourceline,\n\t\t  resultline => $resultline, lines => $num_lines );\n\twhile (get_next_line $obj) {\n\t\t$_ = $obj->{'buf'};\n\t\tchomp;\n\t\tmy ($key, $val) = split ' ', $_, 2;\n\t\t$h{$key} = $val;\n\t\tlast if m/^filename /;\n\t}\n\n\treturn %h;\n}\n\nsub parse_blame {\n\tmy $obj = shift;\n        my $authors = shift;\n\n\tmy %commits;\n\twhile (my %h = parse_blame_entry $obj) {\n\n\t\tif (! exists $commits{$h{'sha1'}}) {\n\n\t\t\tif (! exists $authors->{$h{'author'}}->{$obj->{'filename'}}) {\n\t\t\t\t$authors->{$h{'author'}}->{$obj->{'filename'}} = 0;\n\t\t\t}\n\t\t\t$commits{$h{'sha1'}} =\n\t\t\t\t\\$authors->{$h{'author'}}->{$obj->{'filename'}};\n\t\t}\n\n\t\t${$commits{$h{'sha1'}}} += $h{'lines'};\n\t}\n}\n\nsub count_total_lines {\n\tmy $authors = shift;\n\n\tmy $lines = 0;\n\n\tfor (values %{$authors}) {\n\t\tfor (values %{$_}) { $lines += $_; }\n\t}\n\n\treturn $lines;\n}\n\nsub count_author_lines {\n\tmy $authors = shift;\n\n\tmy %alines;\n\n\tforeach my $author (keys %{$authors}) {\n\t\tmy $lines = 0;\n\t\tfor (values %{$authors->{$author}}) { $lines += $_; }\n\t\t$alines{$author} = $lines;\n\t}\n\n\treturn %alines;\n}\n\nsub count_file_lines {\n\tmy $authors = shift;\n\n\tmy %flines;\n\n\tfor (values %{$authors}) {\n\t\tforeach my $file (keys %{$_}) {\n\t\t\t$flines{$file} += $_->{$file};\n\t\t}\n\t}\n\n\treturn %flines;\n}\n\nsub print_short {\n\tmy $authors = shift;\n\n\tmy %alines = count_author_lines $authors;\n\n\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n\t\tprintf \"%6d  %s\\n\", $alines{$author}, $author;\n\t}\n}\n\nsub print_long {\n\tmy $authors = shift;\n\n\tmy %alines = count_author_lines $authors;\n\n\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n\t\tprint \"$author (\", $alines{$author}, \"):\\n\";\n\t\tforeach my $file (sort\n\t\t    {$authors->{$author}->{$b} <=> $authors->{$author}->{$a}}\n\t\t    keys %{$authors->{$author}}) {\n\t\t\tprintf \"  %10d %s\\n\", $authors->{$author}->{$file},\n\t\t\t      $file;\n\t\t}\n\t}\n}\n\nsub print_longer {\n\tmy $authors = shift;\n\n\tmy %alines = count_author_lines $authors;\n\tmy $total_lines = count_total_lines $authors;\n\n\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n\t\tprintf \"%s (%d, %.2f%%):\\n\", $author, $alines{$author},\n\t\t\t100. * $alines{$author} / $total_lines;\n\t\tforeach my $file (sort\n\t\t    {$authors->{$author}->{$b} <=> $authors->{$author}->{$a}}\n\t\t    keys %{$authors->{$author}}) {\n\t\t\tprintf \"  %10d (%5.2f%%) %s\\n\",\n\t\t\t       $authors->{$author}->{$file},\n\t\t\t       100. *\n\t\t\t       $authors->{$author}->{$file} / $alines{$author},\n\t\t\t       $file;\n\t\t}\n\t}\n}\n\nsub print_with_file_percentage {\n\tmy $authors = shift;\n\n\tmy %alines = count_author_lines $authors;\n\tmy %flines = count_file_lines $authors;\n\tmy $total_lines = count_total_lines $authors;\n\tmy $total_files = scalar(keys %flines);\n\n\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n\t\tprintf \"%s (%d lines in %d files, \" .\n\t\t       \"%.2f%% of all lines, %.2f%% of all files):\\n\",\n\t\t       $author, $alines{$author},\n\t\t       scalar(keys %{$authors->{$author}}),\n\t\t       100. * $alines{$author} / $total_lines,\n\t\t       100. * scalar(keys %{$authors->{$author}})/$total_files;\n\t\tforeach my $file (sort\n\t\t    {$authors->{$author}->{$b} <=> $authors->{$author}->{$a}}\n\t\t    keys %{$authors->{$author}}) {\n\t\t\tprintf \"  %10d (%6.2f%%) of %6d (%6.2f%%) %s\\n\",\n\t\t\t       $authors->{$author}->{$file},\n\t\t\t       100. *\n\t\t\t       $authors->{$author}->{$file} / $flines{$file},\n\t\t\t       $flines{$file},\n\t\t\t       100. *\n\t\t\t       $authors->{$author}->{$file} / $alines{$author},\n\t\t\t       $file;\n\t\t}\n\t}\n}\n\nsub print_with_file_perspective {\n\tmy $authors = shift;\n\n\tmy %flines = count_file_lines $authors;\n\n\tforeach my $file (sort keys %flines) {\n\t\tmy @auths = grep {exists $authors->{$_}->{$file}}\n\t\t\tkeys %{$authors};\n\t\tprint \"$file ($flines{$file}):\\n\";\n\t\tforeach my $author (sort\n\t\t    {$authors->{$b}->{$file} <=> $authors->{$a}->{$file}}\n\t\t    @auths) {\n\t\t\tprintf \" %10d %s\\n\", $authors->{$author}->{$file},\n\t\t\t\t$author;\n\t\t}\n\t}\n}\n\n\nmy $verbose = 0;\nmy $output_format = 0;\nmy $show_total = 0;\n\nour ($opt_f, $opt_l, $opt_s, $opt_t, $opt_v);\ngetopts(\"flstv\") or die \"Invalid options specified\";\n\n\tif ($opt_f) {\n\t\t$output_format = 4;\n\t} elsif ($opt_l && $opt_s) {\n\t\t$output_format = 3;\n\t} elsif ($opt_l) {\n\t\t$output_format = 2;\n\t} elsif ($opt_s) {\n\t\t$output_format = 1;\n\t}\n\tif ($opt_t) {\n\t\t$show_total = 1;\n\t}\n\tif ($opt_v) {\n\t\t$verbose = 1;\n\t}\n\neval {select STDERR; usage; exit 1;} unless $#ARGV >= 0;\n\nmy %authors;\nmy $repo = Git->repository();\n\nmy ($fh, $ctx) = $repo->command_output_pipe('ls-tree', '-r', '--name-only', '--', @ARGV);\nmy $ls_tree = new_parser $fh, $ctx;\nwhile (get_next_line $ls_tree) {\n\tchomp $ls_tree->{'buf'};\n\n        my $is_text = `file \"$ls_tree->{'buf'}\"` =~ m/text/;\n\n\tif ($is_text) {\n\t\tif ($verbose) {\n\t\t\tprint STDERR \"Processing file: \", $ls_tree->{'buf'},\n\t\t\t\t\"\\n\";\n\t\t}\n\t} else {\n\t\tif ($verbose) {\n\t\t\tprint STDERR \"Skipping non-text file: \",\n\t\t\t\t$ls_tree->{'buf'}, \"\\n\";\n\t\t}\n\t\tnext;\n\t}\n\n\t($fh, $ctx) =\n\t    $repo->command_output_pipe('blame', '-C', '-C', '-w', '--incremental',\n\t\t'--', $ls_tree->{'buf'});\n\tmy $blame_obj = new_parser $fh, $ctx;\n\t$blame_obj->{'filename'} = $ls_tree->{'buf'};\n\n\tparse_blame $blame_obj, \\%authors;\n\n\t$repo->command_close_pipe($blame_obj->{'FH'}, $blame_obj->{'CTX'});\n}\n$repo->command_close_pipe($ls_tree->{'FH'}, $ls_tree->{'CTX'});\n\n\nif ($output_format == 0) {\n\tprint_long \\%authors;\n} elsif ($output_format == 1) {\n\tprint_short \\%authors;\n} elsif ($output_format == 2) {\n\tprint_longer \\%authors;\n} elsif ($output_format == 3) {\n\tprint_with_file_percentage \\%authors;\n} elsif ($output_format == 4) {\n\tprint_with_file_perspective \\%authors;\n}\n\nprint count_total_lines(\\%authors), \" total lines.\\n\" if ($show_total);\n\nexit;\n"},{"id":"154225","messageId":"cs0GhwZZ9W-pJdXPmTo0di_hrUwMa14GE8dSJeIQtOwrvDdl4KxJ_g@cipher.nrlssc.navy.mil","threadId":"25528","inReplyTo":"7KKnonc5d5_rj_95MtHHlpKzcnmvDte62cL2vYgfQQkHguIG9qjT2A@cipher.nrlssc.navy.mil","subject":"Re: git as an sfc member project","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2010-10-23T01:30:11Z","receivedAt":"2010-10-23T01:30:11Z","isPatch":false,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"On 10/22/2010 07:09 PM, Brandon Casey wrote:\n\n> \t($fh, $ctx) =\n> \t    $repo->command_output_pipe('blame', '-C', '-C', '-w', '--incremental',\n> \t\t'--', $ls_tree->{'buf'});\n\nI forgot to pass the revision to git-blame.\n\nIt should look like this:\n\n \t($fh, $ctx) =\n \t    $repo->command_output_pipe('blame', '-C', '-C', '-w', '--incremental',\n \t\t$ARGV[0], '--', $ls_tree->{'buf'});\n\n-Brandon\n"},{"id":"154236","messageId":"AANLkTikxMtdvppLur4kuXffRn0G29NFv6ameTpaeY46G@mail.gmail.com","threadId":"25528","inReplyTo":"20101022231820.GB25520@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-10-23T11:52:26Z","receivedAt":"2010-10-23T11:52:26Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Oct 22, 2010 at 23:18, Jeff King <peff@peff.net> wrote:\n> On Fri, Oct 22, 2010 at 03:59:36PM -0700, Junio C Hamano wrote:\n>\n>> Shawn Pearce <spearce@spearce.org> writes:\n>>\n>> > I think a committee of at least 3 people and at most 5, any of whom\n>> > can be a benevolent SFC liasion, is fine.  As far as selection goes,\n>> > the committee can elect or remove a member through a majority vote,\n>> > and should base its decisions based on surviving contributions to the\n>> > code base, but shouldn't be tied to that (just in case someone\n>> > contributes a lot of good code and then becomes a jerk).\n>>\n>> Just a datapoint from quick \"blame -C -C -w\" run as of 1.7.3.2, counting\n>> surviving lines, 7 top from each area, excluding Documentation/RelNotes.\n>>\n>>\n>> ** Everything else **\n>>\n>> 77212        Junio C Hamano\n>> 41388        Shawn O. Pearce\n>> 32676        Linus Torvalds\n>> 28618        Johannes Schindelin\n>> 22120        Ævar Arnfjörð Bjarmason\n>> 20190        Paul Mackerras\n>> 15518        Marius Storm-Olsen\n>\n> How did you calculate this? I don't see how it could be right. For\n> example, Ævar's contribution, while being impressively large lately, is\n> only 12877 lines total over all commits, let alone surviving lines:\n>\n>  $ git log --pretty=format: --numstat --author=Bjarmason |\n>    perl -ne '/^\\d+/ and $total += $&; END { print \"$total\\n\"; }'\n>  12877\n\nEither way it doesn't matter, since I'm not interested in being a SFC\nliasion. I just want to hack, not deal with issues like these (but\nmore power to people who want to).\n\nBut I think picking people for anything based on the number of lines\nthat git-blame thinks people \"own\" is a bad criteria. My contributions\nto Git are relatively small, but I've happened to pick projects (the\ntest suit, gettext) that have touched a lot of lines of code.\n\nBut other people who've done 10x more work than I have (both in time &\nimportance) probably have 10x less lines of code assigned to them.\n\nIf I keep it up I'll probably \"own\" more lines of code than Linus, but\nI think any criteria that brings me within an order of magnitute of\nimportance of him and Junio is pretty much broken by defintion :)\n"},{"id":"154241","messageId":"20101023133948.GA2002@sigill.intra.peff.net","threadId":"25528","inReplyTo":"AANLkTikxMtdvppLur4kuXffRn0G29NFv6ameTpaeY46G@mail.gmail.com","subject":"Re: git as an sfc member project","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-23T13:39:48Z","receivedAt":"2010-10-23T13:39:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 23, 2010 at 11:52:26AM +0000, Ævar Arnfjörð Bjarmason wrote:\n\n> Either way it doesn't matter, since I'm not interested in being a SFC\n> liasion. I just want to hack, not deal with issues like these (but\n> more power to people who want to).\n\nI didn't mean to pick on you, btw. It's just that I was surprised to see\nyou, whose first commit was only 6 months ago, in the list of top\ncontributors by lines of code. You're productive, but not _that_\nproductive. :)\n\nAs it turns out, even though Junio's numbers are doubled, you are in\nfact high by line count. It's because of compat/regex:\n\n  $ git log --pretty=format: --numstat --author=Bjarmason compat/regex/* |\n    perl -ne '/^\\d+/ and $total += $&; END { print \"$total\\n\"; }'\n  11186\n\nwhich accounts for 85% of your contribution. :)\n\n> But I think picking people for anything based on the number of lines\n> that git-blame thinks people \"own\" is a bad criteria. My contributions\n> to Git are relatively small, but I've happened to pick projects (the\n> test suit, gettext) that have touched a lot of lines of code.\n> \n> But other people who've done 10x more work than I have (both in time &\n> importance) probably have 10x less lines of code assigned to them.\n\nI think counting surviving lines via git-blame is not that bad a metric\nfor importance. It's certainly better than counting added lines (as I\ndid above), as it measures lines that people are actually still using.\nThe problem here is that we have quite large chunks of \"uninteresting\".\nJunio made some attempt to account for this by counting various parts of\nthe codebase separately. Probably compat/ should have been removed from\nthe core count (ditto for Marius Storm-Olsen, whose line count is\ninflated by importing nedmalloc; which isn't to say that any of these\ncontributions aren't important. They just aren't the same as sitting\ndown and writing 10,000 lines of custom git code).\n\nIn general, any line count of code (surviving or otherwise) will favor\npeople who are adding features rather than fixing bugs. I prefer commit\ncount, where I personally fare much better. :)\n\nOne interesting metric to me is the ratio of commit log lines to code\nlines. A high ratio implies (to some degree) working on bugfixes, where\nthe actual changed lines of code are less important than the time you\nspend figuring out _which_ lines to change.\n\nYou can measure it with something like:\n\n  $ git log  --format='Author: %an%n%w(0,4,4)%B' --numstat --no-merges |\n    perl -ne '\n      if (/^Author: (.*)/) { $author = $1 }\n      elsif (/^\\s{4}.+/) { $commit{$author}++ }\n      elsif (/^\\d+/) { $code{$author} += $& }\n      END {\n        print($commit{$_} / $code{$_}, \" $_\\n\")\n          for grep { $code{$_} } keys(%code)\n      }\n    ' | sort -rn\n\nOf course it has its own set of flaws. One giant feature contribution\ncan outweight a lot of bugfixes in the average.\n\n-Peff\n"},{"id":"154245","messageId":"4CC3076E.7050707@gmail.com","threadId":"25528","inReplyTo":"20101023133948.GA2002@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-10-23T16:03:58Z","receivedAt":"2010-10-23T16:03:58Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 10/23/2010 09:39 AM, Jeff King wrote:\n> On Sat, Oct 23, 2010 at 11:52:26AM +0000, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Either way it doesn't matter, since I'm not interested in being a SFC\n>> liasion. I just want to hack, not deal with issues like these (but\n>> more power to people who want to).\n>\n> I didn't mean to pick on you, btw. It's just that I was surprised to see\n> you, whose first commit was only 6 months ago, in the list of top\n> contributors by lines of code. You're productive, but not _that_\n> productive. :)\n\nFor what it's worth: my nominees are:\n\n\tJunio\n\tShawn\n\tJeff\n\t?\n\t?\n\nThis group has been involved a long time and each is or has been THE \nmaintainer at some point. More importantly, they have consistently \ndemonstrated critical thinking with a long term view and the ability to \nhandle the \"politics\" of the mailing list.\n\nIn addition to the above, I would like to 2 of the newer members of our \ncommunity in order to bring a different perspective to the \ndeliberations. Even better if they are USA based.\n"},{"id":"154288","messageId":"1287874109-15565-1-git-send-email-drafnel@gmail.com","threadId":"25528","inReplyTo":"cs0GhwZZ9W-pJdXPmTo0di_hrUwMa14GE8dSJeIQtOwrvDdl4KxJ_g@cipher.nrlssc.navy.mil","subject":"Re: git as an sfc member project","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2010-10-23T22:48:29Z","receivedAt":"2010-10-23T22:48:29Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Here's an updated version of this script if anyone is interested.\n\nIt can now do the git-blame calls in parallel.  Use -t #threads.\n\nHere's the usage info:\n\n      ' -c     print count of all lines in all files at the end',\n      ' -f     produce file centric output (overrides -l and -s)',\n      ' -l     produce longer format',\n      ' -s     produce short format, line count and author only',\n      ' -ls    Both -l and -s produce an even longer long format',\n      ' -t n   set number of threads to use',\n      ' -x re  exclude files matching regex',\n      ' -v     be more verbose',\n\nEnjoy.\n\n-Brandon\n\n---\n git_blame_stats.perl |  387 ++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 387 insertions(+), 0 deletions(-)\n create mode 100755 git_blame_stats.perl\n\ndiff --git a/git_blame_stats.perl b/git_blame_stats.perl\nnew file mode 100755\nindex 0000000..618cf0a\n--- /dev/null\n+++ b/git_blame_stats.perl\n@@ -0,0 +1,387 @@\n+#!/usr/bin/perl -w\n+\n+use lib (split(/:/, $ENV{GITPERLLIB} || '/path/to/git/lib/perl5/site_perl/5.10.0'));\n+\n+use strict;\n+use threads;\n+use Thread::Queue;\n+use Getopt::Std;\n+use Git;\n+\n+my @LSTREE_OPTS = ('-r', '--name-only');\n+my @BLAME_OPTS = ('-C', '-C', '-w', '--incremental');\n+\n+$Getopt::Std::STANDARD_HELP_VERSION = 1;\n+$main::VERSION = 1.0;\n+\n+sub usage {\n+\tmy $name;\n+\n+\teval {\n+\t\trequire File::Basename;\n+\t\t$name = File::Basename::basename($0);\n+\t} or do {\n+\t\t$name = substr $0, rindex($0, '/') + 1;\n+\t};\n+\n+\tprint 'Usage: ', $name, ' [--help] [-cflstvx] <rev> [paths...]', \"\\n\";\n+}\n+\n+sub main::HELP_MESSAGE {\n+\tmy $fh = shift;\n+\n+\teval {select $fh; usage};\n+\n+\tlocal $\\ = \"\\n\";\n+\tlocal $, = \"\\n\";\n+\n+\tprint $fh '',\n+\t      'Generate authorship statistics from a git repository.',\n+\t      '',\n+\t      'OPTIONS',\n+\t      ' -c     print count of all lines in all files at the end',\n+\t      ' -f     produce file centric output (overrides -l and -s)',\n+\t      ' -l     produce longer format',\n+\t      ' -s     produce short format, line count and author only',\n+\t      ' -ls    Both -l and -s produce an even longer long format',\n+\t      ' -t n   set number of threads to use',\n+\t      ' -x re  exclude files matching regex',\n+\t      ' -v     be more verbose',\n+\t      ' --help this text',\n+\t      '';\n+}\n+\n+sub parse_blame_entry {\n+\tmy $fh = shift;\n+\n+\treturn () unless defined($_ = <$fh>);\n+\tchomp;\n+\n+\tmy ($sha1, $sourceline, $resultline, $num_lines) = split;\n+\n+\treturn () unless defined $num_lines;\n+\n+\tmy %h = (sha1 => $sha1, sourceline => $sourceline,\n+\t\t resultline => $resultline, lines => $num_lines);\n+\twhile (<$fh>) {\n+\t\tchomp;\n+\t\tmy ($key, $val) = split ' ', $_, 2;\n+\t\t$h{$key} = $val;\n+\t\tlast if m/^filename /;\n+\t}\n+\n+\treturn %h;\n+}\n+\n+sub blame_file {\n+\tmy $repo = shift;\n+\tmy $ref = shift;\n+\tmy $filename = shift;\n+\tmy $authors = shift;\n+\n+\tmy ($fh, $ctx) = $repo->command_output_pipe('blame', @BLAME_OPTS,\n+\t\t$ref, '--', $filename);\n+\n+\tmy %commits;\n+\twhile (my %h = parse_blame_entry $fh) {\n+\n+\t\tif (! exists $commits{$h{'sha1'}}) {\n+\n+\t\t\tif (! exists $authors->{$h{'author'}}->{$filename}) {\n+\t\t\t\t$authors->{$h{'author'}}->{$filename} = 0;\n+\t\t\t}\n+\t\t\t$commits{$h{'sha1'}} =\n+\t\t\t\t\\$authors->{$h{'author'}}->{$filename};\n+\t\t}\n+\n+\t\t${$commits{$h{'sha1'}}} += $h{'lines'};\n+\t}\n+\n+\t$repo->command_close_pipe($fh, $ctx);\n+}\n+\n+sub count_total_lines {\n+\tmy $authors = shift;\n+\n+\tmy $lines = 0;\n+\n+\tfor (values %{$authors}) {\n+\t\tfor (values %{$_}) { $lines += $_; }\n+\t}\n+\n+\treturn $lines;\n+}\n+\n+# Returns hash\n+# key: author name\n+# value: authored lines\n+sub count_author_lines {\n+\tmy $authors = shift;\n+\n+\tmy %alines;\n+\n+\tforeach my $author (keys %{$authors}) {\n+\t\tmy $lines = 0;\n+\t\tfor (values %{$authors->{$author}}) { $lines += $_; }\n+\t\t$alines{$author} = $lines;\n+\t}\n+\n+\treturn %alines;\n+}\n+\n+# Returns hash\n+# key: filename\n+# value: lines in file\n+sub count_file_lines {\n+\tmy $authors = shift;\n+\n+\tmy %flines;\n+\n+\tfor (values %{$authors}) {\n+\t\tforeach my $file (keys %{$_}) {\n+\t\t\t$flines{$file} += $_->{$file};\n+\t\t}\n+\t}\n+\n+\treturn %flines;\n+}\n+\n+# Short format\n+#   lines author\n+sub print_short {\n+\tmy $authors = shift;\n+\n+\tmy %alines = count_author_lines $authors;\n+\n+\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n+\t\tprintf \"%6d  %s\\n\", $alines{$author}, $author;\n+\t}\n+}\n+\n+# Long format\n+# author (lines):\n+#    file_lines filename\n+#    file_lines filename\n+#    file_lines filename\n+sub print_long {\n+\tmy $authors = shift;\n+\n+\tmy %alines = count_author_lines $authors;\n+\n+\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n+\t\tprint $author, ' (', $alines{$author}, '):', \"\\n\";\n+\t\tforeach my $file (sort\n+\t\t    {$authors->{$author}->{$b} <=> $authors->{$author}->{$a}}\n+\t\t    keys %{$authors->{$author}}) {\n+\t\t\tprintf \"  %10d %s\\n\", $authors->{$author}->{$file},\n+\t\t\t      $file;\n+\t\t}\n+\t}\n+}\n+\n+# Longer format\n+# author (lines, % of all lines):\n+#    file_lines (% of author lines) filename\n+#    file_lines (% of author lines) filename\n+sub print_longer {\n+\tmy $authors = shift;\n+\n+\tmy %alines = count_author_lines $authors;\n+\tmy $total_lines = count_total_lines $authors;\n+\n+\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n+\t\tprintf \"%s (%d, %.2f%%):\\n\", $author, $alines{$author},\n+\t\t\t100. * $alines{$author} / $total_lines;\n+\t\tforeach my $file (sort\n+\t\t    {$authors->{$author}->{$b} <=> $authors->{$author}->{$a}}\n+\t\t    keys %{$authors->{$author}}) {\n+\t\t\tprintf \"  %10d (%5.2f%%) %s\\n\",\n+\t\t\t       $authors->{$author}->{$file},\n+\t\t\t       100. *\n+\t\t\t       $authors->{$author}->{$file} / $alines{$author},\n+\t\t\t       $file;\n+\t\t}\n+\t}\n+}\n+\n+# Longer format\n+# author (# lines in X files, % of all lines, % of all files):\n+#    lines (% of file) file_lines (% of author lines) filename\n+#    lines (% of file) file_lines (% of author lines) filename\n+sub print_with_file_percentage {\n+\tmy $authors = shift;\n+\n+\tmy %alines = count_author_lines $authors;\n+\tmy %flines = count_file_lines $authors;\n+\tmy $total_lines = count_total_lines $authors;\n+\tmy $total_files = scalar(keys %flines);\n+\n+\tforeach my $author (sort {$alines{$b} <=> $alines{$a}} keys %alines) {\n+\t\tprintf \"%s (%d lines in %d files, \" .\n+\t\t       \"%.2f%% of all lines, %.2f%% of all files):\\n\",\n+\t\t       $author, $alines{$author},\n+\t\t       scalar(keys %{$authors->{$author}}),\n+\t\t       100. * $alines{$author} / $total_lines,\n+\t\t       100. * scalar(keys %{$authors->{$author}})/$total_files;\n+\t\tforeach my $file (sort\n+\t\t    {$authors->{$author}->{$b} <=> $authors->{$author}->{$a}}\n+\t\t    keys %{$authors->{$author}}) {\n+\t\t\tprintf \"  %10d (%6.2f%%) of %6d (%6.2f%%) %s\\n\",\n+\t\t\t       $authors->{$author}->{$file},\n+\t\t\t       100. *\n+\t\t\t       $authors->{$author}->{$file} / $flines{$file},\n+\t\t\t       $flines{$file},\n+\t\t\t       100. *\n+\t\t\t       $authors->{$author}->{$file} / $alines{$author},\n+\t\t\t       $file;\n+\t\t}\n+\t}\n+}\n+\n+# File perspective format\n+# filename (lines):\n+#    lines author\n+#    lines author\n+sub print_with_file_perspective {\n+\tmy $authors = shift;\n+\n+\tmy %flines = count_file_lines $authors;\n+\n+\tforeach my $file (sort keys %flines) {\n+\t\tmy @auths = grep {exists $authors->{$_}->{$file}}\n+\t\t\tkeys %{$authors};\n+\t\tprint $file, ' (', $flines{$file}, '):', \"\\n\";\n+\t\tforeach my $author (sort\n+\t\t    {$authors->{$b}->{$file} <=> $authors->{$a}->{$file}}\n+\t\t    @auths) {\n+\t\t\tprintf \" %10d %s\\n\", $authors->{$author}->{$file},\n+\t\t\t\t$author;\n+\t\t}\n+\t}\n+}\n+\n+\n+my $verbose = 0;\n+my $output_format = 0;\n+my $show_total = 0;\n+my $exclude_pattern;\n+my $nthreads = 1;\n+\n+our ($opt_c, $opt_f, $opt_l, $opt_s, $opt_t, $opt_v, $opt_x);\n+getopts('cflst:vx:') or die 'Invalid options specified';\n+\n+\tif ($opt_c) {\n+\t\t$show_total = 1;\n+\t}\n+\tif ($opt_f) {\n+\t\t$output_format = 4;\n+\t} elsif ($opt_l && $opt_s) {\n+\t\t$output_format = 3;\n+\t} elsif ($opt_l) {\n+\t\t$output_format = 2;\n+\t} elsif ($opt_s) {\n+\t\t$output_format = 1;\n+\t}\n+\tif (defined $opt_t) {\n+\t\t$nthreads = $opt_t;\n+\t\tif ($nthreads !~ /^\\d+$/ || $nthreads < 0) {\n+\t\t\tdie 'Error: argument to -t must be integer >= 0';\n+\t\t}\n+\t\tif ($nthreads == 0) {\n+\t\t\teval {\n+\t\t\t\trequire Sys::CPU;\n+\t\t\t\t$nthreads = Sys::CPU::cpu_count();\n+\t\t\t} or $nthreads = 1;\n+\t\t}\n+\t}\n+\tif ($opt_v) {\n+\t\t$verbose = 1;\n+\t}\n+\tif ($opt_x) {\n+\t\t$exclude_pattern = $opt_x;\n+\t}\n+\n+eval {select STDERR; usage; exit 1} unless $#ARGV >= 0;\n+\n+my %authors;\n+my @thr;\n+my $repo = Git->repository();\n+\n+# Spawn ls-tree now, so it can fail before creating the threads\n+my ($fh, $ctx) = $repo->command_output_pipe('ls-tree', @LSTREE_OPTS,\n+\t'--', @ARGV);\n+\n+print STDERR 'Using ', $nthreads, ' thread(s).', \"\\n\" if $verbose;\n+\n+my $DataQueue = Thread::Queue->new();\n+\n+# start the threads\n+for (my $i = 0; $i < $nthreads; $i++) {\n+\t($thr[$i]) = threads->create(sub {\n+\t\tmy $tid = threads->tid();\n+\t\tmy %a;\n+\t\twhile (my $f = $DataQueue->dequeue()) {\n+\t\t\tprint STDERR \"[$tid]Processing file: $f\\n\" if $verbose;\n+\t\t\tblame_file $repo, $ARGV[0], $f, \\%a;\n+\t\t}\n+\t\treturn %a;\n+\t});\n+}\n+\n+# now queue up the files\n+while (<$fh>) {\n+\tchomp;\n+\n+\tif ($exclude_pattern && m/$exclude_pattern/o) {\n+\t\tprint STDERR \"Skipping file: $_\\n\" if $verbose;\n+\t\tnext;\n+\t} else {\n+\t\tprint STDERR \"Queuing file: $_\\n\" if $verbose;\n+\t}\n+\n+\t$DataQueue->enqueue($_);\n+}\n+$repo->command_close_pipe($fh, $ctx);\n+\n+# queue up an undef entry for each thread\n+for (my $i = 0; $i < $nthreads; $i++) {\n+\t$DataQueue->enqueue(undef);\n+}\n+\n+# merge the author hash from each thread\n+for (my $i = 0; $i < $nthreads; $i++) {\n+\tmy %th_authors = $thr[$i]->join;\n+\n+\tforeach my $author (keys %th_authors) {\n+\t\tif (! exists $authors{$author}) {\n+\t\t\t$authors{$author} = $th_authors{$author};\n+\t\t\tnext;\n+\t\t}\n+\t\tforeach my $filename (keys %{$th_authors{$author}}) {\n+\t\t\tif (! exists $authors{$author}->{$filename}) {\n+\t\t\t\t$authors{$author}->{$filename} =\n+\t\t\t\t\t$th_authors{$author}->{$filename};\n+\t\t\t} else {\n+\t\t\t\t$authors{$author}->{$filename} +=\n+\t\t\t\t\t$th_authors{$author}->{$filename};\n+\t\t\t}\n+\t\t}\n+\t}\n+}\n+\n+\n+if ($output_format == 0) {\n+\tprint_long \\%authors;\n+} elsif ($output_format == 1) {\n+\tprint_short \\%authors;\n+} elsif ($output_format == 2) {\n+\tprint_longer \\%authors;\n+} elsif ($output_format == 3) {\n+\tprint_with_file_percentage \\%authors;\n+} elsif ($output_format == 4) {\n+\tprint_with_file_perspective \\%authors;\n+}\n+\n+printf \"%6d  total lines\\n\", count_total_lines(\\%authors) if $show_total;\n+\n+exit;\n-- \n1.7.3.1.45.g9855b\n"},{"id":"154465","messageId":"20101026223925.GA29332@sigill.intra.peff.net","threadId":"25528","inReplyTo":"20101022183027.GA12124@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-26T22:39:25Z","receivedAt":"2010-10-26T22:39:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Oct 22, 2010 at 02:30:28PM -0400, Jeff King wrote:\n\n> The draft agreement is here:\n> \n>   http://peff.net/git-sponsorship-agreement.pdf\n\nOK, this thread seems to have died, which I'll take to mean that\neverybody either agrees or doesn't care.\n\nSo let's do this:\n\n  1. There will be a committee of 3-5 Gits who will act as liaisons to\n     the SFC. A simple majority of that committee is required to\n     authorize SFC to do stuff (like disburse money). Existing members\n     can be removed from and new members can be added to the committee\n     by simple majority vote of the existing committee.\n\n     As for the initial committee, Gitzilla already nominated Junio,\n     Shawn, and me. Those sound like a good start to me (assuming the\n     other two accept). I'm happy to hear other nominations. I think\n     starting with the 3 of us would be fine, too, and we can add people\n     who become interested in the management of git and the sfc (and if\n     there _is_ anybody who is interested now, please speak up and/or\n     nominate yourself; I can think of many people on the list who would\n     be good candidates, but the main issue seems to me that nobody is\n     interested. :) ).\n\n  2. We'll give 10% of incoming Git money to the SFC for their\n     operations (where incoming git money is basically SoC money plus\n     any donations SFC collects on our behalf).\n\nUnless I hear objections on the list, this is what I'll present to the\nSFC as our plan.\n\n-Peff\n"},{"id":"154476","messageId":"20101027070348.GF15635@ece.pdx.edu","threadId":"25528","inReplyTo":"20101022183027.GA12124@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Tait","fromEmail":"git.git@t41t.com","sentAt":"2010-10-27T07:03:48Z","receivedAt":"2010-10-27T07:03:48Z","isPatch":false,"sender":{"key":"git.git@t41t.com","avatar":null},"body":"> The draft agreement is here:\n>   http://peff.net/git-sponsorship-agreement.pdf\n\nSorry I'm late to the thread. This agreement brings up one concern for\nme. It would make officially make git a United States project based out\nof New York, and therefore subject to the laws of New York and the United\nStates. Among whatever other laws apply, will be export restrictions and\npatent law. I don't know whether any part(s) of git would be a concern\nunder those laws (and I haven't needed to care, until now). Is legal\nadvice for issues like this part of the services SFC can provide?\n"},{"id":"154489","messageId":"20101027110807.GB3995@sigill.intra.peff.net","threadId":"25528","inReplyTo":"20101027070348.GF15635@ece.pdx.edu","subject":"Re: git as an sfc member project","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-10-27T11:08:07Z","receivedAt":"2010-10-27T11:08:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 27, 2010 at 12:03:48AM -0700, Tait wrote:\n\n> > The draft agreement is here:\n> >   http://peff.net/git-sponsorship-agreement.pdf\n> \n> Sorry I'm late to the thread. This agreement brings up one concern for\n> me. It would make officially make git a United States project based out\n> of New York, and therefore subject to the laws of New York and the United\n> States. Among whatever other laws apply, will be export restrictions and\n> patent law. I don't know whether any part(s) of git would be a concern\n> under those laws (and I haven't needed to care, until now). Is legal\n> advice for issues like this part of the services SFC can provide?\n\nI am not sure that joining the SFC is going to make any difference with\nrespect to those things. Developers and distributors of the software in\nthe United States were already subject to such laws, and I don't see how\nour dealing with the SFC would create any special obligation for those\noutside the US. In particular, it seems to me that git as a legal entity\nsigning this agreement as the SFC (which legally is really just an\nagreement between the SFC and a few members of the project) is different\nfrom git as a community of individuals who happen to contribute and\ndistribute code.  SFC will not own any copyrights, nor take any\nresponsibility for distribution.\n\nBut I am not a lawyer, of course, and yes, this seems like exactly the\nsort of thing we can ask them about. So I've cc'd Bradley. :)\n\n-Peff\n"},{"id":"155011","messageId":"87wrovpbtw.fsf@ebb.org","threadId":"25528","inReplyTo":"20101027110807.GB3995@sigill.intra.peff.net","subject":"Re: git as an sfc member project","fromName":"Bradley M. Kuhn","fromEmail":"bkuhn@sfconservancy.org","sentAt":"2010-11-02T23:03:55Z","receivedAt":"2010-11-02T23:03:55Z","isPatch":false,"sender":{"key":"bkuhn@sfconservancy.org","avatar":"https://avatars.githubusercontent.com/u/45438?v=4"},"body":">> > The draft agreement is here:\n>> >   http://peff.net/git-sponsorship-agreement.pdf\n\n> On Wed, Oct 27, 2010 at 12:03:48AM -0700, Tait wrote:\n\n>> This agreement brings up one concern for me. It would make officially\n>> make git a United States project based out of New York, and therefore\n>> subject to the laws of New York and the United States. Among whatever\n>> other laws apply, will be export restrictions and patent law. I don't\n>> know whether any part(s) of git would be a concern under those laws\n>> (and I haven't needed to care, until now). Is legal advice for issues\n>> like this part of the services SFC can provide?\n\nJeff King wrote on the 27th of October:\n\n> I am not sure that joining the SFC is going to make any difference\n> with respect to those things. Developers and distributors of the\n> software in the United States were already subject to such laws, and I\n> don't see how our dealing with the SFC would create any special\n> obligation for those outside the US. In particular, it seems to me\n> that git as a legal entity signing this agreement as the SFC (which\n> legally is really just an agreement between the SFC and a few members\n> of the project) is different from git as a community of individuals\n> who happen to contribute and distribute code.  SFC will not own any\n> copyrights, nor take any responsibility for distribution.\n\nI believe what Jeff says is basically correct.  The \"Git Project\" will\nbe part of a non-profit in New York, and it's true that the Git Project\ncould be therefore be subject to the laws of New York.  However, it\nisn't that much different of some Git developers being in New York and\nbeing subject thereto.  Developers outside the USA continue to operate\nas volunteers for the project and aren't impacted any more than they\nalready are participating in an unincorporated project.\n\nNevertheless, I'm going to check in with Conservancy's lawyers to verify\nthere are no serious disadvantages to Git joining a USA non-profit that\nweren't already the case anyway since some developers are in the USA\nanyway.  I'll respond back when I hear from them.\n-- \nBradley M. Kuhn, Executive Director, Software Freedom Conservancy\n"}]}