LGPL for Breeze QStyle and qtquickcontrols?

Mon Jun 6 10:17:11 UTC 2016

On 30 May 2016 at 17:11, Michael Pyne <mpyne at 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), 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160606/1300b802/attachment-0001.html>