<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 18 May 2016 at 17:51, Martin Graesslin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote:<br>
> On 17 May 2016 at 20:38, Martin Graesslin <<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>> wrote:<br>
> > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:<br>
> > > > If you show me why it needs to be a framework and I agree with it,<br>
> > > > I might be willing to consider to allow to relicense the code I wrote<br>
> ><br>
> > for<br>
> ><br>
> > > > it.<br>
> > ><br>
> > > There's no request to make it framework from me. LGPLing Breeze does not<br>
> > > automatically add obligation to create and maintain a framweork.<br>
> ><br>
> > Especially<br>
> ><br>
> > > that there are not widely declared use cases. It's just a way to get the<br>
> > > same what was legal in the times of Oxygen and KDElibs 4.<br>
> ><br>
> > Yes exactly! If you would present me reasons why it should become a<br>
> > framework<br>
> > I might see a need for it to have it LGPL. That is something I currently<br>
> > don't<br>
> > see. Thus I don't see a reason to change it to LGPL.<br>
><br>
> But there's no rule in KDE that LGPL code needs to form frameworks.<br>
> No need to switch the topic... Adding a framework is a lot of<br>
> responsibility I am aware of and I don't request more work from others.<br>
> We had an agreement within KDE organization that there's not even rule<br>
> that​ KDE projects have to use C++ or Qt. People can implement things in<br>
> HTML or C# or Java. Unless licenses stay against it but I see no reason why<br>
> would be that.<br>
><br>
> > Similar I don't relicense KWin to LGPL, just because there might be a<br>
> > reason<br>
> > later on.  When we split out code from KWin to KWayland we did the<br>
> > relicense<br>
> > as needed.<br>
><br>
> ​You see​, authors have the benefit of re-licensing when _they_ need.<br>
> I am not the author and have to face unusual extensive testing of my<br>
> reasoning.<br>
<br>
</div></div>You are asking me as a copyright holder whether I agree to a relicense. You<br>
have to convince me. To me the default licence is GPLv3+. Everything else<br>
means an exception to my personal view. You have to provide really good<br>
reasons to make me agree that this is needed.<br>
<br>
So far I have not seen them. It is more a wishy-washy about you want to use<br>
some code. That's not a reasoning. Explain why you need it and explain it that<br>
makes sense with our overall KDE vision about<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div> applications not being part of<br>
Plasma and depending on Plasma. Especially: how do you want to achieve it<br>
without making applications depend on Plasma, which is nothing we want. Copy<br>
code? No way, for that I'm not going to agree to relicense.<br>
<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​Martin,​</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">"​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.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">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.<br></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">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<span> by saying this but to show that in the entire population there are various interests.<br></span></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">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.<br><br>So we, in KDE, lack LGPL style code for our de-facto official look and feel.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"></div><br>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. <br>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). <br></div></div></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">"applications not being part of Plasma and depending on Plasma​" - how does it sound then?<br></div><br>-- <br><div>regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>