jgaeddert / liquid-dsp

digital signal processing library for software-defined radios
http://liquidsdr.org
MIT License
1.87k stars 439 forks source link

license when using fftw #322

Open jhgit opened 1 year ago

jhgit commented 1 year ago

Should there be a mention in the readme or other documentation (configure --help) about using FFTW "infecting" this library with GPLv2?

seonlee2013 commented 1 year ago

好啊,邮件收到啦! Hi, your email is arrived safely

jgaeddert commented 1 year ago

Should there be a mention in the readme or other documentation (configure --help) about using FFTW "infecting" this library with GPLv2?

My understanding is that linking to libraries licensed under GPLv2 from source code under a different license is a bit of a gray area. FFTW isn't a dependency as liquid will run fine without it (albeit slower in several cases). I'm not distributing binaries, either. I am not a lawyer, though, so I can't comment definitively.

jhgit commented 1 year ago

Using FFTW can make liquid-dsp a derivative work (regardless of how FFTW is incorporated into liquid-dsp - dynamically linked, statically linked or directly including the source code of FFTW into liquid-dsp and compiling together). I don't know how much of a gray area it would be, but being gray should be enough to be considered by users who might be sensitive to the terms of a different license. It's up to a legal authority to interpret the license terms and decide if the combination of FFTW and liquid-dsp is significant enough.

I think it would be prudent to at least mention the issue in the documentation that describes how FFTW can affect license terms when combined with liquid-dsp.

EighthOctave commented 1 year ago

I've had concerns about this as well. My understanding is LGPL allows for dynamic linking without being considered derivative work, but I think GPLv2 is pretty clear about any linking being considered derivative work which must also carry GPLv2 license.

Not a lawyer.

jgaeddert commented 1 year ago

I'm not sure if this fits the bill, but I added some notes in the README to that effect. Ideally, liquid wouldn't even need to link to these, but we're not quite there, yet.

I definitely appreciate the comments/feedback!

jimorc commented 10 months ago

Actually, gnu.org is very specific about this. From Frequently Asked Questions about the GNU Licenses:

If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? (#IfLibraryIsGPL)

Yes, because the program actually links to the library. As such, the terms of the GPL apply to the entire combination. The software modules that link with the library may be under various GPL compatible licenses, but the work as a whole must be licensed under the GPL. See also: What does it mean to say a license is “compatible with the GPL”?

jhgit commented 10 months ago

I'm not sure if this fits the bill, but I added some notes in the README to that effect. Ideally, liquid wouldn't even need to link to these, but we're not quite there, yet.

I definitely appreciate the comments/feedback!

Seems okay - adding your interpretation of one of the important caveats of linking with a GPL library (distribution of source code) is fine. It'd be good to explicitly say that linking with fftw subjects liquid-dsp to all distribution terms of the GPLv2 license (or later).

Spelling nitpick: your use of 'vain' in the README should be spelled 'vein'.

But your additions are an improvement - it makes it somewhat clear that depending on third party libraries linked with liquid-dsp, the licensing terms can change from purely the MIT license terms.