ICSM (Australia) transformation file licensing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

ICSM (Australia) transformation file licensing

Alex Leith
Hi

I'm working with ICSM to incorporate Australian ntv2 grids into open source software. There are two existing GSB files, and there will be another soon for the new GDA2020 datum. ICSM are able and prepared to license the files in any way.

I'd like to know what license to apply to these files in order to best enable their inclusion into Proj4 and other projects?

Regards,

Alex
--

Alex Leith
0419 189 050

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Sebastiaan Couwenberg
On 01/18/2017 01:01 AM, Alex Leith wrote:
> I'm working with ICSM to incorporate Australian ntv2 grids into open source
> software. There are two existing GSB files, and there will be another soon
> for the new GDA2020 datum. ICSM are able and prepared to license the files
> in any way.
>
> I'd like to know what license to apply to these files in order to best
> enable their inclusion into Proj4 and other projects?

The NTv2 grids already included in the proj-datumgrids distribution are
in the public domain. Creative Commons CC0 is a better choice than PD
because it covers more jurisdictions.

The license for the Australian grids needs to be compatible with the
terms of the GPL-2+ to allow other projects (PostGIS specifically) to
include it too.

Please don't disallow modification of the correction values like EPSG
and many other national grids following their lead, those terms are
incompatible with the GPL-2+.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Martin Desruisseaux-3
Le 18/01/2017 à 15:33, Sebastiaan Couwenberg a écrit :

> Please don't disallow modification of the correction values like EPSG
> and many other national grids following their lead, those terms are
> incompatible with the GPL-2+.
>
Well, there is discussion at OGC about "open standard" versus "open
source". A summary is available in the "OGC API white paper" at [1].
Chapter 5 lists criterion similar to Open Source software, but
intentionally excludes from that list the freedom to modify the standard.

Open Source and Open Standard have different goals. The purpose of a
standard (even open) is compromised if anyone is allowed to modify it.
Of course restrictions like the EPSG terms of use are annoying for open
source licenses like GPL or Apache, but consequences of allowing
departure can be worst. The mess about axis order is an example.
(Actually the problem is not that much that some software change the
axis order, but that they are still using the "EPSG" name for their
modified CRS).

EPSG terms of use try to find a compromise by actually allowing some
modifications, provided that they preserve numerical equivalence. If
numerical equivalence is broken, then the modified CRS shall not be
named "EPSG". It can be a safety issue in transportation and other
domains if someone though that a coordinate was given in the "EPSG:4326"
CRS while actually it was given in "MyOwnTasteOfEPSG:4326" CRS. It seems
to me that the same issue applies to datum grid shift files and other
data published by authoritative agencies.

I would like to stress out that above does not forbid all modifications.
Some modifications are okay if they either preserve numerical
equivalence or make very clear (by using a different name among others)
that the modified data are not any more compliant with the standard. The
golden rule is to not mislead the users.

I agree that this is annoying for open source software, but we can
workaround by putting the data in a "non-free" (or other name)
repository for making clear that those data are subject to different
licensing conditions than the GPL ones. If forcing the users to download
two bundles is considered too annoying, I think it is still possible to
have a single bundle if the data terms of use are shown together with
the GPL license when the user get Proj.4.

    Martin


[1]
https://raw.githubusercontent.com/opengeospatial/api_whitepaper/master/book.pdf

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Greg Troxel-2
In reply to this post by Sebastiaan Couwenberg

Sebastiaan Couwenberg <[hidden email]> writes:

> On 01/18/2017 01:01 AM, Alex Leith wrote:
>> I'm working with ICSM to incorporate Australian ntv2 grids into open source
>> software. There are two existing GSB files, and there will be another soon
>> for the new GDA2020 datum. ICSM are able and prepared to license the files
>> in any way.
>>
>> I'd like to know what license to apply to these files in order to best
>> enable their inclusion into Proj4 and other projects?
>
> The NTv2 grids already included in the proj-datumgrids distribution are
> in the public domain. Creative Commons CC0 is a better choice than PD
> because it covers more jurisdictions.
>
> The license for the Australian grids needs to be compatible with the
> terms of the GPL-2+ to allow other projects (PostGIS specifically) to
> include it too.
>
> Please don't disallow modification of the correction values like EPSG
> and many other national grids following their lead, those terms are
> incompatible with the GPL-2+.
Agreed.  Before I read Sebastian's reply I was going to suggest CC0.  I
really do not think there is much actual danger of trouble.  Everyone in
the community knows that randomly changing projection code files to
return wrong data is not helpful and I really don't think people are
going to do it.  And if they did, everybody else would then shun such a
distribution.  For example, proj is legally free to make a change that
computes UTM by adding 17m to easting and northing, and that would have
a similar effect of users getting wrong data.  But no one is worried
about that happening, and rightly so.

