Relicensing Krita as LGPLv2+

[Sven Langkamp]

On Thu, Jan 5, 2017 at 10:13 AM, Boudewijn Rempt <boud at valdyas.org> wrote:

> Hi,
>
> Umpteenth draft of this mail, but I think we should consider relicensing
> the GPL code in Krita to LGPL.
>
> One reason is that now that Krita is on its own, the mix of LGPL library
> code inherited from koffice/calligra and GPL library code inherited from
> Krita makes it hard to move code around; like we just did in the svg
> branch, creating the kritacommand library from code from krita/image
> and libs/kundo2. That code needs to be relicensed to LGPL before we
> merge the branch, of course.
>

We could go to GPL for the complete repository and never have to relicense
anything again. It also doesn't happen that often that files need to be
moved across libaries and I have done some relicensing for this in the past.


> Another reason is that there are too many macOS users who get confused
> when they install an application that's not in the app store, and we
> cannot publish GPL software in the app store. I wish I could just shrug
> that off, and I've done that until 3.1, but it's getting quite a
> support burden.
>

This is somewhat of a grey area. At least the FSF thinks that even the LGPL
isn't compatible with the App Store.

https://www.fsf.org/blogs/licensing/left-wondering-why-vlc-relicensed-some-code-to-lgpl

VLC did the same relicensing and is in the App Store, so it works for now.
But I wouldn't bet on that for the future.

Beside that I don't like that Apple indirectly dictates our licensing.

I haven't found a script yet that will figure out who owns copyright
> on the original GPL'ed krita code only -- running things like git fame
> only works on the whole repo, most of which is LGPL already...
>

I'm remain sceptical about this for now.

There is another issue that should be considered. Due to the heavy use of
plugins in Krita it would become very easy to extend Krita with
closed-source plugins. Pratically is would be possible to make a
close-source version on top of the existing code. This may sound
hypothetical, but we had this in the past were the license prevented a
commercial fork. Do we allow that? I think that's something that should at
least be considered.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20170107/50d53baf/attachment.html>