Bug 1297821

daveo's scratch build of qlcplus-4.10.2b-1.fc23.src.rpm for f24 completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12516794

I experienced with Qt and know what is DMX, so I started reviewing this spec.

Your spec is in the very good state.

--------------------------------------------------------------------------------

> Summary:          Q Light Controller Plus

Please try to fit some basic information about "Q Light Controller Plus"
purpose rather than expand %{name}.

--------------------------------------------------------------------------------

> License:          ASL 2.0 and GPLv2+ and BSD and GPLv2 and MIT
> the whole project is licensed under Apache-2.0 execept for

Disclaimer: I'm not IP lawyer, please consider this part of my review as an advice. I hope somebody more experienced in licensing practices will be able to take a look on this package too.

> qmlui/qml/FontAwesomeVariables.qml which is MIT/X11
> ui/src/flowlayout.cpp and ui/src/flowlayout.h which are BSD

It is ok to distribute MIT/X11 sources under Apache-2.0, see http://apache.org/legal/resolved.html

> plugins/udmx/src/libusb_dyn.c and plugins/udmx/src/libusb_dyn.h which are GPLv2+

GPLv2 source can't be re-licensed under Apache 2.0
Anyway, "LIBUSB-WIN32, Generic Windows USB Library" - do you actually use this file on Fedora? I think you can remove this file from a tarball or from a build tree during %prep stage.

> webaccess/src/mongoose.c and webaccess/src/mongoose.h which are GPLv2

It is OK to make a subpackage with different license if this file is used by a plugin. 
It seems that GPLv2 mongoose.c is used as a part of libqlcplus:
Binary file ./libqlcplus-4.10.2b-1.fc24.x86_64.rpm/usr/lib64/libqlcpluswebaccess.so.1.0.0 matches
Binary file ./libqlcplus-4.10.2b-1.fc24.x86_64.rpm/usr/lib64/libqlcpluswebaccess.so.1.0 matches
Binary file ./libqlcplus-4.10.2b-1.fc24.x86_64.rpm/usr/lib64/libqlcpluswebaccess.so.1 matches
Is it possible to split this library into a plugin?

More GPLv2+ files:

+qlcplus-QLC-_4.10.2b/plugins/hid/linux/hidapi.cpp
+qlcplus-QLC-_4.10.2b/plugins/peperoni/win32/peperoni/usbdmx-dynamic.cpp
+qlcplus-QLC-_4.10.2b/plugins/peperoni/win32/peperoni/usbdmx-dynamic.h

Upstream claims to be licensed under ASL 2.0. I hope you will be able to deal with libusb and mongoose and license the main package as ASL 2.0, as it was desired by upstream. If in doubt, please ask upstream to resolve this confusion [1].

[1]: https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification

--------------------------------------------------------------------------------

Please ensure that license file is present when any subpackage combination is installed.

--------------------------------------------------------------------------------

> %package plugin-artnet
> %package plugin-dmx4linux
> %package plugin-dmxusb
> %package plugin-e131
> %package plugin-enttecwing
> %package plugin-hid
> %package plugin-loopback
> %package plugin-midi
> %package plugin-osc
> %package plugin-peperoni
> %package plugin-spi
> %package plugin-udmx
> %package plugin-ola

Do you actually want to split all plugins into separate packages?
How it is supposed to be installed by the end user?
Shouldn't main package Recommends [3] for plugins needed for 99% of users?

> Typical use cases for weak dependencies are:
> Plug-ins or add-ons
> Support for file formats
> Support for protocols
> ...

[3]: https://fedoraproject.org/wiki/Packaging:WeakDependencies

The packaging scheme is very good, though.

--------------------------------------------------------------------------------
># fedora specific patch 
>Patch0:           qlcplus.ola-pkgconfig.patch
># fixed upstream: https://github.com/mcallegari/qlcplus/commit/16b6728e5066a041297bc4d424ada515e85a1e75
>Patch1:           qlcplus.install-paths.patch
># fixed upstream: https://github.com/mcallegari/qlcplus/commit/e29f34f7e89db4db3fce3bcb8449f991ef3b9a1f
>Patch2:           qlcplus.udev-rules-path.patch
># under review: https://github.com/mcallegari/qlcplus/pull/735
>Patch3:           qlcplus.fix-translate.patch
># fixed upstream:
># https://github.com/mcallegari/qlcplus/commit/7dcc3cc006a6b03b659be99b72f9a23ce8b277c2
># https://github.com/mcallegari/qlcplus/commit/81308651bab16a50eb35e8a0431c62de9f94942c
># https://github.com/mcallegari/qlcplus/commit/c6eff5b6b4d3852d922e7c966c21b33faf74299f
>Patch4:           qlcplus.fix-licenses.patch
># fedora specific patch
>Patch5:           qlcplus.fedora-revision.patch