A license that doesn't permit modifications is not compatible with all
Free Software.  It's not just GPL; such a license is also not compatible
with the BSD license.  (It is true that BSD-licensed projects are less
bothered by non-free data licenses, because distributing a tarball that
is mostly Free plus some non-free data, while not under a Free license,
is under a messy license that is compatible with the BSD license.  But
the package is no longer Free Software.)

A middle ground might be CC0 with some extra text:

  To preserve integrity of the projection data, users are strongly
  requested not to make modifications that change numeric results.

Another approach might be to use a 2-clause BSD license that, while
permitting modification, does not allow the modified work to be
distributed under the original name.   But I would suggest that this is
not necessary and just causes needless work from people who are making
changes like fixing == to = to make shell scripts follow POSIX, who then
have to think about whether their change is one that triggers the clause
prohibiting using the name for modified works.

The real way to ensure integrity of geodetic calculation is to publish
test vectors and perhaps code, and encourage those to be added to unit
tests in software that uses the transforms.  Again these can be CC0 --
no one is going to pay attention to modified test vectors.

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Martin Desruisseaux-3
Le 18/01/2017 à 21:32, Greg Troxel a écrit :

> Everyone in the community knows that randomly changing projection code
> files to return wrong data is not helpful and I really don't think
> people are going to do it.
>
But isn't what Proj.4 did when changing axis order? I see units of
measurement issues (e.g. in WKT) as another example.


> A license that doesn't permit modifications is not compatible with all
> Free Software. It's not just GPL; such a license is also not
> compatible with the BSD license.
>
Indeed. But some issues are more important than compatibility with open
source licenses, and standard integrity may be considered as one of
them. Projects who change the data do that because they think that their
changes are legitimate, not because they want to be evil. A typical
example is ignoring some aspects that a developer considers as useless
complexity (e.g. axis order and units of measurement). It is okay to not
implement every aspects of a standard, but when ignoring an aspect
breaks the interoperability goal of that standard, we have a problem.
The EPSG example teaches us that not everyone has an understanding of
"legitimate change" that preserve data integrity, thus the EPSG effort
to clarify which changes are permitted.


> Another approach might be to use a 2-clause BSD license that, while
> permitting modification, does not allow the modified work to be
> distributed under the original name. But I would suggest that this is
> not necessary and just causes needless work from people who are making
> changes like fixing == to = to make shell scripts follow POSIX, who
> then have to think about whether their change is one that triggers the
> clause prohibiting using the name for modified works.
>
I think that protecting the original name could help. But I'm not sure
to understand correctly if in above paragraph, "not necessary" means
"because we do not expect peoples to do that" or "because the
consequences are not considered important"?


> The real way to ensure integrity of geodetic calculation is to publish
> test vectors and perhaps code, and encourage those to be added to unit
> tests in software that uses the transforms. Again these can be CC0 --
> no one is going to pay attention to modified test vectors.
>
Right - this is also what EPSG tried to do with Geospatial Integrity of
Geoscience Software (GIGS) tests. I would support moving forward with
this approach and I can help, but this could be the subject of another
thread.

    Regards,

        Martin


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Sebastiaan Couwenberg
In reply to this post by Martin Desruisseaux-3
On 01/18/2017 09:17 AM, Martin Desruisseaux wrote:

> Le 18/01/2017 à 15:33, Sebastiaan Couwenberg a écrit :
>
>> Please don't disallow modification of the correction values like EPSG
>> and many other national grids following their lead, those terms are
>> incompatible with the GPL-2+.
>
> Well, there is discussion at OGC about "open standard" versus "open
> source". A summary is available in the "OGC API white paper" at [1].
> Chapter 5 lists criterion similar to Open Source software, but
> intentionally excludes from that list the freedom to modify the standard.

