3

I work as academic researcher in software engineering. We have an agreement with our university that we can release source code under EPL.

Currently, I work on two interrelated research projects (both released under EPL):

  • ingraph, an incremental graph query engine supporting Cypher graph queries
  • codemodel-rifle, a static analysis application for JavaScript source code repositories, which uses Cypher graph queries for defining well-formedness rules. This project has a number of external dependencies, including some ASL- and MIT-licensed external libraries, and also uses Cypher-compliant query engine (Neo4j or ingraph) in a client-server setup, talking through a driver with REST or REST-like calls. A key component of this project is the parser that transforms the source code to a graph representation - this requires considerable implementation efforts. The parser has talks to the query engine to build the graph.

We are planning to collaborate with jQAssistant, which is GPLv3-licensed framework for static analysis, also using Cypher graph queries. jQAssistant currently runs as part of the build process, so it uses process calls instead of REST calls (e.g. it uses an embedded version of the GPLv3 Neo4j graph database).

As far as I understand, codemodel-rifle and jQAssistant cannot use each other's code as GPL and EPL are incompatible both ways.

We can request a new license from the university for future projects. In this case, we could re-implement the codemodel-rifle application (cr2) and re-release it under a different license. However, I am not sure which license to choose. cr2 would still depend on ingraph (which is fully EPL-licensed), so we cannot use GPLv3.

The goal of the collaboration would be to:

  1. share the parser component,
  2. share the well-formedness rules.

Potential workarounds seem to be the following:

  • Reimplement codemodel-rifle in GPLv3, and also implement an ASL-licensed driver to use ingraph in a client-server setup.
  • Introduce an ASL-licensed common project that can use codemodel-rifle and can be used by jQAssistant. In this case, we still cannot use our jQAssistant's original code, but can jointly develop the common project. Our partner does not necessarily need ingraph to run the analysis, as they can use Neo4j (which is GPL-licensed), so they could release their software under GPLv3.

Are there any better options for collaborating under these conditions?

Improve this question
5
  • "However, as far as I understand, we cannot use each other's code as GPL and EPL are incompatible both ways." .... this is NOT true in all cases. How do you plan the two to interact? function calls? process spawn? which languages?
    – Philippe Ombredanne
    Mar 3, 2017 at 10:25
  • Also if you can be specific on which projects you are talking about this would help
    – Philippe Ombredanne
    Mar 3, 2017 at 10:26
  • @PhilippeOmbredanne thanks for chiming in - I added the concrete projects to the question.
    – Gabor Szarnyas
    Mar 3, 2017 at 12:43
  • and how do all these package talk together? REST apis? JSON files? function calls? which ways? This matters.
    – Philippe Ombredanne
    Mar 3, 2017 at 13:08
  • @PhilippeOmbredanne I added more details on the communication and the goals of the collaboration.
    – Gabor Szarnyas
    Mar 3, 2017 at 13:33

1 Answer 1

Reset to default
3

Assuming that the communication between all the EPL and GPL-licensed components is done over Cypher calls via REST APIs, then these are independent programs. Both side could eventually use any license without impacting what the license of the API caller would be.

If you were making function calls the situation could be different. As you describe it, each component seems to be running in its own independent process.

Improve this answer
5
  • Okay, it seems I still left out an important detail - unlike codemodel-rifle, jQAssistant currently runs as part of the build process, so it uses process calls instead of REST calls (e.g. it uses an embedded version of the GPLv3 Neo4j graph database). I'll add this to the question as well for completeness.
    – Gabor Szarnyas
    Mar 3, 2017 at 15:38
  • what do you mean by process calls: function calls? if jQAssistant calls directly in-process, in JVM the neo4j db, then it is subject to the GPL. The point is: how do your EPL code interacts with any of the GPL code at runtime. Build time does not matter much.
    – Philippe Ombredanne
    Mar 3, 2017 at 18:43
  • The term "build time" is a bit confusing here - jQAssistant is a tool that is invoked during the build of other tools. So during runtime - from jQAssistant's point of view -, it should be able to 1. call codemodel-rifle to transform the source code to a graph and then 2. call Neo4j to execute Cypher queries. This would already be impossible currently - as jQAssistant now only supports Neo4j run in embedded mode and codemodel-rifle cannot be distributed with Neo4j.
    – Gabor Szarnyas
    Mar 3, 2017 at 18:48
  • Besides using it as an embedded database, Neo4j can be used in a client-server setup through an ASL-licensed driver. So maybe a workaround could be the following: on each build 1. run a Neo4j server, 2. run a codemodel-rifle server, 3. allow jQAssistant to use both through REST(-like) interfaces, and 4. shutdown both services.
    – Gabor Szarnyas
    Mar 3, 2017 at 18:52
  • 1
    at a high level this sounds reasonable.
    – Philippe Ombredanne
    Mar 3, 2017 at 19:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.