[GRASS-dev] gmath and gpde update

GRASS GRASS developer
1

Dear developers,
after a loooong time of development i would like to commit some changes to the gmath and gdpe lib
and some dependent raster modules.

The following changes have been made:

  • The gpde solver (gauss, jacobi, LU, Cholesky, CG, PCG and BiCGStab) are now located in the gmath library.
    Because of that several files in the gpde directory have been removed or updated.
  • Tests and benchmarks for single and multi threaded computation are available.
  • Blas level 1, 2 and 3 functions are implemented with tests, benchmarks and basic support for sparse matrices.
    The implemented BLAS functions are not optimized for high performance, but multi threaded with OpenMP.
  • Some new solver uses the BLAS 1 and 2 functions of the grass implementation.
  • An ATLAS wrapper for BLAS level 1 functions is available, BUT level 2 and 3 function are still work in progress and not finished yet.
  • r.gwflow and r3.gwflow are updated to use the gmath library.
  • Updates to gmath.h and gisdefs.h

The patch file for the latest grass7 trunk is located here:
http://www-pool.math.tu-berlin.de/~soeren/grass/files/soeren_gmath_gpde.diff.gz

A patched grass7 trunk is available here:
http://www-pool.math.tu-berlin.de/~soeren/grass/files/grass_trunk_soeren_gpde_gmath.tar.bz2

To apply the patch unzip the diff file, change directory to the grass_trunk root directory and type:
cat soeren_gmath_gpde.diff | patch -p0

Why a grass BLAS implementation?
There was a discussion more than a year ago, to replace the dependency in
the gmath library to the FORTRAN BLAS and LAPACK libraries with
the ATLAS BLAS/LAPACK implementation.
Because of that i have implemented a simple grass BLAS level 1, 2 and 3 library and a wrapper for ATLAS BLAS level 1 functions,
which uses the grass BLAS implementation as backup in case the ATLAS library is not available. Wrapper for ATLAS BLAS level
2 and 3 functions must be developed to gain any benefit from the ATLAS library.

Replacement of existing lu decomposition?
Most of the new solvers for linear equation systems (Ax = b) are paralleled with OpenMP. This works
fine with the krylov-subspace methods (cg, pcg and bicgstab) which also work with sparse matrices,
but not with the gauss and lu decomposition solver. The speedup of booth solver is quite bad.
I was unable to replace the existing lu decomposition, which is lend from numerical recipes,
with a high performance, parallel algorithm which works also with sparse matrices.
This is much to complicated for me.
Because the new lu and gauss solver are simply paralleled with OpenMP they lack the support of pivot elements.
These new solver will not work with matrices with a bad condition (like the ones from the spline interpolation).
So they are no replacement for the existing lu decomposition.

I have no write acces to the svn repository. If you think my updates are usefully, please commit them.

If you think these updates are not necessary i would like to suggest a radical different solution:

I have had a look on several solver packages in the last year. The most exiting packages to me are
the meschach implementation of real/complex vector/matrix computation including
most of the fastest linear equation/eigenvalue solver for dense and sparse matrices!
and the Trilinos approach of the sandia national laboratories which is based on many free available serial and parallel solvers.

Meschach is available here:
http://www.netlib.org/c/meschach/

Trilinos is available here:
http://trilinos.sandia.gov/

Meschach is implemented in C and is able to replace the gmath library completely with much better implementations.
I have integrated meschach into grass for testing purposes and, after some very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? Can somebody please verify this? Im not an expert in licensing.

The Trilinos approach is quite different. It is a C++ framework with Python bindings which provides a simplified and
unified interface to most of the fastest serial and parallel solver available (BLAS, LAPACK, SuperLU, MUMPS, UMPFPACK, METIS…).
It was never easier for me to start a parallel ilu/gmres computation of a huge sparse matrix on a cluster with some simple Python instructions.
But because Trilinos is implemented in C++, all grass modules which should benefit from Trilinos must be implemented in C++ to.

So devs … what do you think?

Best regards
Soeren

2

On 10/01/09 16:36, Soeren Gebbert wrote:

Meschach is implemented in C and is able to replace the gmath library completely with much better implementations.
I have integrated meschach into grass for testing purposes and, after some very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? Can somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:

"The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not compromised."

