Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 9 hrs ago - more...
|
2020-10-30
, 19:42
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#2
|
Dear @olf,
thank you very much for your letter as well as sending it open. I am very well aware of GPLv3 issue that Jolla has. Maybe not in full detail, but at least partially. Indeed, it is interesting that this time they did not mention any legal issues. Their reply has been polished over some time:
As stated also before, this is something we constantly evaluate. The current plan is still to proceed step by step, but we are not announcing any schedule for the update.
This step-by-step was refereed later from technical POV, but we don't know what is it referring to in practice. Although, I presume it is hard to update license to GPLv2.1, 2.2, ...
Going with GPLv3 version may require opening many (all?) SFOS closed components. We are talking about applications and libraries. That is another aspect they probably consider.
In general, I guess we have to keep asking and also look for whatever other solutions we can come up with.
Not sure that installing newer Qt in /opt (as I suggested) is such a great idea. I suspect there will be quite some packaging work involved in "breaking packages" in terms of removing all kind of "provides" to avoid clashes with the system-installed ones.
Cheers,
rinigus
PS: Note that for visibility on Jolla's side, we should have this correspondence on their forum. As far as I have seen so far, Jolla's folks don't comment over here, unfortunately.
PPS: Feel free to copy-and-paste the original letter at the new forum and I will paste the reply
thank you very much for your letter as well as sending it open. I am very well aware of GPLv3 issue that Jolla has. Maybe not in full detail, but at least partially. Indeed, it is interesting that this time they did not mention any legal issues. Their reply has been polished over some time:
As stated also before, this is something we constantly evaluate. The current plan is still to proceed step by step, but we are not announcing any schedule for the update.
This step-by-step was refereed later from technical POV, but we don't know what is it referring to in practice. Although, I presume it is hard to update license to GPLv2.1, 2.2, ...
Going with GPLv3 version may require opening many (all?) SFOS closed components. We are talking about applications and libraries. That is another aspect they probably consider.
In general, I guess we have to keep asking and also look for whatever other solutions we can come up with.
Not sure that installing newer Qt in /opt (as I suggested) is such a great idea. I suspect there will be quite some packaging work involved in "breaking packages" in terms of removing all kind of "provides" to avoid clashes with the system-installed ones.
Cheers,
rinigus
PS: Note that for visibility on Jolla's side, we should have this correspondence on their forum. As far as I have seen so far, Jolla's folks don't comment over here, unfortunately.
PPS: Feel free to copy-and-paste the original letter at the new forum and I will paste the reply
|
|
2020-10-30
, 20:54
|
|
Posts: 101 |
Thanked: 381 times |
Joined on Aug 2010
|
#3
|
Maybe you have read this about the QT subscrition model - it is written in German though
| The Following 3 Users Say Thank You to JoOppen For This Useful Post: | ||
 |
|
2020-10-31
, 21:00
|
|
Posts: 4,708 |
Thanked: 4,649 times |
Joined on Oct 2007
@ Bulgaria
|
#4
|
Not sure if Qt6 has anything to do with the original post, but Qt subscription model is inherently flawed. JetBrains, since the article mentions them, offer subscriptions, but with each payment, you get a perpetual license until that point in time, so if you stop paying - you only stop getting updates. When JetBrains tried to switch to the subscription model, there were similar problems with their clients, before coming up with that solution, so I hope Qt get sensible and don't do that or they would lose more than they would gain.
__________________
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
Technically, there are three determinate states the cat could be in: Alive, Dead, and Bloody Furious.
| The Following 3 Users Say Thank You to Bundyo For This Useful Post: | ||
 |
