Will this have repercussions in the Maintenance tool? I don't really think that calling Multimedia an "add on" is a reflection of reality, post 1994. For mobile kits (iOS, Android) these are essential features. Sorry, Qt just can't get away with drawing rectangles and text in 2020. I fear this is more maligning of mobile by Lars. I think this will result in providing a lower tier of service than compared to the "essentials".
I object, and wish multimedia to remain an essential part of Qt. > Sent: Friday, May 22, 2020 at 3:47 AM > From: "Lars Knoll" <[email protected]> > To: "Giuseppe D'Angelo" <[email protected]> > Cc: "Qt development mailing list" <[email protected]> > Subject: Re: [Development] Qt Multimedia as Add-on in Qt 6 > > Hi, > > > On 21 May 2020, at 18:08, Giuseppe D'Angelo via Development > > <[email protected]> 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 > [email protected] > https://lists.qt-project.org/listinfo/development > _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
