Chris Santerre <[EMAIL PROTECTED]> writes: > So it would be better for SARE to become an ASF project? We had > discussed that before, and voted "Not at this time." as we saw no real > reason except extra work :) However if it helps rules get implemented > faster...then it should be reconsidered?
There would be some definite advantages: 1. You get ASF support: mailing list(s), subversion, the wiki, and bugzilla 2. ASF is a legal entity that can enter into agreements (the whole permission and licensing thing) with contributors and those agreements are general to the entire ASF, last beyond the participation of any one contributor, etc. 3. The ASF provides a means for individual volunteers to be sheltered from legal suits. 4. You get the oh so cool @apache.org email address and web home page, plus it looks good on the resume. ;-) 5. And of course, easier transfer into official daily updates, new SA releases, etc. 6. Less duplicated work: nightly corpus system, perceptron runs, etc. The disadvantages would be: 1. Higher bar to submit rules: Contributor License Agreements would be required for the first non-trivial contribution from a new contributor, but after that things are very easy. Note that ideas don't need a CLA. So, if you like the idea of a rule, you can always just reimplement it without copying off of the original rule. 2. Bootstrap work (related to #1). Rule sets with a lot of contributors would need to be cleaned and (probably just the IP clearance thing, http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/site/projects/ip-clearance-template.cwiki?rev=1.1 We wouldn't need to bring all rule sets in immediately, though, we could just start with the easy ones (like we did with the anti-drug rules). If SARE decide this is how you want to go, we can talk about who would be on the initial list of committers for the subproject and all that stuff. Now that SpamAssassin is a TLP, this is pretty easy. Daniel -- Daniel Quinlan http://www.pathname.com/~quinlan/
