------------------------------
Message: 5 Date: Tue, 19 Jan 2010 10:25:44 +0100 (CET) From: Roger
Bivand <Roger.Bivand at nhh.no> To: Adrian.Baddeley at csiro.au
Cc: r-sig-geo at stat.math.ethz.ch Subject: Re: [R-sig-Geo] status of
gpclib licence Message-ID:
<alpine.LRH.2.00.1001190947480.24342 at reclus.nhh.no> Content-Type:
TEXT/PLAIN; charset=US-ASCII; format=flowed
On Tue, 19 Jan 2010, Adrian.Baddeley at csiro.au wrote:
Nicholas Lewin-Koh and others have asked about the licence for the R
package 'gpclib'. This is based on the C library 'gpclib' by Alan
Murtagh which has a non-GPL licence.
Recently I contacted the licence holders for the C library, with a
formal request that the licence be changed to GPL. After contacting
Alan Murtagh they replied that it has been decided, definitively,
not to alter the licence.
Hence we are currently looking for a FOSS replacement for gpclib.
Any volunteers?
Adrian,
The rgeos package on R-Forge is almost ready for release.
https://r-forge.r-project.org/projects/rgeos/
http://trac.osgeo.org/geos/
The proof-of-concept has been to link it tightly to sp classes at the
C level. The way GEOS is structured makes tight coupling hard to avoid
- so similar R <-> C interfaces will be needed for other packages.
Because it isn't just for clipping, it doesn't fit the hole left by
gpclib neatly.
Finally, it has an external dependency, the GEOS DLL and headers,
which can be met for Windows binary packages with Uwe Ligges' help
(tried but not yet operative on R-Forge, ready to roll when rgeos is
on CRAN). For Unix/Linux users, either install GEOS from source or
binaries (works on Debian/Ubuntu - libgeos, libgeos-c1, libgeos-dev),
for OSX using the Kyngchaos GEOS framework (untried
http://www.kyngchaos.com/ -> software -> frameworks).
An alternative that ought to be followed up at least as proof-of-
concept is the Boost GGL library:
http://reviews.slashgeo.org/article.pl?sid=09/11/30/1638211
http://trac.osgeo.org/ggl
Build for GGL is as other Boost software, through a mystical graph of
C++ headers - like the R RBGL package, which ships with the Boost
headers in a gzipped tar archive in src/ to create the Boost framework
at compile time. It is, however, not C++ written as C, it is modern
C++. So for me, the GEOS C API was easier to handle (for a chosen
definition of easier).
In the meantime, packages that depend on gpclib could use the
following strategy that we have adopted for 'spatstat'. The
'spatstat' package previously 'Depend'ed on gpclib. I have
reorganised spatstat so that it only 'Suggests' gpclib, and the gpclib-
dependent code can be enabled or disabled using a flag,
spatstat.options("gpclib") which is initialised to FALSE. If you are
an academic or non-profit, set spatstat.options(gpclib=TRUE). If
you're commercial, leave it as FALSE and have a nice day...
Even if you are academic, but doing contracted research, I'd be
concerned with the lack of clarity in:
"Commercial use of GPC (for example: product development / commercial
research)"
http://www.cs.manchester.ac.uk/~toby/alan/software/#Licensing
which is very much broader than compiling GPC into software for sale.
I guess it depends on your half-full/half-empty status ...
Unreleased maptools on the sourceforge r-spatial project follows your
lead on this (different mechanism - flag hidden in environment, same
principle), but where rgeos is present, uses that instead everywhere
gpclib was used before. Partly because of the use of C, it yields the
same results quicker. I'd be very grateful for anyone able to install
source packages trying out rgeos, and then installing maptools from a
cvs checkout from r-spatial. When I have some feedback, I'll release.
Helpers very welcome!
Roger