LGPL for Breeze QStyle and qtquickcontrols?

Mon Jun 6 10:27:11 UTC 2016

On 06/06/2016 12:17 PM, Jaroslaw Staniek wrote:
>
>
> On 30 May 2016 at 17:11, Michael Pyne <mpyne at kde.org 
> <mailto: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),

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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160606/5c414e47/attachment-0001.html>