<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 20:38, 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"><span>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 for<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. Especially<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>
</span>Yes exactly! If you would present me reasons why it should become a framework<br>
I might see a need for it to have it LGPL. That is something I currently don't<br>
see. Thus I don't see a reason to change it to LGPL.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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 responsibility I am aware of and I don't request more work from others.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></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">
<br>
Similar I don't relicense KWin to LGPL, just because there might be a reason<br>
later on.  When we split out code from KWin to KWayland we did the relicense<br>
as needed.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​You see​, authors have the benefit of re-licensing when _they_ need.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I am not the author and have to face unusual extensive testing of my reasoning.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></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><br>
> ​Why on the icons and not on style?​ (See also below)<br>
> I have apps/libs that hard-depend on breeze style. (not just the<br>
> implementation, on the design)<br>
> Example reason: because for my requirements it works better with the icons<br>
> and for example Windows 95 or Windows 7 style does not. Or I hav code that<br>
> does not link to QWidget and still needs to paint/print something that is<br>
> desinged in Breeze style.<br>
<br>
</span>Are that made up examples? If you want to use a QStyle in an application not<br>
using QWidgets you have lost already.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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".<br></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><br>
> ​Bottom line, IIRC there are no KDE applications anymore. You can't predict<br>
> what OS / UX the _Qt_ apps will be used on. So author of applications are<br>
> perfectly free to target other OSes than just the Plasma-based ones.<br>
<br>
</span>We want KDE applications to integrate with the OSes style and not force the<br>
Plasma style on apps in e.g. GNOME. We don't want apps to force the breeze<br>
style.<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<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><br>
><br>
> > > Icons are part of the KF5 product [1] which does not mean libraries<br>
> ><br>
> > depend<br>
> ><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>
> > libraries do depend on icons. Otherwise there wouldn't be efforts on how<br>
> > to<br>
> > package all required icons in the case of Android.<br>
><br>
> Very good, so similarly, ​I am packaging the breeze style for desktop OSes<br>
> that lack Breeze QStyle.​ And like on Android, for these OSes​ the style is<br>
> defined/decided at the application's level. And I have chosen Breeze style<br>
> and icons and using that assumption while developing custom widgets (a hell<br>
> of work for even for one style when QStyle is a stalled API now).<br>
<br>
</span>So you are porting part of Plasma to other OSes. That's great! Though doesn't<br>
mean that Plasma should relicense code.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​No... I don't port a desktop experience.​</div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​ My universe in this case is the application,  ​</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">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">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.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​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.</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><br>
><br>
> > > Do you then agree with relicensing after my explanations here and in the<br>
> > > other email?<br>
> ><br>
> > no, sorry, I still don't see why that would be needed.<br>
><br>
> ​Legal reason:​<br>
> ​​I am distributing the Breeze QStyle for OSes without Plasma installed.​<br>
> There is some LGPL code, it's the same purpose for LGPL as KF5 has, opening<br>
> up for use by GPL-incompatible apps. But ​Breeze code ​can't be used as a<br>
> part of it even by linking. Breeze is GPL unlike all the styles shipped<br>
> with Qt (4 or 5) that are LGPL.<br>
<br>
</span>Huh? Oxygen is also GPL and I don't see how it matters how Qt publishes their<br>
styles.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​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.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​And Breeze and parts of Oxygen, derive from that LGPL ​solution but relicense to GPL closing the usage path of entire Qt.<br></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><br>
> There's no even exception in Breeze style.<br>
> 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<br>
> source projects but that's another matter; it's not possible to compile-in<br>
> an GFDL resource into the app or Mozilla licensed one -- all this is<br>
> incompatible with GPL.<br>
> Hard to explain to developers that there are so many not obvious<br>
> restrictions when they move from styles distributed with Qt5 to Breeze.<br>
<br>
</span>well yes, Plasma as a platform is GPL. If you want to derive your product from<br>
Plasma you need to follow Plasma's licensing.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">​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.<br></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><br>
><br>
> Breeze can be semi-legally used with GPL-incompatible app on the user's<br>
> machine when it is loaded as a plugin without user knowing what is<br>
> happening.<br>
> Semi-legally because such app can't become GPL at runtime. It's just happy<br>
> user not knowing there's a conflict.<br>
<br>
</span>That's not semi-legally. That's fully legally and the idea behind the plugin.<br>
We as Plasma inject the plugin into the running application. If an application<br>
sets it to use the breeze style manually I consider this as derived work.<br></blockquote><div><br><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">You're briefly looking at what plugins are.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Maybe you're concentrating at design pattern levels, direct calls versus inversion of control / dependency injection.<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">See ​<a href="http://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF" target="_blank">http://www.gnu.org/licenses/gpl-faq.en.html#GPLPluginsInNF</a><br><br>App or libs that links with a GPL plugin become GPL.<br></div><br><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">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.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br>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.<br></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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
><br>
> I am afraid this situation also extends so Plasma based OSes became<br>
> generally non-accessible (depends on jurisdiction and IANAL) for non-FOSS<br>
> world. In my opinion Breeze can't be set as default in non-GPL app now. And<br>
> what we're protecting here - has to be decided.<br>
<br>
</span>That looks fine to me. Non-GPL apps should not define a hard dependency on<br>
Plasma.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Years of hard-defaulting to oxygen icons shows otherwise.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<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><br>
><br>
><br>
> ​Technical reason:<br>
> ​Assume a software architecture that displays a check box in an interactive<br>
> document. Say, it's a Qt graphics view with interactive elements. To<br>
> display primitives that are not supported by QStyle or KStyle hints you<br>
> look at the style's code. Say, parts of a combo box are close to impossible<br>
> to draw without a QComboBox instance, proxy-styling and cheating like that.<br>
> So a developer either copies the source code or implements approximate<br>
> result by hand.<br>
> In either case there's little chance of working with the upstream.<br>
> (yet these difficulties does not mean that upstream bug reports should be<br>
> filed - the use cases are beyond of the scope of a "normal" QStyle)<br>
<br>
</span>LGPL-ing won't fix that. If you copy the code the copyleft restrictions will<br>
still apply.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<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><br>
><br>
> ​Architecturally, the eventual solution would be that breeze.git becomes<br>
> layered, and routines beyond what QStyle defines are provided by an LGPL<br>
> lib. It worked with libOxygen that is LGPL.<br>
<br>
</span>The reason for liboxygen was that part of Oxygen was also used by KWin<br>
decoration. We fixed that by moving the decorations together with the style<br>
into one repository.<br>
<br>
Personally I think liboxygen was rather a hack and an annoyance.<br>
<span><br>
> Especially that QStyle is<br>
> mostly just maintained. "Use QStyle and plugins" sounds almost like "use X<br>
> "protocol instead of DWD"...<br>
> Going LGPL is a first step for this being even considered as a task by a<br>
> KDE contributor. Without that the easiest thing is to work downstream<br>
> forking^w copying the design and such.<br>
><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<br>
> ><br>
> > progress.<br>
> ><br>
> > > The design (by VDG) is free to use (LGPL I think), why wouldn't the<br>
> > > implementation be free-to-link?<br>
> ><br>
> > I repeat again: I object to a relicense of code I have written to GPL in<br>
> > the<br>
> > case of Breeze and Oxygen.<br>
><br>
> I see much of oxygen​<br>
><br>
> ​is BSD-like and LGPL of the change happened in with the Breeze.<br>
<br>
</span>I have here a file open oxygenstyleplugin.cpp which is licensed as GPL v2+.<br>
Thus the whole thing is licensed GPLv2+. Why the code is inconsistent licensed<br>
I do not know.<br>
<span><br></span></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br>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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">YMMV...<br></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>
> Again what's wrong for you with libOxygen that is LGPL?<br>
<br>
</span>liboxygen is not lgpl licensed. Look for example at liboxygen/liboxygen.h. It<br>
has a GPLv2+ header, thus is GPLv2+<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Please see the above, code from Oxygen that was handy is LGPL. I don't need that header. ​</div> <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​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.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br>​Good that I've found the blocker before release because I can ask or find a workaround.<br></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"><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><br>
> ​<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<br>
> > > compilers?<br>
> ><br>
> > I don't see what that has to do with it.<br>
><br>
> It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have<br>
> freedoms​ that Breeze actually lack just because the licensing choice. And<br>
> that may or may not be a missed opportunity.<br>
<br>
</span>I just checked the folder qtquickcontrols - those files are unfortunately not<br>
licensed at all. This is clearly wrong.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​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.<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">
<br>
Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also<br>
cannot just take parts of it. Though the individual files are lacking a<br>
copyright header.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​Like said above, I can. Again, my code is LGPL. <br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">This way anyone is free to supply plugins arbitrary licenses - a thing of high value for me.<br></div></div></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>