[MetaCRS] [Proj] Common SQLite-based dictionaries

[Sebastiaan Couwenberg]

On 03-08-15 23:31, Even Rouault wrote:
> 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.

To be Debian Policy compliant, a package in main can only Suggest a
package in non-free (as libgeotiff-dev does for libgeotiff-epsg).
Suggests are not installed by default whereas Depends & Recommends are.

Packages that have a strict dependency (expressed with Recommends or
Depends) on a non-free package but are themselves fully (dfsg-compliant)
free software live in the contrib repository. Both contrib & non-free
are not of the Debian system (but do use most of the packaging
infrastructure, builds for other architectures must be requested
explicitly for non-free).

I'm not entirely opposed to move all of the recursive dependencies to
contrib/non-free to acknowledge the reality of the esstial non-free
parts in the open geospatial ecosystem. But this is a great disservice
to our users I can't endorse. Nor do I want the increased maintenance
burden. Which brings us back to the uncomfortable position in which we
have to deal with the non-free parts in some way to keep everything else
free and functional. I don't have a good solution to this problem.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1