Dear Apache legal advisors, dear Shindig developers,
as you can see from the discussion below, we have a possible license
conflict between AGPL and APL v2.
We want to integrate code that uses neo4j, a graph database which is
licensed under AGPL, into Shindig. From my perspective it is not necessary
to include any neo4j binaries nor code, but I'm not sure how this affects
compilability. Maybe we can only use the REST API then and don't offer to
run neo4j in embedded mode.
I'm not a lawyer nor a licensing specialist, so please advise on how to
proceed. Maybe we can find a workaround that ensures we are conforming to
the licensing terms and still get the new functionality into Shindig.
One suggestion that seems a good one was to check how Apache Camel deals
with this issue.
Regards and many thanks for clarification in advance
René
-----Ursprüngliche Nachricht-----
Von: Ate Douma [mailto:a...@douma.nu]
Gesendet: Montag, 11. März 2013 08:49
An: dev@shindig.apache.org
Cc: Peter Neubauer
Betreff: Re: Review Request: Alternative database backend based on graph
database neo4j
On 03/10/2013 11:59 PM, Matt Franklin wrote:
On Sunday, March 10, 2013, wrote:
Thanks for the insight Ate.
Rene, I think we should take Ate's suggestion and send an email to
legal-discussion@ (please CC shindig-dev@). If they say it is OK
than we continue the discussion about integrating the patch.
Although the answer from Peter Neubauer / neotechnology is accommodating on
this matter and seems to indicate *they* might think this is not a problem,
reading the AGPL [1] license tells me something differently.
I definitely would like this contribution to be acceptable, but we must be
very sure we're not opening a can of worms here.
I agree that legal should be consulted if we intent to ship a war or
other archive with any neo4j (or other agpl) licensed binaries included.
I don't think we can do that anyway. AGPL is a variant of GPL, and we're
not
allowed, by ASF policy, to distribute any GPL artifact.
As a first mitigation step, why don't we make this a separate maven
module and only ship the source and non-inclusive jar? It should not
be a problem to ship a jar and source that only references the neo4j
libs as runtime dependencies.
That might be a possibility to investigate. As Chris noted in another
email,
it might be doable as Camel seemingly also has a neo4j component.
But also note: it will also depend on the type of reference such an
optional
module uses. If it requires explicit Java imports and direct usage of the
neo4j APIs, this might qualifies as what is called in the AGPL
'Corresponding Source'.
Especially as neo4j and Shindig provide and expect 'Remote Network
Interaction'
for which the AGPL is especially created to enforce its license to
downstream users. IMO this can lead to a conflict with the AS2.0 license,
to
possibly not even be allowed distribution under that license from within
the
ASF, or not even its sources be checked into svn...
But IANAL so indeed this should be run through legal-discuss@ first.
[1] http://www.gnu.org/licenses/agpl-3.0.html
On Mar 9, 2013, at 7:56 AM, René Peinl <rene.pe...@hof-university.de>
wrote:
Dear Ate,
thanks for your comments. I already thought about this and asked the
guys from neo technologies. Here is the answer from Peter Neubauer.
in principle (IANAL) it is ok to have ALv2 licensed code binding to
GPL
code. In runtime, the user will not be shielded from the GPL core,
which means the runtime will have GPL characteristics when you plug in
Neo4j.
That is exactly the intent, and should be ok. The bindings-code is
development-time Apache license, regarding contributions and
copyright etc, so I think this should be ok.
I'm not quite sure if that answers your question. I can further
investigate if necessary.
Regards
René
-----Ursprüngliche Nachricht-----
Von: Ate Douma [mailto:a...@douma.nu]
Gesendet: Freitag, 8. März 2013 14:18
An: dev@shindig.apache.org
Betreff: Re: Review Request: Alternative database backend based on
graph
database neo4j
Just from the peanut gallery, but neo4j is AGPL licensed.
Normally any database backend access which is abstracted away behind
'plain'
JDBC interfaces are allright to use, commercial versions or
otherwise
licensed, because the end-user would have the option to choose
whatever
(compatible) database they want to use.
However with neo4j this seems different. Even with only optional
support
for neo4j, the neo4j integration might require explicit neo4j (Java)
APIs and dependencies? I haven't reviewed the code for this, but if
it imports neo4j APIs then their AGPL license can be too invasive and
then possibly not acceptable for uses within our AL2.0 licensed
codebase.
Or even if that could be allowed, I would make sure to check and ask
(legal-discuss@ etc.) if it would be acceptable from ASF policy POV.
Regards, Ate
On 03/07/2013 07:46 PM, Henry Saputra wrote:
This is good news.
One immediate comment is about the package name.
Would it be possible to put it under org.apache.shindig rather than
the de.hofuniversity?
This would make the contributions uniform like from other companies
and organizations.
- Henry
2013/3/6 René Peinl <rene.pe...@hof-university.de>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/9773/
-----------------------------------------------------------
Review request for shindig.
Description
-------
Review for Shindig-1911
Alternative database backend based on graph database neo4j Any
comments welcome. We are committed to further improve this.
This addresses bug Shindig-1911.
https://issues.apache.org/jira/browse/Shindig-1911
Diffs
-----
/trunk/java/neo4j-backend/pom.xml PRE-CREATION
/trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/gra
phb
ackend/Constants.java
PRE-CREATION
/trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/gra
phb
ackend/GraphAPIModule.java
PRE-CREATION
/trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/gra
phb
ackend/GraphConfig.java
PRE-CREATION
/trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/gra
phb
ackend/GuiceModule.java
PRE-CREATION
/trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/gra
phb
acke
