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