Licencing issues

[daveol]

DISCLAMER: I am NOT a lawyer.

The apache2.0 llicense is incompatible with GPLv2, see here.

This means that you can use mongoose, however it can't be bundled in a library with other apache2.0 sources. The same goes for some of the libusb stuff. Files related to this issue:

• plugins/udmx/src/libusb_dyn.c (which is GPLv2+)
• plugins/udmx/src/libusb_dyn.h (which is GPLv2+)
• webaccess/src/mongoose.c (which is GPLv2)
• webaccess/src/mongoose.h (which is GPLv2)
• plugins/hid/linux/hidapi.cpp (which is GPLv2+)
• plugins/peperoni/win32/peperoni/usbdmx-dynamic.cpp (which is GPLv2+)
• plugins/peperoni/win32/peperoni/usbdmx-dynamic.h (which is GPLv2+)

GPLv2+ means that you can choose a later GPL license, like GPLv3 which is compatible with the apache2.0 license. So maybe that is a good idea for those source files.

This issue has been found in the package review for fedora here

[daveol]

This issue has been mentioned before in #759 and #736 by @janosvitok

[mcallegari]

OK, let's try to resolve this mess,

First things first. I have written an email to the Mongoose support to understand how to solve GPLv2 vs APL conflict. As a last resort, I wouldn't mind to license the whole webaccess sources (resulting in a library called libqlcpluswebaccess) with GPLv2 or whatever needed to resolve the matter. Mongoose is an important piece of this project.

libusb_dyn. usbdmx-dynamic. As you stated, I believe there's no issue there, cause it says "either version 2 of the License, or (at your option) any later version." So I'd definitely re-license them with GPLv3 which is compatible with APL. Question: is it necessary to change the headers or can we just say "those are re-licensed with GPLv3" ?

hidapi.cpp As discussed before, HIDAPI is quite open in terms of license. I changed the header because your script didn't recognize the original "super open" license that HIDAPI is distributed with. Moreover the HIDAPI website says:

HIDAPI may be used by one of three licenses as outlined in LICENSE.txt. These licenses are:

• GPL v3 (see LICENSE-gpl3.txt),
• BSD (see LICENSE-bsd.txt),
• The more liberal original HIDAPI license (see LICENSE-orig.txt).

I'll change the headers again with GPLv3.

[daveol]

Well seems like GPLv3 is not gonna solve any of this :cry:

If you read the text here it specifies you can use apache2.0 sources in your GPLv3 project, but not the other way around.....

Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

[mcallegari]

What a mess.. Just found this http://www.apache.org/legal/resolved.html#category-x

The incompatibility is clear :cry: None of the GPL flavours is suitable for APL. This is a problem.

I switched HIDAPI back to the original "free" license

One consideration about the rest: those project are most likely abandoned. libusb_dyn copyright is 10 years old: Copyright (c) 2002-2005 As for Peperoni, I know the developer and I can write an email to him as well and ask what we can do.

is there any "timeout" for copy protection, after which one can simply redistribute the code without any header at all ?

[daveol]

is there any "timeout" for copy protection, after which one can simply redistribute the code without any header at all ?

Probably... when it becomes public domain, but that is not a realistic timespan

[mcallegari]

Peperoni sorted ! 9a66974f7842c5cae522c220f1d86dae3a33bfcd Got the permission from Dr. Jan Menzel to switch those 2 files to APL 2.0

Hi Massimo! Please feel free to change the licence to Apache 2.0. Its also my primary choice. Jan

[janosvitok]

AFAIK, copyright expires usually 70 years after author's death, which is too long to wait...

[keszybz]

plugins/udmx/src/libusb_dyn.c (which is GPLv2+) plugins/udmx/src/libusb_dyn.h (which is GPLv2+)

This is actually LGPLv2+ (GNU Lesser Public License), so it can be linked with ASL-2.0 licensed sources and the resulting binary can be distributed. The only question is whether the other files in plugins/udmx/src/ can be considered to be derived works from libusb_dyn.c. Considering that they can be compiled without libusb_dyn.h, the answer seems to be no:

#if defined(WIN32) || defined(Q_OS_WIN)
#   include <Windows.h>
#   include "libusb_dyn.h"
#else
#   include <usb.h>
#endif

This is the relevant part, which shows that the plugin just uses libusb_dyn.[ch] through a standarized interface, i.e. is not a derived work. No problem here.

plugins/hid/linux/hidapi.cpp (which is GPLv2+)

This is is multi-licensed, including under BSD license. So no problem, it can be combined with anything.

