Hi,
> On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development
> <development@qt-project.org> wrote:
>
> Hi,
>
> Il 21/05/20 11:38, Val Doroshchuk ha scritto:
>> The license is not changed, plans just to not ship QtMultimedia with Qt
>> essentials,
>> can be installed separately. Possibly we also support only a limited set of
>> platforms.
>> Qt Essentials must work on every platform, according to the definition of
>> essentials.
>
> While of course it's up to each module maintainer to decide on its status
> (and thus, if QtMM doesn't qualify for "Essentials" any more, can become an
> "Addon"), I'm left wondering why does this imply being moved to the
> Marketplace, out of Qt itself?
>
>
> * Is this part of a broader plan, aiming at streamlining the Qt offer to just
> mean Essentials, while the Addons get moved to the marketplace?
This is something I’ve been at least mentioning at the Contributor Summit
already. Distributing it through the market place is mainly a different means
of packaging it and decoupling the release schedules. A user should still be
able to discover and install Qt MM (or other add-ons delivered through the
market place) in the installer, just as today.
But yes, this goes then towards streamlining Qt 6 a bit. Reducing the set of
things that you have to install, and making more modules optional.
>
> ("Qt offer" is of course inaccurate, given the many offers available, but you
> get my drift...).
>
>
> * If so, are all the practical issues for such addons sorted out? First few
> things that come to mind:
>
> 1) Version numbering scheme, release schedule
This needs some sorting out, I agree.
> 2) CI testing / platform coverage
That should be ok for now, although if an add-on targets several Qt versions at
once, we don’t yet have a good mechanism to deal with that in CI.
> 3) Compatibility promise (own API/ABI stability, which Qt versions it works
> with, etc.)
I think it will be good to give add-ons a bit more flexibility there how to
handle it. This is because different add-ons have rather different
requirements, that we’ve so long all tried to shoehorn into the Qt release
process. Compare for example WebEngine that needs frequent updates due to new
Chromium releases with e.g. Qt SVG that only receives a very limited amount of
bug fixes.
> 4) Where to put the docs, release notes, etc.
Into the package and on the web site as usual.
>
>
> * What about the KDE/Qt agreement? Are the list of Essential and Addon
> modules being re-evaluated there as well? QtMM is not really at liberty of
> changing license because it's an "Essential" (in the agreement).
There’s the agreements legal term, and the status in terms of the agreement is
something we can’t change without agreement from the board of the KDE Free Qt
Foundation.
When the new agreement was done some years ago, we tried to align terms with
what we had in Qt Project at that time. But things do change and I believe we
can change what we see as essential and add-on in terms of the project (and in
the commercial packages) independently of the agreement.
This is confusing to some extent as the legal agreement uses the same terms as
we’re using, but the terms are defined in the agreement itself, and limited to
the scope of the agreement. They don’t dictate how we package or name things in
our releases (as long as the conditions set forth in the agreement are
fulfilled).
The main thing the agreement mandates is the licensing of add-on and essential
modules. But the only real difference between add-ons and essentials (as
defined in the agreement) are that essentials have to be LGPLv3, while *new*
add-ons can be GPLv3. We can’t change licensing of currently supported modules
without agreement from the foundation in neither case. We also can’t reduce the
scope of the agreement, so Qt Multimedia will be part of that agreement no
matter how we package and deliver it to our users.
Cheers,
Lars
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
