Yes, there is a subtle disjoint or two. :) Excluding patches that simply modify an existing artifact, we do need licensing agreements from all individual contributors, regardless of whether they become ASF committers or members of the podling PMC. Otherwise, the ASF does not have clear title to the code, and anyone who uses the code would be endangered.
It is not unusual for us to collect a licensing agreement from a non-committer before accepting a non-trivial contribution, especially if it is a new artifact. One reason that ASF projects are successful is because people trust us to do the right thing when it comes to IP, even if the right thing is the hard thing. In order to establish an Apache account for someone, we also need licensing agreements from the account owner (regardless of whether they have made a past contribution). Everyone on the initial list of podling committers will need an Apache account, and therefore must file a CLA. One fine point is that the initial list of podling committers, in practice, ultimately becomes the list of initial PMC members. Once the project is up and running, individuals who are only interested in maintaining one piece of code could be a committer, without necessarily becoming a PMC member, if that individual was not interesting in helping with project oversight. Project karma is usually a "staged release", where someone is first a contributor, and then a committer, and finally a PMC member. In practice, moving through all the stages can take someone a year or longer. Podlings are a special case, since everyone becomes a PMC member all at once. (Which is why we need multiple mentors.) Culturally, we tend to offer PMC membership to any committer who demonstrates a persistent, welcome interest in the project, and we share code ownership with all committers and PMC members. Since all project actions are utterly transparent, sharing code ownership is not usually a problem, so long as other committers and PMC members peer-review the commits list. (Trust but verify.) The key cultural bias is toward collaboration, and her handmaidens, equality and transparency. Infrastructure can be a sticky wicket, since there is a bias toward sharing all resources with all projects, in the same way we share code with all committers. Before any technology is deployed as a ASF resource, people want to be sure there is sufficient resources so that it could be shared with all 50+ projects. In the past, projects have introduced technologies by "voting with their feet". For example, people started using JIRA offsite, and ultimately, we obtained our own JIRA instance. The same thing happened with Confluence. Not too long ago, the rule would have been "Any SCM so long as its CVS". Initially, we ran dual systems, but once most projects voluntarily migrated, we pulled the CVS plug -- but only after most projects had already voted with their feet. It is a hard-and-fast rule that the source code, web site, and mailing lists have to be kept here, since they are key material assets of the foundation, and must be under the foundation's direct control. But, third parties often contribute other technologies to the community that live elsewhere, like mailing list archives, source code viewers, continuous build systems, and so forth. svn-git, hosted elsewhere at first, could be another one of those. Some projects even have special "zones" here where people can experiment with new services. (Though I believe that space is becoming precious.) There is someplace to go with git. It's not something that would be made available on a production ASF server right away. But, it is something Thrift could pursue once past incubation. Thrift looks like an interesting product, and I'm looking forward to trying it with my next project. HTH, Ted. On Feb 4, 2008 6:48 PM, Mark Slee <[EMAIL PROTECTED]> wrote: > Well, note that this isn't strictly an IP issue. The issue here was the > committers list, not the IP of the code. I don't see why all the code > would need to be written by people on the initial committers list to > pass IP restrictions. > > These two seem like disjoint issues to me. All code in the codebase > today has been committed by an approved committer with the consent of > the people providing the patches, so things should be consistent on the > IP front. > > Cheers, > Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
