License incompatibility issues

[guillemj]

Hi!

While doing a superficial license review over current git HEAD to see whether we could use freeswitch in our product, but also whether this could be included in Debian (as part of https://bugs.debian.org/389591), I've noticed that there are multiple licensing issues at hand.

• In the LICENSE file there are files listed with an unknown or FIXME license.
• The code is majorly licensed as MPL-1.1, but includes multiple files licensed as GPL-2 or GPL-2+ (not dual licensed), where MPL-1.1 is incompatible with any GPL version. (https://www.gnu.org/licenses/license-list.html#MPL)
• The project being majorly licensed as MPL-1.1 links at least against shared libraries that are GPL licensed:
  • spandsp: LGPL-2.1 but contains at least one GPL-2 file (src/image_translate.c) included in the library which makes it GPL-2.
  • gdbm: GPL-3+
  • unixodbc: GPL-2+

There could be other problems that I might have not noticed because the review was not exhaustive.

[anthmFS]

spandsp is probably a typo from when the author moved to LGPL

I don't think we really use gdbm but mod_perl used to not compile without it, fuzzy memory cos it was a decade ago.
The ODBC iirc does not REQUIRE unixodbc just any ODBC abi, since it runs on windows or Linux etc and is only enabled with explicit configure flags. Native MariaDB/PGSQL support is favored in this day and age so odbc is likely to be deprecated anyway and is not enabled by default.

I would say if you would like it to be included in Debian it could be approached the same way as FFMPEG where you can choose not to build those components that are questionable. The core of FS and all the popular modules are not connected to any GPL stuff.

It also seems like autotools likes to add GPL stuff into build files etc so its probably worth some audit to make sure esp since many of the things referenced are not part of the actual repository anymore.

[guillemj]

Ah, thanks, I checked a bit further today, and some (but certainly not all) of the problems I found were due to the LICENSE file being out of date, and there are some old files with GPL licenses which seem unused, for which I can probably provide MRs. I don't think the autotools files are usually a concern as these tend to have an exception that imposes no license restrictions on the resulting projects.

But there are other modules I noticed today that seem to also be linking against GPL libraries or code, or at leas provide options to link against them, such as mod_gsmopen, mod_rtmp, mod_shout (and the mod_cluechoo example). Where for example mod_shout allows to link against several options: lame, libshout, and libmpg123, but the latter contains GPL source files making the library GPL, and thus incompatible with the freeswitch license, which I think ideally that option should not be made available, otherwise it looks like a ticking license compliance bomb. I could probably provide some MRs for these too, although it's true that for Debian or our own product we might be able to disable most of these problematic modules, but it would be nice for downstreams or users to be able to use the project safely without needing license audits of every component to make sure they are safe.

In any case, your response is encouraging and it looks like the problem at hand might not be as bad as it initially looked, so getting this clarified might not be an insurmountable effort, I'll try to dig deeper tomorrow. :)