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 Fri, 21 Jul 2017 20:29:22 GMT
Although Esri resolved the issue, their Maven-released version still relies
on the incompatible library. We can wait until they release a new version
on Maven but this might take a while. To be able to merge the current code,
we might need to compile our own JAR file and ship it with the source code.
Do you know if this is possible/allowed/recommended in AsterixDB? Is there
another preferred way to handle this issue? Keep in mind that, most likely,
the summer project will conclude before Esri releases the new version.

Thanks
Ahmed

On Tue, Jul 11, 2017 at 11:04 AM, Mike Carey <dtabass@gmail.com> wrote:

> NICE!!!
>
>
>
> On 7/11/17 9:39 AM, Ahmed Eldawy wrote:
>
>> There's a good news. Riyafa has opened an issue on ESRI Geometry API
>> project on Github about the license problem and they made the necessary
>> changes to remove the bad dependency.
>> https://github.com/Esri/geometry-api-java/issues/135
>> The changes are on their github repository but they are not released yet.
>> I
>> think we can just continue what we're doing and wait for the new release
>> to
>> hit Maven repository.
>>
>> Thanks
>> Ahmed
>>
>> On Mon, Jun 26, 2017 at 7:55 AM, Mike Carey <dtabass@gmail.com> wrote:
>>
>> 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
>>>>>
>>>>>
>>>>>
>>
>


-- 

Ahmed Eldawy
Assistant Professor
http://www.cs.ucr.edu/~eldawy
Tel: +1 (951) 827-5654

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