Just came across this one:
It has always been the FSFâs position that dynamically linking applications to libraries creates a single work derived from both the library code and the application code. The GPL requires that all derivative works be licensed under the GPL, an effect which can be described as âhereditary.â So, if an application links to a library licensed under the GPL, the application too must be licensed under the GPL. By contrast, libraries licensed under the GNU Lesser General Public License (LGPL) may be linked to proprietary applications.
To use a GPLed library in a product, you need the Classpath Exception:
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.
If you donât directly link to GPLed code (e.g. using JMS, SOAP or similar communication approaches) it seems to be enough to provide installation instructions, so the user can deploy the GPL libraries himself. You have to provide bridge code licensed under compatible licenses to make this possible. If your code only compiles if a given GPL library is available in the classpath (import statements, use of derived classes, etc), then you must license your code under the GPL as wellâ¦