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

[Aaron J. Seigo]

On Friday, February 14, 2014 04:24:12 Shlomi Fish wrote:
> 1. GPLv3 was not commonly acceptable as a suitable licence. Many companies
> who had no significant with GPLv2 won't get near any GPLv3-licensed code.
> Some people told me you can licence your code as GPLv3 (or worse - AGPLv3),
> so your code will still be considered "free-as-in-speech software" by the
> FSF, but still will require companies to pay you for a commercial exemption
> licence because they refuse to get near the GPLv3 and friends. I.e: the
> GPLv3 is a free-as-in-speech software fig leaf.

This is also true with GPLv2. After all, this is how Qt has been funded for 
the last 20 years. It’s inconsistent to say “well, if you do this with GPLv2 
we’re just fine with that” (Qt) and then say “but not if it is GPLv3!"

The new twist with GPLv3 is that _more_ companies do not like it (particularly 
in the device and media industries) so the prospective market grew for 
relicensing. I also don’t think this is at all relevant to KDE application 
code, which has not to date seen this practice.

> 2. As evident to whoever frequents http://freecode.com/ (formerly known as
> Freshmeat.net ), the introduction of the GPLv3 has fragmented the GPL and
> LGPL using projects into GPLv2-only, LGPLv2-only, GPLv2+, GPLv3+, LGPLv3+
> and AGPLv3+ (assuming I didn't forget anything). Often these fragments are

and LGPLv2+ .. in any case, yes, there are backwards compat issues. I think 
that’s a decision application developers need to make, however, not one for us 
to dictate. We can outline the benefits and challenges of each position in our 
policies.

Looking at the real world impact within KDE, most application code sits 
forever in that one application (meaning it’s a non-issue in the common case) 
and when code sharing does happen that is often in the form of a library and 
then the common case there is to move to LGPL.

As for LGPLv3 libraries, the only code this creates problems for is GPLv2-
only. Hopefully we have less and less of that in git.kde.org with the common 
case becoming GPLv2+. I haven’t looked into that, however ...

> The VideoLAN / VLC project took the opposite approach and after being
> unhappy with the GPLv3, decided to convert all their GPLv2 code into
> LGPLv2.

I can name two likely reasons: DRM and tivoization clauses.

Indeed, there is no one-size-fits-all license.

> 3. As a developer, I always preferred to use permissive licences (first the

So imagine that KDE dropped BSD/MIT style licenses from the policy list; 
saying “no” to GPLv3 does something similar to those who wish to adopt it.

> But like I said, I don't really have a say for it. I'm OK with making an
> exception for GCompris, though.

I agree with Albert that exceptions become hard to defend in future or prevent 
from becoming ‘accidental policy’ over time.

-- 
Aaron J. Seigo