Upgrading Silica to Qt6

[Pasci]

@pherjung

e for the community with an upgraded version of Qt. See this comment for further infor

Yes, but Jolla has been also considering releasing AppSupport for community devices for years…

[attah]

@PeegeeTips

keeping silica as ‘secret sauce’ on QT 5.6 (where the licensing permitted this)

How many times must i repeat that this is not the case?

@attah

Basically no parts of Qt changed LGPL->GPL. They changed LGPL2->LGPL3 and GPL2->GPL3.
I.e. almost all still have the same link-ability; basically only tivolization clauses have changed. I really cannot stress this enough.
This is much more likely to be about that locking a bootloader on preinstalled phones may run afoul of “being able to swap out the software”.

[PeegeeTips]

Happy to be corrected.

FYI - i always thought it was because Silica depended on the QT Wayland Compositor, which was moved from LGPL to GPL after 5.6 (in order to encourage commercial QT licensing):

Warning - AI drek:

• Qt Wayland Compositor: This specific module, which allows developers to create their own Wayland compositors, is licensed under GPLv3 for open source use. This means that any application or device using this specific module must also be licensed under a GPL-compatible license, and the source code must be made available to users.

• Qt Wayland Integration Plugin (Client): The component allowing a Qt application to act as a Wayland client is available under the more permissive GNU Lesser General Public License version 3 (LGPLv3) or GPLv2.

• Commercial Option: To use the Qt Wayland Compositor in a proprietary (closed-source) application, a commercial license from The Qt Company must be purchased.

The distinction in licensing for certain modules, including the Wayland Compositor, has been in place since Qt 5.7 to encourage commercial licensing for proprietary products

[poetaster]

Although technically correct, isn’t it more likely to be related to cross-licensing in the automotive domain? I had always guessed Jolla’s hands were tied because of use in a mixed ecosystem in cars?

[attah]

I don’t obviously see how that would be different. Can you expand on your line of reasoning?

[poetaster]

When manufacturer A purchases licenses from B and C (for use in a mixture of MCUs context), I assume they have to be able to have congruent clauses/conditions. That might not be the case when mixing licenses? It may, of course, boil down to tivolization but I can also imagine that it’s more complicated given the need for the legal departments of A, B and C to justify yearly budget increases. Like I said, I’m just guessing.

[attah]

I would need you to be more specific and relate to the current matter to understand i think.

[poetaster]

For an example of the complexity in automotive, with Mercedes explicitly chosen since they’ve been doing embedded linux for a long time (now with their own branded thing) Mercedes-Benz - Embedded IoT Linux and OSS Day

I can certainly imagine some vendors looking at the supply chain and having ‘anti-foss’ license conditions while others play a more differentiated game?

I’m assuming that Jolla products, now in a new corporate entity, were part of the ui in automobiles. Those ui components of course could be developed in a way that has clear boundaries from other sub-systems and so avoid license collision. But, the complexity of the legal language alone could scare off some vendors, I believe.