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 Thu, 27 Jul 2017 16:23:42 GMT
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