There is no mention of modification, and the second half of the sentence ("while ensuring that the quality of the software is not compromised") sounds quite suspicious to me. So, without claiming any expert knowledge either, I would be sceptical.

Moritz

3

On Sat, Jan 10, 2009 at 8:12 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

On 10/01/09 16:36, Soeren Gebbert wrote:

Meschach is implemented in C and is able to replace the gmath library
completely with much better implementations.
I have integrated meschach into grass for testing purposes and, after some
very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? Can
somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:

"The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not compromised."

There is no mention of modification, and the second half of the sentence
("while ensuring that the quality of the software is not compromised")
sounds quite suspicious to me. So, without claiming any expert knowledge
either, I would be sceptical.

I checked Debian, it is there:
http://packages.debian.org/search?keywords=meschach
http://packages.qa.debian.org/m/meschach.html
http://packages.debian.org/changelogs/pool/main/m/meschach/current/copyright

Markus
(who damaged his working i.spec.unmix (see Addons-SVN) to
remove Meschach some years ago...)

4

Moritz Lennert wrote:

> Meschach is implemented in C and is able to replace the gmath library
> completely with much better implementations.
> I have integrated meschach into grass for testing purposes and, after
> some very basic testing, it works nicely.
> But im unsure if the licence of meschach is compatible with the GPL? Can
> somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:

"The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not compromised."

There is no mention of modification, and the second half of the sentence
("while ensuring that the quality of the software is not compromised")
sounds quite suspicious to me. So, without claiming any expert knowledge
either, I would be sceptical.

Where did you find that? It appears to contradict:

http://packages.debian.org/changelogs/pool/main/m/meschach/current/copyright

  ** This Meschach Library is provided "as is" without any express
  ** or implied warranty of any kind with respect to this software.
  ** In particular the authors shall not be liable for any direct,
  ** indirect, special, incidental or consequential damages arising
  ** in any way from use of the software.
  **
  ** Everyone is granted permission to copy, modify and redistribute this
  ** Meschach Library, provided:
  ** 1. All copies contain this copyright notice.
  ** 2. All modified copies shall carry a notice stating who
  ** made the last modification and the date of such modification.
  ** 3. No charge is made for this software or works derived from it.
  ** This clause shall not be construed as constraining other software
  ** distributed on the same medium as this software, nor is a
  ** distribution fee considered a charge.

The latter is compatible with the GPL, the former certainly isn't.

--
Glynn Clements <glynn@gclements.plus.com>

5

On 11/01/09 14:02, Glynn Clements wrote:

Moritz Lennert wrote:

Meschach is implemented in C and is able to replace the gmath library completely with much better implementations.
I have integrated meschach into grass for testing purposes and, after some very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? Can somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:

"The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not compromised."

There is no mention of modification, and the second half of the sentence ("while ensuring that the quality of the software is not compromised") sounds quite suspicious to me. So, without claiming any expert knowledge either, I would be sceptical.

Where did you find that?

http://www.netlib.org/c/meschach/readme

It appears to contradict:

http://packages.debian.org/changelogs/pool/main/m/meschach/current/copyright

It definitely does. I would tend to trust Debian more than the above...

Moritz

6

Dear developers,
thanks a lot for clarification.

In case we will use the meschach library within grass to replace the existing LAPACK wrapper, my BLAS and solver implementation
and several numerical recipes algorithm (lu, eigenvalues solvers …), i will take the patched debian sources and integrate them into
grass.

IMHO the following changes have to be made in the meschach library:

  • replacing malloc, calloc and realloc with the GRASS implementation
  • replacing printf and fprintf with the GRASS implementation
  • changing the error handling to use G_fatal_error and similar GRASS functions
  • adding the prefix G_math_ to all extern library functions (with preprocessor directives)
  • document the changes i made

Optionally:

  • try to add OpenmMP derectives to matrix-vector and matrix-matrix computation functions
  • try to paralleling the LLT and LDLT solver
  • write benchmarks and more tests

Changes in GRASS:

  • replacing most of the gmath and current gpde stuff in GRASS with the meschach implementation, but keeping the G_alloc_matrix and G_alloc_vector functions
  • integrate meschach in the doxygen documentation system

I think i will need one year again to implement this in my rare spare time. :wink:

Do we need a vote to replace the gmath and gpde parts with meschach?
Any objections against it or criticism or suggestions?

Btw.: this is an interesting article describing the computation speed of meschach in relation to other numerical libraries:
http://www.ibm.com/developerworks/opensource/library/l-matrix.html

Best regards
Soren

2009/1/11 Moritz Lennert <mlennert@club.worldonline.be>

On 11/01/09 14:02, Glynn Clements wrote:

Moritz Lennert wrote:

Meschach is implemented in C and is able to replace the gmath library completely with much better implementations.
I have integrated meschach into grass for testing purposes and, after some very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? Can somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:

“The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not compromised.”

There is no mention of modification, and the second half of the sentence (“while ensuring that the quality of the software is not compromised”) sounds quite suspicious to me. So, without claiming any expert knowledge either, I would be sceptical.

Where did you find that?

http://www.netlib.org/c/meschach/readme

It appears to contradict:

http://packages.debian.org/changelogs/pool/main/m/meschach/current/copyright

It definitely does. I would tend to trust Debian more than the above…

Moritz

7

Soeren Gebbert wrote:

In case we will use the meschach library within grass to replace the
existing LAPACK wrapper, my BLAS and solver implementation
and several numerical recipes algorithm (lu, eigenvalues solvers ...), i
will take the patched debian sources and integrate them into
grass.

IMHO the following changes have to be made in the meschach library:

* replacing malloc, calloc and realloc with the GRASS implementation

Not necessarily. The G_* versions are merely a convenience to avoid
having to explicitly check for failure. If meschach is already
performing the checking, there probably isn't much reason to change
it.

* replacing printf and fprintf with the GRASS implementation

GRASS doesn't have implementations of those functions. It has
G_message() etc, which should be used for communicating with the user.

* changing the error handling to use G_fatal_error and similar GRASS
functions

Probably, although this should be done in a minimal manner, e.g.
making errors call a user-defined callback, and installing a callback
which calls G_fatal_error().

* adding the prefix G_math_ to all extern library functions (with
preprocessor directives)

Why?

Is there some reason why GRASS must "assimilate" meschach rather than
simply using it (with any modifications which are strictly necessary).

In particular, if any distributions provide a meschach package, it's
generally preferable to use that rather than a private copy.

--
Glynn Clements <glynn@gclements.plus.com>

8

On 11/01/09 22:32, Moritz Lennert wrote:

On 11/01/09 14:02, Glynn Clements wrote:

Moritz Lennert wrote:

Meschach is implemented in C and is able to replace the gmath library completely with much better implementations.
I have integrated meschach into grass for testing purposes and, after some very basic testing, it works nicely.
But im unsure if the licence of meschach is compatible with the GPL? Can somebody please verify this? Im not an expert in licensing.

This seems to be the relevant part:

"The source code is available to be perused, used and passed on without
cost, while ensuring that the quality of the software is not compromised."

There is no mention of modification, and the second half of the sentence ("while ensuring that the quality of the software is not compromised") sounds quite suspicious to me. So, without claiming any expert knowledge either, I would be sceptical.

Where did you find that?

http://www.netlib.org/c/meschach/readme

It appears to contradict:

http://packages.debian.org/changelogs/pool/main/m/meschach/current/copyright

The Debian version is what's in the copyright file in the source code available here:

http://www.math.uiowa.edu/~dstewart/meschach/mesch12b.tar.gz

So, sorry for the confusion, no contradiction (just an unclear readme file).

However, is

** Everyone is granted permission to copy, modify and redistribute this
** Meschach Library, provided:
[...]
** 3. No charge is made for this software or works derived from it.
** This clause shall not be construed as constraining other software
** distributed on the same medium as this software, nor is a
** distribution fee considered a charge.

GPL-compatible ?

Moritz

9

Thanks for you suggestions Glynn.

2009/1/12 Glynn Clements <glynn@gclements.plus.com>

Soeren Gebbert wrote:

In case we will use the meschach library within grass to replace the
existing LAPACK wrapper, my BLAS and solver implementation
and several numerical recipes algorithm (lu, eigenvalues solvers …), i
will take the patched debian sources and integrate them into
grass.

IMHO the following changes have to be made in the meschach library:

  • replacing malloc, calloc and realloc with the GRASS implementation

Not necessarily. The G_* versions are merely a convenience to avoid
having to explicitly check for failure. If meschach is already
performing the checking, there probably isn’t much reason to change
it.

