If neo4j was LGPL, I'd agree with this. You could create an Apache Licensed
wrapper around it and depend on the ASL'd library and not be infected.
However, it's the full GPL. Thus, you cannot "link" to anything in it without
the GPL then infecting your code. The wrapper would no longer be Apache
Licensed. It would be GPL'd.
I'd definitely move this to camel-extra. It's not worth taking the chance on
any sort of license/legal problem.
Dan
On Mar 27, 2013, at 12:46 PM, Christian Ohr <christian....@gmail.com> wrote:
> Thanks, Hadrian, for some insight here.
>
> One key issue is that the dependency on a GPL lib is most likely not a
> problem as long as Camel doesn't actually distributes the lib (e.g. the
> scope of the dependency is set on "optional" or "provided").
> The user of camel-neo4j (or in this case spring-data-neo4j) would of course
> need to physically download the lib again (using Maven or other means) in
> order to make the code run... Additionally, he might make the wrong
> assumption that redistributing his software with the lib would be o.k.,
> which is only true under the conditions the GPL imposes although it's
> hidden under layers of ASLv2 libs.
>
> And this is what spring-data-neo4j does - the distribution does not contain
> neo4j jars so from a legal side this is probably safe, but the docs are
> pretty unspecific about redistributing its dependencies ("Neo4j is released
> under a dual free software/commercial license model.")
>
> Camel could do something similar (i.e. exclude neo4j and let its users deal
> with the licensing issues), but I guess moving it to camel-extra would
> really be preferable..
>
> cheers
> Christian
>
>
> 2013/3/27 Hadrian Zbarcea <hzbar...@gmail.com>
>
>> 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<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)..<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.ib...@gmail.com>
>>>
>>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <rajdav...@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<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.ji...@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<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>(
>>>>>> 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: cib...@redhat.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.com
>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>>
>>>>
>>>
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
