2017-03-09 9:02 GMT+01:00 Elvis Stansvik <elvst...@gmail.com>: > 2017-03-09 9:00 GMT+01:00 Elvis Stansvik <elvst...@gmail.com>: >> 2017-03-09 7:15 GMT+01:00 Martin Gräßlin <mgraess...@kde.org>: >>> Am 2017-03-08 22:04, schrieb Elvis Stansvik: >>>> >>>> 2017-03-08 20:55 GMT+01:00 David Edmundson <da...@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
