<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 6 June 2016 at 13:04, 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 Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:<br>
> On 30 May 2016 at 17:11, Michael Pyne <<a href="mailto:mpyne@kde.org">mpyne@kde.org</a>> wrote:<br>
> > On Mon, May 30, 2016 14:42:43 Martin Graesslin wrote:<br>
> > > On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote:<br>
> > > > On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote:<br>
> > > > > All in all, If nobody just noted an issue with the licensing above<br>
> ><br>
> > maybe<br>
> ><br>
> > > > > nobody tried to place/distribute a non-GPL software on top of<br>
> > > > > Plasma?<br>
> > > > > That<br>
> > > > > would be the worst news of all to me.<br>
> > > > ><br>
> > > > > Please speak up someone else because it's a matter of KDE, not just<br>
> > > > > a<br>
> > > > > single desktop shell. Maybe some voting fits here.<br>
> > > ><br>
> > > > I've only been able to keep track of the margins of the thread but I<br>
> ><br>
> > will<br>
> ><br>
> > > > admit that it seems surprising that we would use code licensing as a<br>
> ><br>
> > means<br>
> ><br>
> > > > to either enforce the exclusiveness of Plasma's artwork above and<br>
> ><br>
> > beyond<br>
> ><br>
> > > > the existing license for the artwork, or to prevent applications<br>
> ><br>
> > running<br>
> ><br>
> > > > on<br>
> > > > KDE frameworks (but outside of Plasma) from supplying an alternative<br>
> > > > KDE-authored QStyle.<br>
> > ><br>
> > > heh, that's certainly not the case here. This is not trying to force our<br>
> > > style to be only used in Plasma. That would be a ridiculous stance from<br>
> ><br>
> > my<br>
> ><br>
> > > side.<br>
> > ><br>
> > > I want to have my code stay GPL. I don't think that the breeze code<br>
> ><br>
> > needs to<br>
> ><br>
> > > be licenced in a way that it can be copied into 3rd party applications.<br>
> > > That's all. It has nothing to do with enforcing anything, it's just<br>
> > > about<br>
> ><br>
> > ​​<br>
> > ​​<br>
> > t<br>
> > ​​<br>
> > he<br>
> > ​​<br>
> > actual implementation should stay GPL in my opinion.<br>
> ><br>
> > Alright, my apologies for misunderstanding and then misrepresenting your<br>
> > position. Certainly<br>
> > ​​<br>
> > code licensing is every developer's choice to make, and<br>
> > I'm not sure of better ways than what you're doing to avoid third-party<br>
> > apps<br>
> > from easily cloning the code behind the style (even if it means more<br>
> > difficulty for non-GPL KDE apps outside of Plasma).<br>
><br>
> ​<br>
> Please let me repeat​ (and cover this and any potential similar cases in<br>
> the future): this blocking avoids *any* reuse for non-GPL code no matter if<br>
> via copying or linking (either via private APIs, eventually framework-ify<br>
> that _if_ it pays off). It's hard to assume Martin did not read/understand<br>
> my explanation of the use cases and the technicals.<br>
><br>
> ​Since when LGPL (versus GPL) decrease code reuse?​ Conversely, GPL means<br>
> less chance for collaborating on shared code.<br>
<br>
</div></div>If you really want to be able to reuse the code as one wishes it needs to be<br>
MIT/BSD licensed. Otherwise it's just working for your personal use case that<br>
your LGPL based application (or whatever) can use it.<br>
<br>
Making the code LGPL won't fix the "problem" of not reusing the code. I'm not<br>
open to discuss changing the licence away from GPL due to that. LGPL won't<br>
solve the problem and BSD style license I'm not comfortable with.<br>
<br>
If the code were a library (which it isn't) LGPL could be an option. But it<br>
isn't and nobody wants to turn it into a library. It's a mood point.<br>
<br>
Sorry to having to deny your relicence request. I want my code contributions<br>
to be GPL by default, LGPL is for me already a hard exception which must have<br>
strong understandable reasons (like a library one wants to use, which breeze<br>
isn't).<br>
<br>
Btw. I'm very unhappy with the level of pressure you are exposing here by<br>
bringing it up again and again.<br></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I am done with that then -- I was one who also worked a bit on debugging the lib code, like many others do.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I'd be happy to see the "defaulting to GPL" rules specified officially by some document by KDE, this helps to make decision about contributing.<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">@Hugo I've read your comments about guaranties and such. API/ABI maintenance is a stronger demand, what I discussed here is licensing. The breeze has headers with own functions and much of abstraction beyond of what (really approximate to what style authors want to achieve, at times) QStyle API even offered or is designed for.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I trust you accept the fact that application a developer won't see realistic to wait for Qt 6 and/or contribute to Qt6 QStyle API in order to use a trivial code from breeze style cpp files. He would just reimplement/copy them at least for convenience reasons.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">This is approach already official and popular and recommended for apps after LGPL kdelibs4 when many APIs disappeared for a reason (various KGlobalSettings stuff, KDialog, ...). This made it possible to port Kexi to Qt 5 for example. The only difference here is that for Breeze there's no LGPL code.<br></div></div></div><br>-- <br><div class="gmail_signature" data-smartmail="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>