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

[Soeren Gebbert]

Hello Hamish,

2009/8/21 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.
>

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.


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


Parts of the ccmath library have been copied to grass. These parts are exact
clones.
No changes are made in the ccmath code.
It can run on its own without any dependencies to grass.

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


To put the ccmath library into lib/external is a good idea. I vote for it.

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



Best regards
Soeren

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

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

[Hamish]

Hamish wrote:
> 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,

actually that's used by tcl NVIZ so still in use. wx NVIZ is not yet
to the point where it can replace the tcl version.
(btw, we should rename visualization/nviz2/ to be wxNViz or something;
the tcl version is already version 2.2)

I added a new lib/external/README.license file to explain things.
AFAICT the SUBMITTING file and RFCs do not require adjustment.


Hamish



  

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

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

[Hamish]

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

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

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

The authors already gave consent to do that when they released the
code under the terms of the LGPL, which explicitly allows that.
The terms you see laid out in their LPGL.txt file are /their/ terms,
not the FSF's.

As a matter of good will it could be nice to drop them a note to thank
them and say what we have done, but I don't think we need their permission
to do it.


None the less, my 2c vote would be to keep it as LGPL and put it in the
existing lib/external/ directory.


Hamish



  

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

[GRASS-dev] Re: [GRASS GIS] #727: Rast_get_d_color() segfault in trunk

[GRASS GIS]

#727: Rast_get_d_color() segfault in trunk
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org   
  Type:  defect  |  Status:  new 
  Priority:  normal  |   Milestone:  6.4.0   
 Component:  Raster  | Version:  svn-trunk   
Resolution:  |Keywords:  r.what, Rast_is_null_value()
  Platform:  Linux   | Cpu:  x86-64  
-+--
Comment (by glynn):

 Replying to [ticket:727 hamish]:

 > I'm getting a segfault in grass7's r.what if I give it an out-of-region
 coordinate.

 >
 {{{
 Program received signal SIGSEGV, Segmentation fault.
 ...
 (gdb) bt
 ...
 #7  0x00402783 in main (argc=5, argv=0x7fff847d8c98) at main.c:384
 }}}

 The code in question is:

 {{{
 383 if (out_type[i] == CELL_TYPE)
 384 Rast_get_c_color(&cell[i][cache[point].col],
 385  &red, &green, &blue,
 &ncolor[i]);
 386 else
 387 Rast_get_d_color(&dcell[i][cache[point].col],
 388  &red, &green, &blue,
 &ncolor[i]);
 }}}

 {{{
 > print cache[point].col
 $3 = -19297
 }}}

 The above code needs to check that the indices are within the array's
 bounds.

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

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

[Glynn Clements]

Soeren Gebbert wrote:

> 3.) I can place an ATTENTION.txt file in the ccmath library folder, which
> explains the licensing issue.

