echeipesh
commented
2 years ago Catching up with the discussion in the links you have posted. For now here are the links to the IP review tickets under which EPSG datasets have been approved by Eclipse legal review:
Name: EPSG Geodetic Parameter Dataset Version: 7.9 Description: The EPSG database provides common identifiers for measurements (size and shape of the earth), mathematical models (of the shape of the earth), common reference points (such as the prime meridian) and units (of distance) required for the use of geospatial information.
To facilitate communication between GIS systems (and alleviate an long history of loss of property and life) these identifiers and definitions are required for any and all interoperability between systems. To go further these identifiers and definitions are required to responsibly use any and all data published or information captured.
These definitions are often the responsibility of individual industry, national and international authorities. The assignment of an identifier is the responsibility of the International Association of Oil & Gas Producers (OGP). Formally European Petroleum Standards Groups (EPSG).
This standards body publishes their registry as an access database, with terms permitting commercial use.
The terms restrict \"distribution for profit\" for the identifiers as they form a freely available standard the wide distribution of which is in the interest of safety. Distribution in a commercial context requires that value charged be based on the software, and not by virtue of including this freely available dataset.
The identifiers and definitions are used by a GIS system in a similar fashion as Metric or Imperial systems of measurements provided by the UOMo project.
Cryptography: No
License(s): Historical Permission Notice and Disclaimer Other Project URL: http://www.epsg-registry.org/
- EPSG Geodetic Parameter Dataset Version: 7.9
- Refers specifically to EPSG Terms of Use
- EPSG Geodetic Parameter Dataset Version: 8.6
- EPSG Geodetic Parameter Dataset Version: 9.2 is for proj4j specifically but refers to above
My reading of the above is precisely because the projects themselves add functionality, coordinate reprojection, and do not try to extract commercial value from the database itself they are within the terms of use for EPSG. This would also necessarily be the case for any project that use Proj4J or GeoMesa as a dependency since they would be adding further functionality.
Also, paging @jodygarnett and @jnh5y for deeper answers and insights.
desruisseaux
jnh5y
pomadchin
julianhyde
jodygarnett
Proj4j should not use the Apache License while it continues to contain the EPSG data set. The licensing terms are not compatible. Use of the EPSG data set implies the user's acceptance of EPSG's conditions (such as 'no commercial use'), but the Apache License implies that there are no such conditions.
You can't say 'the users should have read the fine print', because the whole point of the Apache License is that there is no fine print.
In Apache Calcite we used Proj4j, and took at face value Proj4j's assertion that it was under the Apache license. In so doing, we have placed our users in legal jeopardy because they may have used Calcite's
ST_Transformfunction for commercial purposes. See CALCITE-5399 for more details.I think it would be irresponsible for the authors of Proj4j to continue to license under Apache License. Everyone who uses Pro4j is getting a time bomb, and may not know it. (Sure, it sucks that EPSG is not available under an open source license. But you can't hide that fact under a layer of software abstraction.)
May I suggest the following solution. Split the EPSG library into a separate library (jar file) that is NOT under an open source license, say proj4j-data. Keep the rest of the library the same, but make the dependency optional. If the user explicitly downloads proj4j-data and places it on the classpath (thereby signaling their consent to the terms), then proj4j will work as normal. If they do not, pro4j will work in a reduced capacity. Maybe that capacity is massively reduced, I don't know.
Another possible solution. If the discussion on CALCITE-5399, Martin Desruisseaux suggests that Proj4j implements GeoAPI interfaces. If so, downstream projects like Calcite could depend on only those interfaces, and the user could download and "plug in" as an implementation of those interfaces. Calcite would ship with a 'dumb' implementation of those interfaces that did not use the EPSG data set, but would contain instructions on its web site for people to download Proj4j if they agreed with the EPSG conditions.