Doesn’t Jolla already accept patches submitted to their Qt fork?
Yes, they do. The question is whether we start gathering bugs in one place to focus the effort to improve what we’ve got.
1 Like
Interesting. I wonder if QtWayland reverted back to allowing LGPL silently. GPL-only there would indeed have been a potential blocker (but the ~5.9 effort surely was aborted before that license change).
Although it is not clear to me that the existence of such a license file necessarily means it applies to the whole project.
My best-guess was always that the anti-tivolizarion in LGPL3 was a big risk for being able to lock bootloaders and sign stuff in commercial projects. This was somewhat corroborated by abr’s recent talk, iirc.
My memory fails me on where exactly that was… i’ll see if it comes back to me later and edit that in.
Those 5.15 and 6.x patches are not from Jolla that i have seen, but from other projects using these components, or wanting to try them out. I.e. the likes of PostmarketOS, Nemo/Glacier and so on.
2 Likes
Indeed as soon as I saw it I shared the idea with the others. Also to reply to @oroesler , everything is going fine and it will come to reality soon.
1 Like
Very nice to read that. I’m not coming to do it before xmas & I doubt the load will outgrow my wallet that fast. But once we can estimate how much the load will be in the long-term, it’d be nice to hand financial & legal aspects over to the coop.
… since QT 6.4, but not before that if you look closely.
Can you please provide specific pointers (i.e., web-links) to what you mean / saw: I cannot find any newer Qt-version imported there by sailors after their long stalled Qt 5.9 efforts at SailfishOS@GitHub.
Looking at the Qt’s official documentation there is no “licence change” for QtWayland in Qt 6 (and sure not for it in Qt 5).
See also Qt company’s nicely parametrisable licensing overview for all Qt components, which states just the same: No license change for QtWayland, it is GPLv3-only since Qt 5.7 for all non-commercial licenses.
Which abr’s talk where? Any reference / link?
BTW, the whole topic was discussed in depth at TMO in October 2020 in the thread Qt “stuck” at v5.6 in SailfishOS. Core excerpt:
[…] because [the *GPLv3 licenses] consistently use the term “user” (instead of “licensee” etc. as all other FLOSS licenses do, including the *GPLv2s), plus one must provide the “user” with full control over the *GPLv3 software (the “Anti-TiVO paragraph”) including the ability to alter it anytime at free will.
This renders *GPLv3 licensed software unsuitable for devices which are not user-controlled, e.g., MDM-managed devices in a company or government office, and generally any device, whose user is not its owner (specifically when the right to use and the right of possession are both transferred to a user).
2 Likes
Found it…
8 Likes
Thank you for the link (including the correct offset) and @abr for the excellent talk, which provides a nice overview of the software components comprising SailfishOS, its history and basic design goals (e.g., “privacy by allowing device owners to fully inspect and control the software stack”).
AFAIU, Andrew Branson’s statement expresses the same what I deduced more casually and concludes with the same consequence as that TMO post in 2020 (the aforementioned one):
Ultimately Jolla either has to pay a lot for a commercial Qt license or accept the use of *GPLv3 software.
My impression is that this management decision is pending, for years and still.
P.S.: Extra thanks to Andrew for the “I am trying to get that changed”.
1 Like
Couldn’t Jolla adopt Qt’s dual license strategy, e.g. by using the commercial license only if customers request e.g. MDM features and sell these as a business addon (or sth), while the LGPL could still be used for the standard sailfish release?
1 Like
However, I doubt Jolla has the manpower to upgrade the Qt release currently and without the Aurora OS people.
I’m pretty sure that it is against the license to selectively apply it.
1 Like
Well, I thought it might be possibly to sell the parts of sfos which would require a commercial license (like e.g. MDM) as a seperate PACKAGE, not to selectively apply different licensing models on the entire OS.
1 Like
That’s not the problem though. The problem is that locking the user out of modifying even the base stuff would require a license.
To an extent that is a prerequisite of viable MDM - but that does not make MDM the problem.
I don’t think licensing Qt for only locked phones would fly.
3 Likes
I have not full understanding of GPLv3 but would it not be possible to provide support for Qt 6 for specific apps without bundling it with SFOS? The app could add Qt 6 as a dependency and installing the app would also trigger install of Qt 6 on the phone. SFOS could still be running Qt 5.6 but the specific app would use Qt 6. Another possibility would be to build the app with Qt 6 with static linkage so Qt 6 would not be installed on phone.
I am not sure how this would work with Silica though:
- Could Jolla provide a Qt 6 version of Silica without the parts which depends on GPLv3 licensed code to avoid having to open source Silica?
- Could Silica use Qt 5.6 and still be linked with a Qt 6 app?
I thought first that chatgpt could be used to point out changes in the code to be made after giving it the url to the git repo, but unfortunately it doesn’t have access to the file contents, only the readme i guess. Maybe one can copy the code in a file and one can tell it to update it to qt5.6
Why not try to make Sailfish GPLv3 compliant.
To solve vendor locked hardware, caused by firmware blobs that can’t be modified:
Make alternative kernel modules of firmware blobs with generic open source kernel modules that you can revert into if the user wishes so (some configuration that can be changed in the linux kernel starup or similar). You might need to ship these alongside the commercial properiaty ones.
Pros: is not locked from the user (should be GPLv3 compliant as it does not lock you in with hardware)
Cons: if there is no generic open source drivers available you’ll have problems getting a GPLv3 compliant system without separate licensial rights from commericial vendor (ie. allowing “users” to use closed firmware drivers in case they modify their hardware ← might be GPLv3 compliant might be wrong, I ain’t an lawyer).
Then the lipstick/silica issue.
Just document better somewhere what is nesessary (enviroment variables etc.) to open an sailifish application.
Solves: you might not need to open source silica, but you are able to circumvent sooner or later with community open source lock in, if they are able to implement their own variation (which start the software ← relys on community).
Cons: somebody has to write the code…
1 Like
Fine. Will you start writing these modules now?
2 Likes
3 Likes
I intended on writing compile, instead of make. 
(that is using existing open source components).
If somebody would be doing the drivers there needs to be well documented white papers somewhere as reverse enginering the drivers is not that easy.
I just made the assumption that most drivers have an open source version of some degree, which might not be so complete/well optimized than the closed firmware ones.
There is also the question of how well the tivolization clause is to be followed. Ie. if you have mostly all of the drivers open and “usable”, is it allowed to have only those leaving some functionality outside, but still getting the device up and working to console / drm-egl with possibly working input/touchpad functionality (like in a medicore/good port). In a sense it is usable and made in good faith of following GPLv3 as good as possible.
I
1 Like
I litterally added it 5 min ago and am actively working on it. Please give me some time.
I copied from TJC, do you have any source where you still update it?