You can't assume that someone modifying the file will have viewed the
contents of the folder. When I open a source file, it's often from
grep or compilation output (C-x ` or selecting a specific line of
output), or via M-. (find-tag, i.e. locate the point in the source
where a given symbol is defined).

If you want to ensure that the information is seen by anyone modifying
the file, the information needs to go into the file itself.

What would be better still would be if subversion could restrict the
ability to modify those files, or at least send a reminder email if
the files are modified.

An alternative would be to put the library in e.g. lib/nonGPL/ccmath
so that the pathname serves as a reminder.

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

[GRASS-dev] [GRASS GIS] #729: v.to.rast fails to convert area in LL location when region spans equator

[GRASS GIS]

#729: v.to.rast fails to convert area in LL location when region spans equator
-+--
 Reporter:  marisn   |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.5.0
Component:  Vector   | Version:  svn-develbranch6 
 Keywords:  v.to.rast|Platform:  Linux
  Cpu:  Unspecified  |  
-+--
 In some region settings v.to.rast fails to convert area (vector area is
 missing in raster). No error message is printed.

 If computational region is reduced to just one part of equator, area gets
 converted to raster just fine.

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

[GRASS-dev] Re: [GRASS GIS] #729: v.to.rast fails to convert area in LL location when region spans equator

[GRASS GIS]

#729: v.to.rast fails to convert area in LL location when region spans equator
-+--
  Reporter:  marisn  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.5.0
 Component:  Vector  | Version:  svn-develbranch6 
Resolution:  |Keywords:  v.to.rast
  Platform:  Linux   | Cpu:  Unspecified  
-+--
Comment (by marisn):

 First reported in ML: http://lists.osgeo.org/pipermail/grass-user/2009-
 August/052032.html

 Steps to reproduce:
 {{{
 v.to.rast input=def...@permanent output=deff use=cat type=point,line,area
 layer=1 value=1 rows=4096
 }}}

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

[GRASS-dev] Re: db.join useful?

[Markus Neteler]

On Fri, Aug 21, 2009 at 1:07 AM, Markus Neteler wrote:
> Hi,
>
> do you consider a db.join script to be useful?
>
> db.join --help
>
> Description:
>  Allows to join a table into another table.
>
> Keywords:
>  database, attribute table
>
> Usage:
>  db.join table=name column=string otable=name ocolumn=string
>   [--verbose] [--quiet]

For now in Addons. Install with:

g.extension db.join

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

Re: [GRASS-dev] db.join useful?

[Dylan Beaudette]

Hi Markus,

Does your message say that all but DBF back-ends are supported?

Thanks,

Dylan

On Thu, Aug 20, 2009 at 4:07 PM, Markus Neteler wrote:
> Hi,
>
> do you consider a db.join script to be useful?
>
> db.join --help
>
> Description:
>  Allows to join a table into another table.
>
> Keywords:
>  database, attribute table
>
> Usage:
>  db.join table=name column=string otable=name ocolumn=string
>   [--verbose] [--quiet]
>
> Flags:
>  --v   Verbose module output
>  --q   Quiet module output
>
> Parameters:
>    table   Table to join into
>   column   Join column in first table
>   otable   Other table name
>  ocolumn   Join column in other table
>
> what it does:
> - check for duplicate column names, adds a "b" if found
> - adds new column(s) to be joined
> - joins (all expect DBF is supported)
>
> ?
> Markus
> ___
> 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] Re: [GRASS-windows] No such file or dire

[Hamish]

Hamish:
> [r.in.poly fails to read text input file on Windows wxGUI Cmd> line]
> 
> I have checked at the r.in.poly source code, the problem does
> not seem to be there. The path is passed to fopen() verbatim.
> 
> what version/revision of 6.4.0svn is this? is it the latest?
>
> ISTR that Martin&Glynn had fixed this -- wxGUI now uses a
> python parser which understands shell quoting on the Cmd> line.
> But that might only be present in the very latest build.


I'm having a hard time finding that in SVN now...  ??


Peter:
> The 'About' window says 
> GRASS GIS 6.4.0svn (2009)
> GIS Library Revision 37101 (2009-05-10) 
> I downloaded and installed on 02-Aug.


(we are trying to stabilize especially the library so its rev may stay
the same for several versions)

but Aug 2 is a few days into the latest version of Colin's package, so
you'll be using the latest version. Our field laptop just came back from
the field so I can now test the same.


I can reproduce the error; I can also reproduce the error in Linux if
I take the odd step of putting a '\' in the filename.

Workaround 1:
Just use the File-> Import raster -> import lines and polygons from ASCII
file GUI.

Workaround 2:
On the Cmd> line you need to quote the '\' character in the path names
with another '\', for example:

  r.in.poly input=C:\\Grassdata\\polygon.txt

the trouble is that '\' is the verbatim-character-follows quoting
character, disabling it could cause other issues (dealing with spaces
in path names for example). I had though that we were now using the
Python native path parser, but as mentioned above I can't find that in
the code now. I can see how C:\\path\\to\\file would get annoying quite
quickly on Windows.



Hamish



  

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

Re: [GRASS-dev] db.join useful?

[Markus Neteler]

On Fri, Aug 21, 2009 at 5:42 PM, Dylan
Beaudette wrote:
> Hi Markus,
>
> Does your message say that all but DBF back-ends are supported?

Yes - DBF isn't quite SQL capable... same thing as for v.db.join and
other more interesting SQL features.

I usually use SQLite as backend.

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

Re: [GRASS-dev] Re: [GRASS-windows] No such file or dire

[Hamish]

Hamish wrote:
> Workaround 2:
> On the Cmd> line you need to quote the '\' character in the path names
> with another '\', for example:
> 
>   r.in.poly input=C:\\Grassdata\\polygon.txt


a less bizarre but equally effective way to quote it:

   r.in.poly input="C:\Grassdata\polygon.txt"

:)


Hamish



  

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