qsortE infects entire FFTease with GPL

[umlaeute]

the comments in morphine~.c mention that it is released under the GPL because it links to qsortE - and that the other objects are not affected by this.

this is actually not true.

technically, the shared library libfftease statically links in qsortE, which (due to the nature of the GPL) forces the entire shared library to be released under the GPL. since all fftease objects are dynamically linked against libfftease this would also force them to be released under the GPL.

afaict there are two options (if you want to keep [morphine~] with a GPLed qsortE implementation):

• release the entire fftease library under the GPL.
• make sure that only the morphine dylib is actually linked against the GPLed code.

[umlaeute]

i think that the latter suggestion be easiest implemented by:

• Makefile: moving qsortE.c from SHARED_SOURCES to EXTRA_DIST (and remove the qsortE() symbol from fftease.h)
• morphine~.c: doing an #include "qsortE.c" somewhere at the beginning of the file.

it's not the most elegant solution, but certainly the easiest to implement with the current Makefile

[ericlyon]

I always found the GPL's externalities annoying. Maybe the best permanent solution is to move in a non-GPL sorting algorithm eventually. But for now I don't mind what you suggest.

[porres]

now that we're heading to an official 3.0 release and upload to deken, I guess we should take care of this thing also. By the way, Pd uses a sorting algorithm in [text define], maybe we can use that?

[ericlyon]

Sounds like a good idea. Would you like to try updating the code?

[porres]

I can check tonight and see if it's easy for me. There's a sorting algorithm we also use in cyclone that I'm more familiar with

[porres]

I can check tonight and see if it's easy for me. There's a sorting algorithm we also use in cyclone that I'm more familiar with

yeah, it's a bit over my head, actually. So, here's the [text define] sort: https://github.com/pure-data/pure-data/blob/master/src/x_text.c#L488

the sort algorithm we used for cyclone is also found here for this object in my library https://github.com/porres/pd-else/blob/master/Classes/Source/sort.c

Both algorithms above also sort text, and I guess you just need to sort floats, right? So, then you may check a sorting algorithm I'm using in my else/median~ object. I use it to sort FFT amplitudes in ascending order to get a threshold for FFT processing, like noise reduction and stuff, so maybe you're doing something very similar here. Check it out: https://github.com/porres/pd-else/blob/master/Classes/Source/median~.c#L18

so, worst case scenario, we keep this as is and change the license for this release?

[ericlyon]

Worst case might be what @umlaeute suggested above, to avoid GPL infection.

[ericlyon]

That being said, it's just a simple sort requirement. I don't see that it needs to be super efficient as long as it gets the job done. Maybe that's the solution - something simple like the bubble sort, or whatever. After all, the sort only gets called once per FFT frame, and it's not sorting a huge number of elements.

[porres]

Worst case might be what @umlaeute suggested above, to avoid GPL infection.

yeah, right! but I couldn't follow that either :)

[ericlyon]

I'll look into it then.

[ericlyon]

I updated the code with a custom implementation of the quicksort algorithm. It seems to work properly, and also seems to be slightly more efficient than the GPL code that was replaced. The next step will be to remove "qsortE.c" from the distro, and from any makefiles where it appears. FFTease no longer wears GPL handcuffs.

[porres]

awesome, please close this issue then