Avoid FFTW dependency because of GPL

[andreasnoack]

The dependency on FFTW effectively makes this package copy left, which makes it harder to use in some applications. Maybe the specific functionality that depends on FFTs can be factored out or it might be possible to use either https://github.com/Taaitaaiger/RustFFT.jl or https://github.com/JuliaMath/FFTA.jl, although they currently lack the real fft. It should be relatively easy to add to the former, though.

[Datseris]

The dependency on FFTW effectively makes this package copy left

I am a bit confused here as that's not how I thought licenses work. It makes copy left any functionality of this package that actually uses FFTW, not the entire package. That's how I understood it at least. So if someone uses Fourier transformed surrogates, then it is copy left. But if they use some completely independed functionality from FFTW, then they shouldn't care...?

I would be happy to use FFTA but its documentation is abysmal at the moment so it is a high risk that should be avoided...

[andreasnoack]

My formulation was probably not precise, but it remains that it is difficult to use this package in a setting where GPL components can't be included. E.g., when distributing a custom system image. Notice that the dependency might also be indirect (as in our use case), which makes it harder to control which functionality is being used.

I fully understood that this issue might not be a priority, or even desired. In particular, given the state of the alternatives. However, I do think it is useful to track since the dependence on FFTW introduces complications that could be surprising, given that the package code itself is released under the MIT license.

[Datseris]

Absolutely, I agree, and thanks for raising this issue. I have not been considering this issue really at all over the years in open source, so I never kept track of what packages aren't MIT. But now I do take this more seriously and I also would support a switch if a feasible alternative exists!