Does redistributing an unmodified copy of rt.jar from OpenJDK7 using an MIT license violate the GPLv2 with Classpath Exception?

Question

I am considering redistributing a copy of the rt.jar file available within the OpenJDK Zulu distribution within my GitHub project repository which is licensed on a project basis using the MIT license. I downloaded this ZIP file and extracted the rt.jar file from it. The use case of the rt.jar file will be as an input to the execution of my project's maven build. The maven build will pass the location/path of the rt.jar file to the javac compiler using the -Xbootclasspath option. I am not modifying the rt.jar file in any way, and I would be including copies of the LICENSE, README, DISCLAIMER files as well as the source code (src.zip) of the entire Zulu openJDK distribution.

Would this redistribution for this usage be in violation of either the GPLv2 or the MIT license? Would my project be considered an independent module and thus subject to the classpath exception of the GPLv2?

Answer 1

After reviewing the associated licenses I came to the conclusion that while I could not directly distribute the GPLv2 licensed material within the MIT licensed project, there was a workaround that would allow me to accomplish the same result.

Including the GPLv2 licensed files would interfere with the MIT license of the project and I would be forcing my project to re-license under the GPLv2, which I did not want. MIT licensed materials can be used compatibly in a GPLv2 licensed material, but not vice-versa. I came to this conclusion by looking the information listed by GNU.org on the Expat license (same thing as the MIT license) as well as the answer to this Software Engineering exchange question: Include GPLv2 licensed data in MIT licensed project.

My workaround was to independently redistribute the GPLv2 files (without modification and in full license compliance). Those files I needed are simply downloaded at build-time on the user's machine under the terms of the GPLv2 and are passed as input to the Javac compiler itself (not as a code dependency) via the MIT licensed build script.

Because the MIT licensed project simply distributes a build script which downloads the GPLv2 licensed files, and the files themselves are thus indirectly redistributed, it means I can still distribute the MIT licensed project while using the GPLv2 files at build time. This workaround is only possible because of the classpath exception within the openJDK project/Zulu distribution's version of the GPLv2 license. If I didn't have a license with that exception then the independent MIT module/project might still be required to be GPLv2 licensed as well as any output dependent on the GPLv2 licensed material being GPLv2 licensed. That would mean that while my build script and source code would be MIT licensed, I would have to license the binaries as GPLv2. Fortunately that was all avoided due to complying with the classpath exception for independent modules.

Summary

My MIT licensed build script downloads the redistributed GPLv2 licensed JAR file and compiles my MIT licensed code using that GPLv2 JAR on the classpath of the compiler to produce an MIT licensed JAR file containing the compiled form of my MIT licensed source code. My source code does not interact with GPLv2 licensed code directly or indirectly nor does it depend on or import the GPLv2 code. The GPLv2 JAR is used strictly at build time and then only as an independent module passed to the maven-compiler-plugin execution of the Javac compiler using the -Xbootclasspath option. This qualified for the classpath exception of the GPLv2 license and thus is fully compliant with the MIT licensed project.