[kde-community] Request to join the Kde incubator for GCompris

[Aaron J. Seigo]

On Thursday, February 13, 2014 21:16:27 Laszlo Papp wrote:
> On Thu, Feb 13, 2014 at 8:59 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Thursday, February 13, 2014 20:32:36 Laszlo Papp wrote:
> * Before GPLv3, GPLv2 was a commercial friendly license. As far as I
> know GPLv3 made it untenable.

This is false. Samba (which you mention below) is used in many commercial 
products and is licensed under the GPLv3. So obviously it is not “commercially 
untenable”.

There are specific markets (which I already named) which have issues with GPLv3 
due to their business models. This is not a generic issue with the GPLv3, but 
one that comes into play in specific areas of the stack for specific types of 
companies. Is GPLv3 as commercially-friendly as GPLv2? No, it is not. Is it 
commercially untenable? No.

Moreover, I don’t think it is our job to tell an application developer whether 
their product needs to be commercially viable or not. That is their decision 
to make as the creator of the work, imho.

> * You  cannot go back to GPLv2 freely.

This is true of other GPL versions as well, so nothing really new.

> * You already mentioned the sharing yourself. I will give you a
> practical example: Linux and Samba cannot share code for implementing
> two ends of the same protocol.

Well, yes, we agree that GPLv3 code can not be shared with code released under 
licenses. It sucks when that happens, and I wouldn’t encourage everyone to run 
to the GPLv3 due to that. The question is whether we can accept developers who 
choose to do so for their own code, however.

> * One could ask LGPLv3+ in the future (someone consistently after this

Personally, I don’t think we should adopt LGPLv3[+] as an acceptable library 
license: it creates too many issues that are not easily resolvable, as you 
note; however, this is not about libraries but applications. We already have 
different policies for libraries vs. applications.

> There are more among these lines. I am personally not happy with where
> FSF went with this.

I think we should try and keep the FSF and developers who pick that license 
separate in our minds.

-- 
Aaron J. Seigo