Re: Draft of the release process

[Bertil Chapuis <bc...@gmail.com>]

Hello Everyone,

I hope you are doing well. I guess we all have been very busy lately ;-) So let me resume this thread.

Most of the issues reported in this thread have been addressed [1] or added to the release checklist [2]. The main one being the inclusion of a DISCLAIMER-WIP file to the release until we are fully conform to Apache’s standards. From what I understand, this should allow us to make releases, even if we haven’t completely resolved the proj4j issue in Baremaps yet.

Please, do not hesitate to provide feedbacks, report issues, or even to commit in the 492-release branch.

Best,

Bertil

[1] https://github.com/apache/incubator-baremaps/pull/535 <https://github.com/apache/incubator-baremaps/issues/492>
[2] https://github.com/apache/incubator-baremaps/issues/492 <https://github.com/apache/incubator-baremaps/issues/492>
[3] https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc3 <https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc3>

> On 23 Nov 2022, at 00:19, Martin Desruisseaux <martin.desruisseaux@geomatys.com <ma...@geomatys.com>> wrote:
> 
> Hello Bertil
> 
> Le 22/11/2022 à 21:47, Bertil Chapuis a écrit :
> 
>> The terms of the EPSG license are restrictive [1]: The data may not be distributed for profit by any third party. I’m quite amazed to discover that most geospatial solutions out there are probably violating this license.
>> 
> Yes. In the case of PROJ version 6 and later, complying to the license would be just a matter of releasing PROJ under MIT + EPSG terms of use, not MIT alone. Because PROJ is used by GDAL, QGIS and PostGIS (among others), the issue apply to all those software as well and could be resolved in the same way. But my understanding is that adding EPSG Terms of Use would cause problems for packaging QGIS and PostGIS in some Linux distributions (it is a matter of license policy, like the policy we have at Apache), which is why PROJ maintainers are reluctant to address the issue.
> 
> For PROJ version 4, the situation is more tricky because that old version modified the EPSG dataset, notably by changing axis order to (longitude, latitude). The EPSG license does not allow such modifications (because they change the numerical results of coordinate operations), or at least not under "EPSG" namespace. So PROJ4 and PROJ4J are more difficult to resolve. PROJ version 6 and later are better because since version 6, PROJ respects EPSG data integrity.
> 
> 
>> [1]https://svn.osgeo.org/geotools/trunk/licenses/EPSG.html <https://svn.osgeo.org/geotools/trunk/licenses/EPSG.html>
> 
> This is an old version of EPSG terms of use. Current version is https://epsg.org/terms-of-use.html <https://epsg.org/terms-of-use.html>
> 
> Compared to the old version, the new version explains in more details what kinds of changes we are allowed to do. In brief we are allowed to do some changes, but not any changes; they provide a table listing what we can do. This restriction is based on a good intention: the changes shall not alter the result of coordinate operations, otherwise (in worst case) safety could be compromised. Other conditions worth to note are:
> 
> * (…snip…) any use of the EPSG Facilities (…snip…), even if obtained
>   without clicking acceptance, will be acceptance of these Terms of Use.
> * You are obliged to inform anyone to whom you provide the EPSG
>   Facilities of these Terms of Use.
> 
> In other words, even if we obtained the EPSG data in another way than direct download from EPSG web site (e.g. if we obtained the EPSG data through PROJ4 CSV files), the EPSG terms of use still apply.
> 
> 
>> Concretely, does this mean that we could include a couple of EPSGs (not the full database) without concern? In Baremaps, we mainly require EPSG:4326 and EPSG:3857. It not yet clear to me if we can import proj4j and exclude parts of the EPSG database.
>> 
> In Apache SIS I took the risk of including a hard-coded definition of EPSG::4326 used as a fallback if the EPSG dataset is not installed, because that code is so widely used. I included a few other codes as well. I hope that they fall under the "Fair Use" exception, which is allowed by U.S. law [1]. However this is my uneducated interpretation and I may very well be wrong.
> 
> [1]https://www.copyright.gov/help/faq/faq-fairuse.html <https://www.copyright.gov/help/faq/faq-fairuse.html>
> 
> 
>> In the context of a cli, I would prefer to find a solution where the user is not prompted to accept the terms of the EPSG license. For instance, could we have a command (e.g. ./baremaps non-free) that downloads these jars in the lib folder?
>> 
> I don't know. We can ask for advice by opening a JIRA issue on https://issues.apache.org/jira/projects/LEGAL/ <https://issues.apache.org/jira/projects/LEGAL/>
> 
> For making the task easier for legal volunteers, we should not go in details of what is EPSG. Just said that it is a widely used dataset, that the license is classified Category X by Apache (with a link to the license on EPSG web site) and maybe said that a similar issue was discussed in https://issues.apache.org/jira/browse/LEGAL-183 <https://issues.apache.org/jira/browse/LEGAL-183> and resolved by prompting users (when SIS is used as an application) or requiring developers to add themselves a Maven dependency (when SIS is used as a library).
> 
> They may ask that EPSG data are not downloaded from an Apache server. Preference may be let users download themselves from EPSG web site, but I agree that it is so unconvenient (we have to open an account) that not many users will do that. In Apache SIS case, the data are downloaded from Maven Central.
> 
> 
>> I think the Eclipse Foundation did an exception for the locationtech group. According to their FAQ [2] they asked the permission to redistribute some pervasive dependencies in geospatial projects: “We can re-distribute the binaries for certain components. We do have explicit permission to re-distribute Geotools, JTS, and GEOS.”.
>> 
> In the case of Geotools, I guess Eclipse accepted the LGPL license. JTS was also used to have a non-compatible license, but they changed a few years ago to a more permissive one, so the exception may not apply anymore. I'm not sure they were aware of EPSG Terms of Use when they granted exception.
> 
> Anyway, there is nothing wrong in distributing EPSG data in an application, provided that we include EPSG terms in the license folder. Whether a foundation (Apache, Eclipse, Linux distribution…) accepts EPSG license is a matter of foundation policy. Each organization, or each individual, can choose their own policy regarding which licenses to accept.
> 
>     Martin
> 

