Dual license Apache2.0 GPLv3 for a library with optional GPLed code

Question

I have an audio library that optionally uses a GPL sub-library for computing the FFT (FFTW3). At compile time, I can disable FFTW3 and use another FFT implementation (which is slower than FFTW3, but with a more permissive license).

If I release this audio library under GPL, everything would be very easy. Nevertheless, I also want to let the users of this library to deactivate FFTW3 and then make commercial softwares, without the need to open any modifications.

I was thinking of a dual license Apache2.0|GPLv3 for this audio library. Users who want to create a GPL-based software can then use this library with the GPLv3 and activate the GPL sub-library FFTW3. Users who want to create closed source development can also deactivate the FFTW3 and enjoy the audio library with the Apache2.0.

The FFTW3 is also an example, I suppose there might be other interesting GPLed sub-library to add.

Does it make sense ? Is it over-complicate ? Do you see a simpler solution for this situation ?

Answer 1

The FSF and the Apache Foundation both consider the Apache 2.0 license as compatible with the GPL 3.0 but not with the GPL 2.0. But the Apache foundation also considers that L/GPL-licensed code is not suitable for inclusion in Apache products as released by the foundation. Yet most lawyers I conferred with consider acceptable to use unmodified LGPL-licensed libraries and Apache-licensed libraries in some product under many licenses, including proprietary licenses.

At this stage, my head wobbles and your eyes spin.

So I can release my code using the Apache license and when combined with a GPL-3.0-licensed library it could be treated as GPL-licensed overall and this would eschew the need for dual licensing.

However (at least per the FSF):

One lax license, Apache 2.0, has patent clauses which are 
incompatible with GPL version 2

To also provide compatibility with version 2 of the GPL, and to maximize compatibility I could either:

1. license under a choice of Apache 2.0 or GPL 2.0 (or later).
2. OR license under a license that would be treated as compatible with the Apache license (such as a BSD or MIT) and the L/GPL v2 and v3 both inside and outside of the FSF and the ASF.
3. OR license under an LGPL license that would be treated as incompatible with Apache at the ASF, but considered OK outside, including for inclusion in commercial products and would be treated as GPL-compatible by the FSF. And to maximize compatibility this would likely be an LGPL 2.1 or later.

These would be my options.

To avoid my head to hurt too much, I would look at all this options as if these were code dependency issues between various versions of libraries: I would picture each of these licenses options as various combinations of versions of header files and function signatures some of which compile and work, some other that work sometimes but not always, some that result in a segfault and coredump badly unless I do two triple back-flips on a bike.

Finally, I might provide some build configuration options and documentation similar to FFmpeg such that when my code is built with FFTW3 it is quite explicit to my users when GPL-code is mixed in or not.

Answer 2

In addition to the recommendations by Philippe, you can also use the Apache License version 2.0 with the LLVM exceptions.

The SPDX identifier for this is Apache-2.0 WITH LLVM-exception.

This would allow compatibility with both GPLv3 and GPLv2, due to the following exception text:

In addition, if you combine or link compiled forms of this Software with software that is licensed under the GPLv2 ("Combined Software") and if a court of competent jurisdiction determines that the patent provision (Section 3), the indemnity provision (Section 9) or other Section of the License conflicts with the conditions of the GPLv2, you may retroactively and prospectively choose to deem waived or otherwise exclude such Section(s) of the License, but only in their entirety and only with respect to the Combined Software.