LGPL for Breeze QStyle and qtquickcontrols?

Tue May 17 18:38:32 UTC 2016

On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > 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.
> 
> There's no request to make it framework from me. LGPLing Breeze does not
> automatically add obligation to create and maintain a framweork. Especially
> that there are not widely declared use cases. It's just a way to get the
> same what was legal in the times of Oxygen and KDElibs 4.

Yes exactly! If you would present me reasons why it should become a framework 
I might see a need for it to have it LGPL. That is something I currently don't 
see. Thus I don't see a reason to change it to LGPL.

Similar I don't relicense KWin to LGPL, just because there might be a reason 
later on.  When we split out code from KWin to KWayland we did the relicense 
as needed.

> Why on the icons and not on style? (See also below)
> I have apps/libs that hard-depend on breeze style. (not just the
> implementation, on the design)
> Example reason: because for my requirements it works better with the icons
> and for example Windows 95 or Windows 7 style does not. Or I hav code that
> does not link to QWidget and still needs to paint/print something that is
> desinged in Breeze style.

Are that made up examples? If you want to use a QStyle in an application not 
using QWidgets you have lost already.

> Bottom line, IIRC there are no KDE applications anymore. You can't predict
> what OS / UX the _Qt_ apps will be used on. So author of applications are
> perfectly free to target other OSes than just the Plasma-based ones.

We want KDE applications to integrate with the OSes style and not force the 
Plasma style on apps in e.g. GNOME. We don't want apps to force the breeze 
style.

> 
> > > 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.
> 
> Very good, so similarly, I am packaging the breeze style for desktop OSes
> that lack Breeze QStyle. And like on Android, for these OSes the style is
> defined/decided at the application's level. And I have chosen Breeze style
> and icons and using that assumption while developing custom widgets (a hell
> of work for even for one style when QStyle is a stalled API now).

So you are porting part of Plasma to other OSes. That's great! Though doesn't 
mean that Plasma should relicense code.

> 
> > > 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.
> 
> Legal reason:
> I am distributing the Breeze QStyle for OSes without Plasma installed.
> There is some LGPL code, it's the same purpose for LGPL as KF5 has, opening
> up for use by GPL-incompatible apps. But Breeze code can't be used as a
> part of it even by linking. Breeze is GPL unlike all the styles shipped
> with Qt (4 or 5) that are LGPL.

Huh? Oxygen is also GPL and I don't see how it matters how Qt publishes their 
styles.

> There's no even exception in Breeze style.
> Breeze can't be used even if people pay $$$ to KDE in such cases.
> It's closed for this usage paths. It's even close for GPL-incompatible open
> source projects but that's another matter; it's not possible to compile-in
> an GFDL resource into the app or Mozilla licensed one -- all this is
> incompatible with GPL.
> Hard to explain to developers that there are so many not obvious
> restrictions when they move from styles distributed with Qt5 to Breeze.

well yes, Plasma as a platform is GPL. If you want to derive your product from 
Plasma you need to follow Plasma's licensing.

> 
> Breeze can be semi-legally used with GPL-incompatible app on the user's
> machine when it is loaded as a plugin without user knowing what is
> happening.
> Semi-legally because such app can't become GPL at runtime. It's just happy
> user not knowing there's a conflict.

That's not semi-legally. That's fully legally and the idea behind the plugin. 
We as Plasma inject the plugin into the running application. If an application 
sets it to use the breeze style manually I consider this as derived work.

> 
> I am afraid this situation also extends so Plasma based OSes became
> generally non-accessible (depends on jurisdiction and IANAL) for non-FOSS
> world. In my opinion Breeze can't be set as default in non-GPL app now. And
> what we're protecting here - has to be decided.

That looks fine to me. Non-GPL apps should not define a hard dependency on 
Plasma.

> 
> 
> Technical reason:
> Assume a software architecture that displays a check box in an interactive
> document. Say, it's a Qt graphics view with interactive elements. To
> display primitives that are not supported by QStyle or KStyle hints you
> look at the style's code. Say, parts of a combo box are close to impossible
> to draw without a QComboBox instance, proxy-styling and cheating like that.
> So a developer either copies the source code or implements approximate
> result by hand.
> In either case there's little chance of working with the upstream.
> (yet these difficulties does not mean that upstream bug reports should be
> filed - the use cases are beyond of the scope of a "normal" QStyle)

LGPL-ing won't fix that. If you copy the code the copyleft restrictions will 
still apply.

> 
> Architecturally, the eventual solution would be that breeze.git becomes
> layered, and routines beyond what QStyle defines are provided by an LGPL
> lib. It worked with libOxygen that is LGPL.

The reason for liboxygen was that part of Oxygen was also used by KWin 
decoration. We fixed that by moving the decorations together with the style 
into one repository.

Personally I think liboxygen was rather a hack and an annoyance.

> Especially that QStyle is
> mostly just maintained. "Use QStyle and plugins" sounds almost like "use X
> "protocol instead of DWD"...
> Going LGPL is a first step for this being even considered as a task by a
> KDE contributor. Without that the easiest thing is to work downstream
> forking^w copying the design and such.
> 
> > > 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.
> 
> I see much of oxygen
> 
> is BSD-like and LGPL of the change happened in with the Breeze.

I have here a file open oxygenstyleplugin.cpp which is licensed as GPL v2+. 
Thus the whole thing is licensed GPLv2+. Why the code is inconsistent licensed 
I do not know.

> Again what's wrong for you with libOxygen that is LGPL?

liboxygen is not lgpl licensed. Look for example at liboxygen/liboxygen.h. It 
has a GPLv2+ header, thus is GPLv2+

> 
> 
> > > 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.
> 
> It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have
> freedoms that Breeze actually lack just because the licensing choice. And
> that may or may not be a missed opportunity.

I just checked the folder qtquickcontrols - those files are unfortunately not 
licensed at all. This is clearly wrong.

Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also 
cannot just take parts of it. Though the individual files are lacking a 
copyright header.

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/03a28266/attachment.sig>