www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@intertwingly.net>
Subject Re: AGPL/GPL indirect dependencies
Date Wed, 20 May 2015 23:48:41 GMT
Top posting, as my question doesn't fit neatly into your (excellent!)
background.

Following your link[1], I see:

I’m using an Apache-licensed driver to access Neo4j. What does this
mean for my application?

Does this apply here?

- Sam Ruby


On Wed, May 20, 2015 at 7:38 PM, Niclas Hedhman <niclas@hedhman.org> wrote:
> Hi,
> Apache Zest has an Extension mechanism, we call it an SPI, where it is
> possible to create a module that Provides an implementation that the core
> runtime is using. Especially for Storage, there are many (14)
> implementations in the main source tree, a few in the sandbox, and more are
> likely to follow.
>
> We two main issues encountered while vetting the codebase prior to first
> release,
>
> First of all, some of these implementations depend on proprietary APIs, such
> as Amazon S3 or Google AppEngine. It is in our opinion that such dependency
> is not a barrier for releasing these extensions in our SDK, since the user
> will only use those when they are already bound by those licensing terms
> when choosing to use those APIs.
>
> Secondly (and more complex), one of the extensions is for Neo4j, which is in
> itself licensed under AGPL (Enterprise) or GPLv3 (Community). It seems(!)
> that Neo Technology is interpreting GPLv3 that it is possible for someone to
> use Neo4j Community Edition in closed-source projects. Regardless, for
> Apache Zest, the Neo4j Extension was written by Neo Technology employees and
> contributed to the Qi4j community under ALv2. At that time, only AGPL was
> offered, and the conclusion was, that 1. Qi4j project was clear, 2. if
> anyone chose to use Neo4j Extension they would indirectly become dependent
> on AGPL and hence the entire application would be required to AGPL. Pre-ASF,
> we thought that this was still Ok. Once the GPLv3 version become available,
> we thought that now Qi4j+Neo4j/Extension+Neo4j/GPL would not require the
> resulting application to be released under GPL, especially since our
> downstream user could make the extension to be chosen via for instance
> configuration, with its own code referencing it.
>
> Now, under these circumstances;
>   1. Can we release the Neo4j Extension as part of the Apache Zest SDK?
>
>   2. Does the ALv2 contribution from Neo Technologies ensure that GPLv3
> virality isn't triggered into Zest codebase?
>
>   3. Do we need additional explanations/notice/gates to ensure that users
> are not inadvertently failing to comply with licensing?
>
>   4. Do we need to obtain further clarification from Neo Technologies? At
> the time of the contribution, Neo was a small company and easy to
> communicate with. Now it is filled with MBAs and lawyers, and they might
> have a different view from back then.
>
>
> My guess is that Tinkerpop, now in Incubator, is likely to have similar
> relationship with Neo4j, but I haven't looked into their specific
> circumstances.
>
>
> [1] http://neo4j.com/licensing/
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message