LGPL for Breeze QStyle and qtquickcontrols?

Sat May 21 22:22:28 UTC 2016

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

> On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote:
> > 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 are asking me as a copyright holder whether I agree to a relicense. You
> have to convince me. To me the default licence is GPLv3+. Everything else
> means an exception to my personal view. You have to provide really good
> reasons to make me agree that this is needed.
>
> So far I have not seen them. It is more a wishy-washy about you want to use
> some code. That's not a reasoning. Explain why you need it and explain it
> that
> makes sense with our overall KDE vision about
> 
> applications not being part of
> Plasma and depending on Plasma. Especially: how do you want to achieve it
> without making applications depend on Plasma, which is nothing we want.
> Copy
> code? No way, for that I'm not going to agree to relicense.
>
>
Martin,
"Depending on plasma" is a term at the level of deployment. It addresses
requirements that may be important to someone but not to the entire
mankind. Not every software title is developed by operating in the scope of
term that you're referring to. I am sharing examples below.

With all due respect I don't want to even discuss using licenses as a
tool/weapon to dictate deployment, scope of use, etc. And whether all
desktop applications that use Breeze style and icons to display something
(not necessarily QWidgets) must be part of Plasma -- which so far isn't
official component/subsystem of Windows or OS X. So how a KDE app on
Windows has to be part of Plasma is not clear to me.

Then the KDE Vision and copying, good that you're asking because there's
some exercise. The KDE Vision is orthogonal to something even stronger than
copying: _forking_ projects, even without "convincing" or explaining
original authors. And these projects can be part of KDE exactly the way the
original is.

So Plasma (design and icons - SVG code) has been copied multiple times
already out of KDE, what includes a copy for GTK+ apps and LibreOffice
apps. The Breeze style has been copied to the LGPLized GTK+ style. I don't
need to add that none of such apps mention Plasma or even KDE. And most
users of popular KDE apps such as Krita wouldn't even know what _kind_ of
term Plasma is if we ask them. You know, most of these users are on
Windows. I am not trying to devalue Plasma by saying this but to show that
in the entire population there are various interests.

Then, creating an Android or iOS package is ultimately also copying.
Creating Windows/Mac installers of pro apps is very interesting exercise in
copying and picking versions of components that are needed and work
together. Suddenly you become developer and packager, something not very
often practices on Linux. Copying happens not for just copying but it's
possible in extreme cases as a way to circumvent improper license choice,
when other styles (in fact _libraries_ of drawing routines!) are LGPL, this
one is not.

So we, in KDE, lack LGPL style code for our de-facto official look and feel.

That's a paradox, at the moment _non-KDE_ projects have actually more
freedom than KDE contributors to use the current _KDE's_ major desktop
visual identity. That price for having of one style of thinking,
architecture and packaging/dependencies.
Such protection does not work. The Plasma style was not even declared to be
KDE-only visual identity, leading to branding (that's a hard to achieve in
FOSS). Any external project can use the resources as long as the license
requirements are met (and here it is -- Breeze icons in LibreOffice on
non-Plasma desktops).
"applications not being part of Plasma and depending on Plasma" - how does
it sound then?

-- 
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/20160522/08ef9d8f/attachment-0001.html>