Re: Draft of the release process

[Bertil Chapuis <bc...@gmail.com>]

Hello Everyone,

Following the exchanges we had with Calvin on GitHub, I added a DISCLAIMER-WIP file to the pull request. As the latest release is pretty far from what we have on the main branch, I'd like to merge this PR and perform an intermediary release (v0.7.1). Is it possible to publish this kind of release?

Also, we still need to address several issues to comply with Apache guidelines and I was wondering how we could share some of this work. For instance, we need to add license headers to all the javascript files in the basemap and in the examples. We also need to figure out how minified javascript resources should be integrated in the project (as resources in the jar or as resources downloaded from a CDN). If you don't have much time, that's okay, but are there some small tasks such as these ones or those listed in #492 that you would be interested to take on?

Best,

Bertil


> On 5 Feb 2023, at 13:07, Bertil Chapuis <bc...@gmail.com> wrote:
> 
> Hello Everyone,
> 
> I hope you are doing well. I guess we all have been very busy lately ;-) So let me resume this thread.
> 
> Most of the issues reported in this thread have been addressed [1] or added to the release checklist [2]. The main one being the inclusion of a DISCLAIMER-WIP file to the release until we are fully conform to Apache’s standards. From what I understand, this should allow us to make releases, even if we haven’t completely resolved the proj4j issue in Baremaps yet.
> 
> Please, do not hesitate to provide feedbacks, report issues, or even to commit in the 492-release branch.
> 
> Best,
> 
> Bertil
> 
> [1] https://github.com/apache/incubator-baremaps/pull/535
> [2] https://github.com/apache/incubator-baremaps/issues/492
> [3] https://github.com/apache/incubator-baremaps/releases/tag/v0.7.1-rc3
> 
>> On 23 Nov 2022, at 00:19, Martin Desruisseaux <ma...@geomatys.com> wrote:
>> 
>> Hello Bertil
>> 
>> Le 22/11/2022 à 21:47, Bertil Chapuis a écrit :
>> 
>>> The terms of the EPSG license are restrictive [1]: The data may not be distributed for profit by any third party. I’m quite amazed to discover that most geospatial solutions out there are probably violating this license.
>>> 
>> Yes. In the case of PROJ version 6 and later, complying to the license would be just a matter of releasing PROJ under MIT + EPSG terms of use, not MIT alone. Because PROJ is used by GDAL, QGIS and PostGIS (among others), the issue apply to all those software as well and could be resolved in the same way. But my understanding is that adding EPSG Terms of Use would cause problems for packaging QGIS and PostGIS in some Linux distributions (it is a matter of license policy, like the policy we have at Apache), which is why PROJ maintainers are reluctant to address the issue.
>> 
>> For PROJ version 4, the situation is more tricky because that old version modified the EPSG dataset, notably by changing axis order to (longitude, latitude). The EPSG license does not allow such modifications (because they change the numerical results of coordinate operations), or at least not under "EPSG" namespace. So PROJ4 and PROJ4J are more difficult to resolve. PROJ version 6 and later are better because since version 6, PROJ respects EPSG data integrity.
>> 
>> 
>>> [1]https://svn.osgeo.org/geotools/trunk/licenses/EPSG.html
>> 
>> This is an old version of EPSG terms of use. Current version is https://epsg.org/terms-of-use.html
>> 
>> Compared to the old version, the new version explains in more details what kinds of changes we are allowed to do. In brief we are allowed to do some changes, but not any changes; they provide a table listing what we can do. This restriction is based on a good intention: the changes shall not alter the result of coordinate operations, otherwise (in worst case) safety could be compromised. Other conditions worth to note are:
>> 
>> * (…snip…) any use of the EPSG Facilities (…snip…), even if obtained
>>   without clicking acceptance, will be acceptance of these Terms of Use.
>> * You are obliged to inform anyone to whom you provide the EPSG
>>   Facilities of these Terms of Use.
>> 
>> In other words, even if we obtained the EPSG data in another way than direct download from EPSG web site (e.g. if we obtained the EPSG data through PROJ4 CSV files), the EPSG terms of use still apply.
>> 
>> 
>>> Concretely, does this mean that we could include a couple of EPSGs (not the full database) without concern? In Baremaps, we mainly require EPSG:4326 and EPSG:3857. It not yet clear to me if we can import proj4j and exclude parts of the EPSG database.
>>> 
>> In Apache SIS I took the risk of including a hard-coded definition of EPSG::4326 used as a fallback if the EPSG dataset is not installed, because that code is so widely used. I included a few other codes as well. I hope that they fall under the "Fair Use" exception, which is allowed by U.S. law [1]. However this is my uneducated interpretation and I may very well be wrong.
>> 
>> [1]https://www.copyright.gov/help/faq/faq-fairuse.html
>> 
>> 
>>> In the context of a cli, I would prefer to find a solution where the user is not prompted to accept the terms of the EPSG license. For instance, could we have a command (e.g. ./baremaps non-free) that downloads these jars in the lib folder?
>>> 
>> I don't know. We can ask for advice by opening a JIRA issue on https://issues.apache.org/jira/projects/LEGAL/
>> 
>> For making the task easier for legal volunteers, we should not go in details of what is EPSG. Just said that it is a widely used dataset, that the license is classified Category X by Apache (with a link to the license on EPSG web site) and maybe said that a similar issue was discussed in https://issues.apache.org/jira/browse/LEGAL-183 and resolved by prompting users (when SIS is used as an application) or requiring developers to add themselves a Maven dependency (when SIS is used as a library).
>> 
>> They may ask that EPSG data are not downloaded from an Apache server. Preference may be let users download themselves from EPSG web site, but I agree that it is so unconvenient (we have to open an account) that not many users will do that. In Apache SIS case, the data are downloaded from Maven Central.
>> 
>> 
>>> I think the Eclipse Foundation did an exception for the locationtech group. According to their FAQ [2] they asked the permission to redistribute some pervasive dependencies in geospatial projects: “We can re-distribute the binaries for certain components. We do have explicit permission to re-distribute Geotools, JTS, and GEOS.”.
>>> 
>> In the case of Geotools, I guess Eclipse accepted the LGPL license. JTS was also used to have a non-compatible license, but they changed a few years ago to a more permissive one, so the exception may not apply anymore. I'm not sure they were aware of EPSG Terms of Use when they granted exception.
>> 
>> Anyway, there is nothing wrong in distributing EPSG data in an application, provided that we include EPSG terms in the license folder. Whether a foundation (Apache, Eclipse, Linux distribution…) accepts EPSG license is a matter of foundation policy. Each organization, or each individual, can choose their own policy regarding which licenses to accept.
>> 
>>     Martin
>> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@baremaps.apache.org
For additional commands, e-mail: dev-help@baremaps.apache.org