www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: Licensing: exception for allowing Apache SIS to bundle EPSG data?
Date Wed, 16 Apr 2014 21:34:58 GMT
On Tue, Apr 15, 2014 at 6:04 PM, Martin Desruisseaux <
martin.desruisseaux@geomatys.fr> wrote:

> Le 15/04/14 19:05, Kevan Miller a écrit :
> > Clauses 6.3, 6.6, and 6.7 all describe restrictions on the EPSG data
> > -- and they pose problems for including EPSG in SIS.
> Clause 6.7 said that if the user changes the data in a "significant" way
> ("significant" being defined by clause 6.6), he shall not attribute the
> change to EPSG. In some scenarios it may be a matter of human life: if a
> public transportation claims to provide its geographic location
> according the Coordinate Reference System EPSG:4326, if it actually uses
> a "modified EPSG:4326", then the transport will not be where other
> peoples think it is, with all the risks we can imagine. The EPSG
> restriction allows users to change the data, provided that they use
> their own name.
>

I should not have included 6.7 in my list. My mistake.


> Apache license has a similar restriction: "This License does not grant
> permission to use the trade names, trademarks, service marks, or product
> names of the Licensor" (Apache clause 6). FAQ [1] is more explicit: "May
> I call my modified code 'Apache'?", the answer is "no". So why such
> restriction would be acceptable for Apache but not for EPSG, especially
> given the safety implications of EPSG data accuracy?
>
> To me, the EPSG restriction actually seems more flexible than the
> Apache's one :-), because clause 6.6 describes a set of changes that we
> can apply while retaining the "EPSG" name, while Apache license does not
> give any circumstance allowing users to name their modified code "Apache".
>
>
> > If EPSG was software, I would say that EPSG could not be included in
> > Apache SIS, because of these restrictions. I see no reason why we
> > should treat EPSG differently, because EPSG is "data".
> We can rewrite a new software complying to the same contract than the
> original one. But we can not "rewrite" data. For example the Unicode
> tables define "U+0041" as 'A' - there is no way we can create an "Apache
> Unicode" with the same meaning for codes. We could create new tables,
> but they would be incompatible with Unicode. Likewise the EPSG tables
> defines "EPSG:4326" as "World Geodetic System 1984" (together with other
> information). There is no way we can create Apache tables compatible
> with EPSG without copying the data.
>
>
> > So, my question to EPSG would be -- could you make EPSG data available
> > under a license which does not impose these restrictions on use,
> > modification, and redistribution?
> Would it be really responsible to ask for relaxing clause 6.6 and 6.7
> given the safety implications? Furthermore those clauses seem to me
> already more relax than Apache 2 license.
>
> If clause 6.6 and 6.7 are considered acceptable, that would leave only
> clause 6.3 as an open question.
>

Correct me if I'm wrong -- 6.6 means I can change the data, but only using
the techniques described in the table. If I want to change the data in some
other way, I cannot (without violating the terms of use).

6.3 means that I cannot strip off Apache SIS and sell the EPSG data.

Those are restrictions (on top of ALv2) which you would have to add to
Apache SIS. Agreed?

How is that more lax than ALv2?


> > If the answer is no, then the next question for SIS to ask is -- can
> > we make the EPSG data optional? And allow users to download the EPSG
> > data, themselves, if they desire?
> EPSG codes are close to ubiquitous in today geographic web services.
> Most users would likely be forced to download EPSG data before they can
> make non-trivial use of SIS. An additional complication is that new EPSG
> versions sometime requires an SIS code update (which may take some
> time), and EPSG does not provide public archives of their old versions.
>

Thanks for the info.

Mime
View raw message