asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahmed Eldawy <eld...@cs.ucr.edu>
Subject Re: License issue when using esri geometry api
Date Mon, 26 Jun 2017 09:59:44 GMT
It seems that (3) would require modifying the open source Esri API library
which I don't like. Not only for the overhead of understanding and
modifying the code, but also for deviating from the standard library which
means we will miss future updates. One of the reasons we chose to use Esri
API is the hope that it will be well-maintained in the future.
This leaves us with (4). I don't know if it is technically possible to
depend on the standard Esri API without using the non-compliant library or
not. If this is possible, then we can just use the computational geometry
(CG) functionality from the library, and provide our own GeoJSON parser. If
this is not possible, then I would rather consider the use of another
library, e.g., JTS.


Thanks
Ahmed

On Sun, Jun 25, 2017 at 11:47 AM, Wail Alkowaileet <wael.y.k@gmail.com>
wrote:

> I can see from the code that there is a serder steps as such: Asterix
> Object (binary) --> JSON (String) --> Esri geometry (Java object) --> Esri
> geometry (binary).
> I think it would be nice if there is a binary-to-binary conversion without
> any deserialization (4th option).
>
> On Sun, Jun 25, 2017 at 6:36 PM, Mike Carey <dtabass@gmail.com> wrote:
>
> > Agreed that 3 or 4 are what we'll need to do....!  (Sigh.)
> >
> >
> >
> > On 6/25/17 5:57 AM, Till Westmann wrote:
> >
> >> Hi Riyafa,
> >>
> >> I think that the problem is bigger than the failing test. The JSON
> >> license itself is not acceptable for inclusion in an Apache artifact
> >> [4]. So we cannot use the ESRI API as-is, if we want the GeoJSON
> >> functionality be a non-optional part of AsterixDB.
> >>
> >> Here are a few options I see:
> >> 1) Make GeoJSON an optional part of AsterixDB (separate download from a
> >>    non-Apache location).
> >> 2) Make JSON.org a dependency that is not shipped (i.e. each user would
> >>    have to download and install those jars separately - and get error
> >>    messages if the jars are not available).
> >> 3) Create a clone/copy of the ESRI API that uses another JSON library.
> >> 4) Do all of the parsing independently from the ESRI API.
> >>
> >> I’m not sure if 1) is a good option as the extensibility in this part
> >> of the code might not be sufficient to support this option easily.
> >> 2) is technically easier, but it involves an unpleasant user
> >> experience.
> >> Also, I think that both 1) and 2) are not desirable, as GeoJSON should
> >> be supported by vanilla AsterixDB.
> >> For 3) and 4) we would need to look into the details to see how much
> >> work is required for each of those options and if there are other legal
> >> hurdles.
> >>
> >> Are there other options?
> >> Other thoughts/concerns?
> >>
> >> Cheers,
> >> Till
> >>
> >> [4] https://www.apache.org/legal/resolved.html#category-x
> >>
> >> On 25 Jun 2017, at 13:57, Riyafa Abdul Hameed wrote:
> >>
> >> Dear all,
> >>>
> >>> I implemented parse_geojon() function[1] using esri-geometry api[2]
> which
> >>> is apache-2.0 licensed. But this api uses org.json as a dependency.
> >>> org.json is licensed under JSON which causes a license issue in the
> code
> >>> I
> >>> have written[3]. What can I do about this issue?
> >>>
> >>> [1] https://asterix-gerrit.ics.uci.edu/1838
> >>> [2]https://github.com/Esri/geometry-api-java
> >>> [3]
> >>> https://asterix-jenkins.ics.uci.edu/job/asterix-gerrit-integ
> >>> ration-tests/3290/
> >>>
> >>> Thank you.
> >>> Yours sincerely,
> >>> Riyafa
> >>>
> >>
> >
>
>
> --
>
> *Regards,*
> Wail Alkowaileet
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message