subject:"LGPL for Breeze QStyle and qtquickcontrols\?"

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-06-06 Thread Martin Graesslin

On Monday, June 6, 2016 1:29:51 PM CEST Jaroslaw Staniek wrote:
> On 6 June 2016 at 13:04, Martin Graesslin  wrote:
> > On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:
> > > On 30 May 2016 at 17:11, Michael Pyne  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.

Please check: https://community.kde.org/Policies/Licensing_Policy

I think what I express is fully compatible with the licensing policy. Btw. I 
didn't choose the licence for Breeze.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-06-06 Thread Jaroslaw Staniek

On 6 June 2016 at 13:04, Martin Graesslin  wrote:

> On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:
> > On 30 May 2016 at 17:11, Michael Pyne  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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-06-06 Thread Martin Graesslin

On Monday, June 6, 2016 12:17:11 PM CEST Jaroslaw Staniek wrote:
> On 30 May 2016 at 17:11, Michael Pyne  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

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-06-06 Thread Hugo Pereira Da Costa

On 06/06/2016 12:17 PM, Jaroslaw Staniek wrote:

On 30 May 2016 at 17:11, Michael Pyne > 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 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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-06-06 Thread Jaroslaw Staniek

On 30 May 2016 at 17:11, Michael Pyne  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 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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-30 Thread Michael Pyne

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
> the 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).

Regards,
 - Michael Pyne

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-30 Thread Martin Graesslin

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 the actual 
implementation should stay GPL in my opinion.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-30 Thread Hugo Pereira Da Costa


On 05/30/2016 12:33 AM, Aleix Pol wrote:

On Mon, May 23, 2016 at 9:38 AM, Martin Graesslin  wrote:

On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:

So we, in KDE, lack LGPL style code for our de-facto official look and feel.

This is the crucial point. Breeze is not the de-facto official look and feel of
KDE. It's the look and feel of Plasma.

Let's stop there, please. I know where you come from, but here we're
being unhelpful for little reason. The fact that Plasma uses Breeze
doesn't mean that it's Plasma's property. In fact, it's how QtQuick is
shaping up to work for us, shunning Breeze for non-Plasma KDE
applications puts several projects in jeopardy.

We need to decide what we want before assuming everything is set.

Hi,

I am getting so confused by this thread I must say (and by the overall 
tone of it).

Could someone summarize
1/ which part of the following breeze subdirectories would be concerned 
by the change ? (I keep hearing about icons, but they are not in the 
same repo, and by qtquickcontrols but I thought this was handled 
elsewhere and passed to the QStyle, while the directory here is just a 
"preview" of how breeze should look)


- cursors
- kdecoration
- kstyle
- lookandfeel.dark
- misc
- printing
- qtquickcontrols

2/ what would be the reason and use case for making the change, and for 
instance what someone would effectively do with say breeze/kstyle being 
LGPL that he/she cannot do with it being GPL. (in clear, concrete words, 
with example)


3/ which projects presently are in jeopardy, how and why ? (again: 
clear/simple words please)


Sorry if this was already said elsewhere, but the thread is already 
long, a lot of things have been said, and a lot has been chopped.


Thanks,

Hugo



Aleix
___
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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-29 Thread Aleix Pol

On Mon, May 23, 2016 at 9:38 AM, Martin Graesslin  wrote:
> On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:
>> So we, in KDE, lack LGPL style code for our de-facto official look and feel.
>
> This is the crucial point. Breeze is not the de-facto official look and feel 
> of
> KDE. It's the look and feel of Plasma.

Let's stop there, please. I know where you come from, but here we're
being unhelpful for little reason. The fact that Plasma uses Breeze
doesn't mean that it's Plasma's property. In fact, it's how QtQuick is
shaping up to work for us, shunning Breeze for non-Plasma KDE
applications puts several projects in jeopardy.

We need to decide what we want before assuming everything is set.

Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-28 Thread Michael Pyne

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.

On the other hand the major reason we would have needed a KStyle to have a 
license exemption in previous KDE desktop shells was so that third-party apps 
could better integrate into our desktop, not because we wanted applications to 
clone our style and use it outside of our desktop. So the extent that the 
plugin mechanism being discussed still allows apps to integrate into Plasma, 
it sounds to me like it's at least still doing what we'd expect, at least 
within our own shell.

Either way, we seem to have settled on the idea of Qt being wholly responsible 
for integration ties into the desktop shell (whether that's Plasma, Windows, 
something else), and for that integration by Qt to settle on a style. That 
approach is consistent with Breeze-the-style being part of Plasma instead of 
an upstream tier. Whether that's always the ideal approach to take is perhaps 
a different question, but I don't intend to open it here.

Regards,
 - Michael Pyne
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-28 Thread Jaroslaw Staniek

On 23 May 2016 at 09:38, Martin Graesslin  wrote:

> On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:
> > So we, in KDE, lack LGPL style code for our de-facto official look and
> feel.
>
> This is the crucial point. Breeze is not the de-facto official look and
> feel of
> KDE. It's the look and feel of Plasma.

This is playing a word game here.

> Applications shouldn't use it.
>

Because? Who says so? That would be the first SDK that suggest claims. And
that's the only open source style I have around with such clause.
With all respect to the original authors (I spent time for bugfixing too),
things go WRONG if we didn't collect requirements (ability to run non-GPL
apps under Plasma) and started coding.
Relicensing is a clean and simple means to undo this mistake. Earlier --
better.

We were all the time correct with licensing -- I mentioned KDElibs4 before.
Let's see how it went in KDE3 (Plastik, Highcolor, etc.):
https://websvn.kde.org/branches/KDE/3.5/kdelibs/

I started contributions in 2003. These were times when usage of the styles
by non-GPL apps were assumed.
At the same time before LGPL-izing, Qt had non-GPL exception what allowed
to use Qt's styles with non-GPL apps. Everything was clear and Qt app
development was no more closed than Visual Basic and a bit more closed than
GTK+.
After LGPL-izing, Qt styles went all LGPL because obviously otherwise
plugins linking to symbols would make the user's code GPL.

