LGPL a possibility for Breeze Qt widget style?

[Elvis Stansvik]

2017-03-09 9:02 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
> 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.

Or rather I mean the difference between letting the system runtime
linker do the job vs calling dlopen(..).

Elvis

>
> Elvis
>
>>
>>>
>>> Cheers
>>> Martin