2

I am using multiple libraries in a project I plan to release and distribute in both source and binary form. In my project, I use a few other open-source projects, and modified the source-code in a few of them. I am managing the source-code of my project on GitHub, and maintaining forks of the modified projects on GitHub as well.

The projects use the following licenses:

I'll be including both the licenses and notices for each project when releasing the binary form, and in the case of modified projects, in the forked project's repository on GitHub.

I usually prefer to release my code under the MIT license when I have the choice. However, because of the AGPL v3 library, I'm wondering: do I have to release my project under AGPL v3 as well, and if so, would my project be compatible with the other project licenses?

  • You have to use the strictest license, which of those would be the AGPL I think. – curiousdannii Jan 6 '17 at 0:18
  • how do you modify the modified ones? And JNA has changed its license since 4.0: it is Apache 2.0 or LGPL and no longer LGPL only. – Philippe Ombredanne Jan 6 '17 at 7:51
  • @PhilippeOmbredanne I have modified the source code to suit my needs in the project, but they are still compiled and treated as external dependencies of my project linked at runtime. – jocopa3 Jan 6 '17 at 15:38
3

If you agree that the copyleft of the AGPL flows to the calling code in Java (which is effectily "linking" with the AGPL library it calls) and because of the special provisions related to modifications of both the LGPL 2.1, 3.0 and AGPL 3.0, then the effective licensing of your combination is some kind of AGPL 3.0, irrespective of your own overall license and as long as your own license is considered as compatible with the AGPL.

All the projects you list are either under:

  • an LGPL 2.1 or later or LGPL 3.0 or later, both that you could evolve to an LGPL 3.0 or later. That you can then evolve to a GPL or AGPL 3.0.

  • MIT and Apache are considered compatible with the AGPL 3.0 too.

Furthermore, since you modified some of the deps, one theory is that you have created a work "based on the libraries" and therefore their copyleft flows to your own code. the LGPL and AGPL have special terms that apply in these cases.

So in summary:

  • at rest your own source code can be under any license you want as long as it is considered compatible with the AGPL. The MIT would work OK there.

  • but at runtime, the AGPL terms would apply to your code... meaning users of your code would inherit from its rights and obligations too, including eventual source code redistribution for the whole combo.

E.g. someone could reuse your own code and remove the AGPL and modified LGPL deps and not be subject to the LGPL/AGPL copyleft. But for a user reusing your code as-is, the LGPL/AGPL copyleft would be apply to the runtime combo.

If you were to avoid entirely the AGPL-licensed dep (modified or not in this case) and the modification of LGPL-licensed code, then the MIT could stand both at rest and runtime IMHO (the LGPL would still apply to the LGPL-licensed deps of course).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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