plugins/peperoni/win32/peperoni/usbdmx-dynamic.cpp (which is GPLv2+) plugins/peperoni/win32/peperoni/usbdmx-dynamic.h (which is GPLv2+)

This is now relicensed, so no problem.

webaccess/src/mongoose.c (which is GPLv2) webaccess/src/mongoose.h (which is GPLv2)

This one is tough. There is no way to satisfy both licenses (GPLv2 and ASL 2.0) simultaneously in one resulting program. Seperating the code into a library does not change anything, according to FSF [http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL]. It seems that the only options are:

1. remove mongoose.[ch]
2. relicense the other sources so they can be combined with GPLv2 (this could be relicensed as GPLv2, GPLv2+, or something more permissive like BSD), and distribute qlcplus under GPLv2 license.

[janosvitok]

Would it help if we split the mongoose to separate process and tunnel the few required calls using pipe or socket to the main application? (I know, this is a question for a lawyer or mongoose author; GPL FAQ mentions "fork and exec is OK").

[janosvitok]

I wonder if QtWebSockets/QtWebChannel might be used instead of mongoose...

[mcallegari]

Would it help if we split the mongoose to separate process and tunnel the few required calls using pipe or socket to the main application? (I know, this is a question for a lawyer or mongoose author; GPL FAQ mentions "fork and exec is OK").

There are a few "high rate" API like Simple Desk and I'm afraid an IPC channel can create a bottlneck at some point

I wonder if QtWebSockets/QtWebChannel might be used instead of mongoose...

Those are Qt5 only and that would mean saying a definite goodbye to Qt4. Plus they're fairly recent addition to Qt5 (not sure if Qt 5.2.1 included in Ubuntu 14.04 include them) and I don't trust so young technology to replace a consolidated software like Mongoose.

Instead, I am thinking to write a wrapper around mongoose and create libmongoose, released with GPL. The same way we dynamically link against libusb or libftdi. Might be a viable way ?

[janosvitok]

There are a few "high rate" API like Simple Desk and I'm afraid an IPC channel can create a bottlneck at some point

If it's fast enough for MySQL, it must be for QLC+.

I wonder if QtWebSockets/QtWebChannel might be used instead of mongoose...

Those are Qt5 only and that would mean saying a definite goodbye to Qt4.

Right.