> Applications of course can use it as much as they want. Nobody is going to
> forbid it. But the fact that they use it, doesn't make it the de-facto
> official
> look and feel and doesn't mean that we have to licence the style as LGPL.
>

For now the _license_ forbids it. No distributed app can contain
GPL-incompatible part or plugin. If I had to produce no matter what type of
GPL plugin, a style plugin,  SQL plugin, image format - I am spreading the
virality of GPL in all the uses. That's also what are the dual licensing
businesses are about, don't we see?

> I stay where I am: I am not agreeing to having my code in Breeze (and
> Oxygen)
> being relicensed to LGPL. I don't see a need for it, I think GPL is the
> right
> choice for that code.
>

It would not matter as much as what's the right choice for KDE as a
product in the route to success comparable with competing products. If we
think strategically, code is our byproduct.
In another (internal) contributor's thread we just started to discuss
marketing of KDE and that nobody knows what's what in the twisted
architecture.
Compulsive modularization (or limiting licensing) can degrade products I am
afraid.

How is it important to someone who wants to, say, sell a calculator app
that is runing on top of Plasma when all she gets from us is
"GPL-compatibility is good choice for your calculator".

This is not going well. I was _this_ close to a blog entry about default
Plasma installations not allowing non-GPL applications. But why to have
another Akonadi-like rant. There are always solutions. Now I see that maybe
it's better to switch to a breeze-fied fusion style (LGPL).

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.

Cheers

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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-23 Thread Martin Graesslin

On Sunday, May 22, 2016 12:22:28 AM CEST Jaroslaw Staniek wrote:
> So we, in KDE, lack LGPL style code for our de-facto official look and feel.

This is the crucial point. Breeze is not the de-facto official look and feel of 
KDE. It's the look and feel of Plasma. Applications shouldn't use it. 
Applications of course can use it as much as they want. Nobody is going to 
forbid it. But the fact that they use it, doesn't make it the de-facto official 
look and feel and doesn't mean that we have to licence the style as LGPL.

I stay where I am: I am not agreeing to having my code in Breeze (and Oxygen) 
being relicensed to LGPL. I don't see a need for it, I think GPL is the right 
choice for that code.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-21 Thread Jaroslaw Staniek

On 18 May 2016 at 17:51, Martin Graesslin  wrote:

> On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote:
> > On 17 May 2016 at 20:38, Martin Graesslin  wrote:
> > > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > > > > If you show me why it needs to be a framework and I agree with it,
> > > > > I might be willing to consider to allow to relicense the code I
> wrote
> > >
> > > for
> > >
> > > > > it.
> > > >
> > > > There's no request to make it framework from me. LGPLing Breeze does
> not
> > > > automatically add obligation to create and maintain a framweork.
> > >
> > > Especially
> > >
> > > > that there are not widely declared use cases. It's just a way to get
> the
> > > > same what was legal in the times of Oxygen and KDElibs 4.
> > >
> > > Yes exactly! If you would present me reasons why it should become a
> > > framework
> > > I might see a need for it to have it LGPL. That is something I
> currently
> > > don't
> > > see. Thus I don't see a reason to change it to LGPL.
> >
> > But there's no rule in KDE that LGPL code needs to form frameworks.
> > No need to switch the topic... Adding a framework is a lot of
> > responsibility I am aware of and I don't request more work from others.
> > We had an agreement within KDE organization that there's not even rule
> > that KDE projects have to use C++ or Qt. People can implement things in
> > HTML or C# or Java. Unless licenses stay against it but I see no reason
> why
> > would be that.
> >
> > > Similar I don't relicense KWin to LGPL, just because there might be a
> > > reason
> > > later on.  When we split out code from KWin to KWayland we did the
> > > relicense
> > > as needed.
> >
> > You see, authors have the benefit of re-licensing when _they_ need.
> > I am not the author and have to face unusual extensive testing of my
> > reasoning.
>
> You are asking me as a copyright holder whether I agree to a relicense. You
> have to convince me. To me the default licence is GPLv3+. Everything else
> means an exception to my personal view. You have to provide really good
> reasons to make me agree that this is needed.
>
> So far I have not seen them. It is more a wishy-washy about you want to use
> some code. That's not a reasoning. Explain why you need it and explain it
> that
> makes sense with our overall KDE vision about
> 
> applications not being part of
> Plasma and depending on Plasma. Especially: how do you want to achieve it
> without making applications depend on Plasma, which is nothing we want.
> Copy
> code? No way, for that I'm not going to agree to relicense.
>
>
Martin,
"Depending on plasma" is a term at the level of deployment. It addresses
requirements that may be important to someone but not to the entire
mankind. Not every software title is developed by operating in the scope of
term that you're referring to. I am sharing examples below.

With all due respect I don't want to even discuss using licenses as a
tool/weapon to dictate deployment, scope of use, etc. And whether all
desktop applications that use Breeze style and icons to display something
(not necessarily QWidgets) must be part of Plasma -- which so far isn't
official component/subsystem of Windows or OS X. So how a KDE app on
Windows has to be part of Plasma is not clear to me.

Then the KDE Vision and copying, good that you're asking because there's
some exercise. The KDE Vision is orthogonal to something even stronger than
copying: _forking_ projects, even without "convincing" or explaining
original authors. And these projects can be part of KDE exactly the way the
original is.

So Plasma (design and icons - SVG code) has been copied multiple times
already out of KDE, what includes a copy for GTK+ apps and LibreOffice
apps. The Breeze style has been copied to the LGPLized GTK+ style. I don't
need to add that none of such apps mention Plasma or even KDE. And most
users of popular KDE apps such as Krita wouldn't even know what _kind_ of
term Plasma is if we ask them. You know, most of these users are on
Windows. I am not trying to devalue Plasma by saying this but to show that
in the entire population there are various interests.

Then, creating an Android or iOS package is ultimately also copying.
Creating Windows/Mac installers of pro apps is very interesting exercise in
copying and picking versions of components that are needed and work
together. Suddenly you become developer and packager, something not very
often practices on Linux. Copying happens not for just copying but it's
possible in extreme cases as a way to circumvent improper license choice,
when other styles (in fact _libraries_ of drawing routines!) are LGPL, this
one is not.

