[PROJ] OSGeo incubation status

[Kristian Evers]

Bas,

That's not good! Thanks for looking into this. We will have to find a solution
to this.

> He also strongly urged us to
> separate code and data, i.e. don't include the SQL files in the source
> tree nor build the database as part of the build process.

I think this is easier said than done. Even, is this a realistic option?

> Alternatively we need to convince IOPG to dual license the EPSG data
under and DFSG compatible license.

This is obviously the best option. As far as I am aware all attempts so far
has been rejected by the IOGP. We can always try again, this time including
a thorough analysis of the effects of PROJ not being able to provide access
to the EPSG registry in a simple fashion. I suspect that PROJ indirectly is by
far one of the biggest consumers of the registry. Maybe that can provide
a bit of leverage?

/Kristian

-----Original Message-----
From: PROJ <proj-bounces at lists.osgeo.org> On Behalf Of Sebastiaan Couwenberg
Sent: 24. januar 2020 10:39
To: proj at lists.osgeo.org
Subject: Re: [PROJ] OSGeo incubation status

On 9/10/19 1:50 PM, Sebastiaan Couwenberg wrote:
> On 9/10/19 1:16 PM, Martin Desruisseaux wrote:
>> On EPSG, can we really said that the data fail under MIT license because
>> we do not modify it? The EPSG terms of use said:
>>
>>> You are obliged to inform anyone to whom you provide the EPSG
>>> Facilities of these Terms of Use.
>> So we need to inform users that they can not modify those data without
>> changing the EPSG name. And also that they can not extract the data and
>> sell them alone (without the added value of PROJ or other software).
>> Those conditions are not MIT terms.
> 
> Unless PROJ already modifies the data and doesn't attribute it to the
> EPSG dataset. There is no epsg init file any more, there is proj.db now.
> 
> Not being a lawyer I cannot provide an authoritative answer, only my
> interpretation.
> 
>> The Apache Software Foundation legal team has debated about the
>> permission to include EPSG data in Apache software [3], and our
>> conclusion was that we can not provide them directly. We do that
>> indirectly by providing the data in a "non-free" package and require an
>> explicit action from users (which we try to make as simple as possible)
>> to get them.
> 
> I hope we can prevent this situation with proj, as we'll revert back to
> the one with libgeotiff-epsg which few users installed despite needing it.
> 
> In the worst case scenario proj moves to non-free and everything that
> depends on it to contrib, making them not part of Debian and loose QA
> coverage, autobuilding and the like. This would be very harmful to users.
> 
> I would stick to the working theory until IOGP complains and proves us
> otherwise.

There was an event about the new Dutch grids yesterday, there I spoke
with Roel Nicolai who has been involved with EPSG since the beginning
and drafted the EPSG TOU. He told me that my interpretation of the terms
is incorrect, the MIT license cannot be applied to the SQL files derived
from the EPSG data as done currently. He also strongly urged us to
separate code and data, i.e. don't include the SQL files in the source
tree nor build the database as part of the build process.

To resolve this issue without making PROJ non-free with the adverse
ripple effect on all its dependent projects, we should implement a
process similar to Apache SIS.

Alternatively we need to convince IOPG to dual license the EPSG data
under and DFSG compatible license.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
PROJ mailing list
PROJ at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj