LGPL for Breeze QStyle and qtquickcontrols?

Tue May 17 16:23:10 UTC 2016

On 17 May 2016 at 15:02, Martin Graesslin <mgraesslin at kde.org> wrote:

> 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.

LGPL decided earlier than later helps to avoid such threads.
KStyle's origins are internals of KDE3.

> 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.

Above app the license obligations of *GPL do not include explaining use
cases for the code. But my friendly attitude shows that I am sharing some
of the boring details with you below...

>
> >
> > > 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.
>

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.

>
> 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.
>

"application s

tyles do not make the user experience of app but icons for some reason
define the apps" seems arbitrary choice and just a "current" state of
things.

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.

> >
> > 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).

> >
> > 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. 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.

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.

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.

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)

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. 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.
Again what's wrong for you with libOxygen that is LGPL?

>
> >
> > 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.

That's my investment to propose the easy change but without that I have own
downstream solutions. So things are not blocking me too much, just my ease
of experimentation has been limited a tiny bit.

-- 
regards, Jaroslaw Staniek

KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160517/e8ecc5e5/attachment-0001.html>