|
2020-11-02
, 22:37
|
|
Posts: 304 |
Thanked: 1,246 times |
Joined on Aug 2015
|
#5
|
Dear @rinigus,
thank you for your reply.
Let me address some points:
This idea (license proliferation across well defined APIs, in contrast to using a library you technically link to / a "link time dependency") is repeatedly propagated by the FSF (even before the GPLv3, with the GPLv2) to fulfill their (day)dream (or IMO: nightmare) of most Free Software (FLOSS) automatically becoming GPLed software sooner or later (and some proprietary software, too) by "this legal mechanism".
Unfortunately stating this loudly multiple times (and over decades) made many even more afraid of the GPLv3, the *GPL* family of licenses and the FSF, especially in commercial environments. I can comprehend that well.
TL; DR: There is no license proliferation across well defined APIs.
Think of Database Applications becoming automatically licensed as the DBMS they use (e.g., Oracle) due to the SQL API, but at the same time licensed as the OS they use due to syscalls, and concurrently licensed as .... this is nonsense leading nowhere and no reasonable court will follow this.
Thank you again for pursuing this.
I initially did not think about "confronting" Jolla at their forum with this open letter, but this would definitely address my goal "increasing pressure for Jolla to make a decision ..." better. So while I know that some sailors are reading at TMO, they usually do not post here, so posting at FSO makes sense, even though I still do not really expect a (substantial) reply there, either.
But I feel that will need to be done properly to have a slim chance of achieving something:
Last edited by olf; 2021-03-23 at 23:27.
thank you for your reply.
Let me address some points:
Originally Posted by rinigus
Well they shall not be afraid of this "aspect", but probably they are by "considering it".
[...]
Going with GPLv3 version may require opening many (all?) SFOS closed components. We are talking about applications and libraries. That is another aspect they probably consider.
This idea (license proliferation across well defined APIs, in contrast to using a library you technically link to / a "link time dependency") is repeatedly propagated by the FSF (even before the GPLv3, with the GPLv2) to fulfill their (day)dream (or IMO: nightmare) of most Free Software (FLOSS) automatically becoming GPLed software sooner or later (and some proprietary software, too) by "this legal mechanism".
Unfortunately stating this loudly multiple times (and over decades) made many even more afraid of the GPLv3, the *GPL* family of licenses and the FSF, especially in commercial environments. I can comprehend that well.
TL; DR: There is no license proliferation across well defined APIs.
Think of Database Applications becoming automatically licensed as the DBMS they use (e.g., Oracle) due to the SQL API, but at the same time licensed as the OS they use due to syscalls, and concurrently licensed as .... this is nonsense leading nowhere and no reasonable court will follow this.
Originally Posted by rinigus
Yes, this is also my impression.
In general, I guess we have to keep asking and also look for whatever other solutions we can come up with.
Thank you again for pursuing this.
Originally Posted by rinigus
Yes, unfortunately this sounds probable.
Not sure that installing newer Qt in /opt (as I suggested) is such a great idea. I suspect there will be quite some packaging work involved in "breaking packages" in terms of removing all kind of "provides" to avoid clashes with the system-installed ones.
Originally Posted by rinigus
As stated, I started writing a personal letter, then decided to make it an public one, reformulated it a bit for this purpose plus added "P.S." & "P.P.S.", and posted it; basically to make the thoughts I repeatedly had WRT the "ancient Qt issue" more widely known.
PS: Note that for visibility on Jolla's side, we should have this correspondence on their forum. As far as I have seen so far, Jolla's folks don't comment over here, unfortunately.
PPS: Feel free to copy-and-paste the original letter at the new forum and I will paste the reply
I initially did not think about "confronting" Jolla at their forum with this open letter, but this would definitely address my goal "increasing pressure for Jolla to make a decision ..." better. So while I know that some sailors are reading at TMO, they usually do not post here, so posting at FSO makes sense, even though I still do not really expect a (substantial) reply there, either.
But I feel that will need to be done properly to have a slim chance of achieving something:
- Enhance some sentences (i.e., their "wording") to sound nicer (towards Jolla).
- Maybe it is better to address Jolla directly, instead of you. I still would mention your recent inquiries WRT the "ancient Qt issue" as the trigger for the letter, so you are directly invited (per @mention) to comment.
- Search for and link to sources of Jolla's former public statements WRT the "ancient Qt issue" at TJC, FSO and the "SFOS community IRC meeting" logs.
- What shall I conclude with?
- A plea to finally do any practical step towards a newer Qt (technical and practical)
- A plea to finally make a decision and communicate a plan WRT upgraded Qt releases for SFOS (organisational)
- A plea to seriously reconsider the "GPLv3 ban" for SFOS (license strategy)
While this might have resolved Jolla's non-technical issues with newer Qt releases a while ago, the current conditions for commercial licensees (i.e., who is defined as such) may counter that. Another point to research. - A combination of above
IMO, rather not, this overloads the letter, and allows to diverge into a question, which is easy to answer, while ignoring the other ones. - Demanding any of these points, instead of asking kindly, will probably raise the chance of no reply to 100%, but OTOH the wording shall not be too soft, because the "ancient Qt issue" has become a serious and strategic one, technically and WRT licensing, by Jolla not addressing it for years and "the Qt company" winding up their licensing scheme repeatedly.
- Something else to conclude with?
- Other ideas?
Last edited by olf; 2021-03-23 at 23:27.
 |
