On 06/06/2016 12:17 PM, Jaroslaw Staniek wrote:
On 30 May 2016 at 17:11, Michael Pyne <mp...@kde.org
<mailto:mp...@kde.org>> wrote:
On Mon, May 30, 2016 14:42:43 Martin Graesslin wrote:
> On Saturday, May 28, 2016 11:24:52 PM CEST Michael Pyne wrote:
> > On Sat, May 28, 2016 14:53:54 Jaroslaw Staniek wrote:
> > > All in all, If nobody just noted an issue with the licensing
above maybe
> > > nobody tried to place/distribute a non-GPL software on top
of Plasma?
> > > That
> > > would be the worst news of all to me.
> > >
> > > Please speak up someone else because it's a matter of KDE,
not just a
> > > single desktop shell. Maybe some voting fits here.
> >
> > I've only been able to keep track of the margins of the thread
but I will
> > admit that it seems surprising that we would use code
licensing as a means
> > to either enforce the exclusiveness of Plasma's artwork above
and beyond
> > the existing license for the artwork, or to prevent
applications running
> > on
> > KDE frameworks (but outside of Plasma) from supplying an
alternative
> > KDE-authored QStyle.
>
> heh, that's certainly not the case here. This is not trying to
force our
> style to be only used in Plasma. That would be a ridiculous
stance from my
> side.
>
> I want to have my code stay GPL. I don't think that the breeze
code needs to
> be licenced in a way that it can be copied into 3rd party
applications.
> That's all. It has nothing to do with enforcing anything, it's
just about
>
t
he
actual implementation should stay GPL in my opinion.
Alright, my apologies for misunderstanding and then
misrepresenting your
position. Certainly
code licensing is every developer's choice to make, and
I'm not sure of better ways than what you're doing to avoid
third-party apps
from easily cloning the code behind the style (even if it means more
difficulty for non-GPL KDE apps outside of Plasma).
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.
Since when LGPL (versus GPL) decrease code reuse? Conversely, GPL
means less chance for collaborating on shared code.
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.
I'd say, let's not call the apparent overlook regarding licensing an
informed decision. That's opinion.
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.
This complements the current issue that was barely commented here,
that the Breeze style is non-consumable by GPL-incompatible software.
"If it looks like a duck and quacks like a duck, it's a duck". If it
looks like a lib (has APIs),
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 ?
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.
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.
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.
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.
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers,
translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
