I've spotted the library (library M) where developers took some source files from GPL with Classpath Exception licensed library (library G), included them in their project and changed namespaces and accessibility on classes.

They are licensing it under MIT license. But the question is: can they really do that?

  1. Whether developers modified this library G is irrelevant, because Classpath Exception is still there.

  2. Keeping Classpath Exception allows them to merge their's modified (or not?) version with their's library M and publish it under MIT license.

  3. When dealing with the source code I should distinguish between MIT licensed code and GPL Classpath Exception licensed code. Or maybe I should consider whole as GPL licensed?

  4. When developers will provide me with binary (dll) of their's library M I should consider it to be fully MIT licensed.

  5. Can a library be considered executable?

Additional details

I think I should provide additional details so you can better address my questions.

Library M has a structure:

  • Folder1 (Library M files)
  • Folder2 (Library M files)
  • Folder3 (Library M files, in one of the files there is is a call to Library G function)
  • Folder4 (some files from Library G, unmodified in general, but namespaces and class accessibility has been changed)

Changes in Folder4 in my opinion are hardly a derivative. Files are literally copied from library G, no modifications were made in the "creative" part that is methods that actually do something remain unchanged, files keep original GPL with Classpath Exception notice. There is no class inheritance in Library M files.

Here is where things get shoddy. I doubt that changing namespace or class accesibility is really a copyright issue. In the end, it is organizational matter, not about doing any kind of creative work. The same goes with copying only some files. But I can never be sure.

The real, final and most important question is: can I consider binary of Library M, that is the result of compilation of source files structure described above and provided by developers to be fully MIT Licensed?

2 Answers 2


Since the MIT license is GPL-compatible, an author is certainly allowed to license their own work under the MIT license and combine it with a GPL-licensed work. In this case, the work as a whole is GPL-licensed, though the author offers some parts of the work under the MIT license as well. The parts that are GPL-licensed by someone else must remain licensed under the GPL; the later author has no legal right to remove the GPL license.

The use of the GPL with Classpath Exception raises the question of whether the work as a whole must be licensed under the GPL, or if the MIT-licensed portions are completely free of the GPL's copyleft requirements. (Even if this is so, the GPL-licensed parts from the upstream author still must remain under GPL license.) The relevant legal question here is whether the MIT-licensed code is an "independent module" according to the terms of the exception. If so, the downstream author's work may be MIT-licensed without being part of the "whole" that the GPL's copyleft applies to.

In practical terms, this means that if someone compiled the two modules into a binary executable, the GPL with Classpath Exception would only require that the corresponding source of the GPL-licensed module be shared, while the MIT-licensed module could be excluded from the distributed corresponding source. In this regard, the GPL with Classpath Exception is quite similar to the LGPL.

If the author doesn't mention that any part of the work is GPL licensed, that is a serious failure in their licensing documentation. If the repo no longer includes a copy of the GPL and/or GPL license headers in the files, that's probably a GPL violation, and you should alert the original author(s) of the GPL work.

  • Great answer. I've provided additional details so you can understand my concerns better and decided to call these libraries library M (MIT) and library G (GPL). I think that MIT licensed code can be considered "independent module", because no code from library G was copied into library M code. Instead there is a call to function provided by library G. Author keeps GPL notice on files from library G incorporated into his project.
    – Andrzej
    Commented Dec 9, 2017 at 16:36

Rewritten the answer based on the new information in the question.

From the question, I understand

  1. The authors of library M have copied some classes from library G
  2. After copying, some small modifications were made in the namespaces and access modifiers
  3. The authors of library M have kept the copied files in a separate folder (-structure) within their project.
  4. The whole of the project of library M builds into a single binary module.

For determining if library M can legally be distributed under the MIT license, the only points that are really relevant are 1 and 4.
Folder structure is not a consideration for copyright and the act of copying a file is sufficient that you are bound by the copyright license of the original. There is no need to make changes of any kind.

The classpath exception to the GPL license states (emphasis mine)

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

As library M contains a copy of some classes from library G and not links to library G itself, the classpath exception does not trigger.
This means that library M contains some code that is under the GPL+classpath license and which must remain under the GPL with or without classpath exception.

In the current situation, the entire library M must be considered to be GPL licensed.

To be able to release library M under the MIT license, two options are possible:

  1. The classes copied from library G are removed from M and M starts linking to the original library G.
  2. The classes copied from library G are moved into a separate library that is independently licensed under the GPL with classpath exception.

In both cases, the classpath exception can be used to license library M properly under the MIT license, as long as every recipient can also exercise his rights on the GPL-licensed code, which effectively means he is able to replace the GPL-licensed code with a different version.

  • Authors did not mixed up code of library M and library G. Instead they copied some files from library G to library M project. In the project folder, codes from library M and G remain clearly separated and files have valid copyright & license notice. There is no copy&paste or class inheritance from library G in library M files. Library M calls functions from library G. Check out additional details I have provided.
    – Andrzej
    Commented Dec 9, 2017 at 17:10
  • @Andrzej: Does the archive of library M also build a separate jar file with the GPL code? If not, I am not so sure that the GPL-licensed code is really that separated that you can apply a separate license to the rest of the code. Commented Dec 9, 2017 at 17:22
  • Further clarification of my concerns. The question is whether copying some parts and changing namespaces and class accesibility in library G constitutes "modifications" that endanger whole library M to GPL infection. In the end, copying only some parts doesn't modify anything and changing namespaces and class accesibility (public, private, internal etc.) doesn't interfere with any creative or original work that can subject to copyright.
    – Andrzej
    Commented Dec 9, 2017 at 17:23
  • It's not Java project so no jar files. Result of compilation is a library (single dll), that is a product of library M and G. Result is not a source code, but a binary. I'm not sure where your question comes from. Doesn't Classpath Exception explicitly allow linking, whether it is static or dynamic, and distribute binary on my terms?
    – Andrzej
    Commented Dec 9, 2017 at 17:32
  • @Andrzej: I have rewritten my answer. Commented Dec 10, 2017 at 9:50

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.