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 docum
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" :
> Christian,
>
> Personally, I'd go ahead and move it to camel-extra, *still* under t
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
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-n
On Wed, Mar 27, 2013 at 3:36 PM, Christian Ohr 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, bu
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 fin
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. T
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] htt
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
On Wed, Mar 27, 2013 at 7:09 AM, Robert Davies 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
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 c
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/sprin
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 t
13 matches
Mail list logo
