LGPL for Breeze QStyle and qtquickcontrols?

[Martin Graesslin]

On Tuesday, May 17, 2016 2:21:43 PM CEST Jaroslaw Staniek wrote:
> On 9 May 2016 at 07:53, Martin Graesslin <mgraesslin at kde.org> wrote:
> > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> > > Hi,
> > > Is relicensing Breeze QStyle to LGPL from GPL for possible and
> > 
> > acceptable?
> > 
> > > I've found cases when bits of the code beyond QStyle/KStyle API need
> > > to be reused. One example is: custom widgets.
> > > If we're considering Breeze QStyle as implementation of certain
> > > artwork, and KDE artwork in general would be LGPL also for
> > > consistency.
> > > For example wallpapers, icons are LGPL.
> > > 
> > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> > > it's not clear in breeze.git. The same question here: can it be LGPL
> > > or BSD?
> > > 
> > > Bottom line is: if we want to popularise our frameworks in the outside
> > > world...
> > 
> > I fail to follow you why Breeze QStyle should be a framework. No framework
> > should depend on it, Breeze QStyle is a plugin and it's only getting
> > loaded by
> > either setting an env variable manually or using the Plasma QPT plugin
> > which
> > is not in Frameworks either.
> 
> ​Not only KF5 is LGPL. ​Also other libraries and also parts of individual
> apps.

And there are also libraries which are GPL. E.g. kwineffects or kscreenlocker 
library.

> BTW: The latter help to create frameworks in the future (picking GPL too
> early kills the idea).

No it doesn't. It just means that one needs to get everybody to agree on the 
relicense. If you show me why it needs to be a framework and I agree with it, 
I might be willing to consider to allow to relicense the code I wrote for it.

> 
> > Anyway on the question of whether to relicense to LGPL you should ask the
> > copyright holders and I doubt you found them here on frameworks-devel as
> > Breeze is not a framework. I'm one of the copyright holders and as I don't
> > understand why you want it relicensed I would not agree to it. I think GPL
> > is
> > the proper license for our workspace components.
> 
> I'd like more explanation to know if you disagree just for the sake...

of course not!

> Don't you agree with LGPL for breeze or oxygen icons?

We have applications which depend on breeze and oxygen icons. That's why we 
moved them to frameworks. Applications depend on it, LGPL is the proper 
license.

The style though is part of Plasma Workspace and as that should follow the 
licensing of Plasma components which is GPL.  This also applies to many 
libraries in Plasma.

> 
> Styles are in *the same* group. They make-our-user-experience.

They make up the user-experience of Plasma. Not of the applications.

> 
> Icons are part of the KF5 product [1] which does not mean libraries depend
> on them
> https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> (well I believe as a product they depend but that's out-of-the box level
> thinking not belonging here)

libraries do depend on icons. Otherwise there wouldn't be efforts on how to 
package all required icons in the case of Android.

> 
> Do you then agree with relicensing after my explanations here and in the
> other email?

no, sorry, I still don't see why that would be needed.

> 
> The request is about the freedom to use of the code from of the breeze
> style in LGPL code freely opening freedom for experimentation and progress.
> The design (by VDG) is free to use (LGPL I think), why wouldn't the
> implementation be free-to-link?

I repeat again: I object to a relicense of code I have written to GPL in the 
case of Breeze and Oxygen.

> 
> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
> clearly as these would be actually scripts and graphic/style files. Why
> would we have inferior situation just because we happen to use compilers?

I don't see what that has to do with it.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160517/cde4887c/attachment.sig>