[GRASS-dev] gmath/gpde Patch for grass6.5 and grass7

[Hamish]

Paul:
> I think in this instance Hamish suggested it might be a PSC matter
> because of the licensing issue 

right.

Paul:
> [...] the simple solution is to re-licence the LGPL code as GPL
> when it goes into GRASS, to keep everything under the same licence

Soeren:
> IMHO it may be difficult to re-license the ccmath library under
> the GPL ... .

why? Term 3 of the LGPL exists to describe exactly how to do that.


Glynn:
> When the overall project is licensed under the GPL, it's
> reasonable to assume that any contributions are also licensed
> under the GPL. If someone contributes changes to a file which
> happens to be LGPL, they might have actually intended to license
> their contribution under the LGPL, or they might have just
> overlooked that the file in question is LGPL. Also, it means
> that you can't copy or move code from another part of GRASS into
> that library.

Soeren:
> 1.) I can extend the SUBMISSION file to explain that any
> new numerical or mathematical code belongs into the grass
> gmath or gpde libraries. The ccmath lib is connected to
> grass via a wrapper in the gmath lib. Only the wrapper (a
> single C file) includes the ccmath header. The gmath header
> only knows the wrapper functions. So nobody should include
> the ccmath header directly besides the wrapper.
> 
> 2.) We can make a guideline that only bug-fixing is allowed
> in the ccmath library (README.txt in ccmath dir). The grass
> ccmath part must be compatible with the 2.2.1 version of
> ccmath to enable external linking. IMHO i in the near future
> nobody will contribute to the ccmath part in
> grass, because the code is hardly readable and not easy to
> maintain.
> 
> 3.) I can place an ATTENTION.txt file in the ccmath library
> folder, which explains the licensing issue. 
>
> If this is ok, i would like to submit my changes to svn. 


Q: is the ccmath library copied verbatim or is it changed to use
gis.h, G_fatal_error() etc? ie is it cloned intact as a convenience
or has it become assimilated into grass code to the point where it
will not run on its own without libgis?


by the way, I notice that we already ship the bwidget LGPL library
  trunk/lib/external/bwidget/

That is for Tcl which is redundant for grass 7, but you can see in
there what was done wrt LGPL.txt and READMEs.

Keeping it in lib/external/ is a very good idea IMO, see also the
lib/external/shapelib/README  and swig/python/NumPtr/README.GRASS
for example of comments about local changes.

also, lib/external/shapelib code has:
 * Copyright (c) 1999, 2001, Frank Warmerdam
 *
 * This software is available under the following "MIT Style" license,
 * or at the option of the licensee under the LGPL (see LICENSE.LGPL).  This
 * option is discussed in more detail in shapelib.html.

(ISTR Frank also posted some time ago to grass5-dev a blanket license for
GRASS to use his gdal/ogr/etc code as needed)



Certainly arbitrary mixing of licenses within general source tree
would be a mistake. But I think the lib/external/ designation makes the
situation clear enough to the programmer who might happen upon the code.

Also note that 'g.version -c' says:

"""
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.

Parts of GRASS are not copyright by the GRASS development team.
The original authors hold the copyrights and you have to abide
to their licensing terms where noted.
(Keep in mind that code linking into GRASS can only be distributed
if compatible with the GPL.)
"""



Iff the library is intact and has not been extensively modified for
GRASS, my vote would be to add it to lib/external/ (with README.grass
and LGPL.txt files), in the tradition of those other two libraries.

If the library has been reworked to be a grass library my vote would
be to use Term 3 of the LGPL and relicense it to GPL to avoid confusion.


regards,
Hamish