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 <christian....@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 <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
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
--
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: cib...@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
