<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 30 May 2016 at 17:11, Michael Pyne <span dir="ltr"><<a href="mailto:mpyne@kde.org" target="_blank">mpyne@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 class="">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 maybe<br>
> > > nobody tried to place/distribute a non-GPL software on top of 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 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 will<br>
> > admit that it seems surprising that we would use code licensing as a means<br>
> > to either enforce the exclusiveness of Plasma's artwork above and beyond<br>
> > the existing license for the artwork, or to prevent applications running<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 my<br>
> side.<br>
><br>
> I want to have my code stay GPL. I don't think that the breeze code needs to<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 about<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">​​</div> t<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div>he <div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div>actual implementation should stay GPL in my opinion.<br>
<br>
</span>Alright, my apologies for misunderstanding and then misrepresenting your<br>
position. Certainly<div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​​</div> 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 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></blockquote><div><br><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">​<br>Please let me repeat​ (and cover this and any potential similar cases in the future): this blocking avoids *any* reuse for non-GPL code no matter if via copying or linking (either via private APIs, eventually framework-ify that _if_ it pays off). It's hard to assume Martin did not read/understand my explanation of the use cases and the technicals. <br><br>​Since when LGPL (versus GPL) decrease code reuse?​ Conversely, GPL means less chance for collaborating on shared code.<br><br>I also fail to see reasoning for not collaborating  -- "​t​​he ​​actual implementation should stay GPL in my opinion" is not a reason, it's another saying "veto" by one (partial) copyright holder.<br><br>I'd say, let's not call the apparent overlook regarding licensing an informed decision. That's opinion.<br><br>Similarly superficial is associating "being part of Plasma" with "being non-LGPL". Equally well authors of the icons would go GPL -- why is that different? Because actually that would be a blocker for applications? That's exactly the case with the QStyle too.<br><br>This complements the current issue that was barely commented here, that the Breeze style is non-consumable by GPL-incompatible software.<br><br>"If it looks like a duck and quacks like a duck, it's a duck". If it looks like a lib (has APIs), is consumed like a lib (it is), has sharable code, it's a lib. Technicals aside. This also affects the legal layer, the license obligations: (non-GPL)-incompatibility.<br><br>Putting it differently: if the intent was to make the style consumable by non-GPL apps, state it in the license by making a proper choice.<br><br>Code licensing is every developer's choice to make but (away from his sandbox) the responsibility of maintainer is bigger and responsibility of shared code author is even bigger. There's no place for arbitrary private non-discussed choices, like this: the style in non-linkable while the icons are made into the frameworks. Even the division made between the icons and style is arbitrary one and superficial because implementation details should not be a major factor here. Icons are not C++/QML, the style is here, while in the software world there are technologies that keep these both parts of look&feel as one consistent or inseparable piece.<br><br>Let me finally state that many of the KDE frameworks started as a private code, however with unblocked on the road to being libraries by LGPL-ing in the early days.<br></div></div><br></div>-- <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>