Re: Different code bases terminology (and jSPF IP)

[Stefano Bagnara <ap...@bago.org>]

Noel J. Bergman wrote:
> Serge,
> 
>> The term "subproject" is something of a loaded term at Apache
> 
> Thanks for posting this.  I'd started and stopped the same e-mail about
> three times.  Primarily, because I want to doublecheck to make sure that the
> IP for jSPF and then Postage is handled properly.  We should file IP
> Clearance forms for each of them.

I already tried to explain the exact path we followed writing jSPF and 
the third party code involved.
I don't have enough knowledge of the IP and copyright notices law and I 
hoped you could help with this.

We started from spfjava submitted "with grants for inclusion" by the 
author (Roger Fullertone).

We rewrote from scratch the whole parsing and the whole "business" 
processing algorythm. The only code we now have from spfjava (to be 
confirmed by Norman) are a few utilities and costant classes and the 
"MacroExpansion" code. I don't know how much we did change that.

We furthermore added unittests based on tests definition files (txt) 
found at http://www.schlitt.net/spf/tests/tests_v2.1/test.txt (I wrote 
this to the pmc list 20 days ago ;-) ).
We then added this tasks to JIRA to track this issues:
http://issues.apache.org/jira/browse/JSPF-5
http://issues.apache.org/jira/browse/JSPF-12

Norman, talking to an SPF developer in IRC found out that the tests were 
also distributed as part of libspf2 (http://www.libspf2.org/), licensed 
under the "LGPL or 2-clause BSD".

jSPF currently depends on dnsjava and log4j for the core library and 
junit for the unit tests.

We would really be happy if you can help with this issues.

Furthermore we are ready for an 1.0b1 release. Norman closed one of the 
few blocking issues for 1.0 (the website) today. I hope you can help 
with the release steps, too!

SPF specifications we implement are described here:
http://www.ietf.org/rfc/rfc4408.txt

>> For me, the most important issue is that we have only one
>> committer base across all these.  i.e., we're not going to
>> add someone exclusively to mime4j or postage.
> 
> +1

+1

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org