asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: License issue when using esri geometry api
Date Mon, 26 Jun 2017 14:55:22 GMT
It sounds like the best option is 4 minus parsing, then, if we can do 
that.  (Which would also address Wail's comments, which could be a 
killer for big data eventually.)  If not, we could go with 2 for the 
summer as a first step, I guess?  (But figuring out the feasibility of 4 
would be great...)

Cheers,

Mike


On 6/26/17 2:59 AM, Ahmed Eldawy wrote:
> 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