[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: KSyntaxHighlighting License - please read
From:       Christoph Cullmann <cullmann () absint ! com>
Date:       2016-12-17 15:01:55
Message-ID: 2136001986.689037.1481986915993.JavaMail.zimbra () absint ! com
[Download RAW message or body]

Hi,

to have some concrete use-case:

We (aka AbsInt) use the commercial Qt for our GUI and do static linking to have easy deployment.

My colleague that builds the UI for sure would prefer to use this framework (and contribute our
additional hls under MIT or similar) instead of using our "poor-mans" internal hl stuff.

Thought with LGPLx that won't fly, as we can't link that in statically.

Greetings
Christoph

> Hi,
> 
>> On Sunday 13 November 2016 18:01:59 Dominik Haumann wrote:
>>> Hi all,
>>> 
>>> since the KSyntaxHighlighting framework as it stands right now is
>>> still pretty new, I think we should talk about its license again.
>>> 
>>> Right now, it says LGPLv2+, which is reasonable, since most of our
>>> libraries are licensed this way.
>>> 
>>> However, reading https://community.kde.org/Policies/Licensing_Policy
>>> it seems other licenses would be an option, too, in particular BSD and
>>> MIT licenses.
>>> 
>>> Personally, I would even prefer one of these, since it would allow the
>>> framework to be used much more easily also in the commercial world
>>> (for instance, the company I am working for disallows LGPL, and many
>>> others do as well).
>>> 
>>> But since I believe especially the KSyntaxHighlighting framework as it
>>> stands has lots of potential of being used outside of KDE (one reason
>>> why it was developed after all), I think we should at least consider
>>> this. For instance, Qt Creator *should* be using this. I'm not sure
>>> whether LGPL is fine for them (would need to be evaluated I guess).
>> 
>> I picked LGPL for my initial work on this as it covers all my use-cases
>> (including non-FOSS ones), but I'd not be opposed to re-license my
>> contributions under a more liberal license if we have a specific use-case
>> where this would actually help. If this is just theory, I'd stay with LGPL.
>> 
>> QtCreator could be such a use-case, but the feedback Kevin posted doesn't
>> sound like they are actually caring much about this.
>> 
>>> The contributors to the KSyntaxHighlighting framework are right now:
>>> vkrause, dhaumann, and some other through the original work, e.g.
>>> cullmann, jowenn.
>>> 
>>> I think we can do this relicense of KSyntaxHighlighting if we want.
>> 
>> Right, now would be the best time to do this.
> I think the point here is: we will never know if others didn't pick us because
> of the license,
> I can at least tell from my experience that e.g. in our company a more liberal
> licensed
> Qt based framework would be much more appreciated, as we can statically link it
> in (like
> we do with our commercial qt) which is the easiest way to deploy for
> multiple-oses.
> 
> I would favor a change to something like MIT, which is easy to understand and
> commonly used
> for other stuff we use like X11 or Wayland.
> 
> We could set the bar for the highlighting files to that, too, for future
> contributions.
> 
>> 
>>> So what are the opinions? And if so, which license would fit best ?
>> 
>> My bigger problem with the licensing of this framework is actually the data
>> files, not the code, for non-FOSS use. A simple grep shows the following
>> licenses in use:
>> 
>>     54 <none>
>>     16 <empty>
>>      1 Apache & LGPL
>>      2 Artistic
>>      1 Artistic License 2.0
>>      1 BSD
>>      1 CC0 Public Domain Dedication, version 1.0, as published by Creative
>> Commons
>>      2 FDL
>>      1 GNU GPL
>>      1 GNU/GPL
>>     34 GPL
>>      1 GPL,BSD
>>      2 GPLv2
>>      1 GPLv3
>>    124 LGPL
>>      5 LGPL version 2.1, or version 3 or later versions approved by the
>> membership of KDE e.V.; or any other license appoved by the emembership of KDE
>> e.V.
>>      1 LGPL-3
>>      2 LGPL2+
>>      5 LGPLv2+
>>      3 MIT
>>      1 New BSD License
>>      1 Public Domain
>>      6 WTFPL
>>      3 public domain
>>      1 zlib/libpng
>> 
>> With the files being compiled into the library, this is not distributable for
>> a non-FOSS application, and even for a pure FOSS usage I'm not sure if this is
>> free of license conflicts. My workaround is shipping a minimal, hand picked
>> set of syntax definition files and downloading the rest on demand.
>> 
>> Going forward I'd suggest to no longer accept syntax definition files with
>> more restrictive licenses than the framework itself, and to not accept
>> underspecified license descriptions such as "LGPL" (rather than e.g.
>> "LGPLv2+"). Without that any attempt to clean up the existing mess will be
>> futile.
> Yes, that would make sense!

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann@AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
[prev in list] [next in list] [prev in thread] [next in thread]