[MetaCRS] [Proj] Common SQLite-based dictionaries

[Sebastiaan Couwenberg]

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.

We have a similar unresolved problem with the OGC Document Notice terms
which disallows motification of their Standards works (CITE tests most
importantly), the XML schemas also fall under the Document Notice if you
don't use a different namespace for a modified schema.

These unavoidable non-free parts in the GFOSS ecosystem make it
impossible to build a truely free system in which the right to make
modifications is essential.

> When reading of 6.vii of http://www.epsg.org/TermsOfUse ("No data that has 
> been modified other than as permitted in these Terms of Use shall be attributed 
> to the EPSG Dataset.") , I'm not clear of what it really allows . Does that 
> explicetly mean that we are allowed to do any modification ? But in that case, 
> I'm not sure what the associated rights and obligations are.

The unabiguity was also raised in the debian-legal posts linked from:
https://trac.osgeo.org/gdal/wiki/RevisedEPSGLicense

EPSG is the only party that can authoritatively answer your question.

My interpretation is that you're allowed to make modifications if you do
not claim that EPSG is responsible for them. In a similar spirit as the
"Integrity of The Author's Source Code" compromise:

"
 The license may restrict source-code from being distributed in
 modified form only if the license allows the distribution of "patch
 files" with the source code for the purpose of modifying the program
 at build time. The license must explicitly permit distribution of
 software built from modified source code.The license may require
 derived works to carry a different name or version number from the
 original software. (This is a compromise. The Debian group encourages
 all authors not to restrict any files, source or binary, from being
 modified.)
"

https://www.debian.org/social_contract#guidelines

I can envision a project that takes the EPSG database and with a
collection of SQL scripts (patches) creates the database for proj, gdal
& friends. That would be compatible with the compromise when you apply
it to data instead of software. The EPSG ToS is just not very explicitly
about being allowed to distribute changes.

Kind Regards,

Bas

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