Re: [GRASS-dev] gmath and gpde update
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 gl...@gclements.plus.com 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
Re: [GRASS-dev] gmath and gpde update
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
Hi Hamish, 2009/1/13 Hamish hamis...@yahoo.com 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=1aAOdzK3FegCpg=PA52dq=numerical+recipes+algorithm+ludcmpei=2-NtSfSFLYquywTTrIjOCA#PPA52,M1 The G_tqli algorithm for eigenvalue computation is lend line by line from nr: http://books.google.de/books?id=1aAOdzK3FegCpg=PA588dq=numerical+recipes+algorithm+tqliei=n-VtSfDNAoquywTTrIjOCA#PPA588,M1 And so the G_tred2 algorithm at page 582: http://books.google.de/books?id=1aAOdzK3FegCpg=PA588dq=numerical+recipes+algorithm+tred2ei=WeZtSfetD6OOyQS1pIDjCw#PPA582,M1 The G_svdcomp algorithm in svd.c at page 59: http://books.google.de/books?id=7vuNLcQhg8UCpg=PA52dq=numerical+recipes+algorithm+svdcmpei=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
2009/1/13 Glynn Clements gl...@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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
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
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
2009/1/12 Glynn Clements gl...@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. :/ 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 gl...@gclements.plus.com ___ 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
On 13/01/09 09:33, Soeren Gebbert wrote: 2009/1/12 Glynn Clements gl...@gclements.plus.com mailto:gl...@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 ___ 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 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 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 gl...@gclements.plus.com ___ 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 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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
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
[GRASS-dev] gmath and gpde update
Thanks for you suggestions Glynn. 2009/1/12 Glynn Clements gl...@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 gl...@gclements.plus.com ___ 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 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 gl...@gclements.plus.com
___
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 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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
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
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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
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
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 mlenn...@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 ___ 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 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 gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] gmath and gpde update
Dear developers, after a lng 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] gmath and gpde update
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
Re: [GRASS-dev] gmath and gpde update
On Sat, Jan 10, 2009 at 8:12 PM, Moritz Lennert mlenn...@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...) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