Agreed, AFAICT memory checks are performed in meschach.
But i was hoping to get rid of the machine dependent defines within the include files of meschach,
grass already checks for malloc, calloc and realloc.

  • replacing printf and fprintf with the GRASS implementation

GRASS doesn’t have implementations of those functions. It has
G_message() etc, which should be used for communicating with the user.

Sorry for confusion, i ment G_message() etc.
Usage of G_message() will probably integrate meschach better in the grass message handling (quite, verbose …).
But i have to think more about this. You are making a good point.
In case a distribution version of meschach will be used, instead of the copy in grass,
the message handling will process in the original way … so the benefit of changing the
message handling in the grass copy is lost … and because of that not meaningful at all.

  • changing the error handling to use G_fatal_error and similar GRASS
    functions

Probably, although this should be done in a minimal manner, e.g.
making errors call a user-defined callback, and installing a callback
which calls G_fatal_error().

Agreed.

  • adding the prefix G_math_ to all extern library functions (with
    preprocessor directives)

Why?

To mark the meschach code as part of the gmath library. Many functions in meschach are quite short
and in this manner not self explaining. I think the grass code using meschach will
be more readable if a prefix is used. A developer who is not familiar with meschach will identify the
functions as part of the gmath library and will not search for local function definitions.
But i wont touch any function name in the code of meschach. Instead i would like to include the meschach
includes into gmath.h and redefine the meschach names with macros:

gmath.h:

/meschach includes/
#ifndef SYSTEM_MESCHACH
#include “grass/matrix.h”
…
#else
#include <matrix.h>
…
#endif

#define G_math_iv_get iv_get
#define G_math_SPMAT SPMAT
#define G_math_sp_free sp_free
…

Is there some reason why GRASS must “assimilate” meschach rather than
simply using it (with any modifications which are strictly necessary).

No.

In particular, if any distributions provide a meschach package, it’s
generally preferable to use that rather than a private copy.

Agreed.
But IMHO a copy of meschach should be provided in grass with minimal changes so it can be
replaced with a distribution version. I guess this can be handled at configuration time.

Soeren

–

Glynn Clements <glynn@gclements.plus.com>

10

Soeren Gebbert wrote:

> > * adding the prefix G_math_ to all extern library functions (with
> > preprocessor directives)
>
> Why?

To mark the meschach code as part of the gmath library. Many functions in
meschach are quite short
and in this manner not self explaining. I think the grass code using
meschach will
be more readable if a prefix is used. A developer who is not familiar with
meschach will identify the
functions as part of the gmath library and will not search for local
function definitions.
But i wont touch any function name in the code of meschach. Instead i would
like to include the meschach
includes into gmath.h and redefine the meschach names with macros:

That's preferable, although it might be better to create wrapper
functions than macros, e.g.:

  int G_math_somefunc(void) { return somefunc(); }

Excessive use of macros can be a nuisance; macros don't show up in
"nm" output, or in gdb backtraces, can't have breakpoints set on them,
can't be called from gdb, etc.

--
Glynn Clements <glynn@gclements.plus.com>

11

Moritz Lennert wrote:

However, is

** Everyone is granted permission to copy, modify and redistribute this
** Meschach Library, provided:
[...]
** 3. No charge is made for this software or works derived from it.
** This clause shall not be construed as constraining other software
** distributed on the same medium as this software, nor is a
** distribution fee considered a charge.

GPL-compatible ?

Ah; I don't think so.

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

Anyone distributing GRASS binaries is required to provide (or offer to
provide) the source code for "the work as a whole" (which would
include meschach) under the terms of the GPL.

This would then allow the recipient to extract any part (e.g.
meschach) and (try to) sell it. While that seems like a rather
unlikely scenario, the GPL requires that you permit this, and if you
cannot permit it, you cannot satisfy the GPL.

And the meschach library appears not to permit it.

--
Glynn Clements <glynn@gclements.plus.com>

12

On 12/01/09 16:25, Glynn Clements wrote:

Moritz Lennert wrote:

However, is

** Everyone is granted permission to copy, modify and redistribute this
** Meschach Library, provided:
[...]
** 3. No charge is made for this software or works derived from it.
** This clause shall not be construed as constraining other software
** distributed on the same medium as this software, nor is a
** distribution fee considered a charge.

