You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2013/03/27 02:26:40 UTC
[HEADS-UP] Possible issue with neo4j
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/
Re: [HEADS-UP] Possible issue with neo4j
Posted by Raul Kripalani <ra...@evosent.com>.
On Wed, Mar 27, 2013 at 3:36 PM, Christian Ohr <ch...@gmail.com>wrote:
> 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)....
>
I too had some doubts at first, but the case is substantially different.
The MongoDB Java driver doesn't have any dependencies with other libraries
(see pom.xml [1]). Therefore no linkage exists. Just with TestNG – which is
ASL.
In other words, this driver is 100% self-encapsulating, and it's isolated
from MongoDB components or any other incompatible libraries.
[1] https://github.com/mongodb/mongo-java-driver/blob/master/pom.xml
Regards,
*Raúl Kripalani*
Enterprise Architect, Open Source Integration specialist, Program
Manager | Apache
Camel Committer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk
Re: [HEADS-UP] Possible issue with neo4j
Posted by Christian Müller <ch...@gmail.com>.
Ok, the spring-neo4j component is now in Camel extra.
I recreate the documentation in our Apache WIKI and added a link from the
Camel extra site. I did this, because all the other Camel extra components
are documented in this way. However, I think this has to be fixed in the
near future. The documentation for the Camel extra components has to be at
Camel extra. We may could allow a really simple page for each of these
components with a link to the Camel extra documentation. Will start working
on this if I find some time for it... I appreciate any help!
By the way, I also created a mailing list for the Camel extra project at
[1]. Feel free to join if you are interested in it.
[1] http://camel-extra.1091541.n5.nabble.com/
Best,
Christian
On Wed, Mar 27, 2013 at 9:40 PM, Christian Müller <
christian.mueller@gmail.com> wrote:
> I will move it to Camel extra by tomorrow.
> At present, I think it's the safest way.
> We should also not delay Camel 2.11. because of this.
>
> Sent from a mobile device
> Am 27.03.2013 17:23 schrieb "Hadrian Zbarcea" <hz...@gmail.com>:
>
> Christian,
>>
>> Personally, I'd go ahead and move it to camel-extra, *still* under the
>> ALv2 license. That would make it easier to move it back without relicensing
>> *if* at a later point neo4j would release a binding under ALv2. I don't
>> have any cycles this week but hopefully you or Henryk could find some time.
>>
>> Alternatively, we could wait for the comments to LEGAL-162, but would
>> rather save some time and not block the release for too long.
>>
>> My $0.02,
>> Hadrian
>>
>>
>> On 03/27/2013 12:09 PM, Christian Müller wrote:
>>
>>> Good catch Hadrian!
>>>
>>> I propose/support to move this component to Camel extra.
>>> We should also move to documentation [1] to Camel extra and update the
>>> Camel components page [2] with the new home of this component.
>>>
>>> I can do this/support if you want (I'm sick at home and have some time
>>> ;-)
>>> ).
>>>
>>> [1] http://camel.apache.org/neo4j
>>> [2] http://camel.apache.org/**components.html<http://camel.apache.org/components.html>
>>>
>>> Best.
>>> Christian
>>>
>>> On Wed, Mar 27, 2013 at 4:36 PM, Christian Ohr <ch...@gmail.com>
>>> **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 <cl...@gmail.com>
>>>>
>>>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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: cibsen@redhat.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus
>>>>> Blog: http://davsclaus.com
>>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>>>
>>>>>
>>>>
>>>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Christian Müller <ch...@gmail.com>.
I will move it to Camel extra by tomorrow.
At present, I think it's the safest way.
We should also not delay Camel 2.11. because of this.
Sent from a mobile device
Am 27.03.2013 17:23 schrieb "Hadrian Zbarcea" <hz...@gmail.com>:
> Christian,
>
> Personally, I'd go ahead and move it to camel-extra, *still* under the
> ALv2 license. That would make it easier to move it back without relicensing
> *if* at a later point neo4j would release a binding under ALv2. I don't
> have any cycles this week but hopefully you or Henryk could find some time.
>
> Alternatively, we could wait for the comments to LEGAL-162, but would
> rather save some time and not block the release for too long.
>
> My $0.02,
> Hadrian
>
>
> On 03/27/2013 12:09 PM, Christian Müller wrote:
>
>> Good catch Hadrian!
>>
>> I propose/support to move this component to Camel extra.
>> We should also move to documentation [1] to Camel extra and update the
>> Camel components page [2] with the new home of this component.
>>
>> I can do this/support if you want (I'm sick at home and have some time ;-)
>> ).
>>
>> [1] http://camel.apache.org/neo4j
>> [2] http://camel.apache.org/**components.html<http://camel.apache.org/components.html>
>>
>> Best.
>> Christian
>>
>> On Wed, Mar 27, 2013 at 4:36 PM, Christian Ohr <ch...@gmail.com>*
>> *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 <cl...@gmail.com>
>>>
>>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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: cibsen@redhat.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.com
>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>>
>>>>
>>>
>>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Christian,
Personally, I'd go ahead and move it to camel-extra, *still* under the
ALv2 license. That would make it easier to move it back without
relicensing *if* at a later point neo4j would release a binding under
ALv2. I don't have any cycles this week but hopefully you or Henryk
could find some time.
Alternatively, we could wait for the comments to LEGAL-162, but would
rather save some time and not block the release for too long.
My $0.02,
Hadrian
On 03/27/2013 12:09 PM, Christian Müller wrote:
> Good catch Hadrian!
>
> I propose/support to move this component to Camel extra.
> We should also move to documentation [1] to Camel extra and update the
> Camel components page [2] with the new home of this component.
>
> I can do this/support if you want (I'm sick at home and have some time ;-)
> ).
>
> [1] http://camel.apache.org/neo4j
> [2] http://camel.apache.org/components.html
>
> Best.
> Christian
>
> On Wed, Mar 27, 2013 at 4:36 PM, Christian Ohr <ch...@gmail.com>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 <cl...@gmail.com>
>>
>>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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
>>>
>>
>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Christian Müller <ch...@gmail.com>.
Good catch Hadrian!
I propose/support to move this component to Camel extra.
We should also move to documentation [1] to Camel extra and update the
Camel components page [2] with the new home of this component.
I can do this/support if you want (I'm sick at home and have some time ;-)
).
[1] http://camel.apache.org/neo4j
[2] http://camel.apache.org/components.html
Best.
Christian
On Wed, Mar 27, 2013 at 4:36 PM, Christian Ohr <ch...@gmail.com>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 <cl...@gmail.com>
>
> > On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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
> >
>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Daniel Kulp <dk...@apache.org>.
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 <ch...@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 <hz...@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 <cl...@gmail.com>
>>>
>>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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: cibsen@redhat.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus
>>>> Blog: http://davsclaus.com
>>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>>
>>>>
>>>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [HEADS-UP] Possible issue with neo4j
Posted by Christian Ohr <ch...@gmail.com>.
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 <hz...@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 <cl...@gmail.com>
>>
>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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: cibsen@redhat.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus
>>> Blog: http://davsclaus.com
>>> Author of Camel in Action: http://www.manning.com/ibsen
>>>
>>>
>>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Hadrian Zbarcea <hz...@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
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 <cl...@gmail.com>
>
>> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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
>>
>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Christian Ohr <ch...@gmail.com>.
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 <cl...@gmail.com>
> On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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
>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies <ra...@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 <wi...@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
Re: [HEADS-UP] Possible issue with neo4j
Posted by Robert Davies <ra...@gmail.com>.
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
On 27 Mar 2013, at 02:18, Willem jiang <wi...@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/
>
>
>
Re: [HEADS-UP] Possible issue with neo4j
Posted by Willem jiang <wi...@gmail.com>.
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/