LGPL a possibility for Breeze Qt widget style?

[Elvis Stansvik]

2017-03-10 23:26 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
> 2017-03-09 19:21 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>> 2017-03-09 18:41 GMT+01:00 Jonathan Riddell <jr at jriddell.org>:
>>> On Thu, Mar 09, 2017 at 06:30:36PM +0100, Elvis Stansvik wrote:
>>>> I just wish the FSF FAQ was more clear on this (direct dynamic linking vs
>>>> dlopen()ing).
>>>
>>> They can't be more clear as the definition of derived work is set by
>>> legislatures and courts in different justictions and will differ.
>>
>> Ah yes, that is true. But it would still be nice if they did a
>> write-up on what their intention is, even if it's always up to the
>> copyright legislation in the applicable jurisdictions in the end. They
>> do elaborate on their view of the distinction between fork/exec and
>> dynamic linking in their FAQ after all.
>
> In the end, I realized it wasn't really feasible to bundle Breeze
> inside the AppImage anyway, because of the many KF5 dependencies. I
> thought that the widget style .so would only have Qt as dependency,
> but realize now that it does a fair amount of integration with Plasma
> as well.

For the heck of it, I gave it a go anyway, and it seems to work out
fine. I was able to build/install ECM, KWindowSystem, KConfig,
KGuiAddons, KCodecs, KWidgetAddons, KCoreAddons, KAuth, KI18n,
KConfigWidgets, KArchive, KPackage and finally Breeze in the CentOS
6.7 Docker image I use for AppImage builds. The additional breeze.so +
dependencies added around 7 MB to my image. This is quite a chunk, but
I think it's acceptable, to get the Breeze look, since the primary
target machines will be running Plasma. Everything seems to be working
fine from my first tests, the AppImage even respects the Breeze
settings and color scheme from "outside" the image.

Elvis

>
> Elvis
>
>>
>> Elvis
>>
>>>
>>> Also they don't want to be clear, they want everything to be GPL.
>>>
>>> Jonathan