GPL-compatible ?

Ah; I don't think so.

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

Anyone distributing GRASS binaries is required to provide (or offer to
provide) the source code for "the work as a whole" (which would
include meschach) under the terms of the GPL.

This would then allow the recipient to extract any part (e.g. meschach) and (try to) sell it. While that seems like a rather
unlikely scenario, the GPL requires that you permit this, and if you
cannot permit it, you cannot satisfy the GPL.

And the meschach library appears not to permit it.

That's what I thought...

Interesting that Debian thought it DFSG-compatible...

Moritz

13

2009/1/12 Glynn Clements <glynn@gclements.plus.com>

Moritz Lennert wrote:

However, is

** Everyone is granted permission to copy, modify and redistribute this
** Meschach Library, provided:
[…]
** 3. No charge is made for this software or works derived from it.
** This clause shall not be construed as constraining other software
** distributed on the same medium as this software, nor is a
** distribution fee considered a charge.

GPL-compatible ?

Ah; I don’t think so.

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

Anyone distributing GRASS binaries is required to provide (or offer to
provide) the source code for “the work as a whole” (which would
include meschach) under the terms of the GPL.

This would then allow the recipient to extract any part (e.g.
meschach) and (try to) sell it. While that seems like a rather
unlikely scenario, the GPL requires that you permit this, and if you
cannot permit it, you cannot satisfy the GPL.

And the meschach library appears not to permit it.

Oh no.
Does that mean we can not integrate meschach into grass and only provide a framework
or wrapper around it? And the user has to compile and install meschach by himself
to run GRASS?

Or can we risk to integrate it. Because IMHO we have a lot of numerical recipies code
in gmath which we need to replace.
But replacing one license violation with another is not such a good idea.

I have not the time and the knowledge to replace the numerical recipes algorithm
with code developed by myself. :confused:
ATLAS does not provide such algorithms.
In case we choose BLAS, LAPACK, LINPACK and EISPACK
we will depend on a proper FORTRAN to C interface.

What can we do?

–
Glynn Clements <glynn@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

14

On 13/01/09 09:33, Soeren Gebbert wrote:

2009/1/12 Glynn Clements <glynn@gclements.plus.com <mailto:glynn@gclements.plus.com>>

    Moritz Lennert wrote:

     > However, is
     >
     > ** Everyone is granted permission to copy, modify and
    redistribute this
     > ** Meschach Library, provided:
     > [...]
     > ** 3. No charge is made for this software or works derived from it.
     > ** This clause shall not be construed as constraining other
    software
     > ** distributed on the same medium as this software, nor is a
     > ** distribution fee considered a charge.
     >
     > GPL-compatible ?

    Ah; I don't think so.

    The GPL allows you to charge for derivative works (although being
    unable to prohibit free redistribution tends to limit this).

    Anyone distributing GRASS binaries is required to provide (or offer to
    provide) the source code for "the work as a whole" (which would
    include meschach) under the terms of the GPL.

    This would then allow the recipient to extract any part (e.g.
    meschach) and (try to) sell it. While that seems like a rather
    unlikely scenario, the GPL requires that you permit this, and if you
    cannot permit it, you cannot satisfy the GPL.

    And the meschach library appears not to permit it.

Oh no.
Does that mean we can not integrate meschach into grass and only provide a framework
or wrapper around it? And the user has to compile and install meschach by himself
to run GRASS?

Yes, or use the version coming with their distribution.

What can we do?

Either make meschach a dependency, as Glynn suggested, thus just linking to it which, AFAIU, does not violate GPL, and which has the added (important) advantage that we do not have to maintain the code. Or convince the meschach developers to relicense.

Moritz

15

Moritz wrote:

3. No charge is made for this software or works derived from it.
    This clause shall not be construed as constraining other software
    distributed on the same medium as this software, nor is a
    distribution fee considered a charge.

Glynn:

> The GPL allows you to charge for derivative works (although being
> unable to prohibit free redistribution tends to limit this).

as an example, OpenOSX.com sells GRASS for profit (as allowed by the GPL).
ie beyond simply a distribution fee. The GPL says that a customer who
purchased the binary (for any $X) has the right to request the *source
code* at a cost no more than the a reasonable distribution fee. The
original GPL binary could be sold for millions if all parties were happy
with that price.