I've tried to have a discussion with OGC about the issues with their
licensing of standards and their implementation in Free Software
projects several times in the past, all I every got was a reply that
they would discuss it internally and never heard from them again.

This lead me to give up on ever making progress on this issue, the core
of geospatial software is simply non-free and the organisations involved
have not shown willingness to work with the community to resolve that.

The authors of the AC codec made a similar decision to not allow
modification, which subsequently made its use in LASzip problematic
enough that it cannot be included in Linux distributions and users of
LiDAR projects are forced to maintain custom builds because
distributions cannot provide support the LAZ format.

> Open Source and Open Standard have different goals. The purpose of a
> standard (even open) is compromised if anyone is allowed to modify it.
> Of course restrictions like the EPSG terms of use are annoying for open
> source licenses like GPL or Apache, but consequences of allowing
> departure can be worst. The mess about axis order is an example.
> (Actually the problem is not that much that some software change the
> axis order, but that they are still using the "EPSG" name for their
> modified CRS).

Open Source implementations of Open Standards help them thrive,
licensing Open Standards in ways that make them incompatible with open
source projects hinder adoption of the standards.

PROJ.4 using the EPSG name is indeed a problem that should be fixed.

> EPSG terms of use try to find a compromise by actually allowing some
> modifications, provided that they preserve numerical equivalence. If
> numerical equivalence is broken, then the modified CRS shall not be
> named "EPSG". It can be a safety issue in transportation and other
> domains if someone though that a coordinate was given in the "EPSG:4326"
> CRS while actually it was given in "MyOwnTasteOfEPSG:4326" CRS. It seems
> to me that the same issue applies to datum grid shift files and other
> data published by authoritative agencies.
>
> I would like to stress out that above does not forbid all modifications.
> Some modifications are okay if they either preserve numerical
> equivalence or make very clear (by using a different name among others)
> that the modified data are not any more compliant with the standard. The
> golden rule is to not mislead the users.

While I understand the motivations of EPSG, just like I understand them
of the Dutch Kadaster with whom I've had the same discussion after they
published their NTv2 correction grids, limiting modification is simply
incompatible with Free Software licenses.

The right to make modifications is simply essential to Free Software. As
Greg also mentioned, in practice no one wants to make use of this right
because that would make their implementation incompatible with the rest
of the world beating the purpose of standards.

> I agree that this is annoying for open source software, but we can
> workaround by putting the data in a "non-free" (or other name)
> repository for making clear that those data are subject to different
> licensing conditions than the GPL ones. If forcing the users to download
> two bundles is considered too annoying, I think it is still possible to
> have a single bundle if the data terms of use are shown together with
> the GPL license when the user get Proj.4.

"annoying" is not the right word. Limiting modification simply means
that the grid shift files cannot be included in open source projects
using Free Software licenses ensuring it cannot be working out-of-the
box. The users are forced to retrieve and install the grids themselves.

I'm my opinion, all organisations publishing national grid shift files
should consider they're stance on limiting modifications. The French and
New Zealand grids are public domain, and the Hungarian grid is GPL-2+.
They apparently consider compatibility with Free Software projects more
important than limiting modification.

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Even Rouault-2

> PROJ.4 using the EPSG name is indeed a problem that should be fixed.

 

The issue with axis order is not only found in the proj.4/geotiff/GDAL/etc software stack, but it is also deeply anchored in OGC standards themselves, so I don't see it to be solved any time soon.

 

See this excellent retrospective from Carl Reed:

https://lists.osgeo.org/pipermail/standards/2016-October/000989.html

 

And even some recent OGC standards still don't respect EPSG axis order, or at least this is my interpretation of the GeoPackage standard

