Hi All,

When I saw the list of code from Andrew that needed to be rewritten I
thought to myself oh there are some methods I could bang out pretty quickly.
Then I thought about it.  If I can not look at the method to rewrite it then
how can I be sure that I've captured what the method does by its name?  I
can guess what it does but it would be quite easy to get it wrong and not
support some side functionally that is not obvious by the name.  Or I may
just interpret it differently.

So my question is this.  How can we capture the functionally of the missing
methods so that they can be rewritten?  Is it acceptable for someone to
review both the old method and the new method to verify that the new author
did it properly, or is that not ok either?  Could someone review the old
method and write pseudo code or some sort of specification for someone else
to use as a map to create the new method?  If I have reviewed or used the
method previously and know more about it from experience am I ineligible to
do the rewrite?  

I guess my question is this: What process should we use to rewrite and
verify new methods?  Can SFLC give us any guidance concerning what practices
are acceptable for reverse engineering with regard to copyright?

Thanks,
Ron Teitelbaum

P.S. I also realized that the list from Andrew was incomplete because it
doesn't include any external packages.  I assume that we will take up
packages after completing the core image.

> -----Original Message-----
> From: tim Rowledge
> 
> If having the license finally sorted out is truly important to you -
> anyone - then please offer assistance to help us get it solved sooner
> rather than later. Offer to ferret out one or more of the missing
> authors, or to rewrite some of the worrisome methods. It it is
> important to your business, perhaps offering some bounty cash to
> others to do rewrites might help.