Soeren Gebbert wrote:

Or can we risk to integrate it.

never knowingly do the wrong thing.

Because IMHO we have a lot of numerical recipies code in gmath which
we need to replace.

is there? I had thought that was all replaced.

But replacing one license violation with another is not
such a good idea.

FWIW the situation is not exactly equivalent, as long ago GRASS was
granted special permission/exemption by the Numerical Recipes authors.

That sort of special permission is not compatible with e.g. the Debian
Free Software Guidelines, so efforts had been made to replace it all
anyway. It was my understanding that this work had been completed.
Has it not?

(sorry if that is slightly fuzzy, I haven't reread the archives or GRASS
5 source to refresh my memory)

Hamish

16

Moritz Lennert wrote:

> The GPL allows you to charge for derivative works (although being
> unable to prohibit free redistribution tends to limit this).
>
> Anyone distributing GRASS binaries is required to provide (or offer to
> provide) the source code for "the work as a whole" (which would
> include meschach) under the terms of the GPL.
>
> This would then allow the recipient to extract any part (e.g.
> meschach) and (try to) sell it. While that seems like a rather
> unlikely scenario, the GPL requires that you permit this, and if you
> cannot permit it, you cannot satisfy the GPL.
>
> And the meschach library appears not to permit it.

That's what I thought...

Interesting that Debian thought it DFSG-compatible...

I don't really see a problem with it. It's a "you do not have the
freedom to make this program less free" restriction, similar to the
restrictions imposed by the GPL.

Essentially, it's a question of how to resolve competing freedoms, and
the meschach licence took a different view to the GPL. It's just a
different (and incompatible) sort of "free".

--
Glynn Clements <glynn@gclements.plus.com>

17

Moritz Lennert wrote:

Either make meschach a dependency, as Glynn suggested, thus just linking
to it which, AFAIU, does not violate GPL, and which has the added
(important) advantage that we do not have to maintain the code. Or
convince the meschach developers to relicense.

AFAIK, distributing binaries of GRASS which are linked against
meschach is a violation of the GPL, the same as linking against e.g.
DWG.

In some cases, it may be possible to rely upon the "part of the OS"
exemption for distributions which include a meschach package. But not
all distributions include meschach (Gentoo doesn't have an ebuild for
it).

The situation is a bit different for v.in.dwg, as that's a
non-essential package, while the gmath library is quite important. Any
use of meschach would have to be implemented in such a way that
existing functionality isn't lost in versions built without.

--
Glynn Clements <glynn@gclements.plus.com>

18

Hi Hamish,

2009/1/13 Hamish <hamish_b@yahoo.com>

Moritz wrote:

  1. No charge is made for this software or works derived from it.
    This clause shall not be construed as constraining other software
    distributed on the same medium as this software, nor is a
    distribution fee considered a charge.

Glynn:

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

as an example, OpenOSX.com sells GRASS for profit (as allowed by the GPL).
ie beyond simply a distribution fee. The GPL says that a customer who
purchased the binary (for any $X) has the right to request the source
code at a cost no more than the a reasonable distribution fee. The
original GPL binary could be sold for millions if all parties were happy
with that price.

Soeren Gebbert wrote:

Or can we risk to integrate it.

never knowingly do the wrong thing.

Because IMHO we have a lot of numerical recipies code in gmath which
we need to replace.

is there? I had thought that was all replaced.

The lu decomposition is lend line by line from nr:
http://books.google.de/books?id=1aAOdzK3FegC&pg=PA52&dq=numerical+recipes+algorithm+ludcmp&ei=2-NtSfSFLYquywTTrIjOCA#PPA52,M1

The G_tqli algorithm for eigenvalue computation is lend line by line from nr:
http://books.google.de/books?id=1aAOdzK3FegC&pg=PA588&dq=numerical+recipes+algorithm+tqli&ei=n-VtSfDNAoquywTTrIjOCA#PPA588,M1

And so the G_tred2 algorithm at page 582:
http://books.google.de/books?id=1aAOdzK3FegC&pg=PA588&dq=numerical+recipes+algorithm+tred2&ei=WeZtSfetD6OOyQS1pIDjCw#PPA582,M1

The G_svdcomp algorithm in svd.c at page 59:
http://books.google.de/books?id=7vuNLcQhg8UC&pg=PA52&dq=numerical+recipes+algorithm+svdcmp&ei=COdtSYqtIIPmzAS1rtjcDQ#PPA59,M1

