LGPL for Breeze QStyle and qtquickcontrols?

Wed May 18 10:41:49 UTC 2016

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

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

But there's no rule in KDE that LGPL code needs to form frameworks.
No need to switch the topic... Adding a framework is a lot of
responsibility I am aware of and I don't request more work from others.
We had an agreement within KDE organization that there's not even rule
that KDE projects have to use C++ or Qt. People can implement things in
HTML or C# or Java. Unless licenses stay against it but I see no reason why
would be that.

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

You see, authors have the benefit of re-licensing when _they_ need.
I am not the author and have to face unusual extensive testing of my
reasoning.
You're free to do that but that sounds oppressive. From the KF5
perspective I am the "customer", framework authors would have to listen to
in some real world.

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

It would be better not experiencing one KDE contributor patronising other
KDE contributor. it would be more proactive to hear "I don't see this use
case maybe because I don't work on such software but I trust you and I am
happy with more FOSS working together".

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

You can't stop that with restrictions but with a great architecture. I
have different approach now and licensing won't stop that, it will just
just cost more and ultimately would be uglier. Inclusive attitude instead
we-they and licensing can be the cheapest solution and investment for the
future.

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

No... I don't port a desktop experience.

 My universe in this case is the application,  

that's not unusual in the real world. Many apps used nowadays (mobile, web)
do so I don't see why this should be prohibited.  I am cherry picking to
make app that looks the same.
In the real world you don't buy a new Ferrari without body so you can play
with own bodies or use one from Ford. Either you like and get the whole
experience or build your care on your own.

Plasma is not referred in any place of that work. This may be a challenge
in conservative circles as in this thread but new things are challenging.

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

It matters when you realize that the Qt Project most likely did that for a
purpose: to allow for non-GPL-compatible apps to exist (not even non-FOSS).
Entire framework has to be LGPL for that. See below for the official
opinion of people I care about.

And Breeze and parts of Oxygen, derive from that LGPL solution but
relicense to GPL closing the usage path of entire Qt.

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

I don't write for Plasma. I am using painting routines that draw what the
VDG designed for Breeze. I was contributor there too it that matters.

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

You're briefly looking at what plugins are.
Maybe you're concentrating at design pattern levels, direct calls versus
inversion of control / dependency injection.

See http://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF

App or libs that links with a GPL plugin become GPL.

If they were originally LGPL, they jsut become GPL, fine. If they link with
any GPL-incompatible component, even a plugin, they can't be distributed
legally in this setup. They have to be strip down what sometimes removes
much of value of the product.

All this IMHO narrows the availability of Breeze QStyle for general
software development. For Qt Quick it may be the same for simpler reason:
Qt Quick projects hat I know about sometimes borrow snippets of code to
glue things. That is why some of the Qt Project's Qt Quick stuff is BSD.
And examples.

I also can't spot exceptions in Oxygen or Breeze for usage in non-GPL apps
or at least with LGPL code. That would be some solution but LGPL is the
KISS approach.

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

Years of hard-defaulting to oxygen icons shows otherwise.
I don't see a reason to be so much selective: when you need things from
plasma in the frameworks (icons), you're moving it and/or re-licensing. But
when app developer needs some code, it's prohibited at the level of license.

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

My code is LGPL. And if it wasn't, it's possible to create to create a
small LGPL container libraries if copying is unavoidable. When the code is
GPL, only reimplementation is possible. Or using alternative ones like the
GTK+ one.

>
> >
> > 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.
>
>
Generally I do know the licenses for code I am using. The file is almost
just a StylePlugin::create() one-liner so of course I don't need it. If
you look at oxygen/liboxygen/ it's consistently BSD or LGPL.
If I've been using it as such before and it is going to be re-licensed,
that won't remove my usage. In worst case I'll be keeping a copy making
upstream contributions harder. The same rules apply to any such cases. This
is exactly the reason why I default to LGPL in my code - because give them
freedom to decide about the architecture.
YMMV...

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

Please see the above, code from Oxygen that was handy is LGPL. I don't need
that header. 

I was using the LGPL code in Oxygen times and now in Breeze times I
spotted the relicensing, found it as unusual, so started this thread. I bet
I even had packages of liboxygen somewhere that say LGPL, and it sounded
natural to me and in the "KDE" way.

Good that I've found the blocker before release because I can ask or find
a workaround.

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

Any license plans here? Asking because it's better to know upfront what to
pick for a Qt Quick version of my app(s) -- say, Material style or Breeze.
Whatever is legal.

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

Like said above, I can. Again, my code is LGPL.
This way anyone is free to supply plugins arbitrary licenses - a thing of
high value for me.

-- 
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/20160518/6b563ca1/attachment-0001.html>