Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of hzbarcea@gmail.com designates
 209.85.214.174 as permitted sender)
Message-ID: <51531A8F.8010609@gmail.com>
Date: Wed, 27 Mar 2013 12:13:03 -0400
From: Hadrian Zbarcea <hzbarcea@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [HEADS-UP] Possible issue with neo4j
References: <51524AD0.6030109@gmail.com>
 <1B583C2CD65944F29F5C561D5AD255E2@gmail.com>
 <E4FB0237-6DCE-4759-892A-06A247BF0CE8@gmail.com>
 <CAGB5yNmzWnPd6=GPwKYc39W8qqosyp+G5YzWARBbTuFDXr5xnA@mail.gmail.com>
 <CAEhQ+8_=3NeZMhERraUmeh+WYKm+3ox6jwNyi4AZiFvysG3BUg@mail.gmail.com>
In-Reply-To: 
 <CAEhQ+8_=3NeZMhERraUmeh+WYKm+3ox6jwNyi4AZiFvysG3BUg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Christian,

Thanks for making the point. The governance you are talking about is in 
place not only for the Camel project, but *all* Apache projects and is 
one of the reason the ASF exists.

Granted, the neo4j issue slipped through our fingers for a bit. Luckily 
we caught it before a release. This is one of the things I like about 
the ASF projects: with so many eyes on the projects, somebody is bound 
to spot problems at some point, hopefully earlier. For all the major 
contributions you will find comments showing that at least a PMC member 
verified the licensing (Christian, Claus, myself, to name a few, but 
others as well).

To be fair, Christian Mueller did check the licensing for the 
dependencies and added a comment to the jira back on Aug 6th. His 
problem was that he trusted springsource to do the right thing, but did 
not verify the downstream dependencies. I remember looking into too, 
obviously not closely enough, I guess I trusted too much Christian's 
German pedigree :), and assumed the situation to resemble mongodb.

FWIW, the mongodb licensing was *designed* to allow the inclusion of the 
binding into other projects (oss or not) *without* virally infecting 
them. I remember ages ago, gridgain changed to a similar model at our 
request (James, iirc), although sadly we ended up not having a gridgain 
component. Since the binding has no value by itself and would require a 
deployment of the GPL project, it's a smart move that extends the reach 
of the GPL project.

The reason I caught is is because of something similar happening in 
Shindig, who, like us, thought about using spring-data-neo4j as a 
shield. So I got to talk to Ate, a fellow ASFer, looked closer at the 
dependency tree and realized the the shield does not work. We do exclude 
a neo4j dependency in the pom:
         <exclusion>
           <groupId>org.neo4j</groupId>
           <artifactId>neo4j-cypher-dsl</artifactId>
         </exclusion>
... but others still remain. Even if we excluded *all* the neo4j 
dependencies (assuming the component would work, which it won't) it's 
still not ok, because spring-data-neo4j couldn't have been released as 
ALv2 in the first place (imho, ianal) because of the viral nature of gpl.

That said, although both me and Ate are pretty sure we know what the 
answer will be, we decided to raise the issue to the legal team, to get 
it on the record and for future reference. There is a thread going on on 
the public legal-discuss@ list [1] and an open jira [2] as well. (It's 
not as clear what the answer would be about lgpl, but we'll tackle that 
later).

I hope this helps,
Hadrian


[1] http://s.apache.org/l162
[2] https://issues.apache.org/jira/browse/LEGAL-162


On 03/27/2013 11:36 AM, Christian Ohr wrote:
> Hi,
>
> I'm frequently doing license compliance exercises at work, and an ASL2
> project depending on a (A)GPL lib  is clearly *very* troublesome due to
> GPL's 'viral' character of imposing licensing conditions to derivative
> work. Regardless of whether this dependency is direct or transitive.
>
> Things can be subtle, though, e.g. MongoDB is also (A)GPL, but the
> mongo-java-driver that camel-mongodb depends upon is ASL2 (
> https://github.com/mongodb/mongo-java-driver/blob/master/LICENSE.txt)....
>
> Still I think the Camel project needs to establish some kind of governance
> to make sure that contributions of new components don't result in license
> compliance violations.
>
> cheers
> Christian
>
>
> 2013/3/27 Claus Ibsen <claus.ibsen@gmail.com>
>
>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <rajdavies@gmail.com>
>> wrote:
>>> Just looking at the spring-data-neo4 (which is ASL 2) - it uses directly
>> org.neo4j.graphdb directly - which is an (A)GPLv3 licence.
>>> I agree with Hadrian, we would be infecting users of camel-spring-neo4j
>> with (A)GPLv3 - which is very undesirable. Unless I've missed a different
>> licence for the client-side piece of neo4j that meets with our licence
>> restrictions[2] - it should be moved to camel-extra with appropriate
>> warnings.
>>>
>>> thanks,
>>>
>>> Rob
>>>
>>> [2]http://www.apache.org/legal/3party.html
>>>
>>
>> Yeah if it uses directly a JAR that is GPL then its a problem.
>>
>> Great catch Hadrian just in time. We haven't done any releases with
>> this camel-spring-neo4j component.
>> So we should move it to camel-extra.
>>
>>
>>
>>
>>> On 27 Mar 2013, at 02:18, Willem jiang <willem.jiang@gmail.com> wrote:
>>>
>>>> Hi Hadrian,
>>>>
>>>> We don't use the neo4j directly, the camel-spring-neo4j is based on the
>> spring-data-neo4j[1] which is ASF license.
>>>> I'm not quite sure if it is OK for us to host and distribute the
>> camel-spring-neo4j in ASF, so please let us know the result :)
>>>>
>>>> [1]
>> https://github.com/SpringSource/spring-data-neo4j/blob/master/license.txt
>>>>
>>>> --
>>>> Willem Jiang
>>>>
>>>> Red Hat, Inc.
>>>> FuseSource is now part of Red Hat
>>>> Web: http://www.fusesource.com | http://www.redhat.com
>>>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/)
>> (English)
>>>>           http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>>>> Twitter: willemjiang
>>>> Weibo: 姜宁willem
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wednesday, March 27, 2013 at 9:26 AM, Hadrian Zbarcea wrote:
>>>>
>>>>> I've been asked today by a fellow ASFer if it's ok for us to distribute
>>>>> neo4j and I got to look more into it. As neo4j is GPL3 and virally
>>>>> infects whatever uses it, I think we do have a problem that needs to be
>>>>> resolved before the 2.11.0 release.
>>>>>
>>>>> My guts instinct says that we'll have to pull the camel-spring-neo4j
>>>>> component out and host it maybe at camel-extra, but we'll see in the
>>>>> coming days.
>>>>>
>>>>> Cheers,
>>>>> Hadrian
>>>>>
>>>>>
>>>>> --
>>>>> Hadrian Zbarcea
>>>>> Principal Software Architect
>>>>> Talend, Inc
>>>>> http://coders.talend.com/
>>>>> http://camelbot.blogspot.com/
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: cibsen@redhat.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
>