Subject: Re: License issue when using esri geometry api

From: Riyafa Abdul Hameed <[email-masked]>
Date: Mon, 4 Sep 2017 12:14:13 +0530

Hi,

Esri geometry-api version 2.0.0 have been released in maven central[1]. Now
I am able to use it without any license issues[2].

[1] https://github.com/Esri/geometry-api-java/issues/140
[2] https://asterix-gerrit.ics.uci.edu/#/c/1838

Thank you.
Sincerely,
Riyafa

On 30 July 2017 at 07:58, Riyafa Abdul Hameed <[email-masked]>
wrote:

> Hi Till,
>
> Thank you. You seem to have followed the option 2). I didn't understand
> how to get along with option 1). I wanted to ask with Ahmed about it and
> get back.
> I have no idea when they will release so I asked a question[1] though I
> didn't get an answer for that.
>
> Thank you.
> Sincerely,
> Riyafa
>
> [1] https://github.com/Esri/geometry-api-java/issues/140
>
> On 29 July 2017 at 10:58, Till Westmann <[email-masked]> wrote:
>
>> Hi Riyafa,
>>
>> I’ve uploaded another commit to your change [4] that shows what option 2)
>> would look like.
>> Please take a look and see what you think.
>> I think that this could only be a temporary solution.
>> Do you have an idea, when Esri might publish a new version of the API?
>>
>> Cheers,
>> Till
>>
>> [4] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>
>>
>> On 27 Jul 2017, at 10:13, Mike Carey wrote:
>>
>> +1 on option 1 for now, I would say (from afar :-)), until ESRI finishes
>>> resolving stuff on their end.
>>>
>>> Aloha,
>>>
>>> Mike
>>>
>>>
>>> On 7/27/17 6:23 AM, Till Westmann wrote:
>>>
>>>> Hi,
>>>>
>>>> I’m sorry for the late reply on the subject.
>>>>
>>>> Generally, Apache-releases are source releases [3] and so adding a
>>>> precompiled jar without sources would prevent us from being able to
>>>> release AsterixDB. So we will have to find another solution.
>>>>
>>>> A few options that I can think of right now would be to
>>>> 1) make it an optional dependency and require the user to
>>>> require/obtain the jar external and to provide it to the platform that
>>>> they build on or to
>>>> 2) include the source files in the AsterixDB source repository or to
>>>> 3) download and build the source as part of the build process.
>>>>
>>>> Of these 3 options, I think that 1) is the cleanest option from a
>>>> licensing perspective, 2) can be managed if we understand the
>>>> provenance of the source files and 3) seems problematic as we would put
>>>> a load on a system that provide the source for every build and as we
>>>> could retrieve use unvetted source code.
>>>>
>>>> Thoughts/concerns about these options?
>>>> Does anybody see other options?
>>>>
>>>> Cheers,
>>>> Till
>>>>
>>>> [3] http://www.apache.org/legal/release-policy.html#artifacts
>>>>
>>>> On 27 Jul 2017, at 7:21, Riyafa Abdul Hameed wrote:
>>>>
>>>> Dear all,
>>>>>
>>>>> Is there a way to ship a jar file as a dependency for AsterixDB apart
>>>>> from
>>>>> the method I have used here[1]. This is because the build of
>>>>> asterix-app
>>>>> seems to fail[2] when I use the external jar file like this.
>>>>> Though I am unable to find a connection between the failure and the
>>>>> dependency it seems I need to assume that it is the cause, because
>>>>> otherwise if I use the Maven-released version the build passes without
>>>>> issue.
>>>>>
>>>>> Any help would be highly appreciated.
>>>>> [1]
>>>>> https://asterix-gerrit.ics.uci.edu/#/c/1895/3/asterixdb/aste
>>>>> rix-om/pom.xml
>>>>> [2] https://asterix-gerrit.ics.uci.edu/#/c/1895
>>>>>
>>>>> On 22 July 2017 at 01:59, Ahmed Eldawy <[email-masked]> wrote:
>>>>>
>>>>> 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 <[email-masked]>
>>>>>> 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 <[email-masked]>
>>>>>>>> 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 <
>>>>>>>>>>
>>>>>>>>> [email-masked]>
>>>>>>
>>>>>>> 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 <[email-masked]>
>>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Riyafa Abdul Hameed
>>>>> Undergraduate, University of Moratuwa
>>>>>
>>>>> Email: [email-masked]
>>>>> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
>>>>> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa>
>>>>> <http://twitter.com/Riyafa1>
>>>>>
>>>>
>
>
> --
> Riyafa Abdul Hameed
> Undergraduate, University of Moratuwa
>
> Email: [email-masked]
> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
> <http://facebook.com/riyafa.ahf>  <http://lk.linkedin.com/in/riyafa>
> <http://twitter.com/Riyafa1>
>

-- 
Riyafa Abdul Hameed
Undergraduate, University of Moratuwa

Email: [email-masked]
Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
<http://facebook.com/riyafa.ahf>  <http://lk.linkedin.com/in/riyafa>
<http://twitter.com/Riyafa1>

---

From: Mike Carey <[email-masked]>
Date: Mon, 4 Sep 2017 08:37:34 -0700

Nice!

---

From: "Till Westmann" <[email-masked]>
Date: Mon, 04 Sep 2017 21:43:19 -0700

Indeed, that’s very good news.

Cheers,
Till

On 4 Sep 2017, at 8:37, Mike Carey wrote:

>>>>>>>>>>>>>>> [4] 
>>>>>>>>>>>>>>> https://www.apache.org/legal/resolved.html#category-x
>>>>>>>>>>>>>>>