Incompatible licenses (GPL-2 cannot be combined with GPL-3+)

[eeickmeyer]

Hi there. I was attempting to add your software to Ubuntu, but upon review by our archive admins, it was pointed out to me that you have some incompatible licenses.

While some of your included files are licensed as GPL-2 (not GPL-2+, usually worded with the "or later version" clause) and also includes GPL-3+, your software is basically not redistributable per the terms of the license when the software that is created in binary form is basically a combination of the two licenses.

I hate to be the bearer of bad news, and I'd like to include it in Ubuntu, but it's just not possible, and technically no binaries can be redistributed by anyone, even yourself.

[harryhaaren]

Hey, thanks for investigating - it'd be nice to be included in Ubuntu packaging. I see your point - wasn't aware that there was a mixture of GPv2, v2+ and it seems most of the Luppp code in src/* is v3+. I'd be happy to re-license whatever section as required - any suggested easiest way to resolve?

[eeickmeyer]

The GPLv2 and v2+ can be combined, but the v3+ cannot be part of it in any way. Unfortunately, the v3+ license doesn't allow for a lower version via fork, so anything that is currently licensed as v3+ has to be dropped altogether and replaced with either your own code or something else licensed with a compatible license.

Additionally, the GVLv2 items could theoretically also be replaced with GPLv2+ or GPLv3+ items, but they cannot be forked into a later license, much like the v3+ items can't be forked into an earlier license.

Unfortunately, this means you don't have an easy way to resolve, so I'd recommend doing whichever is the easiest path.

This is a similar situation to the Linux kernel which has parts (mostly some of the original pieces) licensed as GPL-2, which means that anything added cannot be GPL-3+ or even LGPL-2.1+.

[harryhaaren]

OK, thanks for the additional detail. It seems all the UI code should be OK (I'm the author, so any issues can be fixed easily). The DSP parts for 3 plugins are a bit more tricky, as some of the DSP implementations come from other projects (documented here: https://github.com/openAVproductions/openAV-ArtyFX/blob/master/src/dsp/README):

• Kuiza - "FIL" ladspa plugin in dsp/eq/* - GPLv2 (COPYING file) or GPLv2+ (in .h .c files)
• Driva - "Rakkarack" guitar fx program (dsp/rr/* - GPLv2
• Panda - "Qompander/Compander" FAUST code - GPLv3
• Satma - "Barrys Satan Maximizer" from SWH ladspa plugins - GPLv2.

So it seems I'd have to remove the DSP for those plugins, or find alternate implementations.

Packaging a subset of the plugins feels like a bad idea for usability - users would expect them all to be present if the "artyfx" package is installed. Similarly, changing the DSP without changing the plugin "LV2 URI" would break user's projects that have used the previous DSP.

I think possibly the best solution is to work towards an ArtyFX 2.0, which updates the DSP components to new DSP algorithms that don't have the licencing mixups. Unfortunately that means that there's no easy path forward right now to get plugins packaged.

Does the above sound reasonable or am I missing something obvious?

[trebmuh]

Just throwing an idea here: what about asking upstreams (FIL, SWH,...) is they would be nice enough to relicense their work?

[eeickmeyer]

@harryhaaren No, that sounds good. Just anything that fixes the license incompatibility issue would be good. :)

[siraben]

We at Nixpkgs would also like a clarification which GPL-2 variant (plus or only) this software is packaged under.

[harryhaaren]

Would creating two packages be an alternate solution? Convert the artyfx package into a meta-package, that pulls in two seperate packages, one for GPLv2 and one for GPLv2+ and GPLv3?

Honestly reworking DSP is a huge task, and there will always be differences (which breaks backward compatibility of users' existing projects - somethat that DSP devs should never do). Even just finding a similar, stable, good-sounding version (and testing it for all of those properties) of a DSP would take me more time than I have readily available... and that wouldn't be a good solution for users, although it would simplify packaging.

[eeickmeyer]

It doesn't matter how it's done, it still can't compile incompatible licenses into the same code.

[harryhaaren]

It doesn't matter how it's done, it still can't compile incompatible licenses into the same code.

Yes i understand that incompatibe licenses cannot be compiled into the same binary, and then packaged.

My suggestion was to split the .so shared object of ArtyFX into two, and packaging them separately. This would allow one to be gplv2 only, and the other to be gplv2-and-later and gplv3 etc.

With that clarification, does that seems a reasonable solution given the scarcity of quality DSP code?

[eeickmeyer]

That is reasonable, so long as they stay separate when compiled into binary form.