I personally dislike idea of manually cherry-picking bugfixes from upstream's
git tree. It is like supporting a new fork and so requires too many efforts.
Ideally, it should be possible to bump `Version:` and then get spec for the
next release.

Your efforts to push all requires changes to the upstream is the right direction.
It is possible to make a snapshot package directly from git [2] and then wait for the next tagged release.

[2]: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

--------------------------------------------------------------------------------

> Source1:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/etc/qlcplus.appdata.xml
> Source2:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/etc/qlcplus-fixtureeditor.appdata.xml
> # metainfo files from upstream
> Source3:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/E1.31/qlcplus-e131.metainfo.xml
> Source4:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/artnet/src/qlcplus-artnet.metainfo.xml
> Source5:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/dmx4linux/qlcplus-dmx4linux.metainfo.xml
> Source6:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/dmxusb/src/qlcplus-dmxusb.metainfo.xml
> Source7:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/enttecwing/src/qlcplus-enttecwing.metainfo.xml
> Source8:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/hid/linux/qlcplus-hid.metainfo.xml
> Source9:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/loopback/src/qlcplus-loopback.metainfo.xml
> Source10:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/midi/qlcplus-midi.metainfo.xml
> Source11:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/ola/qlcplus-ola.metainfo.xml
> Source12:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/osc/qlcplus-osc.metainfo.xml
> Source13:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/peperoni/unix/qlcplus-peperoni.metainfo.xml
> Source14:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/spi/qlcplus-spi.metainfo.xml
> Source15:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/udmx/src/qlcplus-udmx.metainfo.xml

All these files already exist in the source tarball, generated by GitHub.

--------------------------------------------------------------------------------

Minor issue, please report to upstream:

libqlcplus.x86_64: E: missing-call-to-setgroups-before-setuid /usr/lib64/libqlcpluswebaccess.so.1.0.0

https://github.com/mcallegari/qlcplus/blob/49a0a6d29070bc17a632f84f0a18add8ba859573/webaccess/src/mongoose.c#L5096-L5101

--------------------------------------------------------------------------------

Please open a ticket in the upstream to create simple man pages for
binaries un /usr/bin:

/usr/bin/qlcplus
/usr/bin/qlcplus-fixtureeditor

--------------------------------------------------------------------------------

Probably -data should depend on lib, but I'm not sure about that.
--------------------------------------------------------------------------------

=> Licensing and tarball are main problems.
Great work. Thanks!

> > Summary:          Q Light Controller Plus
> 
> Please try to fit some basic information about "Q Light Controller Plus"
> purpose rather than expand %{name}.

Okay, how about "DMX light controller software"

> > qmlui/qml/FontAwesomeVariables.qml which is MIT/X11
> > ui/src/flowlayout.cpp and ui/src/flowlayout.h which are BSD
>
> It is ok to distribute MIT/X11 sources under Apache-2.0, see http://apache.org/legal/resolved.html

The MIT/X11 source is for something that comes in a later release, the 5.0 release if I remember correctly. The BSD source gets used though

> > plugins/udmx/src/libusb_dyn.c and plugins/udmx/src/libusb_dyn.h which are GPLv2+
> 
> GPLv2 source can't be re-licensed under Apache 2.0
> Anyway, "LIBUSB-WIN32, Generic Windows USB Library" - do you actually use
> this file on Fedora? I think you can remove this file from a tarball or from
> a build tree during %prep stage.

Well these seem to be GPLv2+ so it can be re-licensed to GPLv3 which is compatible with the apache2.0 license

> > webaccess/src/mongoose.c and webaccess/src/mongoose.h which are GPLv2
> 
> It is OK to make a subpackage with different license if this file is used by
> a plugin.
> Is it possible to split this library into a plugin?

Does it have to be a plugin? or can it be a separate library too?

