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 Tue, 11 Jul 2017 18:04:15 GMT
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
>>>>
>>>>
>


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