FreeSWITCH license analysis
Hi!
At work we have been checking whether switching to FreeSWITCH would
be feasible, with an eye to eventually help package and/or maintain
it in Debian (as part of <https://bugs.debian.org/389591>). One of
the points was doing a license audit. For context, because FreeSWITCH
is licensed under the MPL-1.1 and that is incompatible with any GPL
version, this resulted in the following issue and PR upstream to
clean up stuff:
<https://github.com/signalwire/freeswitch/issues/2092>
<https://github.com/signalwire/freeswitch/pull/2107>
Which overall on the FreeSWITCH side do not seem like major issues (or
at least potential issues that can easily be solved by removing code or
disabling ancillary modules/dependencies). But as mentioned on that issue
above, while then checking its dependencies, I stumbled over src:spandsp,
where the library is LGPL licensed (so *not* MPL-1.1 incompatible) and
some of the tools or build machinery are GPL licensed, but found some
files that end up directly or indirectly being included in the library
were part of those GPL licensed ones. This resulted in:
<https://github.com/freeswitch/spandsp/issues/70>
Upstream mentioned that the C file that gets included directly was a
slip-up, and promptly corrected that in git. But there are still few
tools (GPL licensed) that are used as part of its build system that
generate code (data types and data tables) that ends up included in
the library.
At this point upstream is stating this is not a problem (as in those do
not "pollute" the library with GPL code). And I'm though wondering whether
that is indeed fine or I'm being overzealous/overcautious with this. So
I'd like your opinion whether these tools and their output are fine as is,
or there would ideally be some licensing change applied to those source
files.
Thanks,
Guillem
Reply to: