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 Thu, 27 Jul 2017 17:13:57 GMT
+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/asterix-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>


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