[MetaCRS] [Proj] Common SQLite-based dictionaries

[Even Rouault]

On Monday 03 August 2015 22:37:18 Sebastiaan Couwenberg wrote:
> On 03-08-15 21:54, Even Rouault wrote:
> > On Monday 03 August 2015 16:25:15 Sebastiaan Couwenberg wrote:
> >> On 03-08-15 15:37, Howard Butler wrote:
> >>>> On Aug 3, 2015, at 8:32 AM, Sebastiaan Couwenberg <sebastic at xs4all.nl>
> > 
> > wrote:
> >>>>> I recognize there are some things to work through on the EPSG ToS.
> >>>>> Thanks for bringing these issues up.>>
> >>>> 
> >>>> For the eventual Debian package this is the most important issue to
> >>>> resolve. The CSV files distributed with geotiff are split off because
> >>>> the EPSG ToS is not acceptable for the Debian main repository, the ToS
> >>>> is incompatible with the Debian Free Software Guidelines and the Open
> >>>> Source Definition. The ToS discriminates against field of endeavor and
> >>>> limits derived works via parameter modification restrictions.
> >>> 
> >>> Are there some links to discussion about why Debian has made this
> >>> determination?
> >> 
> >> The EPSG ToS was considered non-free by the initial maintainer, and
> >> noted this in the README for the Debian package:
> >> 
> >> "
> >> 
> >>  This version of the GeoTIFF library lacks the EPSG data files which
> >>  are distributed in a separate non-free package libgeotiff-epsg due to
> >>  license limitations.
> >> 
> >> "
> >> 
> >> http://anonscm.debian.org/cgit/pkg-grass/libgeotiff-dfsg.git/tree/debian/
> >> REA DME.Debian
> >> 
> >> For libgeotiff 1.4.0 & 1.4.1 I also did a license & copyright review for
> >> the update of the debian/copyright file with the new machine readable
> >> format, and I also consider the EPSG ToS to be incompatible with the
> >> DFSG:
> >> 
> >> https://www.debian.org/social_contract#guidelines
> >> 
> >> If you want the opinion of Debian people other than the package
> >> maintainers you can contact ftpmaster at ftp-master.debian.org who review
> >> the license & copyright of new packages before they're accepted into the
> >> archive. Or the general debian-legal at lists.debian.org list.
> >> 
> >>>> If the proposed database derived from the EPSG database is bound by the
> >>>> non-free EPSG ToS it won't be acceptable for Debian and by extension
> >>>> Ubuntu.>
> >>> 
> >>> I don't see how the situation is any different than it is now. The
> >>> community can bootstrap its own db, but the amount of expertise required
> >>> to do so in relation to the "convenience" of simply submitting to EPSG
> >>> makes it a tough sell.
> >> 
> >> The EPSG ToS limitions don't seem to apply to derived subsets as long as
> >> they aren't attributed to the EPSG Dataset.
> >> 
> >> In Debian we consider the derived EPSG data in proj/nad/epsg for example
> >> to fall under the MIT license of PROJ.4, because these are subsets of
> >> the EPSG data.
> >> 
> >> Martin's proposal to use a different name and not attributing the
> >> changes to the EPSG Dataset should allow new database to be licensed
> >> freely (e.g. MIT, or maybe ODbL).
> > 
> > How would that be different from the current libgeotiff-epsg package ?
> > Because the later has epsg in its name and the directory is
> > /usr/share/epsg_csv ?
> In essence it wouldn't be much different from the current
> libgeotiff-epsg package.
> 
> But from what I understand of the proposed solution it would replace the
> proj/nad/espg file for example.
> 
> This would mean a strict dependency of the gdal, proj, geotiff, etc
> packages on the newly created srs-data package that includes the SRS
> database built on top of the EPSG database ("standardize the [...] SRS
> coordinate system handling dictionaries on a SQLite database that starts
> with EPSG, with each project adding its own auxiliary tables as
> necessary.").
> 
> The cascading reverse dependencies will require everything from proj on
> up to move out of the Debian main repository into contrib/non-free
> because at the core is a dependency on non-free data.

The dependency to the srs.db package could be a weak one ("recommended"), and 
GDAL/proj/libgeotiff could be made to still work if the srs.db isn't found, 
although some interesting functionality would be missing.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com