commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Diggory <mdigg...@gmail.com>
Subject Re: [math] JAMA update and options
Date Sun, 06 Mar 2005 01:24:06 GMT
Even if we have to go through the incubator, I'm convinced that adding 
the JAMA codebase into the math library is the best option. IMHO, I'm 
convinced that while the JAMA folks were very generous and open to 
providing the codebase to the public domain, that further enhancing its 
capabilities and providing any user support is not really in their 
interest. It would be far more in our interest if we forked the codebase 
and supported it. Any suggestion that the "JAMA folks" would have to 
"agree" to this is not the nature of public domain, IMO reuse of public 
domain doesn't require any such acknowledgment, though we should 
liberally acknowledge their contribution wherever possible.

http://www.google.com/search?hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&oi=defmore&q=define:public+domain

http://math.nist.gov/javanumerics/jama/

> *Copyright Notice* /This software is a cooperative product of The 
> MathWorks and the National Institute of Standards and Technology 
> (NIST) which has been released to the public domain. Neither The 
> MathWorks nor NIST assumes any responsibility whatsoever for its use 
> by other parties, and makes no guarantees, expressed or implied, about 
> its quality, reliability, or any other characteristic./
>
Note, JAMA is not a large codebase, and is in the public domain. As 
such, does this really require the need for an "Incubator project"?

Thanks Phil for taking such an initiative.

My $0.02,
-Mark

Phil Steitz wrote:

> I have gone back and forth a few times with one of the JAMA developers 
> at NIST (Bruce Miller) and legal-discuss and have finally asked the 
> ASF board for a ruling on whether or not we can start pulling in some 
> JAMA code. I wanted to start with the QR class, so we can use that to 
> get multiple regression implemented with decent numerics.
>
> Before we start down this path, though I want to present some logical 
> alternatives and get others' reactions to them.  Rather than pulling 
> in bits of implementation code, we could
>
> 1) Introduce a jar dependency on JAMA and wrap / extend / directly use 
> the stuff we need.  For the QR use case, there will be no performance 
> / efficiency hit from this. For some of the other RealMatrix uses, 
> this might be tricky.
>
> 2) Bring in the full code base.  This would probably result in a side 
> trip through the incubator and might provide the occasion to get us 
> kicked out of commons (I am sure there are some who will be happy to 
> see us go :-) but that might be a good thing.  I don't know yet if the 
> JAMA guys would go for this, am interested in opinions of others here.
>
> If I get the go ahead from the board, we will need to decide between
>
> 0) fork selected stuff into [math] and pass bug fixes back and forth 
> with JAMA
>
> and 1) or 2).  WDYT?
>
> Note that the same considerations apply to RngPack.
>
> Phil
>
> ---------------------------------------------------------------------
> 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