Library A is licensed under GPLv3. I want to write a program that uses that library as a dependency (programming against interfaces and using classes in that library), so I have to put my own program under GPLv3 as well, or under GPLv3 with a linking exception.

I also need a second library B which is licensed under the Apache license 2.0, which is compatible with GPLv3 so it is fine to use it with my program.

Library B directly or indirectly depends on library C which is e.g. Eclipse Public License which is compatible with Apache but not compatible with GPLv3.

My question: is it possible to distribute my program like this or would that be a violation of the GPL?

This is all about dependencies of Java libraries on other java libraries as described by Maven. So X depends directly on Y means that the library X lists library Y in their pom file, while X depends indirectly on Y means that X has some library Z in their pom file which in turn has Y in their pom file.

  • What does "indirectly" mean? May 18, 2016 at 18:25
  • It says in the Eclipse Public License Wikipedia article that the EPL is incompatible with the GPL because it contains a "Patent Retaliation" clause. The Apache License 2.0 also contains such a clause, so it's unclear to me why AL would be GPL compatible while EPL is not, though the AL patent retaliation clause is much narrower (only covering rights granted under the specific patent claim, not the entire license). As with all such things, if they are important to you, consult a legal expert. May 18, 2016 at 18:32
  • Saw your edit. There isn't anything in these licenses that say that their terms only apply "one level deep," so. May 18, 2016 at 18:36
  • Thanks Robert Harvey, I hope I clarified this with an update. My question is less about compatibility of AL vs. EPL, those were just given as examples since in the real world, many more libraries are involved. What I am really curious about is if just a single library with a license that is not compatible anywhere in the transitive closure of dependencies will make the whole project legally impossible to distribute.
    – jpp1
    May 18, 2016 at 18:37
  • 1
    As I stated before, there's nothing in the licenses that allows you to start ignoring them after more than one level of indirection. May 18, 2016 at 20:13

1 Answer 1


The comments include the basic answer, but not much in the way of overcoming the obstacle. Unfortunately, yes, the entire chain of dependencies must have compatible licensing when you distribute your program.

Your have several legal options:

  1. Find a free library with a compatible license,
  2. Implement the functions you need yourself,
  3. Request a GPL-compatible license/release from the library owner (which they may not be able to offer legally or may not want to offer at all)

Perhaps implementing it yourself is the only alternative. If so, consider making your implementation a GPL library, even if it is far more basic than the GPL-incompatible library. This is how open source software grows.

Disclaimer: Not a lawyer. Maybe there are more options, but these are the only ones I've ever seen.

Your Answer

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

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