Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

Soeren Gebbert wrote:

> I may found a way to avoid licensing problems or the need to
> convince the meschach developers to change there license
> to be compatible with the gpl.
> 
> We can use parts of the ccmath library.
> http://freshmeat.net/projects/ccmath/
> 
> The ccmath library is licensed under the LGPL,
> and i hope we don't face any problems with this license?

No. Linking definitely isn't a problem (even proprietary code can link
against LGPL libraries). It appears to be LGPL-2, so we can also
incorporate code directly into GRASS.

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

Re: [GRASS-dev] gmath and gpde update

[Soeren Gebbert]

I may found a way to avoid licensing problems or the need to
convince the meschach developers to change there license
to be compatible with the gpl.

We can use parts of the ccmath library.
http://freshmeat.net/projects/ccmath/

The ccmath library is licensed under the LGPL,
and i hope we don't face any problems with this license?

To replace the nr code in grass we need:

* a fast lu decomposition with pivoting
* computation of eigen values and eigen vectors
* singular value decomposition

Here a cite from the ccmath matrix library documentation:

###

   The matrix algebra library contains functions that
   perform the standard computations of linear algebra.
   General areas covered are:

 o Solution of Linear Systems
 o Matrix Inversion
 o Eigensystem Analysis
 o Matrix Utility Operations
 o Singular Value Decomposition
...

 o  Solving and Inverting Linear Systems:

solv  - solve a general system of real linear equations.
solvps  --- solve a real symmetric linear system.
solvru  --- solve a real right upper triangular linear system.
solvtd  --- solve a tridiagonal real linear system.

minv  - invert a general real square matrix.
psinv   invert a real symmetric matrix.
ruinv   invert a right upper triangular matrix.

...

 o  Eigensystem Analysis:

eigen  -- extract all eigen values and vectors of a real
  symmetric matrix.
eigval  - extract the eigen values of a real symmetric matrix.
evmax  -- compute the eigen value of maximum absolute magnitude
  and its corresponding vector for a symmetric matrix.

...

 o Singular Value Decomposition:

svdval  - compute the singular values of a m by n real matrix.
sv2val  - compute the singular values of a real matrix
  efficiently for m >> n.
svduv  -- compute the singular values and the transformation
  matrices u and v for a real m by n matrix.
sv2uv  -- compute the singular values and transformation
  matrices efficiently for m >> n.
svdu1v  - compute the singular values and transformation
  matrices u1 and v, where u1 overloads the input
  with the first n column vectors of u.
sv2u1v  - compute the singular values and the transformation
  matrices u1 and v efficiently for m >> n.

end
###

So the ccmath library provides all the algorithms we need to replace the nr
code in grass.

I would suggest to extract the needed parts from ccmath and integrate
them in the gmath library structure i already created (take a look at the
patch i provided).
I would suggest an extraction of needed parts because the ccmath library
ships a lot of algorithms we don't need and
the source code is not well documented and difficult to read.
We only need the matrix computation algorithm including documentation and
tests.

I will keep my sparse matrix solver and matrix-vector algorithm in gmath and
extend them,
(more sparse matrix and sparse vector operations ... inspired from
meschach),
to implement in the future a sparse ILU and LU factorisation with minimal
fill in.
This is needed for huge sparse linear equation systems with bad condition.
Such linear equation systems
can not be solved with the sparse matrix solver i implemented.

Things to be done (very roughly estimated):

* extraction of the needed algorithm from ccmath
* Implementation of a wrapper around these functions, so a user can replace
the grass ccmath extraction with
  a distribution or self compiled version of the ccmath library.
* integration of the documentation and the tests of ccmath matrix into gmath
* integration of the ccmath solver in the gmath solver structure. This may
result in a modification of the current matrix
  access methods and a rewrite of the blas 1, 2 and 3 functions i
implemented.
* replacing the nr code which results in the modification of all dependent
gmath code and grass modules
* writing tests for all depended modules
* improving the grass sparse matrix algorithms and solver

Well i guess i will need at least another year to code this.
...

So, how about this approach? Any hints, suggestions or criticism?
Did i over see an issue?


Best regards
Soeren




2009/1/15 Glynn Clements 

>
> Moritz Lennert wrote:
>
> > > 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 th

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

Moritz Lennert wrote:

> > 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...

The meschach licence doesn't prohibit selling an aggregation of which
meschach is a component.

That makes the problematic clause even more pointless. You could sell
a CD containing meschach and a two-line script, on the basis that
meschach is free but the script costs $50k.

> > 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]:

Only the copyright holder can provide such an exemption.

The author can release their code under any licence they choose,
including e.g. GPL-but-you-can-link-against-meschach (KDE provided
such an exemption for Qt before it was available under the GPL).

But you can't provide such an exemption for anyone else's GPL code. So
you couldn't distribute a binary linked against e.g. both meschach and
readline. I don't know if this would apply on a module-by-module basis
or to GRASS as a whole. IOW, whether you can claim that GRASS is a
"mere aggregation" of its components or a single work. I suspect the
latter.

> So, we might be able to do this, but AFAICT this would need the 
> agreement of all people holding copyright over GRASS code.

Yes. Including any GPL libraries (e.g. readline).

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

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Soeren Gebbert]

2009/1/13 Glynn Clements 

>
> 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 
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Soeren Gebbert]

Hi Hamish,

2009/1/13 Hamish 

> 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.


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
>
>
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Hamish]

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



  

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

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

On 13/01/09 09:33, Soeren Gebbert wrote:
2009/1/12 Glynn Clements >



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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Soeren Gebbert]

2009/1/12 Glynn Clements 

>
> 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. :/
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 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Soeren Gebbert]

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.
;)

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 

> 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Glynn Clements]

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 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Markus Neteler]

On Sat, Jan 10, 2009 at 8:12 PM, Moritz Lennert
 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...)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] gmath and gpde update

[Moritz Lennert]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev