[GRASS-dev] GRASS inefficiency and FFTW

[Daniel Calvelo]

On 2/26/07, stefano de paoli <dplsfn at yahoo.it> wrote:
> Hi Daniel,

Ciao Stefano.

> > I think you need to take into acount in your
> > analysis the constraining
> > scarce resource within several FLOSS projects:
> > motivated manpower. WRT
> > FFT, the current implementation is efficient in
> > development cost,
> > although inefficient at runtime wrt to the NR
> > illegal implementation.
>
>
> This is a good point. I think I need to take in
> account what GRASS is (few developers, large code base
> and so on).
>
> But following your arguments about development cost we
> can try to immagine a different scenario.
> The Numerical Recipes FFT was eliminated due to the
> incompatibility between the NR copyright and the GPL.
>
> What if GRASS would have been released under a license
> compatible with the Numerical recipes copyright?
> (I'm not sure whwther such a license exists)

The licence proviso you point to below goes in that direction.

> Probably, in such a situation the development cost
> argument conclusion would be that the Numerical
> Recipes would still be in GRASS.

Possible, but it would depend on the level of restriction of the
licence. See below.

> Not changing the code at all is much more efficient in
> term of development cost.

Of course :)

> Note that previous GRASS development team (CERL) had
> an agreement with the authors of NR, to use freely NR:
>
> /* Based on "Numerical Recipies in C; The Art of
> Scientific Computing" (Cambridge University Press,
> 1988).  Copyright (C) 1986, 1988 by Numerical Recipes
> Software.
> Permission is granted for unlimited use within GRASS
> only.  */

Ok, so NR code within GRASS is not illegal. It is just not Free. This
states that unlimited "use" is granted. This *could* be construed as
use and use only, thus not derivation nor redistribution of
derivatives nor relicensing, which is what the GPL is all about
(except the last point, of course). This would make the license
proviso GPL-incompatible.

But I think the mindset around GNU- or Debian-style Free is to
construct and advance a common pool of code (hence knowledge). This
needs Free in the GPL sense.

> I still support the conclusion that there is an
> inefficiency which heavily dependes on the GPL choice.

Yes, but I suspect this comes second to the motivation and capacity
arguments within a legacy framework.

I wouldn't be surprised that your raising the issue of a possible
inefficiency (which Glynn suggests isn't one actually) provides enough
motivation for the issue to be resolved within a week, perhaps less.

Daniel.

-- 
-- Daniel Calvelo Aros