So we, in KDE, lack LGPL style code for our de-facto official look and feel.

That's a paradox, at the moment _non-KDE_ projects have actually more
freedom than KDE contributors to use the current _KDE's_ major desktop
visual identity. That price for

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-18 Thread Martin Graesslin

On Wednesday, May 18, 2016 12:41:49 PM CEST Jaroslaw Staniek wrote:
> On 17 May 2016 at 20:38, Martin Graesslin  wrote:
> > On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > > > If you show me why it needs to be a framework and I agree with it,
> > > > I might be willing to consider to allow to relicense the code I wrote
> > 
> > for
> > 
> > > > it.
> > > 
> > > There's no request to make it framework from me. LGPLing Breeze does not
> > > automatically add obligation to create and maintain a framweork.
> > 
> > Especially
> > 
> > > that there are not widely declared use cases. It's just a way to get the
> > > same what was legal in the times of Oxygen and KDElibs 4.
> > 
> > Yes exactly! If you would present me reasons why it should become a
> > framework
> > I might see a need for it to have it LGPL. That is something I currently
> > don't
> > see. Thus I don't see a reason to change it to LGPL.
> 
> But there's no rule in KDE that LGPL code needs to form frameworks.
> No need to switch the topic... Adding a framework is a lot of
> responsibility I am aware of and I don't request more work from others.
> We had an agreement within KDE organization that there's not even rule
> that KDE projects have to use C++ or Qt. People can implement things in
> HTML or C# or Java. Unless licenses stay against it but I see no reason why
> would be that.
> 
> > Similar I don't relicense KWin to LGPL, just because there might be a
> > reason
> > later on.  When we split out code from KWin to KWayland we did the
> > relicense
> > as needed.
> 
> You see, authors have the benefit of re-licensing when _they_ need.
> I am not the author and have to face unusual extensive testing of my
> reasoning.

You are asking me as a copyright holder whether I agree to a relicense. You 
have to convince me. To me the default licence is GPLv3+. Everything else 
means an exception to my personal view. You have to provide really good 
reasons to make me agree that this is needed.

So far I have not seen them. It is more a wishy-washy about you want to use 
some code. That's not a reasoning. Explain why you need it and explain it that 
makes sense with our overall KDE vision about applications not being part of 
Plasma and depending on Plasma. Especially: how do you want to achieve it 
without making applications depend on Plasma, which is nothing we want. Copy 
code? No way, for that I'm not going to agree to relicense.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-18 Thread Jaroslaw Staniek

On 17 May 2016 at 20:38, Martin Graesslin  wrote:

> On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > > If you show me why it needs to be a framework and I agree with it,
> > > I might be willing to consider to allow to relicense the code I wrote
> for
> > > it.
> >
> > There's no request to make it framework from me. LGPLing Breeze does not
> > automatically add obligation to create and maintain a framweork.
> Especially
> > that there are not widely declared use cases. It's just a way to get the
> > same what was legal in the times of Oxygen and KDElibs 4.
>
> Yes exactly! If you would present me reasons why it should become a
> framework
> I might see a need for it to have it LGPL. That is something I currently
> don't
> see. Thus I don't see a reason to change it to LGPL.
>

But there's no rule in KDE that LGPL code needs to form frameworks.
No need to switch the topic... Adding a framework is a lot of
responsibility I am aware of and I don't request more work from others.
We had an agreement within KDE organization that there's not even rule
that KDE projects have to use C++ or Qt. People can implement things in
HTML or C# or Java. Unless licenses stay against it but I see no reason why
would be that.

>
> Similar I don't relicense KWin to LGPL, just because there might be a
> reason
> later on.  When we split out code from KWin to KWayland we did the
> relicense
> as needed.
>

You see, authors have the benefit of re-licensing when _they_ need.
I am not the author and have to face unusual extensive testing of my
reasoning.
You're free to do that but that sounds oppressive. From the KF5
perspective I am the "customer", framework authors would have to listen to
in some real world.

>
> > Why on the icons and not on style? (See also below)
> > I have apps/libs that hard-depend on breeze style. (not just the
> > implementation, on the design)
> > Example reason: because for my requirements it works better with the
> icons
> > and for example Windows 95 or Windows 7 style does not. Or I hav code
> that
> > does not link to QWidget and still needs to paint/print something that is
> > desinged in Breeze style.
>
> Are that made up examples? If you want to use a QStyle in an application
> not
> using QWidgets you have lost already.
>

It would be better not experiencing one KDE contributor patronising other
KDE contributor. it would be more proactive to hear "I don't see this use
case maybe because I don't work on such software but I trust you and I am
happy with more FOSS working together".

>
> > Bottom line, IIRC there are no KDE applications anymore. You can't
> predict
> > what OS / UX the _Qt_ apps will be used on. So author of applications are
> > perfectly free to target other OSes than just the Plasma-based ones.
>
> We want KDE applications to integrate with the OSes style and not force the
> Plasma style on apps in e.g. GNOME. We don't want apps to force the breeze
> style.
> 
>

You can't stop that with restrictions but with a great architecture. I
have different approach now and licensing won't stop that, it will just
just cost more and ultimately would be uglier. Inclusive attitude instead
we-they and licensing can be the cheapest solution and investment for the
future.

>
> >
> > > > Icons are part of the KF5 product [1] which does not mean libraries
> > >
> > > depend
> > >
> > > > on them
> > > > https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> > > > (well I believe as a product they depend but that's out-of-the box
> level
> > > > thinking not belonging here)
> > >
> > > libraries do depend on icons. Otherwise there wouldn't be efforts on
> how
> > > to
> > > package all required icons in the case of Android.
> >
> > Very good, so similarly, I am packaging the breeze style for desktop
> OSes
> > that lack Breeze QStyle. And like on Android, for these OSes the style
> is
> > defined/decided at the application's level. And I have chosen Breeze
> style
> > and icons and using that assumption while developing custom widgets (a
> hell
> > of work for even for one style when QStyle is a stalled API now).
>
> So you are porting part of Plasma to other OSes. That's great! Though
> doesn't
> mean that Plasma should relicense code.
>

