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.

Digging a little further, all I could find at FSF about dlopen is this tidbit:

"5. Full object-file-level link, call, and interface map (not required
for 100% Free Software products). This link and call map should
include:

a. all dynamic links in the system that cannot be determined with the
ldd command(e.g., links done with dlopen()).
b. for each object file, a list of functions defined in that object
file, and a list of functions that are called from that object file.
c. a work-flow description between any GPL-compatible and
GPL-incompatible bi-nary components that communicate in ways other
than static or dynamic linking. (Examples of such communication are
IPC, network protocols, named pipes, and shared data files.)"

This is from their submission requirements you have to fulfill if you
submit your product to their certification program [1]. That they want
you to submit information about which parts you interact with through
dlopen(..) suggests to me that they might consider this as regular
dynamic linking.

Elvis

[1] https://www.fsf.org/licensing/compliancelab.html

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