On Tue, Jul 16, 2013 at 8:46 AM, René Peinl <rene.pe...@hof-university.de>wrote:
> Dear Ate, dear Shindig developers, > it's been some time since this discussion because we were a bit frustrated > and the project on our side was frozen for some time. Fortunately, I came > up > with an idea of how to circumvent this problem and this time wanted to do > the legal check BEFORE we start the coding. > > The current code has a direct compilation dependency on either neo4j > directly or at least their REST/JSON wrapper, which is also GPLv3 licensed. > That seems to be the problem. > We therefore propose to split our code into two parts. One part should > become part of the Apache Shindig project and will be licensed APLv2. The > other part will directly use neo4j and therefore be licensed under GPLv3 > and > published on sourceforge or somewhere. Between those two parts there will > be > only network communication, no compilation dependency. > > Could somebody from the core team please confirm, that > a) this new proposal will have no licensing problem (my German lawyer, who > is specialized in OSS licensing confirmed that, but the ASF may still see > it > differently) > b) the community is still interested in the neo4j backend as an option for > Shindig > I actually had a conversation with Emil Eifrem from Neo Technologies at a conference about this subject and we couldn't come to any better proposal than what you suggest. As long as there is no reference to the GPL API in the code, I don't foresee an issue at all. Ate, do you have any concerns? > > Otherwise, we would not invest any more time in this issue. > Regards > René > > -----Ursprüngliche Nachricht----- > Von: Ate Douma [mailto:a...@douma.nu] > Gesendet: Mittwoch, 27. März 2013 15:22 > An: dev@shindig.apache.org > Cc: Peter Neubauer; René Peinl; Florian Holzschuher > Betreff: Re: Review Request: Alternative database backend based on graph > database neo4j > > Sorry about top posting (and dropping legal-discuss@) but as we didn't get > any feedback yet on the below question from legal-discuss@, I've dived > into > it myself a bit further. > > I already came to the conclusion (and discussed this internally with > another > ASF > member) that the current proposed contribution which directly uses Neo4J > GPL3 licensed APIs cannot be allowed, as that (source) dependency will > enforce the > GPL3 license upon this contribution as a whole, optional or not. > > The possible 'workaround' of using a 3rd party library like > spring-data-neo4j > (only) which is ALv2 licensed I am also very doubtful about, because that > library itself has direct usage and dependency on the Neo4J APIs, so it > really is only 'hiding' the same problem. > If this is a correct assumption, and I created an specific JIRA question > [1] > for legal-discuss@ for it, then the spring data 'workaround' is also > tainted > and not to be allowed either. > > I've also brought this forward to someone at Apache Camel which intend to > (but hasn't yet) release a Camel Neo4J component, and it looks like they > will decide also that Neo4J cannot be supported after all, at the ASF. > > Pending the resolution of [1], it now seems doubtful to me Apache Shindig > can accept the neo4j support contribution. > If this becomes the case, I see two possible solutions, in preferred order > (besides dropping it): > > a) NeoTechnology provides an additional (probably API only) library of its > own under an ALv2 compatible license, which can be used to create > integrations like these. This would be the most practical and beneficial > solution IMO, similar to for instance the MongoDB (AGPL3 licensed) > mongodb-java-driver library which is > ALv2 licensed, see [2]. > > b) Provide the Shindig Neo4J support in a separate project outside the ASF, > maybe at Apache Extras [3]. Downside of this of course is that alignment > with Apache Shindig itself will be more difficult and likely trailing the > development @Shindig. > > I'll keep the list noted on any progress or conclusion of [1]. > > Regards, Ate > > [1] https://issues.apache.org/jira/browse/LEGAL-162 > [2] https://github.com/mongodb/mongo-java-driver > [3] http://community.apache.org/apache-extras/faq.html > > On 03/11/2013 11:09 AM, Ate Douma wrote: > > Now replying again, but to the proper mail address, see inline below. > > > > Cheers, Ate > > > > On 03/11/2013 11:05 AM, Ate Douma wrote: > >> Another forward of an incorrectly addressed email for legal-discuss@ > >> > >> On 03/11/2013 09:41 AM, Peter Neubauer wrote: > >>> Also, > >>> keep in mind that only the enterprise components of Neo4j are AGPL, > >>> the community edition, which I believe is the most interesting part > >>> here, is GPL. > > > > That is useful information indeed. Thanks for correcting me in this! > > > > So for this case at hand I assume we only need to consider the > > possibilities to use the GPL3 licensed community edition of neo4j. > > > > The question then is if at the ASF we may reference and explicitly use > > GPL3 licensed APIs in our AL2.0 licensed code, in an optional module, > > which also requires these GPL3 libraries at runtime. > > Even if we don't distribute those 3rd party GPL3 libraries ourselves. > > > >>> > >>> /peter > >>> > >>> > >>> Cheers, > >>> > >>> /peter neubauer > >>> > >>> G: neubauer.peter > >>> S: peter.neubauer > >>> P: +46 704 106975 > >>> L: http://www.linkedin.com/in/neubauer > >>> T: @peterneubauer > >>> > >>> Graph database introduction book for the uninitiated - > >>> http://graphdatabases.com Neo4j questions? Please use SO - > >>> http://stackoverflow.com/search?q=neo4j > >>> > >>> > >>> On Mon, Mar 11, 2013 at 9:22 AM, René Peinl > <rene.pe...@hof-university.de>wrote: > >>> > >>>> 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 > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > > > > > > > >
