search

freeswitch / spandsp

SpanDSP is a low-level signal processing library that modulates and demodulates signals commonly used in telephony, such as the "noise" generated by a fax modem or DTMF touchpad.
Other
152 stars 120 forks source link

Problematic GPL-2 license for some src/ sources #70

Open guillemj opened 10 months ago

guillemj commented 10 months ago

Hi!

While doing a license review on FreeSWITCH (https://github.com/signalwire/freeswitch/issues/2092), I noticed that spandsp contains the following GPL-2 licensed files which end up directly included into the built shared library or end up generating output derived from their source code:

src/image_translate.c
src/make_at_dictionary.c
src/make_cielab_luts.c
src/make_math_fixed_tables.c
src/make_modem_filter.c
src/make_t43_gray_code_tables.c

By itself this is not a big problem for libspandsp itself, even though that means the resulting library is covered by the GPL-2 instead of LGPL-2.1. The problem for FreeSWITCH is that the MPL-1.1 (its primary license) is incompatible with the GPL-2, which means linking this library into freeswitch would be a violation of the licenses.

To be able to relicense these files, any author that has touched in a significant way (excluding removals, or very simple mechanical changes or additions) would need to be contacted and approve such license change.

From git history it looks like, for:

mjerris commented 10 months ago

image_translate is the only one of the ones listed that is in the library, the rest are not. image_translate is not gpl licensed.

guillemj commented 10 months ago

Ah! It looks like @coppice-git just changed the license in 7b0b8cf3d42b725405bcc63145de5e280265ce4e (thanks for that change!). This still leaves the make_*.c files, which as I mentioned, are not included directly, but are used to generate code that gets included into the library. Because these files are GPL, the code they generate is derived from them which means it would also be GPL, having the same license incompatibility problems for freeswitch as I mentioned.

Changing license might require approval from all relevant copyright holders, when those changes seem copyrightable though, as I mentioned in my initial message.

guillemj commented 7 months ago

Hey! From the initial analysis, I think that for almost all files (except for src/make_at_dictionary.c) if @coppice-git and @mjerris agree on the license change then that seems enough. For the exception we might need also agreement from @wj1918. If there's such agreement, then I'm happy to provide the needed patches to do the change. :)

coppice-git commented 7 months ago

There are no licence changes necessary. The licence in image_translate.c was a slip-up, which has been fixed in the latest version. It should have been LGPL like the rest of the library code. The other files have no problems with their existing licences. They are tools, which do not form a part of the compiled library. I am the author of all this code. I will be very pissed off if anyone tried to tamper with it.

guillemj commented 7 months ago

Hi @coppice-git! Please see my earlier reply to @mjerris (who also brought up that these are tools) in https://github.com/freeswitch/spandsp/issues/70#issuecomment-1827995342, in summary the way I understand it, these tools generate code that ends up in the library, so that would also be GPL.

(I'm not sure what your comment on being annoyed by someone tampering with the code refers to, if that was about me providing a patch in case all supposed copyright holders agreed on the relicensing , that was just to to try to help with the process (and I cannot merge anything on my own anyway), but I'm as happy if someone else can fix the issues as I understand them, or clarifies why these would not be so.)

Thanks!

coppice-git commented 7 months ago

In what parallel universe do you live where the output of an application gathers the licence of the application? Is every document spat out by openoffice licenced with the openoffice licence?

guillemj commented 7 months ago

I guess that depends on the case, and again I'm not a lawyer, etc, this is all how I understand it from years of being involved in Debian and having to deal with licensing issues.

For a document, the actual content of the document is user created so the user is the copyright holder, the rest of the document is just a transport container. For a tool that generates code as output, the license of the original code where that code is written would apply to it. The usual options here are to add a GPL exception for the output or to change the license for the program (in this case that could be LGPL to match the library).

Examples of this can be found in GCC, autoconf, or bison:

https://www.gnu.org/licenses/exceptions.html https://www.gnu.org/licenses/gcc-exception-3.1-faq.html https://www.gnu.org/software/bison/manual/html_node/Conditions.html

which generate or embed their own code into the output.

guillemj commented 7 months ago

For a document, the license situation might get trickier depending on what the editor program does, if for example it would embed fonts into the document which have their own copyright holders and licenses, or images or sounds from a media library or similar, or JavaScript when exporting to HTML, etc, etc.

coppice-git commented 7 months ago

If a document is stuffing copyright material, like fonts, into its output, that would certainly affect the copyright of the produced material. My tools synthesis data tables.

The three references you quoted are irrelevant here. They refer to code from the distributions which end up embedded in the final constructed application. Those cases certainly need to be handled properly. My tools in spandsp only create data tables. The data doesn't even exist until the tool is run. If I make the tools insert LGPL copyright notices into the generated data files, will that keep you happy? Its a meaningless step, as anyone is entitled to remove that, as the tools are GPL code.