<br><br><div class="gmail_quote">2009/8/14 Hamish <span dir="ltr"><<a href="mailto:hamish_b@yahoo.com" target="_blank">hamish_b@yahoo.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Soeren wrote:<br>
> if there are no objections against the changes and the new<br>
> LGPL'd ccmath library?<br>
<br>
</div>I have no comment either way on the technical side of the library changes<br>
beyond wondering if it will peacefully interact with the (mostly unused)<br>
existing --with-blas --with-lapack ./configure switches.</blockquote><div><br>The changes do not break or interfer the --with-blas --with-lapack ./configure switches.<br>The la.c file contains lapack matrix and vector functionality as well as an LU solver and<br>
a eigenvalue vector sorter. Function names start with G_matrix or G_vector.<br>The ccmath wrapper as well as the numerical functions taken from the gpde libary and<br>the blass functionality starting with G_math.<br>The ccmath matrix computation functions are compatible with the default grass matrix allocation methods.<br>
<div><br>
</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
As for including a dependent library in GRASS I personally don't have<br>
a problem with that as it does not seem to be widely available or have<br>
much infrastructure of its own (beyond a e.g. Freshmeat.net writeup<br>
page*). i.e. not a fork because there isn't really any new version to<br>
keep in sync with, and users would have a hard time finding a package<br>
for it.<br>
</blockquote><div><br>Indeed, the last code changes are from 2001.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
As for including LGPL code in the main trunk I personally don't have a<br>
problem with that as it reflects the upstream license/author's wishes,<br>
is new code, and is used as a library. By my reading the RFC2 doc nor<br>
'g.version -c' & the COPYING file need any adjustment to cover this.<br>
But a formal decision on that may be a matter for the PSC.</blockquote><div><br>I will start a PSC request.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
As long as everything in the lib/ccmath/ dir falls under the same (GPL<br>
compatible) license and the LGPL.txt file is placed in that dir I'd be<br>
happy.</blockquote><div><br>I will make sure that every ccmath file includes a lgpl header and i will provide a copy of the lgpl.license file in lib/ccmath.<br><br>Best regards<br>Soeren <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<br>
<br>
Hamish<br>
<br>
<br>
[*] a web search for ccmath found a most interesting auto-georegistration<br>
tool for applying/projecting a 3D registration onto 2D photographs:<br>
gipfel. Check out the .avi demo.<br>
<a href="http://io.debian.net/%7Etar/debian/gipfel/" target="_blank">http://io.debian.net/~tar/debian/gipfel/</a><br>
Note the track overlay is from a x,y,z text file, very neat.<br>
reminds me a bit of i.points.auto, Stereo[1], and autopano-sift[2]<br>
software.<br>
[1] <a href="http://grass.osgeo.org/gdp/stereo-grass/index.html" target="_blank">http://grass.osgeo.org/gdp/stereo-grass/index.html</a><br>
[2] <a href="http://user.cs.tu-berlin.de/%7Enowozin/autopano-sift/" target="_blank">http://user.cs.tu-berlin.de/~nowozin/autopano-sift/</a><br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br>