[GRASS-dev] GRASS inefficiency and FFTW

[Hamish]

Stefano De Paoli wrote:
> 
> Given this problem I started to wonder whether this example fit with
> the issue that Free Software is primarly about so called "freedom" and
> not about efficency. As many many Open Source advocates usually say.
> 
> Which means that an inefficient solution has been introduced in GRASS
> in order to maintain the integrity of the GPL license.

Efficiency is a relative term.

Current fft translation code gets the job done faster than the
alternative NR version, as the NR solution can't be used at all.

We could optimize the software to be very efficient in some aspects
(fft), but we would have to compromise in others (legality).
We must balance the efficiency of a module's resource needs versus
of the efficiency of the greater project development (both code and
social*).

[*] see discussions covering relicensing the GRASS 6 vector lib under
the LGPL; some devels would not continue to contribute under those
conditions. (FWIW I wouldn't mind e.g. dglib network routing becoming
LGPL, but some of that is GPL (c) FSF so that's not really probable)


the classic FOSS priorities are, in order of importance:
  0. code is legal. (it can be used at all)
  1. code works.
  2. code is easy to understand and maintain.
  3. code is optimized.


I would encourage you to search the archives for threads concerning
Radim's v.in.dwg vs. Huidae Cho's v.in.dxf port. Similar issues apply.



best of luck,
Hamish