Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Pig >> mail # dev >> A major addition to Pig. Working with spatial data

Copy link to this message
Re: A major addition to Pig. Working with spatial data
If a way could be found, this would be an awesome addition to Pig.

Russell Jurney http://datasyndrome.com

On May 3, 2013, at 4:09 PM, Daniel Dai <[EMAIL PROTECTED]> wrote:

> I am not sure how other Apache projects dealing with it? Seems Solr also
> has some connector to JTS?
> Thanks,
> Daniel
> On Thu, May 2, 2013 at 11:59 AM, Ahmed Eldawy <[EMAIL PROTECTED]> wrote:
>> Thanks Alan for your interest. It's too bad that an open source licensing
>> issue is holding me back from doing some open source work. I understand the
>> issue and your workarounds make sense. However, as I mentioned in the
>> beginning, I don't want to have my own branch of Pig because it makes my
>> extension less portable. I'll think of another way to do it. I'll ask vivid
>> solutions if they can double license their code although I think the answer
>> will be no. I'll also think of a way to ship my extension as a set of jar
>> files without the need to change the core of Pig. This way, it can be
>> easily ported to newer versions of Pig.
>> Thanks
>> Ahmed
>> Best regards,
>> Ahmed Eldawy
>> On Thu, May 2, 2013 at 12:33 PM, Alan Gates <[EMAIL PROTECTED]> wrote:
>>> I know this is frustrating, but the different licenses do have different
>>> requirements that make it so that Apache can't ship GPL code.  A legal
>>> explanation is at http://www.apache.org/licenses/GPL-compatibility.htmlFor additional info on the LGPL specific questions see
>>> http://www.apache.org/legal/3party.html
>>> As far as pulling it in via ivy, the issue isn't so much where the code
>>> lives as much as what code we are requiring to make Pig work.  If
>> something
>>> that is [L]GPL is required for Pig it violates Apache rules as outlined
>>> above.  It also would be a show stopper for a lot of companies that
>>> redistribute Pig and that are allergic to GPL software.
>>> So, as I said before, if you wanted to continue with that library and
>> they
>>> are not willing to relicense it then it would have to be bolted on after
>>> Apache Pig is built.  Nothing stops you from doing this by downloading
>>> Apache Pig, adding this library and your code, and redistributing, though
>>> it wouldn't then be open to all Pig users.
>>> Alan.
>>> On May 1, 2013, at 6:08 PM, Ahmed Eldawy wrote:
>>>> Thanks for your response. I was never good at differentiating all those
>>>> open source licenses. I mean what is the point making open source
>>> licenses
>>>> if it blocks me from using a library in an open source project. Any
>> way,
>>>> I'm not going into debate here. Just one question, if we use JTS as a
>>>> library (jar file) without adding the code in Pig, is it still a
>>> violation?
>>>> We'll use ivy, for example, to download the jar file when compiling.
>>>> On May 1, 2013 7:50 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:
>>>>> Passing on the technical details for a moment, I see a licensing
>> issue.
>>>>> JTS is licensed under LGPL.  Apache projects cannot contain or ship
>>>>> [L]GPL.  Apache does not meet the requirements of GPL and thus we
>> cannot
>>>>> repackage their code. If you wanted to go forward using that class
>> this
>>>>> would have to be packaged as an add on that was downloaded separately
>>> and
>>>>> not from Apache.  Another option is to work with the JTS community and
>>> see
>>>>> if they are willing to dual license their code under BSD or Apache
>>> license
>>>>> so that Pig could include it.  If neither of those are an option you
>>> would
>>>>> need to come up with a new class to contain your spatial data.
>>>>> Alan.
>>>>> On May 1, 2013, at 5:40 PM, Ahmed Eldawy wrote:
>>>>>> Hi all,
>>>>>> First, sorry for the long email. I wanted to put all my thoughts here
>>>>> and
>>>>>> get your feedback.
>>>>>> I'm proposing a major addition to Pig that will greatly increase its
>>>>>> functionality and user base. It is simply to add spatial support to
>> the
>>>>>> language and the framework. I've already started working on that but