[R-sig-Geo] status of gpclib licence

[Roger Bivand]

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

>
> Adrian Baddeley
>
> _______________________________________________
> R-sig-Geo mailing list
> R-sig-Geo at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no