|
2020-11-07
, 09:29
|
|
Posts: 584 |
Thanked: 1,550 times |
Joined on Sep 2019
|
#6
|
This has been an intersting read so far!
Now let me ask a provocative question:
What's wrong with staying with this "ancient" Qt version for - ever, maybe?
Now let me ask a provocative question:
What's wrong with staying with this "ancient" Qt version for - ever, maybe?
|
|
2020-11-07
, 16:18
|
|
Posts: 304 |
Thanked: 1,246 times |
Joined on Aug 2015
|
#7
|
Originally Posted by nonsuch
[...]
What's wrong with staying with this "ancient" Qt version for - ever, maybe?
- Security
It is unmaintained upstream, for years in case of Qt. - Functionality
Well, I think @rinigus and others could write long lists of functions in newer Qt versions, which would make programming for it much easier, plus the loss of interoperability of software not specifically for SailfishOS, because all other Linux distributions are on a way newer Qt.
This is why it is obvious that they have to resolve this, and I wish this would happen rather sooner than later (even better: long ago!), because the severeness of the impacts of this issue are permanently increasing (until on a Qt version, which is maintained upstream).
Last edited by olf; 2020-11-09 at 20:42. Reason: Typo
| The Following 7 Users Say Thank You to olf For This Useful Post: | ||
|
|
2020-11-08
, 08:57
|
|
Posts: 1,414 |
Thanked: 7,547 times |
Joined on Aug 2016
@ Estonia
|
#8
|
Dear @olf:
sorry for missing your reply - it somehow slipped. Hence the delayed reply.
Re FSO: yes, please address it to Jolla, as the target would be different. I think it makes sense to contact them regarding it and get engaged in constructive discussion. If we manage to pull them out from this comfort zone with "soon we will decide".
Re GPL and APIs: As you have to link to Qt, I expect that GPL will infect your code through it. This is in contrast to SQL and other ways of process separation allowing you to mix licenses. GPL has it's purpose and we just have realize it when the license for your code is selected. In case of Qt, it is a way to ask for commercial licenses for non-free software. So, if Jolla goes for Qt update, there maybe a problem with mixing non-free Silica with GPLv3 Qt. While with the apps they can use proprietary licenses as software is built in-house, I don't know whether it extends to SFOS API distributed for all.
Cannot add much to your list, though.
As for why we need to update: @olf addressed it well. In addition, if we are in sync with others (Plasma Mobile, for example), we can work together on browser, email clients, and so on. Right now we are in isolation and have to choose the platform. While Flatpak helps, don't expect it to be working that well for all the software. And, in the end, we, as the developers, will have to choose whether work on ancient SFOS Qt or switch the platform.
sorry for missing your reply - it somehow slipped. Hence the delayed reply.
Re FSO: yes, please address it to Jolla, as the target would be different. I think it makes sense to contact them regarding it and get engaged in constructive discussion. If we manage to pull them out from this comfort zone with "soon we will decide".
Re GPL and APIs: As you have to link to Qt, I expect that GPL will infect your code through it. This is in contrast to SQL and other ways of process separation allowing you to mix licenses. GPL has it's purpose and we just have realize it when the license for your code is selected. In case of Qt, it is a way to ask for commercial licenses for non-free software. So, if Jolla goes for Qt update, there maybe a problem with mixing non-free Silica with GPLv3 Qt. While with the apps they can use proprietary licenses as software is built in-house, I don't know whether it extends to SFOS API distributed for all.
Cannot add much to your list, though.
As for why we need to update: @olf addressed it well. In addition, if we are in sync with others (Plasma Mobile, for example), we can work together on browser, email clients, and so on. Right now we are in isolation and have to choose the platform. While Flatpak helps, don't expect it to be working that well for all the software. And, in the end, we, as the developers, will have to choose whether work on ancient SFOS Qt or switch the platform.
| The Following 5 Users Say Thank You to rinigus For This Useful Post: | ||
 |
