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 Sat, 29 Jul 2017 05:28:55 GMT
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/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
View raw message