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.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
