I have been assigned to audit third-party dependencies for one of my company's products to make sure we aren't in danger of running afoul of any licenses. This is probably a job for a lawyer, but such is life when you work at a small company.

At my company, we are using CS2J, an open-source project, to translate C# to Java. CS2J is itself MIT-licensed, and we use it in two ways. First, we use it as an internal tool to translate our source code from one language to another. Second, it comes with a support library (a jar file) that the translated files reference. We package this support library with our main distribution.

It turns out that the support library depends on JavaMail, a GPL-licensed product. (There's technically another license option, but it has the same copyleft clause.) I believe at one time it had something other than a GPL license, but that is no longer the case.

We had been planning on to ship the support library (CS2JSupport.jar) and JavaMail (mail.jar) as its dependency. I have a few questions:

  1. Is CS2J allowed to be licensed under the MIT license in the first place if it's distributed with a GPL dependency?
  2. If we are shipping mail.jar as a dependency of our dependency, does that mean the copyleft applies to us? Or does it just apply to CS2J?
  3. We have a close relationship with the CS2J author. If we asked the CS2J author to make available a CS2JSupport.jar that had mail.jar included inside the jar, then is CS2JSupport simply a derivative work of mail.jar? And since the derivative work is covered under the MIT license instead of the GPL license, would that exempt my company from the copyleft even if we wouldn't be exempt in the situation described in #2?
  • This question appears to be off-topic because it is about legal advise, out of scope for this website.
    – jwenting
    May 9, 2014 at 7:08
  • 1
    I don't agree that it is beyond our scope. It is a question about how some licenses interact with each other and licensing questions are explicitly on-topic. May 9, 2014 at 8:48

2 Answers 2


As Ross Patterson notes in his answer, the JavaMail library is not simply GPL licensed, but GPLv2 with Classpath exception. This is an important distinction, because it makes a world of difference for the answers to your questions.

The Classpath exception to the GPLv2 license effectively restricts the copyleft nature of the GPLv2 to the JavaMail library itself (in a way similar to the LGPL does).

To answer the specific questions:

  1. As the classpath exception restricts the GPL terms to apply only to the JavaMail library, there is no problem in having a non-GPL work (library or program, in this case an MIT-licensed library) depend on it.
    Even if CS2J depends on a library that uses the regular GPL license, the CS2J sources themselves can have a different license. The only 'difficulty' then is that the license must be compatible with the GPL, because the terms and conditions of the GPL would have extended to CS2J.

  2. Due to the Classpath exception, the copyleft of JavaMail is contained within JavaMail itself. Without that exception, the copyleft would have extended also to your software.

  3. Requesting the authors of CS2J to physically include JavaMail in their CS2JSupport.jar would make the CS2JSupport library a derived work from JavaMail that must be licensed under the GPL (with or without the Classpath exception), so that would not give you a route for exemption from the GPL copyleft terms. At best, the situation remains as is (your software depends on a GPL library with classpath exception) and at worse you suddenly have a dependency on a full GPL licensed library and must open up your own software as well.


According to the JavaMail project's "JavaMail License" page, "[m]ost of the JavaMail source code is licensed under the CDDL license and the GPLv2 with Classpath Exception license". The key point is that last bit - the "Classpath Exception". That exception, common for Java libraries, is stated at the end of the license, where it says:


Certain source files distributed by Sun Microsystems, Inc. are subject to the following clarification and special exception to the GPL Version 2, but only where Sun has expressly included in the particular source file's header the words

"Sun designates this particular file as subject to the "Classpath" exception as provided by Sun in the License file that accompanied this code."

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 Version 2 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.

Note that last paragraph - you can use the JavaMail library and "distribute the resulting executable under terms of your choice". No copyleft here.

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.