LGPL for Breeze QStyle and qtquickcontrols?

Hugo Pereira Da Costa hugo.pereira.da.costa at gmail.com
Wed May 18 09:36:20 UTC 2016


On 05/18/2016 11:13 AM, Jaroslaw Staniek wrote:
>
>
> On 17 May 2016 at 20:48, Hugo Pereira Da Costa 
> <hugo.pereira.da.costa at gmail.com 
> <mailto:hugo.pereira.da.costa at 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 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
>
>
>
>
>
> -- 
> regards, Jaroslaw Staniek
>
> KDE:
> : A world-wide network of software engineers, artists, writers, 
> translators
> : and facilitators committed to Free Software development - http://kde.org
> Calligra Suite:
> : A graphic art and office suite - http://calligra.org
> Kexi:
> : A visual database apps builder - http://calligra.org/kexi
> Qt Certified Specialist:
> : http://www.linkedin.com/in/jstaniek

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


More information about the Kde-frameworks-devel mailing list