Problematic GPL-2 license for some src/ sources
guillemj opened this issue · 9 comments
Hi!
While doing a license review on FreeSWITCH (signalwire/freeswitch#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:
src/image_translate.c, only @coppice-git has relevant changes there,src/make_at_dictionary.c, @coppice-git, @mjerris and @wj1918 have relevant changes,src/make_cielab_luts.c, only @coppice-git has relevant changes,src/make_math_fixed_tables.c, only @coppice-git has relevant changes,src/make_modem_filter.c, part of the history is not visible from git as the code got imported in bulk, so it's not clear what other authors this might involve, but for the code from git it looks like it's mostly @coppice-git and two minor changes from @jlenk and @mjerris which might not even be copyrightable.src/make_t43_gray_code_tables.c, pretty much all changes by @coppice-git (one minor change by @jlenk which does not look copyrightable),
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.
Ah! It looks like @coppice-git just changed the license in 7b0b8cf (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.
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. :)
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.
Hi @coppice-git! Please see my earlier reply to @mjerris (who also brought up that these are tools) in #70 (comment), 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!
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?
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.
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.
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.