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?
Yes, it is linked there in the footer. Reading most often helps!
But my point is: Copying is always the wrong approach, especially as you ripped my source apart into pieces so any bigger context is lost.
I think copying is legitimate, as my goal is to make knowledge more accessible. Option 1 isn’t intended to stay that way, this was a test months ago. At least for my own blogpost, I think it is nice when others can improve spelling and instructions.
Out of the context it should have been possible for you to guess that I didn’t read the software parts.
As I can’t DM you, I have to write it here. I’m sorry for offending you. I picked the section more to give a structural example of what I imagine as wiki structure than as a final instruction guide. If you don’t like the “ripping parts” approach, I’ll respect that, but I also don’t want this to become a link archive. If you want to discuss this further, please DM to not spam this topic any further.
I’d like to bring back this topic on top of the stack.
I really wonder how is it possible to run a sustainable business based on obsolete SW component like Qt 5.6.
Since now Sailfish is supported by a new company, and because EULA conditions have changed for next Sailfish releases after 4.5, is there any plan to upgrade Qt?
6 Likes
i realise that there may be a few jumps to get there, but aligning with a KDE6 LTS release might be useful…
The company is the same. The EULA changes were mostly alternate wording to reflect its restructuring.
While discouraged by everybody due to its uselessness, you can try to bring this up in the next community meeting. If you do so, there is a 98% chance you will get one of the following answers:
- “We have no plans for now”
- “We are still restructuring, please give us time”
- “We will look into it”
Good luck.
8 Likes
Oh, can’t believe that they “have no plans for now” for years… in an age that so many vendors making their version number taking off