We’ve already looked at your top questions about the GPL, the Apache 2.0 License, the Ms-PL, the CDDL, and the BSD Licenses. Today, let’s take a look at your most frequently asked questions about the GNU GPL with the Classpath exception.
The GNU GPL requires that every work based on the program – that is, every derivative of the original program or any modifications one introduces to it – be subject to the GPL. As such, it may cover your original code if you combined it with a GPL module.
The classpath exception permits linking a GPL library with an independent module (“which is not derived from or based on the library“), without subjecting the resulting program to the GPL. The independent module can obviously be your own proprietary program. Therefore, the classpath exception enables to use GPL’ed license components in a certain way without risking the integrity of your Intellectual Property.
Further, the resulting executable can be copied and redistributed under a license of your choice – as long as you meet the terms and conditions that govern the existing modules you’re using.
Essentially, the classpath exception protects you from having to release your project under the GNU license, if you link to a GPL with classpath exception library— thereby protecting you from having to publically open your entire source code.
You can either link the modules statically or dynamically. The GNU GPL classpath exception permits both methods.
If you use the GPL library as is, then you must. However if you modify the GPL with classpath exception library, you may choose whether to extend the exception to your modified library. This is not compulsory. If you don’t want to extend the exception, you don’t have to include the exception statement in your modified library.
Only the copyright owner – usually, the developer of the library – can choose to release his or her program under the GPL with a classpath exception.
The LGPL allows a developer to link the LGPL’d ‘library’ with other software, thus creating a larger “executable program” that contains the ‘library’. The LGPL contends that the resulting larger executable program is a derivative of the LGPL’d library, and that the executable is therefore subject to the LGPL’d section that specifically addresses such derivative. According to that section of the LGPL, the developer can distribute the resulting larger executable program under the terms of his or her own choice, but those terms must permit users to engage in certain modifications to the executable program and reverse engineering for debugging those modifications.
Additionally, if the LGPL’d library is statically (rather than dynamically) linked with the other software, the developer must also provide the linkable object code version of the other software (or alternatively, the source code of the other software). This is so the recipient can modify the LGPL’d library and then relink it with the object code version of the other software to produce a modified executable containing the modified LGPL’d library.
The GPL with classpath exception is less demanding. Like the LGPL, the GPL with classpath exception also allows a developer to link the classpath library with different programs, creating a larger “executable program” that can be distributed under the terms of the developer’s choice. But unlike the LGPL, the GPL with classpath exception doesn’t require that those terms permit modifications to the larger executable program and reverse engineering. It also doesn’t require that the developer provide the object code version of his/her program.
The LGPL and GPL with classpath exception have certain other differences, outside the scope of this FAQ.
The GPLv3, is a major revision of the GPLv2. It introduced changes to the license terminologies, discussed patent rights in detail, addressed compatibility issues with other open source licenses, and more. Like the GPLv2, it subjects any work that is derived from the GPL program to the terms and conditions of the GPL, in what is often called the “reciprocal” nature of the GPL.
The GNU GPL with the Classpath exception is a special case of the GNU GPL that allows developers to link to GPL classpath exception licenses library to different programs irrespective of their licenses, without subjecting the “derived” result to the terms and conditions of the GPL.
The EPL subjects any work that is derived from an EPL program to the terms and conditions of the EPL. The EPL itself does not delineate what is or is not considered a work derived from the EPL (e.g., it does not clarify whether linking an EPL’d library with other software results in an overall program that would be considered a derivative of the EPL’d library). Hence, in terms of its reciprocal effect, the EPL is somewhat similar to the GPL.
Unlike the EPL’s lack of clarity as to what constitutes a “derivate” that would be reciprocally subject to the EPL, the GPL with classpath exception makes it clear that linking a classpath library with other software does not reciprocally subject the derived result to the terms and conditions of the GPL.
The EPL and GPL with classpath exception have certain other differences, outside the scope of this FAQ.
The MPL is a “weak reciprocity” license, in that only source code files that contain original or modified MPL’d code, are subject to the MPL. Therefore, linking an MPL’d library with other software does not result in an overall program that is reciprocally subject to the MPL.
The effect of the GPL with classpath exception is similar: linking a GPL with classpath exception library with other software does not result in an overall program that is reciprocally subject to the GPL.
The MPL and GPL with classpath exception have certain other differences, outside the scope of this FAQ.
The author of this blog is not a lawyer, and you should not interpret this as legal advice of any kind. Information is provided on an as-is basis. For a legal consultation, please contact your legal advisor.