But replacing one license violation with another is not
such a good idea.

FWIW the situation is not exactly equivalent, as long ago GRASS was
granted special permission/exemption by the Numerical Recipes authors.

That sort of special permission is not compatible with e.g. the Debian
Free Software Guidelines, so efforts had been made to replace it all
anyway. It was my understanding that this work had been completed.
Has it not?

(sorry if that is slightly fuzzy, I haven’t reread the archives or GRASS
5 source to refresh my memory)

Hamish

19

2009/1/13 Glynn Clements <glynn@gclements.plus.com>

Moritz Lennert wrote:

Either make meschach a dependency, as Glynn suggested, thus just linking
to it which, AFAIU, does not violate GPL, and which has the added
(important) advantage that we do not have to maintain the code. Or
convince the meschach developers to relicense.

AFAIK, distributing binaries of GRASS which are linked against
meschach is a violation of the GPL, the same as linking against e.g.
DWG.

In some cases, it may be possible to rely upon the “part of the OS”
exemption for distributions which include a meschach package. But not
all distributions include meschach (Gentoo doesn’t have an ebuild for
it).

The situation is a bit different for v.in.dwg, as that’s a
non-essential package, while the gmath library is quite important. Any
use of meschach would have to be implemented in such a way that
existing functionality isn’t lost in versions built without.

Thats the point. Many grass modules depend on libgmath. We cannot only write a
wrapper for meschach and remove the existing nr algorithms. We need to replace
the nr algorithm with something new and then optionally provide a wrapper
for meschach.
Additionally a unified interface must be implemented, because the grass modules should not care if
meschach or the standard grass implementation is used.

Thats a lot of work.

–

Glynn Clements <glynn@gclements.plus.com>

20

On 13/01/09 23:43, Glynn Clements wrote:

Moritz Lennert wrote:

The GPL allows you to charge for derivative works (although being
unable to prohibit free redistribution tends to limit this).

Anyone distributing GRASS binaries is required to provide (or offer to
provide) the source code for "the work as a whole" (which would
include meschach) under the terms of the GPL.

This would then allow the recipient to extract any part (e.g. meschach) and (try to) sell it. While that seems like a rather
unlikely scenario, the GPL requires that you permit this, and if you
cannot permit it, you cannot satisfy the GPL.

And the meschach library appears not to permit it.

That's what I thought...

Interesting that Debian thought it DFSG-compatible...

I don't really see a problem with it. It's a "you do not have the
freedom to make this program less free" restriction, similar to the
restrictions imposed by the GPL.

Well, the first paragraphe of the DFSG is:

"Free Redistribution

The license of a Debian component may not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources."

So, forbidding to sell seems against the DFSG...

Essentially, it's a question of how to resolve competing freedoms, and
the meschach licence took a different view to the GPL. It's just a
different (and incompatible) sort of "free".

There seems to be a possibility of exceptions for these situations in the GPL[1]:

"If you're using GPLv2, you can provide your own exception to the license's terms. The following license notice will do that. Again, you must replace all the text in brackets with text that is appropriate for your program. If not everybody can distribute source for the libraries you intend to link with, you should remove the text in braces; otherwise, just remove the braces themselves.

"
[License text]

In addition, as a special exception, the copyright holders of [name of your program] give you permission to combine [name of your program] with free software programs or libraries that are released under the GNU LGPL and with code included in the standard release of [name of library] under the [name of library's license] (or modified versions of such code, with unchanged license). You may copy and distribute such a system following the terms of the GNU GPL for [name of your program] and the licenses of the other code concerned{, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code}."

and something similar exists in GPLv3:

"Additional permission under GNU GPL version 3 section 7

If you modify this Program, or any covered work, by linking or combining it with [name of library] (or a modified version of that library), containing parts covered by the terms of [name of library's license], the licensors of this Program grant you additional permission to convey the resulting work. {Corresponding Source for a non-source form of such a combination shall include the source code for the parts of [name of library] used as well as that of the covered work.}"

So, we might be able to do this, but AFAICT this would need the agreement of all people holding copyright over GRASS code. So, it might be easier to convince the meschach authors. Soeren, maybe you could contact them ?

Moritz

[1] http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs