[Development] Updating the licence policy for Qt Project

Oswald Buddenhagen oswald.buddenhagen at digia.com
Wed Aug 27 18:25:44 CEST 2014


On Wed, Aug 27, 2014 at 08:26:15AM -0700, Thiago Macieira wrote:
> On Wednesday 27 August 2014 15:55:37 Oswald Buddenhagen wrote:
> > On Fri, Aug 22, 2014 at 07:21:38AM +0000, Knoll Lars wrote:
> > > 2. New modules that get added to Qt Project from now on can be licensed
> > > either under
> > 
> > for simplicity, i would suggest qt-project states preferences for
> > 
> > specific options:
> > >     * LGPLv2.1, LGPLv3 and commercial or
> > 
> > of course lgpl2 still makes sense for add-ons hosted outside qt-project,
> > and ones where the author explicitly doesn't want digia to make money
> > from selling this module (though in this case i wouldn't host on
> > qt-project to start with).
> > i don't suppose many people would object if we officially discourage this
> > option ...
> 
> Well, there are still very good reasons to use LGPLv2.1,
>
which are (within the scope of qt-project)?

> so I won't pass judgement here. Let's leave this to the author to
> decide.
> 
correct, but i was suggesting stating preferences, not limiting the
options.

> > >     * LGPLv3 and commercial
> > 
> > is this really a good idea at this point? [...] with qt's long history,
> > there are now many gpl2-only applications which cannot be relicensed any
> > more, so they won't be ever able to use these new modules.
> 
> It's required because we need to link to libraries that are compatible with 
> the v3 but not v2. Namely, the Apache Licence v2-licensed code in Android.
> 
right, i forgot that case.

> Besides, applications from the long history of Qt are not using these modules 
> yet because they don't exist. We're not removing any freedom of theirs.
> 
the point is that they are limited in their expansion of their qt usage,
which would be a natural development in many cases.
so if one follows this argumentation, this licensing choice should be
discouraged unless it is imposed by 3rd-party licensing compatibility.



More information about the Development mailing list