<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 17 May 2016 at 15:02, 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 class=""><div class="h5">On Tuesday, May 17, 2016 2:21:43 PM CEST Jaroslaw Staniek wrote:<br>
> On 9 May 2016 at 07:53, Martin Graesslin <<a href="mailto:mgraesslin@kde.org">mgraesslin@kde.org</a>> wrote:<br>
> > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:<br>
> > > Hi,<br>
> > > Is relicensing Breeze QStyle to LGPL from GPL for possible and<br>
> ><br>
> > acceptable?<br>
> ><br>
> > > I've found cases when bits of the code beyond QStyle/KStyle API need<br>
> > > to be reused. One example is: custom widgets.<br>
> > > If we're considering Breeze QStyle as implementation of certain<br>
> > > artwork, and KDE artwork in general would be LGPL also for<br>
> > > consistency.<br>
> > > For example wallpapers, icons are LGPL.<br>
> > ><br>
> > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,<br>
> > > it's not clear in breeze.git. The same question here: can it be LGPL<br>
> > > or BSD?<br>
> > ><br>
> > > Bottom line is: if we want to popularise our frameworks in the outside<br>
> > > world...<br>
> ><br>
> > I fail to follow you why Breeze QStyle should be a framework. No framework<br>
> > should depend on it, Breeze QStyle is a plugin and it's only getting<br>
> > loaded by<br>
> > either setting an env variable manually or using the Plasma QPT plugin<br>
> > which<br>
> > is not in Frameworks either.<br>
><br>
> ​Not only KF5 is LGPL. ​Also other libraries and also parts of individual<br>
> apps.<br>
<br>
</div></div>And there are also libraries which are GPL. E.g. kwineffects or kscreenlocker<br>
library.<br>
<span class=""><br>
> BTW: The latter help to create frameworks in the future (picking GPL too<br>
> early kills the idea).<br>
<br>
</span>No it doesn't. It just means that one needs to get everybody to agree on the<br>
relicense.</blockquote><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>​​LGPL ​decided earlier than later helps to avoid such threads.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">KStyle's origins are internals of KDE3.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 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 for it.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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...<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
><br>
> > Anyway on the question of whether to relicense to LGPL you should ask the<br>
> > copyright holders and I doubt you found them here on frameworks-devel as<br>
> > Breeze is not a framework. I'm one of the copyright holders and as I don't<br>
> > understand why you want it relicensed I would not agree to it. I think GPL<br>
> > is<br>
> > the proper license for our workspace components.<br>
><br>
> I'd like more explanation to know if you disagree just for the sake...<br>
<br>
</span>of course not!<br>
<span class=""><br>
> Don't you agree with LGPL for breeze or oxygen icons?<br>
<br>
</span>We have applications which depend on breeze and oxygen icons. That's why we<br>
moved them to frameworks. Applications depend on it, LGPL is the proper<br>
license.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​Why on the icons and not on style?​ (See also below)<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I have apps/libs that hard-depend on breeze style. (not just the implementation, on the design)<br>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.<br></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The style though is part of Plasma Workspace and as that should follow the<br>
licensing of Plasma components which is GPL.  This also applies to many<br>
libraries in Plasma.<br>
<span class=""><br>
><br>
> Styles are in *the same* group. <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div>They make-our-user-experience.<br>
<br>
</span>They make up the user-experience of Plasma. Not of the applications.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">"application s</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​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.<br><br>​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.<br></div></div></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
><br>
> Icons are part of the KF5 product [1] which does not mean libraries depend<br>
> on them<br>
> <a href="https://www.kde.org/announcements/kde-frameworks-5.22.0.php" rel="noreferrer" target="_blank">https://www.kde.org/announcements/kde-frameworks-5.22.0.php</a><br>
> (well I believe as a product they depend but that's out-of-the box level<br>
> thinking not belonging here)<br>
<br>
</span>libraries do depend on icons. Otherwise there wouldn't be efforts on how to<br>
package all required icons in the case of Android.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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).<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
><br>
> Do you then agree with relicensing after my explanations here and in the<br>
> other email?<br>
<br>
</span>no, sorry, I still don't see why that would be needed.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​Legal reason:​</div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​​I am distributing the Breeze QStyle for OSes without Plasma installed.​ <br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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. <br>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. <br>Hard to explain to developers that there are so many not obvious restrictions when they move from styles distributed with Qt5 to Breeze.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Semi-legally because such app can't become GPL at runtime. It's just happy user not knowing there's a conflict.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br><br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​Technical reason:<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">So a developer either copies the source code or implements approximate result by hand.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">In either case there's little chance of working with the upstream.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">(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)<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​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"...<br>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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><br><span class=""></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
><br>
> The request is about the freedom to use of the code from of the breeze<br>
> style in LGPL code freely opening freedom for experimentation and progress.<br>
> The design (by VDG) is free to use (LGPL I think), why wouldn't the<br>
> implementation be free-to-link?<br>
<br>
</span>I repeat again: I object to a relicense of code I have written to GPL in the<br>
case of Breeze and Oxygen.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I see much of oxygen​</div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​is BSD-like and LGPL of the change happened in with the Breeze.<br>Again what's wrong for you with libOxygen that is LGPL?<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
><br>
> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL<br>
> clearly as these would be actually scripts and graphic/style files. Why<br>
> would we have inferior situation just because we happen to use compilers?<br>
<br>
</span>I don't see what that has to do with it.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></div></div></div><br>-- <br><div class="gmail_signature">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>