LGPL for Breeze QStyle and qtquickcontrols?

Martin Graesslin mgraesslin at kde.org
Mon Jun 6 11:04:01 UTC 2016


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.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160606/a5167ef6/attachment-0001.sig>


More information about the Kde-frameworks-devel mailing list