So I am creating an Android app that uses a Java module called core-ui which is licensed under GPLv3. If I am right, GPLv3 imposes to use the same license in my project as the license of the module.

Since I plan to release this app to the public and that I made modifications to the source code of the Java module : Does my entire project need to be under the GNU GPLv3 or may I only release the modified module ?

Note : I wrote every other component of the app


Yes: The GPL doesn't just extend to that particular component but to the entire program that includes GPL components.

So if you publish your app, you will have to publish your app as a whole under the GPL and provide the Corresponding Source for the entire app. But this just means that any other parts need a GPLv3-compatible license. For example, you could publish the code you've written yourself under LGPL, Apache, or the MIT license instead.

When you include a GPL component in your software, it is insufficient to only publish the Corresponding Source for that component.

  • "you could publish the code you've written yourself under LGPL, Apache, or the MIT license instead." - instead, or in addition? If "you will have to publish your app as a whole under the GPL" I don't see how parts of it could be non-GPL. – Bergi May 11 at 15:35
  • @Bergi It is generally accepted that you can include non-GPL components into a GPL program, for example a library licensed under BSD-3-Clause. But the person making this inclusion has no right to sub-license the unmodified BSD library as GPL. So I think it is only the program as a whole that is covered by GPL, whereas the individual components can be more permissive. If this works with third-party components, there's no reason why my own components shouldn't have a more permissivle license as well. So I'd argue “instead”, not “in addition”. – amon May 12 at 10:06
  • Due to license compatibility, this doesn't matter very much. However, it is possible to construct a scenario where it does matter. Let there be a MIT-licensed library L that relies on a software patent held by party P. P publishes a GPLv3-software S which includes L. Clearly, the users of S have received a patent license from P so that they can safely use the software. But what about L in isolation from software S? If L became GPLv3-licensed, users could extract L from S and enjoy the patent license. If L only ever was and continues to be MIT-licensed, using L outside of S would be risky. – amon May 12 at 10:10

Depends on whether your application is a derivative work of the modified module.

If for example you create an application using the BSD libedit library, using the char *readline(const char*) interface and later someone links your application to libreadline, the linked application is not a derivative work of the module and the linked binary can freely be redistributed, even though the first and most common implementation of char *readline(const char*) is in the GPL licensed libreadline.

However, note that GPL might still put restrictions on the redistribution of the dependency. So for example someone redistributing the linked application along with libreadline, the mere act of distributing libreadline, a freely redistributable component, is something that can only be done if complying with the GPL. So even though the linked binary is not a derivative work, it can be a copyright crime to distribute along with libreadline. However, distributing libreadline and the linked binary separately is permitted.

Free software foundation, the creator of the GPL license, would like everyone to interpret it in such a manner that mere linking creates a derivative work. This is not necessarily the case. A counterargument could be the availability of a compatible interface in a non-GPL component. So you could ensure the validity of the counterargument by creating your own module with a compatible interface -- but that's a lot of effort and why would you use the GPL version of the module if you have rewritten it?

Almost everyone agrees that for running in separate address space and communicating with pipes is not derivative work. However, if the data structures communicated over said pipes contain specific internal details of the program, someone could successfully argue that too intimate communication could make even a program that communicates over pipes a derivative work.

Also, in practice if you are distributing an Android app, you are distributing the dependency module at the same time, so you have little options than to comply with GPL even if you don't like the strictest interpretations of it.

It is too worth mentioning that inline functions can somewhat complicate the situation in C language programs -- in such a case, including a header could make the linked binary a derivative work even though the source code is not a derivative work.

The Linux kernel authors have devised their own way of marking some functions GPL functions, so that all modules using them should be categorized as under GPL. However, a court is not bound by such an interpretation. Yet, it may be wisest to be cautious and not willfully create a component that provides access to GPL-only functions using an interface that is claimed to be not under GPL.

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.