just some food for thought, since this exact topic is of particular interest to me, especially in the Java realm, and I have had similar questions.... here is an excerpt from a message I recently sent to an acquaintance of mine. (The example is realistic but contrived; I've never used fast Fourier transforms for any major project I've worked on or am likely to work on.)
I hereby release this post to the public domain -- apologies for the length, but when I wrote it, I wanted to provide a fairly concrete example.
I also pledge US$250 as a contribution to the first non-profit organization (other than FSF) who can provide some useful guidance to the questions at the end, and whose mission includes promoting the use of open-source software.
Consider the Shared Scientific Toolbox in Java. ( http://hubris.ucsd.edu/shared/ ) This is a library for programming scientific applications. It is licensed under the LGPL, with a caveat about its optional use of the GPL'd FFTW library for fast Fourier transforms (excerpt from the SST manual follows):
1.5 Licensing Issues
Some of the SST’s functionality is backed by excellent, free, third party software packages. Keep in mind that FFTW3
is the default FFT [5] service provider. It is licensed under the GPL; however, a commercial, non-free version not
bound by the terms of the GPL exists.
Most of the work for the SST is original, and this author has released said parts under the LGPL. Take note
that the free version of FFTW3 is released under the GPL; any distribution of the SST that links to it, or anything
else GPL’d, is covered under the GPL by extension. For licensing disambiguity, the permissive parts of the code
base reside in directories not suffixed with an x, and they do not depend on the GPL’d parts. Long story short,
one can obtain a distribution usable under the LGPL by removing src/sharedx, src/libx, native/src/sharedx, and
native/include/sharedx.
So assuming this interpretation of licensing terms is accurate, I can obtain the SST source, cut out the parts of it that utilize FFTW, and produce an SST-LGPL.jar library which is covered by the LGPL license and not GPL. The library SST-LGPL.jar contains an interface shared.fft.FFTService, which abstracts the general features of a class that provides FFT functionality. It also includes the class shared.fft.JavaFFTService, an implementation of FFTService which is probably not as fast as FFTW. Both FFTService and JavaFFTService are covered under the LGPL license.
Now suppose I modify the SST-LGPL.jar library to add the following class:
/**
* allow choosing an implementation of FFTService at runtime,
* through mechanisms that are not contained within the SST library.
* The default implementation class used is specified by the
* property "FFTService.implementation", loaded from the classpath
* specified by the property "ServiceFactory.classpath", with both
* properties contained in a "SST.properties" file in the same directory
* as this .jar file.
*/
class FFTServiceFactory
{
public FFTServiceFactory() {}
public FFTService createService(String className) // exception clauses elided
{
Class<FFTService> serviceClass = loadClass(
className, lookupProperty("ServiceFactory.classpath", null));
return serviceClass.newInstance();
}
private String lookupProperty(String propName, String defaultValue)
{
/* exercise for the reader:
* look up a property with a specified name,
* in a "SST.properties" file in the same directory as the .jar file
* containing this class. If not found, use defaultValue.
*/
}
private <T> Class<T> loadClass(String className, String classPath)
{
/* exercise for the reader:
* write a custom classloader that looks up a className class from
* the given dynamically specified classPath (or if classPath is null,
* it uses the standard Class.forName() )
*/
}
public FFTService createService() {
return createService(lookupProperty("FFTService.implementation", "shared.fft.JavaFFTService"));
}
}
Suppose I also create and distribute three other packages:
1) SST-FFTW-JNI.jar + SST-FFTW-JNI.dll
This consists of those parts of the SST.jar that were cut out, including the class sharedx.fftw.FFTWService which wraps the FFTW C library (compiled into a dynamically-linked library) and accesses it "directly" through JNI.
2) SST-FFT-IPC.jar + SST-FFTW-IPC.exe + SST-FFTRI-IPC.exe + SST-FFT-IPC.pdf
This consists of two programs, a library, and a specification.
SST-FFTW-IPC.exe: contains the FFTW C library and runs FFT algorithms, obtaining its data through some IPC mechanism (e.g. sockets or standard I/O).
SST-FFTRI-IPC.exe: contains a Reference Implementation of an FFT algorithm, does not contain FFTW, and obtains its data through the same protocol as SST-FFTW-IPC.exe
SST-FFT-IPC.jar: a .jar file that contains the class shared.fft.FFTIpcService, which implements shared.fft.FFTService, by launching either SST-FFTW-IPC.exe or SST-FFTRI-IPC.exe (which one used is configurable at runtime) and communicating with it through IPC.
SST-FFT-IPC.pdf: specifies the IPC mechanism used by the above 3 programs. I choose to release this through some sort of open-source license.
3) WaveformViewer.jar
This is proprietary application software. It depends on, and is distributed with, SST-LGPL.jar, for several features including fast Fourier transforms. It has documentation that talks about how to use it with the SST-FFTW-JNI and SST-FFT-IPC packages, but those packages must be obtained separately.
=====
As far as I can tell, here are the licensing/distribution requirements of the individual packages/files:
SST-LGPL.jar LGPL (all the source files used are LGPL, so my modifications are also LGPL)
SST-FFTW-JNI.dll GPL (required since it statically links to FFTW which is GPL)
SST-FFTW-JNI.jar GPL (required since it dynamically links to SST-FFTW-JNI.dll which is GPL)
SST-FFTW-IPC.exe GPL (required since it statically links to FFTW which is GPL)
SST-FFTRI-IPC.exe Licensing is up to me, since I create this program using FFT first principles.
SST-FFT-IPC.jar Licensing is up to me. This library can utilize SST-FFTW-IPC.exe,
but IPC communication does not spread GPL, and anyway I can use SST-FFTRI-IPC.exe
SST-FFT-IPC.pdf Licensing is up to me. This is a document describing ideas.
WaveformViewer.jar Licensing is up to me. I choose a license that is not compatible with GPL
(whether proprietary or open-source) because I feel like it.
It depends on (links to) SST-LGPL.jar but that is LGPL.
There are 4 ways of running WaveformViewer.jar:
A) base method: WaveformViewer.jar + SST-LGPL.jar, uses shared.fft.JavaFFTService.
B) base + SST.properties pointing to sharedx.fftw.FFTWService through SST-FFTW-JNI.jar
C) base + SST.properties pointing to shared.fft.FFTIpcService through SST-FFT-IPC.jar + SST-FFTRI-IPC.exe
D) base + SST.properties pointing to shared.fft.FFTIpcService through SST-FFT-IPC.jar + SST-FFTW-IPC.exe
(A) and (C) do not use the FFTW library at all.
(D) uses FFTW, but it is contained within a separate executable, so I'm fairly sure it does not violate any licensing requirements.
(B) uses FFTW. Technically it links to FFTW dynamically. An external user has to configure SST.properties to make it work, and my WaveformViewer.jar neither depends upon any FFTW library, nor takes any explicit steps to use the FFTW library.
Three questions:
In case (B), what, if anything, triggers the GPL here? Does this violate the terms of the GPL?
In case (D), if I don't create SST-FFTRI-IPC.exe, so that SST-FFT-IPC.jar utilizes the separate GPL executable SST-FFTW-IPC.exe, does this violate the terms of the GPL? Here I have created a GPL program, and written a Java library specifically created to communicate with a separate GPL executable to avoid spreading the GPL terms to my library. Technically my library does not depend upon SST-FFTW-IPC.exe, because my library can be configured to use a different executable instead.
Does the licensing of the specification SST-FFT-IPC.pdf have any relevance to software designed to implement that specification?