No... I don't port a desktop experience.

 My universe in this case is the application,  

that's not unusual in the real world. Many apps used nowadays (mobile, web)
do so I don't see why this should be prohibited.  I am cherry picking to
make app that looks the same.
In the real world you don't buy a new Ferrari without body so you can play
with own bodies or use one from Ford. Either you like and get the whole
experience or build your care on your own.

Plasma is not referred in any place of that work. This may be a challenge
in conservative circles as in this thread but new things are challenging.

>
> >
> > > > Do you then agree with relicensing after my explanations here and in
> the

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-18 Thread Aleix Pol

On Wed, May 18, 2016 at 11:36 AM, Hugo Pereira Da Costa
 wrote:
> On 05/18/2016 11:13 AM, Jaroslaw Staniek wrote:
>
>
>
> On 17 May 2016 at 20:48, Hugo Pereira Da Costa
>  wrote:
>>
>> Hi,
>>
>> [snip]
>>>
>>>
>>> Architecturally, the eventual solution would be that breeze.git becomes
>>> layered, and routines beyond what QStyle defines are provided by an LGPL
>>> lib. It worked with libOxygen that is LGPL.
>>> The reason for liboxygen was that part of Oxygen was also used by KWin
>>> decoration. We fixed that by moving the decorations together with the
>>> style
>>> into one repository.
>>
>> liboxygen was also there to take care of code shared between the style and
>> the decoration, but internal only, no headers exported, no so version, no
>> abi, api stability guaranty of any kind. I have no clue how this could be
>> used by the external world in any way.
>
>
> It is, I explained it a bit. But anyway it's FOSS so explaining was not
> needed. I am not implementing frameworks or plasma so I am not obligated to
> rules or habits expressed here.
>
>
>>
>>
>>> Personally I think liboxygen was rather a hack and an annoyance.
>>
>> based on the above, I was seeing it as a "private" library, needed to
>> avoid code duplication and ease maintenance between two parts of oxygen.
>> As for the licensing of such a thing, no clue, but again, I never intended
>> it to be re-used by any other code.
>
>
> Like above, do you agree it to be reused or not.
>
> I would not agree with the library to be linked against because I do not
> want to provide the guaranties that goes with it (about ABI and API
> stability) or do not want to be held responsible for these to be broken. I
> do agree for people copying the code around and take over these
> responsibilities if they want.
>
> I am not asking if you intend to use it, I am asking if you are OK/open with
> others using the code in other FOSS code.
>
>
>>
>>
>>>
 Especially that QStyle is
 mostly just maintained. "Use QStyle and plugins" sounds almost like "use
 X
 "protocol instead of DWD"...
 Going LGPL is a first step for this being even considered as a task by a
 KDE contributor. Without that the easiest thing is to work downstream
 forking^w copying the design and such.

>> The request is about the freedom to use of the code from of the breeze
>> style in LGPL code freely opening freedom for experimentation and
>
> progress.
>
>> The design (by VDG) is free to use (LGPL I think), why wouldn't the
>> implementation be free-to-link?
>
> I repeat again: I object to a relicense of code I have written to GPL
> in
> the
> case of Breeze and Oxygen.

 I see much of oxygen

 is BSD-like and LGPL of the change happened in with the Breeze.
>>>
>>> I have here a file open oxygenstyleplugin.cpp which is licensed as GPL
>>> v2+.
>>> Thus the whole thing is licensed GPLv2+. Why the code is inconsistent
>>> licensed
>>> I do not know.
>>
>>
>> Probably me copying code around without caring much. I would agree to
>> re-license all the part I wrote to GPL v2+.
>>
>
> Cool but that was not my question
>
> .
>
> I know. And I did not agree to relicense to LGPL. I did agree with Martin
> about it being licenced GPL and agree to relicense the code I wrote to GPL.
>
> I am ok with the compile code being used as a plugin, and not to be linked
> against (because of the same responsibilities I do not want to take). I am
> ok with bits of code being copied and reused.
>
>
> I asked to relicense to LGPL so I don't need to reimplement the same bits of
> style for non-QStyle code. Or reuse artwork from GTK+.
>
>
>
>
>
>
>> best,
>>
>> Hugo
>>
>>
>>>
 Again what's wrong for you with libOxygen that is LGPL?
>>>
>>> liboxygen is not lgpl licensed. Look for example at
>>> liboxygen/liboxygen.h. It
>>> has a GPLv2+ header, thus is GPLv2+
>>>


>> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
>> clearly as these would be actually scripts and graphic/style files.
>> Why
>> would we have inferior situation just because we happen to use
>> compilers?
>
> I don't see what that has to do with it.

 It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have
 freedoms that Breeze actually lack just because the licensing choice.
 And
 that may or may not be a missed opportunity.
>>>
>>> I just checked the folder qtquickcontrols - those files are unfortunately
>>> not
>>> licensed at all. This is clearly wrong.
>>>
>>> Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also
>>> cannot just take parts of it. Though the individual files are lacking a
>>> copyright header.
>>>
>>> Cheers
>>> Martin
>>
>>

This is very gratuitous confrontation.

To be honest, I still don't really understand what's the proposal and
we're going to the details

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-18 Thread Jaroslaw Staniek

On 17 May 2016 at 20:48, Hugo Pereira Da Costa <
hugo.pereira.da.co...@gmail.com> wrote:

> Hi,
>
> [snip]
>
>>
>> Architecturally, the eventual solution would be that breeze.git becomes
>> layered, and routines beyond what QStyle defines are provided by an LGPL
>> lib. It worked with libOxygen that is LGPL.
>> The reason for liboxygen was that part of Oxygen was also used by KWin
>> decoration. We fixed that by moving the decorations together with the
>> style
>> into one repository.
>>
> liboxygen was also there to take care of code shared between the style and
> the decoration, but internal only, no headers exported, no so version, no
> abi, api stability guaranty of any kind. I have no clue how this could be
> used by the external world in any way.
>

It is, I explained it a bit. But anyway it's FOSS so explaining was not
needed. I am not implementing frameworks or plasma so I am not obligated
to rules or habits expressed here.



>
> Personally I think liboxygen was rather a hack and an annoyance.
>>
> based on the above, I was seeing it as a "private" library, needed to
> avoid code duplication and ease maintenance between two parts of oxygen.
> As for the licensing of such a thing, no clue, but again, I never intended
> it to be re-used by any other code.


Like above, do you agree it to be reused or not. I am not asking if you
intend to use it, I am asking if you are OK/open with others using the code
in other FOSS code.



>
>
>> Especially that QStyle is
>>> mostly just maintained. "Use QStyle and plugins" sounds almost like "use
>>> X
>>> "protocol instead of DWD"...
>>> Going LGPL is a first step for this being even considered as a task by a
>>> KDE contributor. Without that the easiest thing is to work downstream
>>> forking^w copying the design and such.
>>>
>>> The request is about the freedom to use of the code from of the breeze
> style in LGPL code freely opening freedom for experimentation and
>
 progress.

 The design (by VDG) is free to use (LGPL I think), why wouldn't the
> implementation be free-to-link?
>
 I repeat again: I object to a relicense of code I have written to GPL in
 the
 case of Breeze and Oxygen.

>>> I see much of oxygen
>>>
>>> is BSD-like and LGPL of the change happened in with the Breeze.
>>>
>> I have here a file open oxygenstyleplugin.cpp which is licensed as GPL
>> v2+.
>> Thus the whole thing is licensed GPLv2+. Why the code is inconsistent
>> licensed
>> I do not know.
>>
>
> Probably me copying code around without caring much. I would agree to
> re-license all the part I wrote to GPL v2+.
>
>
Cool but that was not my question

. I asked to relicense to LGPL so I don't need to reimplement the same
bits of style for non-QStyle code. Or reuse artwork from GTK+.





best,
>
> Hugo
>
>
>
>> Again what's wrong for you with libOxygen that is LGPL?
>>>
>> liboxygen is not lgpl licensed. Look for example at
>> liboxygen/liboxygen.h. It
>> has a GPLv2+ header, thus is GPLv2+
>>
>> 
>>>
>>> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
> clearly as these would be actually scripts and graphic/style files. Why
> would we have inferior situation just because we happen to use
> compilers?
>
 I don't see what that has to do with it.

>>> It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have
>>> freedoms that Breeze actually lack just because the licensing choice.
>>> And
>>> that may or may not be a missed opportunity.
>>>
>> I just checked the folder qtquickcontrols - those files are unfortunately
>> not
>> licensed at all. This is clearly wrong.
>>
>> Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also
>> cannot just take parts of it. Though the individual files are lacking a
>> copyright header.
>>
>> Cheers
>> Martin
>>
>
>


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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-17 Thread Hugo Pereira Da Costa


Hi,

[snip]


Architecturally, the eventual solution would be that breeze.git becomes
layered, and routines beyond what QStyle defines are provided by an LGPL
lib. It worked with libOxygen that is LGPL.
The reason for liboxygen was that part of Oxygen was also used by KWin
decoration. We fixed that by moving the decorations together with the style
into one repository.
liboxygen was also there to take care of code shared between the style 
and the decoration, but internal only, no headers exported, no so 
version, no abi, api stability guaranty of any kind. I have no clue how 
this could be used by the external world in any way.



Personally I think liboxygen was rather a hack and an annoyance.
based on the above, I was seeing it as a "private" library, needed to 
avoid code duplication and ease maintenance between two parts of oxygen.
As for the licensing of such a thing, no clue, but again, I never 
intended it to be re-used by any other code.



Especially that QStyle is
mostly just maintained. "Use QStyle and plugins" sounds almost like "use X
"protocol instead of DWD"...
Going LGPL is a first step for this being even considered as a task by a
KDE contributor. Without that the easiest thing is to work downstream
forking^w copying the design and such.


The request is about the freedom to use of the code from of the breeze
style in LGPL code freely opening freedom for experimentation and

progress.


The design (by VDG) is free to use (LGPL I think), why wouldn't the
implementation be free-to-link?

I repeat again: I object to a relicense of code I have written to GPL in
the
case of Breeze and Oxygen.

I see much of oxygen

is BSD-like and LGPL of the change happened in with the Breeze.

I have here a file open oxygenstyleplugin.cpp which is licensed as GPL v2+.
Thus the whole thing is licensed GPLv2+. Why the code is inconsistent licensed
I do not know.


Probably me copying code around without caring much. I would agree to 
re-license all the part I wrote to GPL v2+.


best,

Hugo




Again what's wrong for you with libOxygen that is LGPL?

liboxygen is not lgpl licensed. Look for example at liboxygen/liboxygen.h. It
has a GPLv2+ header, thus is GPLv2+





PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
clearly as these would be actually scripts and graphic/style files. Why
would we have inferior situation just because we happen to use
compilers?

I don't see what that has to do with it.

It means that styles for HTML and Qt Quick _and_ GTK+ Breze style have
freedoms that Breeze actually lack just because the licensing choice. And
that may or may not be a missed opportunity.

I just checked the folder qtquickcontrols - those files are unfortunately not
licensed at all. This is clearly wrong.

Concerning GTK+ Breeze style: the COPYING.lib says it's LGPL. So you also
cannot just take parts of it. Though the individual files are lacking a
copyright header.

Cheers
Martin


___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-17 Thread Martin Graesslin

On Tuesday, May 17, 2016 6:23:10 PM CEST Jaroslaw Staniek wrote:
> > If you show me why it needs to be a framework and I agree with it,
> > I might be willing to consider to allow to relicense the code I wrote for
> > it.
> 
> There's no request to make it framework from me. LGPLing Breeze does not
> automatically add obligation to create and maintain a framweork. Especially
> that there are not widely declared use cases. It's just a way to get the
> same what was legal in the times of Oxygen and KDElibs 4.