(http://www.geopackage.org/spec/) mentionning in footnote 11 :

 

The axis order in WKB is always (x,y{,z}{,m}) where x is easting or longitude, y is northing or latitude, z is optional elevation and m is optional measure.

 

and mandating the EPSG:4326 definition to be:

GEOGCS ["WGS 84", DATUM ["World Geodetic System 1984", SPHEROID["WGS 84", 6378137, 298.257223563 , AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0 , AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943278, AUTHORITY["EPSG","9102"]], AUTHORITY["EPSG","4326"]

 

so with no explicit axis order.

 

> I'm my opinion, all organisations publishing national grid shift files

> should consider they're stance on limiting modifications. The French and

> New Zealand grids are public domain, and the Hungarian grid is GPL-2+.

> They apparently consider compatibility with Free Software projects more

> important than limiting modification.

 

+1. While I can understand the motivation from authoritative sources to not see their data to be modified and misused, so as not to alter their credibility, the practical implications of restricting changes is a practical burden. Open source software and open data also leave the door open to the possibility of doing non-sense with them, and that's perfectly fine. As raised, even if the original data is unaltered, the software can still make a wrong use of it anyway.

 

One simple solution to solve the issue of allowing modifications while not presenting modified data as being the one from the original provider is to have a clause similar to the one found in the ZLib license :

"""Altered source versions must not be misrepresented as being the original software"""

 

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Martin Desruisseaux-3

Le 19/01/2017 à 04:34, Even Rouault a écrit :

The issue with axis order is not only found in the proj.4/geotiff/GDAL/etc software stack, but it is also deeply anchored in OGC standards themselves, so I don't see it to be solved any time soon. See this excellent retrospective from Carl Reed: https://lists.osgeo.org/pipermail/standards/2016-October/000989.html

As Carl said, older WMS and WFS standards were unclear about axis order except for EPSG:4326. The same issue happens also with units of measurement, which were unclear in the first WKT specification before they were clarified in OGC 01-009 and more recently in ISO 19162 (WKT 2). But those historical facts show how difficult it is to fix problems caused by departure from a standard (including OGC departing from EPSG). This history can be taken as an argument against allowing unrestricted changes to a standard.

The axis order policy discussed in latest OGC meetings is that if the order is not as defined by the authority, then the departure shall be obvious from the metadata. For example by using a CRS identifier like "EPSG:4326;axisOrder=(lon,lat)" (example only - not an official syntax).


And even some recent OGC standards still don't respect EPSG axis order, or at least this is my interpretation of the GeoPackage standard (http://www.geopackage.org/spec/) mentionning in footnote 11 : The axis order in WKB is always (x,y{,z}{,m}) where x is easting or longitude, y is northing or latitude, z is optional elevation and m is optional measure.

In that case this is a legacy standard (WKB) incorporated into a newer one. If OGC were defining WKB today, I don't think they would have specified it that way. Geopackage requirement 11 [1] also said: "The record with an srs_id of 4326 SHALL correspond to WGS-84 as defined by EPSG in 4326" with links to EPSG documentation and registry with (latitude, longitude) axis order. Requirement 11 and footnote 11 may seem to contradict each other, but maybe not completely since the "spatial_ref_sys" table allows CRS definitions from different organizations (not necessarily EPSG).

In the process of adopting GeoJSON as an IETF standard, they preferred to exclude any CRS definition (other than saying that the default is CRS:84) rather than adopting the GeoJSON usage of EPSG codes with non-compliant axis order. We have been told that, ironically, IETF has been easier to convince about the importance of standard compliance than the geospatial community.


and mandating the EPSG:4326 definition to be: GEOGCS ["WGS 84", DATUM ["World Geodetic System 1984", SPHEROID["WGS 84", 6378137, 298.257223563 , AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich", 0 , AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943278, AUTHORITY["EPSG","9102"]], AUTHORITY["EPSG","4326"] so with no explicit axis order.

They do not mandate the WKT to be exactly like that since they also said "ignoring any optional EBNF components <twin axes> and <to wgs84> and whitespace differences in the returned text". However I'm not sure if the editor realized that when axes are omitted in WKT 1, the default is (longitude, latitude), which introduce a contradiction with above-cited requirement 11. I will post an email on OGC mailing list asking for a clarification.


While I can understand the motivation from authoritative sources to not see their data to be modified and misused, so as not to alter their credibility, the practical implications of restricting changes is a practical burden.
In long term, I don't think that discarding the data integrity concerns as "less important" than open source convenience will work. As we are entering in a "big data" world, I expect those concerns to increase, maybe sometime with human life at play (e.g. medicine). My personal opinion is that open source should prepare to adapt, if not for EPSG at least for other data to come in next years. Again it does not mean that no change are allowed, but to reduce the risk that the data are not what the user think they are. This is not necessarily incompatible with open source - see next paragraph about name.


One simple solution to solve the issue of allowing modifications while not presenting modified data as being the one from the original provider is to have a clause similar to the one found in the ZLib license : "Altered source versions must not be misrepresented as being the original software"

Apache license also has a similar restriction. If a company changes an Apache Foo software, they can not name it "Apache Foo" anymore [2]. They can call it "MyCompany Whatever" instead. I see clause 6vii of EPSG terms of use ("No data that has been modified other than as permitted in these Terms of Use shall be attributed to the EPSG Dataset") as a similar restriction. Maybe actually the EPSG condition is even more flexible than Apache in this regard since EPSG gives a list of changes that we are allowed to do and still keep the "EPSG" name, while Apache license does not mention any exception to their restriction.

I think that international standards and sensitive data need slightly different licenses than open source software. It may cause incompatibilities in the foreseeable future, but open source have resolved other incompatibilities issues in the past (e.g. incompatibility between Apache and GPL licenses, resolved with Apache 2 + GPL 3). In the meantime, we have workarounds.

    Martin


[1] http://www.geopackage.org/spec/#gpkg_spatial_ref_sys_cols
[2] http://www.apache.org/foundation/license-faq.html#Name-changes



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: ICSM (Australia) transformation file licensing

Martin Desruisseaux-3
In reply to this post by Sebastiaan Couwenberg
Le 19/01/2017 à 03:31, Sebastiaan Couwenberg a écrit :

> I've tried to have a discussion with OGC about the issues with their
> licensing of standards and their implementation in Free Software
> projects several times in the past, all I every got was a reply that
> they would discuss it internally and never heard from them again.
>
Could the "API white paper" (link in my previous email) be seen as a
publication of their current state of though? Their discussions have
been reported in the Open Architecture Board (OAB) sessions in many
recent OGC meetings. The GitHub repository of the API white paper is
public - we can submit merge requests.


> This lead me to give up on ever making progress on this issue, the
> core of geospatial software is simply non-free and the organisations
> involved have not shown willingness to work with the community to
> resolve that.
>
OGC has signed a "memorandum of understanding" with OSGeo [1], giving
OGC membership for free (in my understanding) to a few OSGeo members at
some conditions documented on OSGeo wiki. There is also an agreement
between OGC and the Eclipse Software Foundation. Similar agreement
between OGC and the Apache Software Foundation has been discussed but
not yet materialized. However OGC is already active at Apache, helping
us to organize a "Geospatial track" in both Apache Conferences of 2016.

The OGC/OSGeo memorandum of understanding cites liaison contacts. My
experience with the geospatial track in Apache Conferences is that the
liaison on OGC side is responsive. Maybe your should contact the
liaisons on OSGeo side?


> While I understand the motivations of EPSG, just like I understand
> them of the Dutch Kadaster with whom I've had the same discussion
> after they published their NTv2 correction grids, limiting
> modification is simply incompatible with Free Software licenses.
>
Free software licenses are important, but not necessarily the most
important thing in the world. Some may argue that data integrity is more
important. I do not want to enter in the debate of what is most
important - I just want to said that this issue may require compromise
on both sides, and open source licenses have proved a capability to
adapt to other issues in the past (e.g. Apache-GPL compatibility,
patents, etc.).


> The right to make modifications is simply essential to Free Software.
>
The right to make modifications is not unrestricted in Free Software.
Apache has restrictions (we can not keep the "Apache" name), GPL has
restrictions (we must publish our changes), etc.


> As Greg also mentioned, in practice no one wants to make use of this
> right because that would make their implementation incompatible with
> the rest of the world beating the purpose of standards.
>
Some projects do make incompatible changes (e.g. axis order), sometime
in good faith (e.g. following the path of someone else, e.g. WMS
standard before it was fixed) but the result is still incompatibility.
Another example is the old days when Internet Explorer had its own
interpretation of HTML standard.

    Regards,

        Martin

[1]
https://wiki.osgeo.org/wiki/OSGeo_signs_Memorandum_of_Understanding_with_OGC


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj