commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: [math] matters of copyright
Date Wed, 04 Jun 2003 00:26:39 GMT
robert burrell donkin wrote:
> On Tuesday, June 3, 2003, at 12:41 AM, Phil Steitz wrote:
> 
>> --- robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> wrote:
> 
> 
> <snip>
> 
>>> it seems to me that brent is assuring us that he went back to the
>>> mathematical basis of the algorithm and started from that. a clean
>>> implementation based on the mathematics should not infringe the 
>>> copyright
>>> nor is it ethically dubious (providing that the correct credits for the
>>> original mathematics are provided if that's possible). what we need to
>>> think about is how we can demonstrate this to everybody's satisfaction.
>>> the openness of the ASF is one of it's great strengths and there 
>>> should be
>>> some way we can show the right way to develop new implementations. (of
>>> course, we need to work out what that is first ;)
>>
>>
>> From Brent's notes on the gamma function implementations, I at least am
>> convinced that his implementation was developed from the math, not the NR
>> algorithm or code.  The dodgy bit is that someone else who did the same
>> derivation and ended up with a similar implementation (e.g. NR) might 
>> claim
>> ownership of the algorithm itself.  This is why the limitation 
>> expressed in the
>> NR copyright statement is important.
> 
> 
> definitely. i think that there are two important lessons here.
> 
> the first that brent was right in the way that he went about 
> demonstration that he developed his implementation from the mathematics. 
> we should probably think about asking for mathematical descriptions of 
> the algorithms so addition to the developers manual

Have you had a chance to look at the draft developer's guidelines that I 
started and submitted here:

http://issues.apache.org/bugzilla/show_bug.cgi?id=20404

We could add a note on this to the section called "documentation".


> if these are not 
> available on the web then we should make efforts (as brent did) to 
> create some notes and add them to the developers guide.

I agree.  I think that the best approach will be to include full 
descriptions of mathematical algorithms not available on the web using 
links in the javadoc to the commons-math developers/users guide.

> 
> the second is that we're going to need to audit our implementations 
> against copyrighted ones. (i'm hoping that some better qualified folks 
> might volunteer for this.) if we find any that are too similar, then we 
> should use apache development resources to create fresh clean room 
> implementations.

I don't understand exactly what you mean here.  It might be difficult to 
find people with the combined legal and math skills to "audit" the code 
for copyright infringement. What did you have in mind here?

>>> i believe that providing new implementation from the basic 
>>> mathematics is
>>> what commons-math should do. there is no real reason why we should start
>>> from existing code. if we can't, then maybe that's a sign that we're
>>> moving away from our aims.
>>
>>
>> The one exception to this is obviously existing code that is owned by the
>> contributor.  Even in this case, however, refactoring will usually be 
>> required
>> (certainly has been for me :-)).
> 
> 
> maybe 'clean and original implementations created by commons-math 
> developers' was probably closer to what i wanted to say than 'new 
> implementations'.
> 
> - robert
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


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


Mime
View raw message