> More GPLv2+ files:
> 
> +qlcplus-QLC-_4.10.2b/plugins/hid/linux/hidapi.cpp
> +qlcplus-QLC-_4.10.2b/plugins/peperoni/win32/peperoni/usbdmx-dynamic.cpp
> +qlcplus-QLC-_4.10.2b/plugins/peperoni/win32/peperoni/usbdmx-dynamic.h
> 
> Upstream claims to be licensed under ASL 2.0. I hope you will be able to
> deal with libusb and mongoose and license the main package as ASL 2.0, as it
> was desired by upstream. If in doubt, please ask upstream to resolve this
> confusion [1].
> 
> [1]:
> https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/
> LicensingGuidelines#License_Clarification
> 

Again GPLv2+ can be re-licensed under GPLv3, and since GPLv3 is compatible with apache2.0 that seems to solve the problem. I have opened a issue on their github which can be found here[1]

[1]: https://github.com/mcallegari/qlcplus/issues/760

> Please ensure that license file is present when any subpackage combination
> is installed.

Good point, I will put them in the -data package next revision

> > %package plugin-artnet
> > %package plugin-dmx4linux
> > %package plugin-dmxusb
> > %package plugin-e131
> > %package plugin-enttecwing
> > %package plugin-hid
> > %package plugin-loopback
> > %package plugin-midi
> > %package plugin-osc
> > %package plugin-peperoni
> > %package plugin-spi
> > %package plugin-udmx
> > %package plugin-ola
> 
> Do you actually want to split all plugins into separate packages?
> How it is supposed to be installed by the end user?
> Shouldn't main package Recommends [3] for plugins needed for 99% of users?
> 
> > Typical use cases for weak dependencies are:
> > Plug-ins or add-ons
> > Support for file formats
> > Support for protocols
> > ...
> 
> [3]: https://fedoraproject.org/wiki/Packaging:WeakDependencies

I will add some Recommends in the next revision. I think this is a better way of doing things honestly, since for advanced users now have the ability to strip away plugins without it breaking every update.


> ># fedora specific patch 
> >Patch0:           qlcplus.ola-pkgconfig.patch
> ># fixed upstream: https://github.com/mcallegari/qlcplus/commit/16b6728e5066a041297bc4d424ada515e85a1e75
> >Patch1:           qlcplus.install-paths.patch
> ># fixed upstream: https://github.com/mcallegari/qlcplus/commit/e29f34f7e89db4db3fce3bcb8449f991ef3b9a1f
> >Patch2:           qlcplus.udev-rules-path.patch
> ># under review: https://github.com/mcallegari/qlcplus/pull/735
> >Patch3:           qlcplus.fix-translate.patch
> ># fixed upstream:
> ># https://github.com/mcallegari/qlcplus/commit/7dcc3cc006a6b03b659be99b72f9a23ce8b277c2
> ># https://github.com/mcallegari/qlcplus/commit/81308651bab16a50eb35e8a0431c62de9f94942c
> ># https://github.com/mcallegari/qlcplus/commit/c6eff5b6b4d3852d922e7c966c21b33faf74299f
> >Patch4:           qlcplus.fix-licenses.patch
> ># fedora specific patch
> >Patch5:           qlcplus.fedora-revision.patch
> 
> I personally dislike idea of manually cherry-picking bugfixes from upstream's
> git tree. It is like supporting a new fork and so requires too many efforts.
> Ideally, it should be possible to bump `Version:` and then get spec for the
> next release.
> 
> Your efforts to push all requires changes to the upstream is the right
> direction.
> It is possible to make a snapshot package directly from git [2] and then
> wait for the next tagged release.
> 
> [2]:
> https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages

I don't think a snapshot package would go good for this package since the recent development doesn't make it that stable. I would rather keep up with normal releases then going with an unstable snapshot.
 
