asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Riyafa Abdul Hameed <riyafa...@cse.mrt.ac.lk>
Subject Re: License issue when using esri geometry api
Date Sun, 30 Jul 2017 02:28:55 GMT
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 <tillw@apache.org> 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 <eldawy@cs.ucr.edu> 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 <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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Riyafa Abdul Hameed
>>>> Undergraduate, University of Moratuwa
>>>>
>>>> Email: riyafa.12@cse.mrt.ac.lk
>>>> 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: riyafa.12@cse.mrt.ac.lk
Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/>
<http://facebook.com/riyafa.ahf>  <http://lk.linkedin.com/in/riyafa>
<http://twitter.com/Riyafa1>

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