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