|
2020-11-08
, 12:46
|
|
Posts: 4,118 |
Thanked: 8,901 times |
Joined on Aug 2010
@ Ruhrgebiet, Germany
|
#9
|
Sorry in advance for my negativity.
The way I have got to know Jolla as a company is not the best.
(just two latest examples: a) breaking overlay compatibility, b) they claim to be open and do SFOS with the community and then change the answering UI out of the blue - coming up afterwards that this decision was due to a huge end customer querying - without any interaction/information of this community beforehand. Not that I say it is bad, just the way it was done.)
I would assume this letter would just not be answered or as you already wrote answered with the same wordings as the last 7 years.
Of course there are internal company decisions not meant for the folks but ...
Nevertheless, I do appreciate your efforts in realizing and writing this. And you should post it to FSO!
But at the same time include/invite the CEO/CTO, press/community official via e-mail to this open letter!
So they see the need to answer. And hopefully join a fruitful discussion!
--
and yes, keep it friendly, asking (not demanding) but in an insistent tone
Last edited by peterleinchen; 2020-11-08 at 12:51.
The way I have got to know Jolla as a company is not the best.
(just two latest examples: a) breaking overlay compatibility, b) they claim to be open and do SFOS with the community and then change the answering UI out of the blue - coming up afterwards that this decision was due to a huge end customer querying - without any interaction/information of this community beforehand. Not that I say it is bad, just the way it was done.)
I would assume this letter would just not be answered or as you already wrote answered with the same wordings as the last 7 years.
Of course there are internal company decisions not meant for the folks but ...
Nevertheless, I do appreciate your efforts in realizing and writing this. And you should post it to FSO!
But at the same time include/invite the CEO/CTO, press/community official via e-mail to this open letter!
So they see the need to answer. And hopefully join a fruitful discussion!
--
and yes, keep it friendly, asking (not demanding) but in an insistent tone
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!
Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257
editsignature, http://talk.maemo.org/profile.php?do=editsignature
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!
Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257
editsignature, http://talk.maemo.org/profile.php?do=editsignature
Last edited by peterleinchen; 2020-11-08 at 12:51.
|
|
2020-11-08
, 23:46
|
|
Posts: 339 |
Thanked: 1,623 times |
Joined on Oct 2013
@ France
|
#10
|
Not sure how that could change Jolla's answer, but Qt is not only GPLv3, but also LGPLv3 for most of its modules : https://www.qt.io/product/features#js-6-3
Some useful modules like QtCharts or Qt Wayland Compositor, Qt Quick WebGL would still be under GPLv3 only, so that doesn't change much the problem, and I don't know if you could have core modules as LGPLv3 allowing closed source app, and at the same time the GPLv3 additional module requiring open sourcing only for the app that uses them ?
Another point is that the Qt Project is currently releasing Qt6, which will break some API, whereas the Qt5 minor versions where intended to keep binary compatibility between them.
The first Qt6.0 will not be feature complete, but really soon probably all other platforms will switch to it, so that will widen the gap with sailfish and make it even harder to keep compatibility between platforms (you don't only need to not use or backport the new functionality, you also have to change the code to compile on both versions).
Also, the work to upgrade the full OS to a new major version would be harder than updating a minor one, which hasn't been done for several years.
My 2 cts...
Some useful modules like QtCharts or Qt Wayland Compositor, Qt Quick WebGL would still be under GPLv3 only, so that doesn't change much the problem, and I don't know if you could have core modules as LGPLv3 allowing closed source app, and at the same time the GPLv3 additional module requiring open sourcing only for the app that uses them ?
Another point is that the Qt Project is currently releasing Qt6, which will break some API, whereas the Qt5 minor versions where intended to keep binary compatibility between them.
The first Qt6.0 will not be feature complete, but really soon probably all other platforms will switch to it, so that will widen the gap with sailfish and make it even harder to keep compatibility between platforms (you don't only need to not use or backport the new functionality, you also have to change the code to compile on both versions).
Also, the work to upgrade the full OS to a new major version would be harder than updating a minor one, which hasn't been done for several years.
My 2 cts...
| The Following User Says Thank You to Zeta For This Useful Post: | ||
Hello @rinigus,
I appreciate that you repeatedly query Jolla about upgrading Qt in SFOS at Jolla's "IRC community meeting", the last time yesterday (2020-10-29).
But reading the "answers" from Jolla over the years when this issue has been brought up at TJC, by others at the "IRC community meeting" before and lately multiple times by you there, their two basic statements were always the same: "We will upgrade Qt from v5.6 step by step (i.e., not "jumping" to a very recent Qt version)" and "This will take some time to be come", sometimes spiced with mentioning some technical hurdles.
Both "answers" only address procedural aspects. The licensing aspects have only been addressed by community people and Jolla did avoid to say anything specific on that topic.
IMO the specific licensing scheme of Qt (basically dual licensed: commercial, plus (L)GPL with a CLA), which has been altered by "The Qt company" (formerly Digia) several times, is the crucial point:
Examples: GnuPG is in SFOS in its last GPLv2+ version, various other GNU utilities also were, but most of them are migrated to busybox (due to their current license, not the size reduction!) and so is Qt (v5.6).
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.
IMO Jolla does not really have a choice, because they are a small company, the costs and conditions of the commercial Qt licenses are becoming worse and worse, and avoiding *GPLv3 software causes ever increasing work for Jolla by substituting more and more components in SFOS. They should have made that decision long ago, which would have saved them a lot of conversion, maintenance and technical trouble (e.g., GNU-tar vs. busybox-tar incompatibilities breaking the GUI backup / restore function).
And specifically for the future of the (L)GPLv3 Qt releases: The KDE community is committed to handle that somehow (trying to convince the Qt company to alter their plans for the GPLv3 releases or to "soft-fork" Qt), Jolla could contribute to these efforts and make use of them.
HTH,
olf
P.S.: Why am I writing this up?
- I see (at TJC, FSO and Jolla's "IRC community meetings"), that many people believe the ancient Qt in SFOS primarily has technical reasons, while that likely originates from licensing aspects.
- This enables Jolla to evade further discussion by replying with their aforementioned "two standard phrases" each time.
- I also sense that crucial aspects of the licensing situation (especially the properties of the *GPLv3 licenses and their consequences) are not fully understood by many.
- I would like to raise understanding in the SFOS-community for the difficult decisions Jolla has to make here (Qt, plus *GPLv3 software in general).
- I would like to see the pressure rising for Jolla to finally make these decisions, to create a plan based on them and to communicate this plan (fuzzy and without timelines, of course
). May this write-up help to shape more pinpointed questions.
Adding all this up, I do not believe that an upgraded Qt will be deployed for all per SFOS release soon (e.g., within half a year).P.P.S.: This text is licensed CC BY-SA 4.0 (by olf, 2020-10-30), please reuse it.
Feel free to discuss the topic and its various aspects, ask "checks & balances" questions etc.
Last edited by olf; 2021-04-20 at 15:13. Reason: Slightly updated per discussion outcome & per Jolla's policy change (*GPLv3 software is now O.K. as additional packages)