commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Questions about the linear package
Date Sun, 18 Oct 2009 14:25:56 GMT
Luc Maisonobe wrote:
> Jake Mannix a écrit :
>> On Wed, Oct 14, 2009 at 11:10 AM, Luc Maisonobe <>wrote:
>>> When this topic was discussed previously, Sam asked to someone called
>>> Bjorn-Ove and the reply was positive, see
>>> <>.
>> Ok, so reading this thread left it at the following:
>>   1) the maintainers of MTJ were all willing to relicense it as Apache, that
>> which
>> wasn't already BSD licensed.  So licenses are workable.
>>   2) there was discussion about what level of native code / generated code
>> would
>> be acceptable in [math], which the consensus was that java source code was
>> required,
>> but f2j had some weird post-processing on .class files necessary, meaning
>> that to
>> include mtj, [math] would need to depend on:
>>     a) Fortran source code files which could be included, or
>>     b) compiled java jars which have the translated BLAS/LAPACK code
>> Does 2) hinder the acceptability of MTJ in [math] ?  JIRA tickets MATH-269,
>> MATH-270,
>> and MATH-271 haven't been commented on since they were created back in
>> May...
> I think 2) is a real problem.
> Choice 2a) opens a can of worms with native compilation of a library
> with just the right set of compiler/linker options to allow it to be
> opened by Runtime.getRuntime().loadLibrary(name). I've done it several
> times on Unix and Linux systems with autoconf/automake/libtool but this
> is really a pain. I also don't know how to do that on Windows or other
> systems.
> Choice 2b) raises different issues: f2j is distributed under a modified
> GPL license (i.e. GPL with the addition of the BSD advertising clause,
> something I have never seen before). It is announced in sourceforge as
> being published under a BSD license, but the LICENSE file in both f2j
> 08. and f2j 0.8.1 are GPL with BSD clause ... The underlying javab tool
> is also freely available only for education, research and non-profit
> purposes. We clearly can redistribute neither f2j itself nor javaB due
> to these licensex and so would have to distribute only the already
> compiled jar files. I'm reluctant to distribute binary only blobs in our
> distribution (and if I remember correctly, Phil also didn't like this idea).

Your recollection is correct. I have four problems with this

1. We need to remain fully open source - i.e., what we release is
*openly developed source code*.  Our binary distributions are for
convenience of the user. Users *must* be able to build binaries
identical to our binary distributions from our source distros.

2. Code and algorithms need to be *fully documented* and what the
code does needs to be *transparent* to the user.  This is again
basic OSS.

3. We need to be able to support the code. It is challenging enough
for us to support our own translations of the lapack stuff. I do not
relish the thought of decompiling byte code to figure out what it
does to troubleshoot bug reports.

4. It is a basic principle of commons-math that we will not bring in
hard dependencies on third party libraries or native code or require
complex configuration.  See the Guiding Principles here:

If there is a way that we can integrate the mtj stuff in a way that
leaves it as a clean, optional dependency, bringing in only
comprehensible, documented code and someone is willing to volunteer
to do it, I am OK with it.  If we can't do it without violating the
principles above, then I am not OK with it.


> I don't know of any other fortran to java conversion tools.
> Luc
>>   -jake
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message