asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Till Westmann" <ti...@apache.org>
Subject Re: License issue when using esri geometry api
Date Tue, 05 Sep 2017 04:43:19 GMT
Indeed, that’s very good news.

Cheers,
Till

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

> Nice!
>
>
> On 9/3/17 11:44 PM, Riyafa Abdul Hameed wrote:
>> 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 
>> <riyafa.12@cse.mrt.ac.lk>
>> 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 <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
View raw message