[SciPy-dev] PRIMME: PReconditioned Iterative MultiMethod Eigensolver

Gary Ruben gruben at bigpond.net.au
Sat Oct 28 00:43:01 CDT 2006


Hi Brian,
The issue is not one of convenience. The issue is that the GPL and LGPL 
are legally and practically incompatible with the scipy/MIT licence and 
would require a change of the scipy licence is any of their code were to 
be included with the existing package. What I'm unsure of if whether 
it's OK to combine GPL and LGPL code (and GPL3?) into a single package. 
My guess is that it's not and that this means a proliferation of extra 
packages are required. If this is the case maybe they should be called 
scipy_gpl and scipy_lgpl or scikits.gpl, scikits.lgpl or something. 
Maybe there can be an individual egg for each one which carries the 
relevant licence around.
Gary R.

Brian Granger wrote:
> My few cents...
> 
> While the license issues are important, I don't think they should be
> the only thing that is considered when deciding about what gets
> included into scipy.  A few things that I think /should/ be strongly
> considered:
> 
>  * Is the code strongly coupled to scipy already?  Does it have scipy
> as a requirement?  Does it only require NumPy?
> 
>  * Does the code provide capabilities that *many* users of scipy would want?
> 
>  * Would people ever want to use the code without the rest of scipy?
> If the answer is yes then I think the code should probably NOT be
> included in SciPy.  Two example of projects that fit into this
> category (license issues aside): pytables and mpi4py.  While one could
> make an argument that scipy should include tools like these, many
> people need to use these things who don't need scipy  at all.  I work
> with many people who use pytables/mpi4py on supercomputers regularly -
> and installing things on these systems can be a huge pain.  If these
> packages were included with scipy, scpy would become a hinderance and
> burden at that point.
> 
>  * NumPy goes a long way in encouranging interoperability amongst
> numerical codes written in Python.  If a code already interoperates
> with NumPy and SciPy is there any additional benefit to actually
> including it with with SciPy?
> 
> I do think it is a good idea to keep the non BSD code in a separate
> namespace (as Fernando has suggested).  Either that or they can be
> hosted as separate foo.scipy.org projects like ipython.scipy.org,
> pyxg.scipy.org, wavelets.scipy.org, etc.  Why not have
> PyPRIMME.scipy.org?
> 
> Brian


More information about the Scipy-dev mailing list