LGPL a possibility for Breeze Qt widget style?

[Elvis Stansvik]

2017-03-09 9:00 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
> 2017-03-09 7:15 GMT+01:00 Martin Gräßlin <mgraesslin at kde.org>:
>> Am 2017-03-08 22:04, schrieb Elvis Stansvik:
>>>
>>> 2017-03-08 20:55 GMT+01:00 David Edmundson <david at davidedmundson.co.uk>:
>>>>
>>>> There was a thread:
>>>> https://mail.kde.org/pipermail/kde-frameworks-devel/2016-May/034272.html
>>>>
>>>> I'm not sure it helps much.
>>>
>>>
>>> Oh wow. What a hornets nest that thread was! Almost too technical for
>>> me to understand. But it's clear to me after reading it that LGPLing
>>> of the Breeze style seems out of the question. It's a little sad
>>> because I don't think Jaroslaw presented his case very
>>> well/succinctly, and I understand Martins failure to see any strong
>>> reasons for LGPLing in his reasoning.
>>
>>
>> I must say that I find your argument way more convincing to put it on
>> LGPL. That said I don't think a relicense is feasible due to the historic
>> nature of breeze which is in large parts based on Oxygen code, thus has
>> dozens of developers on it and a decade of code history.
>
> Alright, that's understandable. Partly why I called this a "long shot"
> in my original post :)
>
>>
>> The issue you raise is very valid. App images don't get the integration.
>> And that's not just the widget style, but also things like lacking
>> plasma-integration. Many won't work on Wayland, due to not including
>> qtwayland, etc. etc.
>
> Yes, the platform integration is another issue (in our case, mostly
> the file dialog). I guess it would have been possible to bundle that
> in the AppImage as well though? Wayland is also a good point, though
> our app has other dependencies that I think are unfortunately X11 only
> at the moment (VTK, ...).
>
>>
>> I think we need to come up together with distributions to a solution
>> which allows app images to be a first class citicen.
>
> Yea, it's still young technology, and this was just an idea for an
> experiment from my side. We'll probably go with the APT repo approach
> as distribution method, at least initially.
>
>>
>> For the case of breeze I don't think that a relicense to LGPL is needed.
>> The argumentation from the other thread holds, though IANAL, you only
>> load the plugin at runtime and it's not a derived work. It is the intended
>> usage.
>
> Hm, I'm not sure (and of course not a lawyer either), and I want to
> tread lightly here.
>
> By creating an AppImage, where the AppImage is configured to make the
> bundled Breeze available (e.g. by setting up QT_PLUGIN_PATH I guess?),
> am I not creating a derived work? I know that nothing in my AppImage
> would link directly to Breeze, but wouldn't it become a derived work
> when the link is established (even if it's indirect)?
>
> The relevant FSF FAQs I could find are:
>
> https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
> https://www.gnu.org/licenses/gpl-faq.en.html#NFUseGPLPlugins
>
> https://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF

Bah, I hit send too soon. This last part was supposed to be:

The relevant FSF FAQs I could find are:

https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation
https://www.gnu.org/licenses/gpl-faq.en.html#GPLAndPlugins
https://www.gnu.org/licenses/gpl-faq.en.html#NFUseGPLPlugins
https://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF

The plugin ones only speak of fork/exec vs dynamic linking as the
dividing line, but doesn't go into detail on the difference between
link-time and run-time linking.

Elvis

>
>>
>> Cheers
>> Martin