LGPL for Breeze QStyle and qtquickcontrols?

[Jaroslaw Staniek]

On 6 June 2016 at 13:04, Martin Graesslin <mgraesslin at kde.org> wrote:

> On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:
> > 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.
>
> If you really want to be able to reuse the code as one wishes it needs to
> be
> MIT/BSD licensed. Otherwise it's just working for your personal use case
> that
> your LGPL based application (or whatever) can use it.
>
> Making the code LGPL won't fix the "problem" of not reusing the code. I'm
> not
> open to discuss changing the licence away from GPL due to that. LGPL won't
> solve the problem and BSD style license I'm not comfortable with.
>
> If the code were a library (which it isn't) LGPL could be an option. But it
> isn't and nobody wants to turn it into a library. It's a mood point.
>
> Sorry to having to deny your relicence request. I want my code
> contributions
> to be GPL by default, LGPL is for me already a hard exception which must
> have
> strong understandable reasons (like a library one wants to use, which
> breeze
> isn't).
>
> Btw. I'm very unhappy with the level of pressure you are exposing here by
> bringing it up again and again.
>

I am done with that then -- I was one who also worked a bit on debugging
the lib code, like many others do.

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.

@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.
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.
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.

-- 
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/88238e24/attachment.html>