polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject AGPL/GPL indirect dependencies
Date Wed, 20 May 2015 23:38:59 GMT
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

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

[1] http://neo4j.com/licensing/

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message