Plus they're fairly recent addition to Qt5 (not sure if Qt 5.2.1 included in Ubuntu 14.04 include them) I'm afraid the minimum is 5.4 (I've read somewhere that 5.3 had bugs in this area).

Instead, I am thinking to write a wrapper around mongoose and create libmongoose, released with GPL.

When it's directly linked (statically or dynamically) it doesn't work that way: http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCGPLWrapper

The same way we dynamically link against libusb or libftdi.

Both are licenced under LGPL which is a big difference.

[mcallegari]

The same way we dynamically link against libusb or libftdi.

Both are licenced under LGPL which is a big difference.

Well, then we already have an issue with libmad (GPLv2) and libfftw (GPLv2+) !

[daveol]

when looking back at the commit history, you switched this project from GPLv2 to apache2.0 here, what was the reason behind that? maybe it is a good idea to switch back to fix all of this mess?

[janosvitok]

Reason for APL2.0 was CTK RangeSlider that is under APL 2.0.

It seems that the easiest way is to drop CTK Range Slider and go back to GPLv2...

[mcallegari]

1. I haven't received any reply from the Mongoose support
2. I will not switch back to any of the GPL flavours
3. According to http://www.apache.org/legal/resolved.html#category-x even a LGPL library cannot be included in a APL project. We're talking about the whole Qt framework here, so even the CTK widgets would be considered illegal because in some kind of way they are a "derivative work" of the Qt framework. This is not a APL fault, but instead the freaking willing of the Free Software foundation to impose their stupid rules to "open source" software and, because of them, it becomes impossible to re-use any GPL covered source unless your project is GPL as well. (which to me it sounds more like "close source" than anything)

In conclusion, I don't give a damn about this whole licensing stuff, especially because there is no money involved in this project. If someone wants the sources, they can be found online. Period. I will add a statement to the QLC+ website where I will say that the Mongoose files are released under GPLv2 and kept intact from the original sources.

I've made my decision and if this prevents QLC+ from entering the Fedora repositories, then I'm sorry, but these "open" licenses should consider the "best" or "malicious" intentions of a developer in the first place, and not who has the longer dick. I'm not going to be part of any incompatibility war between GNU and Apache, and if someone tries to involve me on legal matters, I will close the project right away.

[mcallegari]

@daveol , by the way, the discussion happening here is misleading

Zbigniew Jędrzejewski-Szmek says (referring to Mongoose):

Seperating the code into a library does not change anything, according to FSF [http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL].

while the linked page says:

You have a GPL'ed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program? Yes

QLC+ is not a proprietary program

and again (in the next FAQ):

The idea of the GPL is that if you want to include our code in your program, your program must also be free software. It is supposed to put pressure on you to release your program in a way that makes it part of our community.

QLC+ is a free software, but it's not part of the "our community", and doesn't want to be cause of their stupid rules

[keszybz]

I urge you to not leave this unresolved. As is, QLC+ is free software, and can be freely used, even when linked with the GPLv2-only mongoose, but it's not freely distributable when compiled. This limits its usefulness a lot. There are people who would like to make it more widely available and use it themselves (hence the Fedora package review). For most people compiling from source is too hard, and for a program to have wider use, precompiled binaries need to be provided. Current licensing forbids the distribution of such binaries.

Nobody enjoys this licensing stuff. Linux distribution packagers certainly don't. Nevertheless, the existence of Linux distributions depends on copyleft licensing, and we have no choice but to take licensing seriously. Mongoose authors specified a license which sets certain rules how their software can be used, which can be annoying, but it's their right to do so.

I will not switch back to any of the GPL flavours

OK. What about BSD-style license? This license is similarly permissive to ASL 2.0 and would allow the binaries to be distributed under GPL2.

According to http://www.apache.org/legal/resolved.html#category-x even a LGPL library cannot be included in a APL project.

Yes, because Apache Foundation wants all of their products to be distributable without further restrictions and wants to keep their licensing uniform. So GPL/LGPL are forbidden for their software repository, but this doesn't apply to all software under the ASL.

@daveol:

QLC+ is not a proprietary program

"Proprietary" here means just "differently licensed".

QLC+ is a free software, but it's not part of the "our community", and doesn't want to be cause of their stupid rules

That's totally fine. Nobody is forcing QLC+ authors to do anything. But also nobody is forcing them to use mongoose. But if they want to use mongoose, then unfortunately the only way is to accept the rules under which it is given.

[mcallegari]

@keszybz thanks for your intervention and your patience

Changing the license of the whole project is something that I would like to avoid. Instead, considering to drop mongoose seems like a more viable option to me, since it is clear their intention is to make money with it. Mongoose was just a shortcut to avoid writing a ton of code and if I find an alternative (more flexible) solution, I'll happily do the port to it. I've had a quick look at libmicrohttpd (the same OLA uses), but it lacks the support for websockets, which we use a lot. They have to be implemented "manually" via HTTP responses.

I'll continue the search in the next days.

[EDIT] Something like this: https://github.com/vinipsmaker/tufao [EDIT2] Most likely we can do everything with this: https://libwebsockets.org/index.html, which includes basic HTTP commands and it's already deployed on many distros

[mcallegari]

Just a quick update. I played a bit with libwebsockets (LGPL2). Latest version would be perfect BUT:

• the mandatory version for QLC+ is 1.3 and above (HTTP POST support has been added quite late)
• Ubuntu 14.04 delivers version 1.2.2
• Fedora is still reviewing version 1.6 (correct me if I'm wrong)
• MSYS2 on Windows delivers version 1.4 (so it would be OK)
• macports on OSX doesn't include it at all

So ATM it is a no go :cry: I'm still digging the net to find a solution suitable for Qt and APL, with no luck yet. I'm sad.

[trebmuh]

hi @mcallegari are you 100% sure that Ubuntu delivers any QLC version ? I can't find one using their tool : http://packages.ubuntu.com/ neither in debian : http://packages.debian.org/ . You might then refer to a PPA. So, if Ubuntu is the only no-go from your side, a solution could to try to get a QLC+ version > 1.3 into Debian (then ubuntu would take it from there). What do you think ?

[mcallegari]

are you 100% sure that Ubuntu delivers any QLC version ?

Please read my last post again. The subject is libwebsockets and not QLC+.

[trebmuh]

My bad.

[mcallegari]

[EDIT] I got rid of Mongoose. See https://github.com/mcallegari/qlcplus/tree/newweb

I've used a bit of MIT code to speed up the transition, and included the related license files in the subfolder

[mcallegari]

@daveol @keszybz I've merged the new web server code into master. It includes some MIT code and I have left the original file headers unaltered. However, the Fedora package review has been closed, so I'm not sure if it can be re-opened or if there's still interest in having QLC+ in the official repos.

Please just let me know, otherwise I will close this issue as well.

[daveol]

I'll give it a try when the next version rolls around

[mcallegari]

Alright, thanks. 4.10.3 should happen in a week or so.

[mcallegari]

A month has passed. Closing for inactivity.