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

Fri Feb 14 11:02:31 GMT 2014

Hi Aaron,

On Fri, 14 Feb 2014 09:17:05 +0100
"Aaron J. Seigo" <aseigo at kde.org> wrote:

> 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.
> 

I kinda explained my point not clearly enough, because of the deviation to the
commercial exemption. What I meant to say was that I was told most companies
(I don't know which ones he was referring to, but I concluded it included more
than just the ones you include) fear the GPLv3 enough to not wish to allow it
into their systems. So when someone asked for advice on which open source
licence to use while still protecting their copyright (or the so-called
"Intellectual Property" or "IP"), he suggested using GPLv3 which is good enough
for that and will force most people to negotiate a commercial licence deal.

So if some of our applications will become GPLv3 they may become unacceptable
for use by many such companies, and it won't be feasible for KDE to exempt them
(due to the proliferation of contributors or the non-commercial nature of
the KDE organisation). So these programs simply won't be used as much as they
could if they were GPLv2-and-above.

> > 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 ...
> 

OK.

> > 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.

Yes.

BTW, regarding the so-called "Tivoisation", from what I recall reading on
http://zgp.org/pipermail/linux-elitists/ , the whole story was that Tivo
contacted the https://en.wikipedia.org/wiki/Free_Software_Foundation (FSF)
asking whether the practise of signing the kernel was allowed by the GPLv2.
After consulting their lawyers, the FSF replied "Yes , it's OK, thanks for
asking.". Then after Tivo became popular, this practice was deemed
non-desireable and Richard Stallman nicknamed it "Tiovization" after Tivo
despite the fact that earlier the FSF told Tivo that it was acceptable.

This led to some of the licensing decisions in Android of not having
FSF-licensed code anywhere there, which made it an environment almost
completely, but not quite, unlike GNU/Linux (to paraphrase 
on https://en.wikipedia.org/wiki/The_Hitchhiker%27s_Guide_to_the_Galaxy ).

> 
> > 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.

Well, there are many other licenses that people may wish to use -
https://www.gnu.org/licenses/license-list.html and here -
http://opensource.org/licenses/alphabetical - some of which are not compatible
with the GPLv2 and/or the GPLv3. The Ruby legal document used to mention a
mishmash of licences including beer-ware:
http://www.mail-archive.com/perl6-internals@perl.org/msg07471.html .

People may wish to use all those licences. ;-)

In any case, the MIT licence specifically allows sublicensing to any other
licence and is considered compatible with any present (and I presume future)
version of the GPL, the LGPL and the AGPL. On the other hand, the GPLv3 is not
compatible with the GPLv2 and cannot be easily converted into it without a
rewrite and/or getting the accepted permission of all parties.

People who wish to use the GPLv3 can use a compatible licence that can
be sublicensed or converted to it such as GPLv2-and-above or the MIT licence.
(I am not a lawyer / etc., but I think what I say is correct.).

> 
> > 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.
> 

I see. Well, perhaps a better policy would be that application code that
is contributed to KDE should be kept as GPLv2-and-above if it's already the case
for it, unless it was GPLv3-and-above in the first place or there was a
compelling reason to convert it to such. I'm not sure how much this will be
legally valid.

Anyway, I guess having the libraries as LGPLv2-and-above is also acceptable,
because the LGPLv3, is from what I was told, incompatible with the GPLv2, and
also carries some of the additional restrictions of the GPLv3 (Again - I am
not a lawyer).

I now read most of the original E-mail and saw that what he hopes to get from
the KDE project include:

<<<<

- We need the best skills to create a solid framework
- This is easier to jump on a new project and more interesting for a new 
contributor
- Wehave no on line development tools to migrate

>>>>

Don't know if GCompris can receive short-term help from the KDE project by doing
that, and there are plenty of other hosting services for online projects -
https://en.wikipedia.org/wiki/Forge_%28software%29 - and downstream distributors
can opt to package the Qt version of GCompris too or put it in "task-kde" or
equivalent.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Best Introductory Programming Language - http://shlom.in/intro-lang

Inigo Montoya: You seem a decent fellow. I hate to kill you.
The Man in Black: You seem a decent fellow. I hate to die.
    — http://en.wikiquote.org/wiki/The_Princess_Bride_%28film%29

Please reply to list if it's a mailing list post - http://shlom.in/reply .