Den 9 mars 2017 11:24 fm skrev "Jonathan Riddell" <j...@jriddell.org>: > > On Wed, Mar 08, 2017 at 10:04:56PM +0100, Elvis Stansvik wrote: > > 1) I want to make an AppImage of a GPL-incompatible Qt application, > > that bundles a newer Qt than the one provided by the target system. > > Go ahead > > The main unresolved issue with AppImage as I see it is not being able > to provide source code in a convenient way for the bits which are GPLed. > The same is true to Snap and FlatPak as far as I can see. > > > 2) I want that application to look native under Plasma, hence I'd like > > to bundle a Breeze built against the bunded Qt. > > Shouldn't be a problem. Breeze is a plugin of Qt and you can provide > the full source code on request (even if Appimage doesn't give any > convenient way to do so). It's not a derived work of your application > just as when I install Skype on my laptop which uses Qt and it uses > breeze that doesn't make Skype a derived work of breeze. > > Putting it inside an AppImage is mere aggregation just as any distro > making a package of Skype and of breeze and putting it on an ISO is > mere aggregation.
Alright, I just wasn't sure if aggregating a GPL plugin (in the dlopen()ing sense) with an application and distributing that aggregation constitutes creating a derived work in the eyes of GPL. But since you give an counter example I feel more confident now that it doesn't. I just wish the FSF FAQ was more clear on this (direct dynamic linking vs dlopen()ing). > > In the case of the other thread he did want to reuse parts of Breeze > code in custom widgets which would make it a derived work. That's not > the case for your app. Right. Elvis > > Jonathan
