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. Elvis > >> >> Cheers >> Martin
