[MetaCRS] [Proj] Common SQLite-based dictionaries

[Sebastiaan Couwenberg]

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/README.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).

Kind Regards,

Bas

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