> > Source1:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/etc/qlcplus.appdata.xml
> > Source2:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/etc/qlcplus-fixtureeditor.appdata.xml
> > # metainfo files from upstream
> > Source3:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/E1.31/qlcplus-e131.metainfo.xml
> > Source4:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/artnet/src/qlcplus-artnet.metainfo.xml
> > Source5:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/dmx4linux/qlcplus-dmx4linux.metainfo.xml
> > Source6:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/dmxusb/src/qlcplus-dmxusb.metainfo.xml
> > Source7:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/enttecwing/src/qlcplus-enttecwing.metainfo.xml
> > Source8:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/hid/linux/qlcplus-hid.metainfo.xml
> > Source9:          https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/loopback/src/qlcplus-loopback.metainfo.xml
> > Source10:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/midi/qlcplus-midi.metainfo.xml
> > Source11:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/ola/qlcplus-ola.metainfo.xml
> > Source12:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/osc/qlcplus-osc.metainfo.xml
> > Source13:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/peperoni/unix/qlcplus-peperoni.metainfo.xml
> > Source14:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/spi/qlcplus-spi.metainfo.xml
> > Source15:         https://github.com/mcallegari/qlcplus/raw/c126fcaaf59622009db8e3dca1f72e47bd9e77bd/plugins/udmx/src/qlcplus-udmx.metainfo.xml
> 
> All these files already exist in the source tarball, generated by GitHub.

Not the source tarball for the most recent release, however this is probably because you mentioned the git snapshot package.

> 
> Minor issue, please report to upstream:
> 
> libqlcplus.x86_64: E: missing-call-to-setgroups-before-setuid
> /usr/lib64/libqlcpluswebaccess.so.1.0.0
> 
> https://github.com/mcallegari/qlcplus/blob/
> 49a0a6d29070bc17a632f84f0a18add8ba859573/webaccess/src/mongoose.c#L5096-L5101

Done: https://github.com/mcallegari/qlcplus/issues/759

> 
> Please open a ticket in the upstream to create simple man pages for
> binaries un /usr/bin:
> 
> /usr/bin/qlcplus
> /usr/bin/qlcplus-fixtureeditor
> 

https://github.com/mcallegari/qlcplus/issues/761

> Probably -data should depend on lib, but I'm not sure about that.

How is that? -data doesn't need anything from lib, data and lib get installed when you install either qlcplus or qlcplus-fixtureeditor

> Does it have to be a plugin? or can it be a separate library too?

libqlcpluswebaccess.so.1 contains GPLv2+ code, that means you have to re-license libqlcpluswebaccess.so under GPLv2+. Your binary linked with shared librarylibqlcpluswebaccess.so => the binary also have to be re-licesned under GPLv2+. That is exactly how copyleft designed to work.

> Well these seem to be GPLv2+ so it can be re-licensed to GPLv3 which is compatible with the apache2.0 license

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. [1]

[1]: http://www.apache.org/licenses/GPL-compatibility.html

> Not the source tarball for the most recent release, however this is probably because you mentioned the git snapshot package.

It looks like an attempt to backport new features from the trunk. Original qclplus 4.10.2b doesn't have these files (=features), right? Why not package 4.10.2b as it was expected by the upstream? It is OK to backport critical bugfixes for security vulnerabilities, crashes, memory leaks and so on. New features should increment at least minor version of software. Please don't mislead the users.

> I don't think a snapshot package would go good for this package since the recent development doesn't make it that stable. I would rather keep up with normal releases then going with an unstable snapshot.

Yes, that is exactly what I wanted. I agree with the approach to keep up with normal upstream's releases or create an unstable snapshot.

> How is that? -data doesn't need anything from lib, data and lib get installed when you install either qlcplus or qlcplus-fixtureeditor

I had orphaned qlcplus-data after removing qlcplus and qlcplus-fixtureeditor using dnf. It seems that this problem was caused by `rpm -i *.rpm`. 
`dnf autoremove` should work for this case when -data installed implicitly as a dependency. Sorry for my inadvertence.

> libqlcpluswebaccess.so.1 contains GPLv2+ code, that means you have to
> re-license libqlcpluswebaccess.so under GPLv2+. Your binary linked with
> shared librarylibqlcpluswebaccess.so => the binary also have to be
> re-licesned under GPLv2+. That is exactly how copyleft designed to work.

I was more thinking of a whole separate lib only for mongoose, that would be something like libqlcplusmongoose.so, so libqlcpluswebaccess.so links to libqlcplusmongoose.so for the mongoose functionality. 
 
> It looks like an attempt to backport new features from the trunk. Original
> qclplus 4.10.2b doesn't have these files (=features), right? Why not package
> 4.10.2b as it was expected by the upstream? It is OK to backport critical
> bugfixes for security vulnerabilities, crashes, memory leaks and so on. New
> features should increment at least minor version of software. Please don't
> mislead the users.