Yes exactly! If you would present me reasons why it should become a framework 
I might see a need for it to have it LGPL. That is something I currently don't 
see. Thus I don't see a reason to change it to LGPL.

Similar I don't relicense KWin to LGPL, just because there might be a reason 
later on.  When we split out code from KWin to KWayland we did the relicense 
as needed.

> Why on the icons and not on style? (See also below)
> I have apps/libs that hard-depend on breeze style. (not just the
> implementation, on the design)
> Example reason: because for my requirements it works better with the icons
> and for example Windows 95 or Windows 7 style does not. Or I hav code that
> does not link to QWidget and still needs to paint/print something that is
> desinged in Breeze style.

Are that made up examples? If you want to use a QStyle in an application not 
using QWidgets you have lost already.

> Bottom line, IIRC there are no KDE applications anymore. You can't predict
> what OS / UX the _Qt_ apps will be used on. So author of applications are
> perfectly free to target other OSes than just the Plasma-based ones.

We want KDE applications to integrate with the OSes style and not force the 
Plasma style on apps in e.g. GNOME. We don't want apps to force the breeze 
style.

> 
> > > Icons are part of the KF5 product [1] which does not mean libraries
> > 
> > depend
> > 
> > > on them
> > > https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> > > (well I believe as a product they depend but that's out-of-the box level
> > > thinking not belonging here)
> > 
> > libraries do depend on icons. Otherwise there wouldn't be efforts on how
> > to
> > package all required icons in the case of Android.
> 
> Very good, so similarly, I am packaging the breeze style for desktop OSes
> that lack Breeze QStyle. And like on Android, for these OSes the style is
> defined/decided at the application's level. And I have chosen Breeze style
> and icons and using that assumption while developing custom widgets (a hell
> of work for even for one style when QStyle is a stalled API now).

So you are porting part of Plasma to other OSes. That's great! Though doesn't 
mean that Plasma should relicense code.

> 
> > > Do you then agree with relicensing after my explanations here and in the
> > > other email?
> > 
> > no, sorry, I still don't see why that would be needed.
> 
> Legal reason:
> I am distributing the Breeze QStyle for OSes without Plasma installed.
> There is some LGPL code, it's the same purpose for LGPL as KF5 has, opening
> up for use by GPL-incompatible apps. But Breeze code can't be used as a
> part of it even by linking. Breeze is GPL unlike all the styles shipped
> with Qt (4 or 5) that are LGPL.

Huh? Oxygen is also GPL and I don't see how it matters how Qt publishes their 
styles.

> There's no even exception in Breeze style.
> Breeze can't be used even if people pay $$$ to KDE in such cases.
> It's closed for this usage paths. It's even close for GPL-incompatible open
> source projects but that's another matter; it's not possible to compile-in
> an GFDL resource into the app or Mozilla licensed one -- all this is
> incompatible with GPL.
> Hard to explain to developers that there are so many not obvious
> restrictions when they move from styles distributed with Qt5 to Breeze.

well yes, Plasma as a platform is GPL. If you want to derive your product from 
Plasma you need to follow Plasma's licensing.

> 
> Breeze can be semi-legally used with GPL-incompatible app on the user's
> machine when it is loaded as a plugin without user knowing what is
> happening.
> Semi-legally because such app can't become GPL at runtime. It's just happy
> user not knowing there's a conflict.

That's not semi-legally. That's fully legally and the idea behind the plugin. 
We as Plasma inject the plugin into the running application. If an application 
sets it to use the breeze style manually I consider this as derived work.

> 
> I am afraid this situation also extends so Plasma based OSes became
> generally non-accessible (depends on jurisdiction and IANAL) for non-FOSS
> world. In my opinion Breeze can't be set as default in non-GPL app now. And
> what we're protecting here - has to be decided.

That looks fine to me. Non-GPL apps should not define a hard dependency on 
Plasma.

> 
> 
> Technical reason:
> Assume a software architecture that displays a check box in an interactive
> document. Say, it's

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-17 Thread Jaroslaw Staniek

On 17 May 2016 at 15:02, Martin Graesslin  wrote:

> On Tuesday, May 17, 2016 2:21:43 PM CEST Jaroslaw Staniek wrote:
> > On 9 May 2016 at 07:53, Martin Graesslin  wrote:
> > > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> > > > Hi,
> > > > Is relicensing Breeze QStyle to LGPL from GPL for possible and
> > >
> > > acceptable?
> > >
> > > > I've found cases when bits of the code beyond QStyle/KStyle API need
> > > > to be reused. One example is: custom widgets.
> > > > If we're considering Breeze QStyle as implementation of certain
> > > > artwork, and KDE artwork in general would be LGPL also for
> > > > consistency.
> > > > For example wallpapers, icons are LGPL.
> > > >
> > > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> > > > it's not clear in breeze.git. The same question here: can it be LGPL
> > > > or BSD?
> > > >
> > > > Bottom line is: if we want to popularise our frameworks in the
> outside
> > > > world...
> > >
> > > I fail to follow you why Breeze QStyle should be a framework. No
> framework
> > > should depend on it, Breeze QStyle is a plugin and it's only getting
> > > loaded by
> > > either setting an env variable manually or using the Plasma QPT plugin
> > > which
> > > is not in Frameworks either.
> >
> > Not only KF5 is LGPL. Also other libraries and also parts of individual
> > apps.
>
> And there are also libraries which are GPL. E.g. kwineffects or
> kscreenlocker
> library.
>
> > BTW: The latter help to create frameworks in the future (picking GPL too
> > early kills the idea).
>
> No it doesn't. It just means that one needs to get everybody to agree on
> the
> relicense.

LGPL decided earlier than later helps to avoid such threads.
KStyle's origins are internals of KDE3.

> If you show me why it needs to be a framework and I agree with it,
> I might be willing to consider to allow to relicense the code I wrote for
> it.
>

There's no request to make it framework from me. LGPLing Breeze does not
automatically add obligation to create and maintain a framweork. Especially
that there are not widely declared use cases. It's just a way to get the
same what was legal in the times of Oxygen and KDElibs 4.

Above app the license obligations of *GPL do not include explaining use
cases for the code. But my friendly attitude shows that I am sharing some
of the boring details with you below...

>
> >
> > > Anyway on the question of whether to relicense to LGPL you should ask
> the
> > > copyright holders and I doubt you found them here on frameworks-devel
> as
> > > Breeze is not a framework. I'm one of the copyright holders and as I
> don't
> > > understand why you want it relicensed I would not agree to it. I think
> GPL
> > > is
> > > the proper license for our workspace components.
> >
> > I'd like more explanation to know if you disagree just for the sake...
>
> of course not!
>
> > Don't you agree with LGPL for breeze or oxygen icons?
>
> We have applications which depend on breeze and oxygen icons. That's why we
> moved them to frameworks. Applications depend on it, LGPL is the proper
> license.
>

Why on the icons and not on style? (See also below)
I have apps/libs that hard-depend on breeze style. (not just the
implementation, on the design)
Example reason: because for my requirements it works better with the icons
and for example Windows 95 or Windows 7 style does not. Or I hav code that
does not link to QWidget and still needs to paint/print something that is
desinged in Breeze style.

>
> The style though is part of Plasma Workspace and as that should follow the
> licensing of Plasma components which is GPL.  This also applies to many
> libraries in Plasma.
>
> >
> > Styles are in *the same* group.
> 
> 
> 
> 
> 
> They make-our-user-experience.
>
> They make up the user-experience of Plasma. Not of the applications.
>

"application s

tyles do not make the user experience of app but icons for some reason
define the apps" seems arbitrary choice and just a "current" state of
things.

Bottom line, IIRC there are no KDE applications anymore. You can't predict
what OS / UX the _Qt_ apps will be used on. So author of applications are
perfectly free to target other OSes than just the Plasma-based ones.

> >
> > Icons are part of the KF5 product [1] which does not mean libraries
> depend
> > on them
> > https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> > (well I believe as a product they depend but that's out-of-the box level
> > thinking not belonging here)
>
> libraries do depend on icons. Otherwise there wouldn't be efforts on how to
> package all required icons in the case of Android.
>

Very good, so similarly, I am packaging the breeze style for desktop OSes
that lack Breeze QStyle. And like on Android, for these OSes the style is
defined/decided at the application's level. And I have chosen Breeze style
and icons and using that assumption while developing

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-17 Thread Martin Graesslin

On Tuesday, May 17, 2016 2:21:43 PM CEST Jaroslaw Staniek wrote:
> On 9 May 2016 at 07:53, Martin Graesslin  wrote:
> > On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> > > Hi,
> > > Is relicensing Breeze QStyle to LGPL from GPL for possible and
> > 
> > acceptable?
> > 
> > > I've found cases when bits of the code beyond QStyle/KStyle API need
> > > to be reused. One example is: custom widgets.
> > > If we're considering Breeze QStyle as implementation of certain
> > > artwork, and KDE artwork in general would be LGPL also for
> > > consistency.
> > > For example wallpapers, icons are LGPL.
> > > 
> > > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> > > it's not clear in breeze.git. The same question here: can it be LGPL
> > > or BSD?
> > > 
> > > Bottom line is: if we want to popularise our frameworks in the outside
> > > world...
> > 
> > I fail to follow you why Breeze QStyle should be a framework. No framework
> > should depend on it, Breeze QStyle is a plugin and it's only getting
> > loaded by
> > either setting an env variable manually or using the Plasma QPT plugin
> > which
> > is not in Frameworks either.
> 
> Not only KF5 is LGPL. Also other libraries and also parts of individual
> apps.

And there are also libraries which are GPL. E.g. kwineffects or kscreenlocker 
library.

> BTW: The latter help to create frameworks in the future (picking GPL too
> early kills the idea).

No it doesn't. It just means that one needs to get everybody to agree on the 
relicense. If you show me why it needs to be a framework and I agree with it, 
I might be willing to consider to allow to relicense the code I wrote for it.

> 
> > Anyway on the question of whether to relicense to LGPL you should ask the
> > copyright holders and I doubt you found them here on frameworks-devel as
> > Breeze is not a framework. I'm one of the copyright holders and as I don't
> > understand why you want it relicensed I would not agree to it. I think GPL
> > is
> > the proper license for our workspace components.
> 
> I'd like more explanation to know if you disagree just for the sake...

of course not!

> Don't you agree with LGPL for breeze or oxygen icons?

We have applications which depend on breeze and oxygen icons. That's why we 
moved them to frameworks. Applications depend on it, LGPL is the proper 
license.

The style though is part of Plasma Workspace and as that should follow the 
licensing of Plasma components which is GPL.  This also applies to many 
libraries in Plasma.

> 
> Styles are in *the same* group. They make-our-user-experience.

They make up the user-experience of Plasma. Not of the applications.

> 
> Icons are part of the KF5 product [1] which does not mean libraries depend
> on them
> https://www.kde.org/announcements/kde-frameworks-5.22.0.php
> (well I believe as a product they depend but that's out-of-the box level
> thinking not belonging here)

libraries do depend on icons. Otherwise there wouldn't be efforts on how to 
package all required icons in the case of Android.

> 
> Do you then agree with relicensing after my explanations here and in the
> other email?

no, sorry, I still don't see why that would be needed.

> 
> The request is about the freedom to use of the code from of the breeze
> style in LGPL code freely opening freedom for experimentation and progress.
> The design (by VDG) is free to use (LGPL I think), why wouldn't the
> implementation be free-to-link?

I repeat again: I object to a relicense of code I have written to GPL in the 
case of Breeze and Oxygen.

> 
> PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
> clearly as these would be actually scripts and graphic/style files. Why
> would we have inferior situation just because we happen to use compilers?

I don't see what that has to do with it.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-17 Thread Jaroslaw Staniek

On 9 May 2016 at 07:53, Martin Graesslin  wrote:

> On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> > Hi,
> > Is relicensing Breeze QStyle to LGPL from GPL for possible and
> acceptable?
> > I've found cases when bits of the code beyond QStyle/KStyle API need
> > to be reused. One example is: custom widgets.
> > If we're considering Breeze QStyle as implementation of certain
> > artwork, and KDE artwork in general would be LGPL also for
> > consistency.
> > For example wallpapers, icons are LGPL.
> >
> > Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> > it's not clear in breeze.git. The same question here: can it be LGPL
> > or BSD?
> >
> > Bottom line is: if we want to popularise our frameworks in the outside
> > world...
>
> I fail to follow you why Breeze QStyle should be a framework. No framework
> should depend on it, Breeze QStyle is a plugin and it's only getting
> loaded by
> either setting an env variable manually or using the Plasma QPT plugin
> which
> is not in Frameworks either.
>

Not only KF5 is LGPL. Also other libraries and also parts of individual
apps.
BTW: The latter help to create frameworks in the future (picking GPL too
early kills the idea).


>
> Anyway on the question of whether to relicense to LGPL you should ask the
> copyright holders and I doubt you found them here on frameworks-devel as
> Breeze is not a framework. I'm one of the copyright holders and as I don't
> understand why you want it relicensed I would not agree to it. I think GPL
> is
> the proper license for our workspace components.
>
>
I'd like more explanation to know if you disagree just for the sake...
Don't you agree with LGPL for breeze or oxygen icons?

Styles are in *the same* group. They make-our-user-experience.

Icons are part of the KF5 product [1] which does not mean libraries depend
on them
https://www.kde.org/announcements/kde-frameworks-5.22.0.php
(well I believe as a product they depend but that's out-of-the box level
thinking not belonging here)

Do you then agree with relicensing after my explanations here and in the
other email?

The request is about the freedom to use of the code from of the breeze
style in LGPL code freely opening freedom for experimentation and progress.
The design (by VDG) is free to use (LGPL I think), why wouldn't the
implementation be free-to-link?

PS: If our tech was HTML and Qt Quick only, our styles would be LGPL
clearly as these would be actually scripts and graphic/style files. Why
would we have inferior situation just because we happen to use compilers?





> Cheers
> Martin
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>


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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-15 Thread Jaroslaw Staniek

On Monday, 9 May 2016, Martin Graesslin  wrote:
> On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
>> Hi,
>> Is relicensing Breeze QStyle to LGPL from GPL for possible and
acceptable?
>> I've found cases when bits of the code beyond QStyle/KStyle API need
>> to be reused. One example is: custom widgets.
>> If we're considering Breeze QStyle as implementation of certain
>> artwork, and KDE artwork in general would be LGPL also for
>> consistency.
>> For example wallpapers, icons are LGPL.
>>
>> Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
>> it's not clear in breeze.git. The same question here: can it be LGPL
>> or BSD?
>>
>> Bottom line is: if we want to popularise our frameworks in the outside
>> world...
>
> I fail to follow you why Breeze QStyle should be a framework. No framework
> should depend on it, Breeze QStyle is a plugin and it's only getting
loaded by
> either setting an env variable manually or using the Plasma QPT plugin
which
> is not in Frameworks either.

Sorry for wrong selection of email. If someone is interested in a us case
for apps I am sharing it below.

I am saying certain *apps* can depend on the code that is not exported via
the plugin interface. Such usage makes the code more like lib than a self
contained plugin for QStyle.

I am not saying that modern styling is a subject possible to
design/distribute as a framework. Rather copy-paste is the ultimate way as
we know in Qt Quick world.
In the optimistic case -- a set of primitive painting functions. Hence the
LGPL can be useful.

>
> Anyway on the question of whether to relicense to LGPL you should ask the
> copyright holders and I doubt you found them here on frameworks-devel as
> Breeze is not a framework. I'm one of the copyright holders and as I don't
> understand why you want it relicensed I would not agree to it. I think
GPL is
> the proper license for our workspace components.
>
> Cheers
> Martin

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

Re: LGPL for Breeze QStyle and qtquickcontrols?

2016-05-08 Thread Martin Graesslin

On Saturday, May 7, 2016 10:10:50 PM CEST Jaroslaw Staniek wrote:
> Hi,
> Is relicensing Breeze QStyle to LGPL from GPL for possible and acceptable?
> I've found cases when bits of the code beyond QStyle/KStyle API need
> to be reused. One example is: custom widgets.
> If we're considering Breeze QStyle as implementation of certain
> artwork, and KDE artwork in general would be LGPL also for
> consistency.
> For example wallpapers, icons are LGPL.
> 
> Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
> it's not clear in breeze.git. The same question here: can it be LGPL
> or BSD?
> 
> Bottom line is: if we want to popularise our frameworks in the outside
> world...

I fail to follow you why Breeze QStyle should be a framework. No framework 
should depend on it, Breeze QStyle is a plugin and it's only getting loaded by 
either setting an env variable manually or using the Plasma QPT plugin which 
is not in Frameworks either.

Anyway on the question of whether to relicense to LGPL you should ask the 
copyright holders and I doubt you found them here on frameworks-devel as 
Breeze is not a framework. I'm one of the copyright holders and as I don't 
understand why you want it relicensed I would not agree to it. I think GPL is 
the proper license for our workspace components.

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

LGPL for Breeze QStyle and qtquickcontrols?

2016-05-07 Thread Jaroslaw Staniek

Hi,
Is relicensing Breeze QStyle to LGPL from GPL for possible and acceptable?
I've found cases when bits of the code beyond QStyle/KStyle API need
to be reused. One example is: custom widgets.
If we're considering Breeze QStyle as implementation of certain
artwork, and KDE artwork in general would be LGPL also for
consistency.
For example wallpapers, icons are LGPL.

Similarly I can only deduce that breeze/qtquickcontrols/* is GPL now,
it's not clear in breeze.git. The same question here: can it be LGPL
or BSD?

Bottom line is: if we want to popularise our frameworks in the outside world...

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

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

Re: LGPL for Breeze QStyle and qtquickcontrols?

LGPL for Breeze QStyle and qtquickcontrols?

25 matches

Site Navigation

Mail list logo

Footer information