[SciPy-dev] License review / weave bsd-ification
Travis E. Oliphant
Mon Nov 3 08:00:42 CST 2008
Jarrod Millman wrote:
> On Mon, Nov 3, 2008 at 1:30 AM, Gael Varoquaux
> <email@example.com> wrote:
>> +1 on all this. Practicality beats purity. It is going to be pretty hard
>> to explain to people that they have to install a bunch of different
>> packages get a full working environment.
> Well my vote is to move weave out of scipy (and has been for some
> time), but it seems like there is some interest in keeping it as part
> of scipy. I am not going to have anymore time to work on weave for
> the next week. But I am opposed to releasing another version of scipy
> with GPL code; so this needs to be fixed or removed before the 0.7
> release. I also want to have all tests passing before we release 0.7,
> which means that all the weave tests need to pass as well.
> If you feel strongly about keeping weave in scipy, now would be a good
> time to step up and get weave in shape for the 0.7 release.
It's only the blitz portion of weave that has "GPLish" features. These
can be disabled or moved to a scikit with no difficulty. Or, they could
be moved back to an older version of blitz (I recall that an upgrade to
the blitz code is what changed the license. I'm pretty sure that Eric
did not put GPL code into weave to begin with).
The original idea was to move weave into numpy not out into a scikit.
So, I'm very much against moving weave outside. If weave were to move
outside then I would support it if it were to move it into a weave /
f2py / pypy hybrid package called "compile" or something like that ---
where C-code, Fortran-code, and RPython code could be compiled into fast
loops, dynamically loaded, and integrated into NumPy (in the spirit of
> It looks like the license issue can be resolved. Newer versions of
> the Mersenne Twister random number generator have a more liberal
> license: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/elicense.html
> Is anyone willing to volunteer to get the newer version working? Is
> it worth considering moving this code out of weave and making the MT
> RNG more generally available?
Isn't NumPy's random number generator the MT algorithm?
More information about the Scipy-dev