It was originally not a backport, it is now because of my work to patch upstream, this is a feature that doesn't impact performance or the program itself in any way, it is only appstream metadata[1] which fedora suggests including for desktop applications[2]. You can see they originally came from me if you look at the copyright header. I wanted the upstream ones since the maintainer made a couple changes and it included a couple translations.

[1]: http://www.freedesktop.org/software/appstream/docs/sect-Metadata-Application.html
[2]: https://fedoraproject.org/wiki/Packaging:AppData

Spec URL: https://bewaar.me/fedora/qlcplus/4.10.2b-2/qlcplus.spec
SRPM URL: https://bewaar.me/fedora/qlcplus/4.10.2b-2/qlcplus-4.10.2b-2.fc23.src.rpm

New revision, it fixes some weak dependencies and changes the summary

daveo's scratch build of qlcplus-4.10.2b-2.fc23.src.rpm for f24 completed http://koji.fedoraproject.org/koji/taskinfo?taskID=12574662

>-Release:          1%{?dist}
>-Summary:          Q Light Controller Plus
>+Release:          2%{?dist}
>+Summary:          DMX light controller software

OK.

> +Recommends:       %{name}-plugin-artnet = %{version}-%{release}
> +Recommends:       %{name}-plugin-dmxusb = %{version}-%{release}
> +Recommends:       %{name}-plugin-e131 = %{version}-%{release}
> +Recommends:       %{name}-plugin-udmx = %{version}-%{release}
> +Recommends:       %{name}-plugin-loopback = %{version}-%{release}
> +Recommends:       %{name}-plugin-midi = %{version}-%{release}
> +Recommends:       %{name}-plugin-osc = %{version}-%{release}
> +Suggests:         %{name}-plugin-enttecwing = %{version}-%{release}
> +Suggests:         %{name}-plugin-hid = %{version}-%{release}
> +Suggests:         %{name}-plugin-peperoni = %{version}-%{release}
> +Suggests:         %{name}-plugin-spi = %{version}-%{release}
> +Suggests:         %{name}-plugin-ola = %{version}-%{release}
> +Suggests:         %{name}-plugin-dmx4linux = %{version}-%{release}

OK.

I'm still not confident that GPLv2 + ASL 2.0 problem is handled properly.

I'm not sure that newbie members like me can make this decision on their own. I asked for help from Zbigniew Jędrzejewski-Szmek who reviewed my packages.

Lots of issues discussed, but let's concentrate on the mongoose part, because it seems most serious.

webaccess/src/mongoose.c is GPLv2 (not GPLv2+). This seems intentional, part of dual licensing scheme by cesanta. Other sources are ASL 2.0. Those two licenses are incompatible, in the meaning that it is not possible to distribute the resulting binary and satisfy both licenses ["Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2" from http://www.apache.org/licenses/GPL-compatibility.html.
"Please note that this license is not compatible with GPL version 2, because it has some requirements that are not in that GPL version." from http://www.gnu.org/licenses/license-list.html#apache2].

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].

Upstream is apparently trying to fix the licensing mess, so there's some hope.
But things currently stand, this package cannot be added to Fedora.

I'll comment some more on the github issue.

I agree this is quite the mess, an that this package is currently not in a state it can be shipped.... I will keep in touch with upstream and when they have fixed all of this mess I'll try again.

After the last two comments from upstream i'll close this review indefinitely, since i don't think communication with upstream can exist in a normal fashion after this licensing talk.

qlc+ replaced mongoose with libwebsockets: https://github.com/mcallegari/qlcplus/commit/ddcde1a1684c8f73da4a5ee3c21148b83de6e90f. libwebsockets review is finished, it should be available in repos shortly.

In the end qlc+ upstream handled this issue properly. Dave, what do you think, maybe we should revisit this?

sure, are you willing to do the review? They sill use a library though, this time it's qhttpserver[1], which seems to be licensed under the MIT license. Should I unbundle that?

1. https://github.com/nikhilm/qhttpserver

Yes, I can do the review.

https://github.com/nikhilm/qhttpserver/commit/a051b3773b2c2dc123da79568c7c1e35cd511dc1 suggests that qhttpserver is not worth packaging on its own. It's really up to you, whether you think that the unbundled project would be useful elsewhere and is worth your time to do it. According to the new rules [https://fedorahosted.org/fesco/ticket/1483#comment:17] you don't have to unbundle it.