LGPL for Breeze QStyle and qtquickcontrols?

Sat May 28 12:53:54 UTC 2016

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

> On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:
> > So we, in KDE, lack LGPL style code for our de-facto official look and
> feel.
>
> This is the crucial point. Breeze is not the de-facto official look and
> feel of
> KDE. It's the look and feel of Plasma.

This is playing a word game here.

> Applications shouldn't use it.
>

Because? Who says so? That would be the first SDK that suggest claims. And
that's the only open source style I have around with such clause.
With all respect to the original authors (I spent time for bugfixing too),
things go WRONG if we didn't collect requirements (ability to run non-GPL
apps under Plasma) and started coding.
Relicensing is a clean and simple means to undo this mistake. Earlier --
better.

We were all the time correct with licensing -- I mentioned KDElibs4 before.
Let's see how it went in KDE3 (Plastik, Highcolor, etc.):
https://websvn.kde.org/branches/KDE/3.5/kdelibs/

I started contributions in 2003. These were times when usage of the styles
by non-GPL apps were assumed.
At the same time before LGPL-izing, Qt had non-GPL exception what allowed
to use Qt's styles with non-GPL apps. Everything was clear and Qt app
development was no more closed than Visual Basic and a bit more closed than
GTK+.
After LGPL-izing, Qt styles went all LGPL because obviously otherwise
plugins linking to symbols would make the user's code GPL.

> Applications of course can use it as much as they want. Nobody is going to
> forbid it. But the fact that they use it, doesn't make it the de-facto
> official
> look and feel and doesn't mean that we have to licence the style as LGPL.
>

For now the _license_ forbids it. No distributed app can contain
GPL-incompatible part or plugin. If I had to produce no matter what type of
GPL plugin, a style plugin,  SQL plugin, image format - I am spreading the
virality of GPL in all the uses. That's also what are the dual licensing
businesses are about, don't we see?

> I stay where I am: I am not agreeing to having my code in Breeze (and
> Oxygen)
> being relicensed to LGPL. I don't see a need for it, I think GPL is the
> right
> choice for that code.
>

It would not matter as much as what's the right choice for KDE as a
product in the route to success comparable with competing products. If we
think strategically, code is our byproduct.
In another (internal) contributor's thread we just started to discuss
marketing of KDE and that nobody knows what's what in the twisted
architecture.
Compulsive modularization (or limiting licensing) can degrade products I am
afraid.

How is it important to someone who wants to, say, sell a calculator app
that is runing on top of Plasma when all she gets from us is
"GPL-compatibility is good choice for your calculator".

This is not going well. I was _this_ close to a blog entry about default
Plasma installations not allowing non-GPL applications. But why to have
another Akonadi-like rant. There are always solutions. Now I see that maybe
it's better to switch to a breeze-fied fusion style (LGPL).

All in all, If nobody just noted an issue with the licensing above maybe
nobody tried to place/distribute a non-GPL software on top of Plasma? That
would be the worst news of all to me.

Please speak up someone else because it's a matter of KDE, not just a
single desktop shell. Maybe some voting fits here.

Cheers

-- 
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/20160528/ecbcbf92/attachment.html>