Hello Hamish,<br><br><div class="gmail_quote">2009/8/21 Hamish <span dir="ltr"><<a href="mailto:hamish_b@yahoo.com">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;">
Paul:<br>
> I think in this instance Hamish suggested it might be a PSC matter<br>
> because of the licensing issue<br>
<br>
right.<br>
<br>
Paul:<br>
> [...] the simple solution is to re-licence the LGPL code as GPL<br>
> when it goes into GRASS, to keep everything under the same licence<br>
<br>
Soeren:<br>
> IMHO it may be difficult to re-license the ccmath library under<br>
> the GPL ... .<br>
<br>
why? Term 3 of the LGPL exists to describe exactly how to do that.<br>
</blockquote><div><br>I am not concerned about the technical way, but about agreement of the original author of ccmath. Maybe i am wrong, but AFAICT as the copyright holder he has to agree that we can change the license of his code. <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>
Glynn:<br>
<div class="im">> When the overall project is licensed under the GPL, it's<br>
> reasonable to assume that any contributions are also licensed<br>
> under the GPL. If someone contributes changes to a file which<br>
> happens to be LGPL, they might have actually intended to license<br>
> their contribution under the LGPL, or they might have just<br>
> overlooked that the file in question is LGPL. Also, it means<br>
> that you can't copy or move code from another part of GRASS into<br>
> that library.<br>
<br>
</div>Soeren:<br>
<div class="im">> 1.) I can extend the SUBMISSION file to explain that any<br>
> new numerical or mathematical code belongs into the grass<br>
> gmath or gpde libraries. The ccmath lib is connected to<br>
> grass via a wrapper in the gmath lib. Only the wrapper (a<br>
> single C file) includes the ccmath header. The gmath header<br>
> only knows the wrapper functions. So nobody should include<br>
> the ccmath header directly besides the wrapper.<br>
><br>
> 2.) We can make a guideline that only bug-fixing is allowed<br>
> in the ccmath library (README.txt in ccmath dir). The grass<br>
> ccmath part must be compatible with the 2.2.1 version of<br>
> ccmath to enable external linking. IMHO i in the near future<br>
> nobody will contribute to the ccmath part in<br>
> grass, because the code is hardly readable and not easy to<br>
> maintain.<br>
><br>
> 3.) I can place an ATTENTION.txt file in the ccmath library<br>
> folder, which explains the licensing issue.<br>
><br>
> If this is ok, i would like to submit my changes to svn.<br>
<br>
<br>
</div>Q: is the ccmath library copied verbatim or is it changed to use<br>
gis.h, G_fatal_error() etc? ie is it cloned intact as a convenience<br>
or has it become assimilated into grass code to the point where it<br>
will not run on its own without libgis?</blockquote><div><br>Parts of the ccmath library have been copied to grass. These parts are exact clones.<br>No changes are made in the ccmath code.<br>It can run on its own without any dependencies to grass. <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>
by the way, I notice that we already ship the bwidget LGPL library<br>
trunk/lib/external/bwidget/<br>
<br>
That is for Tcl which is redundant for grass 7, but you can see in<br>
there what was done wrt LGPL.txt and READMEs.<br>
<br>
Keeping it in lib/external/ is a very good idea IMO, see also the<br>
lib/external/shapelib/README and swig/python/NumPtr/README.GRASS<br>
for example of comments about local changes.<br>
<br>
also, lib/external/shapelib code has:<br>
* Copyright (c) 1999, 2001, Frank Warmerdam<br>
*<br>
* This software is available under the following "MIT Style" license,<br>
* or at the option of the licensee under the LGPL (see LICENSE.LGPL). This<br>
* option is discussed in more detail in shapelib.html.<br>
<br>
(ISTR Frank also posted some time ago to grass5-dev a blanket license for<br>
GRASS to use his gdal/ogr/etc code as needed)<br>
<br>
<br>
<br>
Certainly arbitrary mixing of licenses within general source tree<br>
would be a mistake. But I think the lib/external/ designation makes the<br>
situation clear enough to the programmer who might happen upon the code.<br>
<br>
Also note that 'g.version -c' says:<br>
<br>
"""<br>
This program is free software; you can redistribute it and/or modify it<br>
under the terms of the GNU General Public License as published by the<br>
Free Software Foundation; either version 2 of the License, or (at your<br>
option) any later version.<br>
<br>
Parts of GRASS are not copyright by the GRASS development team.<br>
The original authors hold the copyrights and you have to abide<br>
to their licensing terms where noted.<br>
(Keep in mind that code linking into GRASS can only be distributed<br>
if compatible with the GPL.)<br>
"""<br>
<br>
<br>
<br>
Iff the library is intact and has not been extensively modified for<br>
GRASS, my vote would be to add it to lib/external/ (with README.grass<br>
and LGPL.txt files), in the tradition of those other two libraries.</blockquote><div><br>To put the ccmath library into lib/external is a good idea. I vote for it. <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>
If the library has been reworked to be a grass library my vote would<br>
be to use Term 3 of the LGPL and relicense it to GPL to avoid confusion.</blockquote><div><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>
regards,<br>
<font color="#888888">Hamish<br>
<br>
<br>
<br>
<br>
<br>
</font></blockquote></div><br>