[SciPy-dev] PRIMME: PReconditioned Iterative MultiMethod Eigensolver
gruben at bigpond.net.au
Sat Oct 28 00:43:01 CDT 2006
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.
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
> * 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
More information about the Scipy-dev