<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 06/06/2016 12:17 PM, Jaroslaw
Staniek wrote:<br>
</div>
<blockquote
cite="mid:CAOj7QQ309Q=iknvdLC8kKsz0S10w58J0i456QqaPVuQPoxuqpg@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 --
"the 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), </div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I am confused again. (but does not matter since my comments are
ignored anyway). Breeze widget style is a consumer of QStyle, which
has an API, and which breeze style uses. But I fail to see how
breeze widget style itself has an API of its own. (and has no
installed headers). What do I miss ?<br>
<br>
<blockquote
cite="mid:CAOj7QQ309Q=iknvdLC8kKsz0S10w58J0i456QqaPVuQPoxuqpg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<div class="gmail_default"
style="font-family:monospace,monospace;font-size:small;display:inline">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 moz-do-not-send="true" href="http://kde.org"
target="_blank">http://kde.org</a><br>
Calligra Suite:<br>
: A graphic art and office suite - <a
moz-do-not-send="true" href="http://calligra.org"
target="_blank"><a class="moz-txt-link-freetext" href="http://calligra.org">http://calligra.org</a></a><br>
Kexi:<br>
: A visual database apps builder - <a
moz-do-not-send="true" href="http://calligra.org/kexi"
target="_blank"><a class="moz-txt-link-freetext" href="http://calligra.org/kexi">http://calligra.org/kexi</a></a><br>
Qt Certified Specialist:<br>
: <a moz-do-not-send="true"
href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Kde-frameworks-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>