Qt "stuck" at v5.6 in SFOS
 

Originally I intended this to become a private message, but ultimately decided for an "open letter" which can be discussed openly, because this topic is of common interest.

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:

• Jolla strictly avoids *GPLv3 licensed software for packages, which are part of a basic SailfishOS installation.
  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).

  Side note:
  I can understand why Jolla and its primary SFOS-licensee are afraid of the *GPLv3, because it consistently uses 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). IMO, the proper, general wording is "licensee" and specifically for the "Anti-TiVO paragraph" the term "device owner"; with this wording the *GPLv3 would have nicely achieved its announced goals, without causing broad collateral damage. But the FSF refuses to acknowledge that wording for decades and so the *GPLv3s have become what they are: troublesome nonsense.
  But Jolla is not Google, who can avoid *GPLv3 software (also for these reasons) at all costs (usually by re-implementing software components under a different, most often "permissive" FLOSS license). All the classic (desktop) Linux distributors do not seem to have an fundamental, legal issue with the *GPLv3s, although they also have paying customers, who run these Linux distributions on computers, which are owner- but not user-controlled. Hence I am unable to comprehend why Jolla does not handle this in the same way these big Linux distributors do.

• "The Qt company" has increased prices for commercial Qt licenses multiple times and recently switched from a "perpetual license" to a subscription model, plus plans to restrict the FLOSS releases by delaying them and releasing only selected versions in order to make them less attractive, because they are so successful with Qt, tools for it and customising it, that they feel they can further increase their revenue this way (seriously!).

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.

Re: Qt "stuck" at v5.6 in SFOS
 

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 :)

Re: Qt "stuck" at v5.6 in SFOS
 

Maybe you have read this about the QT subscrition model - it is written in German though

Re: Qt "stuck" at v5.6 in SFOS
 

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.

Re: Qt "stuck" at v5.6 in SFOS
 

Dear @rinigus,

thank you for your reply.
Let me address some points:

Well they shall not be afraid of this "aspect", but probably they are by "considering it".

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.

Yes, this is also my impression.
Thank you again for pursuing this.

Yes, unfortunately this sounds probable.

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.
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?

  1. A plea to finally do any practical step towards a newer Qt (technical and practical)
  2. A plea to finally make a decision and communicate a plan WRT upgraded Qt releases for SFOS (organisational)
  3. 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.
  4. 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.
  5. 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.
  6. Something else to conclude with?

• Other ideas?

Re: Qt "stuck" at v5.6 in SFOS
 

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?

Re: Qt "stuck" at v5.6 in SFOS
 

• 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.

Both aspects were the main incentives for Jolla to update most of SailfishOS' basic tools and utilities (GCC & Co., GNU-utilities / Busybox etc. etc.) over the past two years.
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).

Re: Qt "stuck" at v5.6 in SFOS
 

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.

Re: Qt "stuck" at v5.6 in SFOS
 

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

Re: Qt "stuck" at v5.6 in SFOS
 

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...

Re: Qt "stuck" at v5.6 in SFOS
 

Yes, but after that they helped Coderus to solve problem with overlay.

Re: Qt "stuck" at v5.6 in SFOS
 

First: after! (a lot of devices 'crashed/reflashed', ya know)
Second: orly? Then I must have missed this. Where and when, do you have a link, please?

--
but we are derailing this thread here, sorry for the noise.

Re: Qt "stuck" at v5.6 in SFOS
 

Ad Second. They suggested him to use this https://git.sailfishos.org/mer-core/...27801261_23_39

And here is the result:
https://github.com/CODeRUS/harbour-s...e41d9b228cb011

Re: Qt "stuck" at v5.6 in SFOS
 

Dear @rinigus,

O.K.

No, all relevantMost Qt-libraries are licensed LGPL (v3 nowadays) or commercially (at the customer's choice), so any software can link to these libraries (regardless if FLOSS or not).

@zeta already hinted that in
, but there is no choice to make ("also") between LGPL and GPL, only between a FLOSS license (a specific ?GPLvX one) and their commercial one (this is badly phrased multiple times at their licensing web pages):
Digia / "The Qt company" chooses the licenses for their software components very well (primarily for their own goals), i.e. LGPL for all basic libraries (which they want to be used easily by everyone) and GPL for a few components, which are not essential and for which they want to restrict their usage.
They seem to have "fun playing licensing" at premier league level (and plenty of success with it), in contrast to Jolla, which seems to be driven by fear and an avoidance strategy.

Specifically see

• overview of Qt licensing: https://doc.qt.io/qt-5/licensing.html
• specifics of Qt's FLOSS licensing: https://www.qt.io/faq/tag/qt-open-source-licensing
  IMO the most relevant point there is "Why do you have an agreement with KDE about your licensing? What[...]’s the history of Qt and KDE?".
• at https://www.qt.io/product/features the FLOSS-license of every software component can be looked up, which is part of Qt.
• side note: Notice, how consciously "The Qt company" also chooses software they use for and redistribute with Qt!
  Most of it is under a permissive FLOSS license ("BSD-/MIT-/Apache-style"), LGPL or GPL with linking exception (e.g., Bluez), so it cannot interfere with their commercial licensing. For details, see https://doc.qt.io/qt-5/licenses-used-in-qt.html

Re: Qt "stuck" at v5.6 in SFOS
 

Dear @olf:

going through https://www.qt.io/product/features#js-6-3 (LGPLv3), I can see that Qt Wayland Compositor is not compatible with it and requires GPLv3 (or "commercial"). Lipstick runs on it, but fortunately it is open-source. Not sure of the rest of the composer.

Qt Wayland is also used by Flatpak UI, but that is open source.

LGPLv3 has Tivoization/DRM clauses (referred to in Qt FAQ) which maybe an issue for Jolla as well.

Re: Qt "stuck" at v5.6 in SFOS
 

I was going to say "It's (only) a UI toolkit!" - But then I seem to remember that Qt has modules that provide direct access to the internet? I guess that's where security comes in.

Yes, this I expected and understand.

Re: Qt "stuck" at v5.6 in SFOS
 

Good catch, thanks!
I went through the list and thought, "really everything essential is LGPL", but missed Qt Wayland Compositor. So this is only the case under X11, which is useless on SailfishOS and becomes less and less relevant on other Linux distributions.

Let us assume it all is (also because I want to limit our research on this at some point), so rather the v3 (vs. v2 up to and including Qt 5.6) poses an issue for Jolla here, than the GPL (vs. LGPL) specifically for Qt Wayland Compositor.

Edit / side note: And while Jolla can do little to change the licensing situation of third party components (trying to negotiate with "The Qt company" is likely futile; and swapping components, like GNU-utilities -> Busybox, is impossible for Qt), but can alter the licenses of their own components at their own will.

It likely is, as denoted in the lengthy "side note" WRT *GPLv3 of my original post here.

P.S.: The longer we discuss this, the clearer it becomes that there is no easy way out of this for Jolla, if there is any viable path for them through Ex-Digia's licensing thicket at all.
But our starting point was that leaving SailfishOS "stuck" at Qt 5.6 is not a viable path for SailfishOS and its ecosystem, either!
:\

Re: Qt "stuck" at v5.6 in SFOS
 

Not exactly the same topic but somehow related ?
https://forum.sailfishos.org/t/silic...urce-code/3561

Re: Qt "stuck" at v5.6 in SFOS
 

https://together.jolla.com/question/...embrace-gplv3/

The current Jolla is even worse than the Jolla of the past. It's clear to me the Maemo people were right and I was wrong. Sorry everyone I discussed with.


This looks super dubious. Any source?

Re: Qt "stuck" at v5.6 in SFOS
 

As explained, the GPL v3.
Its "core innovation", the anti-TiVo clause in combination with its consistent (-ly idiotic) "user" wording!
As intended, *GPLv3 software must be alterable by a user, for which cryptographic (and any other) mechanisms must be circumventable by a user.

HTH

Re: Qt "stuck" at v5.6 in SFOS
 

You are quoting yourself.... not the license.

To avoid a couple of extra roundtrips...
I really doubt that interpretation of the license. And I have never heard of anyone else actually interpreting it that way, and the license actually goes out of its way to avoid using the concept of "user".
It talks about user _products_ and the like and you're most definitely not "transferring the right of possession and use" of any product by manipulating a touchscreen in a museum.

I don't know if the source of this FUD is either Jolla or if this is your interpretation. If it's Jolla, it's really shameful.

Re: Qt "stuck" at v5.6 in SFOS
 

Please stop this nonsense!
I linked to the GPLv3 to read, specifically terms #2, #3 and #6, plus this paragraph in the preamble:

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

This is no "interpretation", it is what the license states and what the FSF deliberately intends (and clearly states so)!
And it is the reason why Google, Jolla and many others avoid *GPLv3 code like hell.

This is nitpicking, but yes, while as museum definitely "transfers the right to use" its explanatory, fixed touchscreens to visitors, it does not "transfer the right of possession" for these.
But as soon as the visitors are provided with tablets for that purpose (had that in a Dutch museum) the "right of possession" for these is transferred to their users (note, that "owning" a product is not necessary!), as with centrally administered computers, MDMed tablets and phones etc. in companies, government offices and many other use cases (i.e., most non-private ones).
The latter are the use cases Jolla, Google have to respect, if they want big licensees for their software stacks.

Sorry, who is spreading "alternative facts" here?
Please, try to disprove my statements by quoting the GPLv3 or shut up.

P.S. / edit: For me the *GLPv3 family of licenses are "unfree" licenses, which should never have been OSI-approved, because they factually restrict the absolute "Freedom to use" by ultimately stating, "one may use *GPLv3 software to create lock-down mechanisms, but then must provide users with means to circumvent them", which renders lock-down mechanisms useless in the first place.

Re: Qt "stuck" at v5.6 in SFOS
 

Do note: I am not questioning that you need to provide the "encryption keys" if you transfer ownership.

I am questioning that you have to provide the "encryption keys" if you don't transfer ownership. i.e. the situation where a museum lets you use a touchscreen fixed device, or it lends you a tablet.

That is as absurd as claiming that if let you use a device of mine with GPL3+ software, temporarily or permanently, I would have to provide the source code of it. It's just absurd. No legal system is going to parse the license that way. There is even a FAQ item about it:


What I am asking is precisely for evidence of any legal system of any country where the license was actually parsed in the way you described. An interpretation that
1. Contradicts the intention of the license, as evidenced by the FAQ
2. Contradicts _everyone else's_ reading of the license, to the best of my knowledge (I have never seen the license ever interpreted like that anywhere other than in this thread).
3. Is just a plain absurdity and would need for everyone to rethink the way they use software completely.

i.e. what is this "Dutch museum" story?

There are companies shipping products with GPLv3. Just not Jolla. Google ships products with GPLv3 software just fine.

Re: Qt "stuck" at v5.6 in SFOS
 

Please quote from the license!
I cannot find any of the terms "ownership", "owner", to "own" or "encryption keys" in the GPLv3.
So what are you talking about?

As you quoted, the point is "transferring the right of possession and use" in legalese.
To "own" (as a legal term) is not a requirement.

Which?
If you really know any (and are not just trolling), please provide a pointer to Google software for the aforementioned target audience ("big licensees") with GPLv3 components.
I cannot see any in AOSP, ChromeOS, Chromium etc.!

Please stop FUDding and substanciate your statements with sources.

Side note:
Many of the FSF's explanations around the GPLv3 state some things (their details vary), which are definitely not in the GPLv3.
Some believe this is done deliberately.

Re: Qt "stuck" at v5.6 in SFOS
 

You are making the insane interpretation. Not even Jolla!
I am just asking for a source of your bizarre reading and I am yet to see it! Even the "Dutch museum" story would do.

ChromeOS ships damn Bash! The original motivation for the entire Jolla GPL3 rant was about this package itself!!!!

And you still claim that this is not just plain FUD???

Okey, waste of time...

Re: Qt "stuck" at v5.6 in SFOS
 

Re: Qt "stuck" at v5.6 in SFOS
 

That is not true!
You have to enable "developer mode", then a bash is being installed, which you cannot if your device is locked, ...
... exactly my point: GPLv3-free for the "big licensees" target audience.
Thanks for pointing to this good example!
Plus it is nicely depicting the conclusion / "solution" Jolla has recently come to, too.

No, this thread is about Qt "stuck" at v5.6 in SFOS, as its title clearly says.
But exploring the GPLv3 issues Jolla has and sees definitely plays a role here.
Though bash is irrelevant in this context.

True, my dear troll.
I was still hoping for anything substancial from your side.

Re: Qt "stuck" at v5.6 in SFOS
 

To get back to the original topic of this thread, "Qt "stuck" at v5.6 in SFOS" and in this very context "Jolla's relation to the *GPLv3 license family", they have achieved a little step:

As denoted in the IRC community meeting log of 2021-02-25, Jolla ceased to avoid GPLv3 software in general.
Instead they started distributing GPLv3 software as optional RPMs for SailfishOS, i.e. what formerly was (until SailfishOS 2.2.1) in the mer-tools repository. Now (since SailfishOS 4) only the RPMs for the basic SailfishOS (i.e., which may be installed by default) are still kept free of GPLv3 software.
For example, this change in strategy allowed Jolla to update the historic, last GPLv2 version of bash (v3.2.57) to a recent bash v5, but only as an optional RPM. Side note: At the same time a recent busybox version of ash is installed by default (which carries a "permissive" / "weak-copyleft" license), along with a symlink which calls ash in its (limited) bash compatibility mode.

Well, to put this into context, that strategy change addresses half of point 3 of the identified items Jolla could be asked for.
And while this is nice and viable for small, interchangeable tools (as a UNIX shell or UNIX command line utilities), applying this scheme seems to be technically hard to infeasible to big, local infrastructure components, as ... Qt with all of its components.

IMO the major takeaways from this license strategy change are:

• Jolla has shown for the the first time (in 7 years), that they are not only "thinking about addressing license issues" (as they stated so many times), but are also able to further develop their license strategy (just a little, this time) and to execute that in practice.
  Even though this is a small step taken now, I think "execution over blah" cannot be overevaluated.
• For the first time Jolla is willing and able to clearly communicate an aspect of their license strategy (i.e., aforementioned change) publicly, though only when asked and with a tiny audience (IRC community meeting).
• Jolla sounded much more confident in recent IRC community meetings to update Qt beyond 5.6 "soon" (well, we know that Jolla slang means "some time").
  Sadly they provided no indication how (WRT licenses); I guess we will know from the header files, when it happens, but not before that.

Re: Qt "stuck" at v5.6 in SFOS
 

This discussion on GPLv3 between Javispedro and Olf is very interesting to a noob like me. (even though it escalated a bit at the end :p)
I would not say that one won over the other but I tend (with my zero knowledge and so without weighing anything in the discussion) to be convinced more by Olf ;-)
And I believe even tiny Jolla paid quite some bulk to some lawyers over the years to try and find the best way to deal with it. I have difficulties to believe that they avoid GPLv3 for nothing.

Regarding Qt 5.6, I have one question: If Jolla pays the commercial license to the Qt fundation, that means I guess they can avoid GPLv3 for the Qt pack. Do you think they will go that path?
Because I do not think to have Qt5.X above 5.6 can be optional...as done for bash

Re: Qt "stuck" at v5.6 in SFOS
 

1. Not only that is not true, but considering that literally chromeos-base already depends on bash, I find that hard to believe. So, source?
2. Even if that were true, it would mean that Google _is shipping GPL3 software_! So much for "Google avoiding GPL3 software".
3. That Google was forced to offer "developer mode" as a consequence of shipping GPL3 (this I don't dispute).. how is this a bad thing?

https://together.jolla.com/question/...embrace-gplv3/


Aaaaaand we start the namecalling.
Summary what I see from my side:

1. A claim (that "GPLv3 licensed software [is] unsuitable for devices which are not user-controlled, e.g. a "presentation point" (in a museum etc.)" which I find hard to believe and I asked for sources, only to be shown that it didn't came from Jolla, but from you (my mistake).

2. When I inquiry into the claim, I get that "this is nitpicking; I meant tablets lended by museums", and a vague reference to a story about a "Dutch museum"

3. This is directly contradicting the GPLv3 FAQ by the own FSF, so I quote the relevant FAQ item, while asking for further details on the "Dutch museum" story. I specifically mention that I am interested on the claim about the "museum devices".

4. Again, I don't get an answer.
Rather you start subjecting me to an higher standard, e.g. now if I use a word like "encryption keys" apparently I waste a roundtrip in the discussion since you will simply stop the conversation to ask me to use clearly-defined words. Do you realize how this sounds to others? What if every time you used a phrase like "cryptographic mechanisms" (which you have) I would stop the conversation and ask you to please limit yourself to license terms, wasting another post?

5. Despite claiming that you are not trying to FUD, you try to FUD your way out at literally _every_ _single_ _opportunity_.
Every message of yours has a totally gratuitous remark about how you think the FSF is more dangerous than people think or why the FSF is lying about the meaning of the licenses. If this is not FUD, I don't know what it is. Examples:

"For me the *GLPv3 family of licenses are "unfree" licenses, which should never have been OSI-approved," -- Guess what. They are approved.

"Many of the FSF's explanations around the GPLv3 state some things (their details vary), which are definitely not in the GPLv3.
Some believe this is done deliberately. " -- Here claiming the FSF literally lies _deliberately_ about the GPLv3. A claim that apparently _I_ am supposed to prove is not true (so I have to prove a negative! how nice!) . Also note the prevalence of weasel words like "Some people say" , which is a textbook example of FUD.

"And it is the reason why Google, Jolla and many others avoid *GPLv3 code like hell." -- Despite the fact that Google is literally shipping GPLv3 software in products _right now_,
and I cannot think of any company avoiding the GPLv3 other than Jolla and maybe Apple.

"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), " -- the KDE community is NOT threatening to use the FreeQT clause because of the GPLv3, which they actually _requested_ back in the Trolltech days (and literally applauded when it was announced). The reason is because Qt is delaying open source dumps for up to 12 months in some cases, which is not related to the GPLv3 at all.

6. I try to ignore these off-topic baits (as best as I can, but I admit I am not very good at not biting them ), but fail. I claim that Google is shipping GPLv3 software.

7. Again I don't get an answer about the "Dutch museum story".
Rather, I get namecalled, and then you claim that Google only ships GPLv3 software in "developer mode". Not only this is nonsense for reasons mentioned above, it also shows a failure to understand the point of the GPLv3. Plus the fact that Google ships GPLv3 software is already enough to dispel your FUD.

8. Then, in an additional post, you even claim that "Jolla is now going to ship GPLv3", as if it was some type of miracle.

First, this contradicts any argument regarding Jolla "not being able to" ship GPLv3 software.

Second, what is so hard about it? I have right now a Remarkable Tablet in front of me. This was built by some KDE guys. It uses GPL+3 software like Bash or Qt 5.15. (So much for the FUD about KDE disliking GPLv3!) The only thing they have to do is to give me the root password, which they do!

Look, even Microsoft is shipping GPLv3 bash these days. There is just no point to the discussion. It is particularly offensive that you even try to bring in KDE (which happily distributes GPLv3 software too) in your poor attempts at FUD. Cut it .

I am only interested in the story about the strange legal interpretation (the "Dutch museum thing").

Re: Qt "stuck" at v5.6 in SFOS
 

Well, if one reads this ebuild script for ChromeOS, it clearly states that bash is only used for building ChromeOS, but dash is embedded into the built image.

Thanks again for proving my statement, "Google avoids GPLv3 like hell, if the target audience is 'big licensees'".
But you already did that before, IMO it did not need another proof.
And ChromeOS was just an example how Google handles GPLv3 software in order to understand Jolla's concerns and strategy better (which is achieved now).

WRT the GPLv3 itself:
It is only the license text which is legally binding, last but not least because this is usually the only legal text referenced by or supplied with GPLv3 software.
Demanding references to statements of the GPLv3 not to point at paragraphs within the GPLv3 does not make much sense (even if the "demanding" aspect is fully ignored).
Especially as you completely fail to reference any of your claims with something within the GPLv3 license text!

Re: Qt "stuck" at v5.6 in SFOS
 

No, it doesn't say that anywhere. The comment just says that they use dash as the main shell, exactly like Debian. But they still ship bash, and in fact depend on it for running scripts which specify it on the shebang. Again exactly like Debian. In fact, RDEPEND means runtime dependency, not build-time dependency.

More evidence?

• Go to chromeos://os-credits and grep for Bash, developer mode or not.
• Kill your Wi-Fi (so that you can't claim that enabling developer mode installs something; you just need developer mode to get a allow terminal access), enable developer mode, open crosh, and let me know what happens when you type "bash".
• Download _any_ image of ChromeOS and tell me what you see in the system partition, /bin/bash

Other GPL-3 packages that are preinstalled on my pixel go:
binutils, coreutils, dosfstools, exfat-utils, fuse-exfat, gdbm, glmark, gmp, gzip, mesa, mtools, readline, pycairo, rsync, rsyslog, samba (of course), .... and just way too many to count.

Well, I still don't understand the concern. All the companies in the world can do it, even Microsoft and Google, can do it, so why can't Jolla?

Jolla, who _used_ to be one of the "most open" mobile devices around, and has disappointed me so much I've had to _publicly apologize_ about it?

I quoted the authors of the license directly contradicting your statement. But this is apparently not enough.

On the other hand, you are just blanket-quoting the entire license and claiming that it satisfies your point of view.

I disagree and literally point how the authors of the license as well as all the largest software companies in the world disagree with your point of view.

Yet you again claim that I'm not providing sources while you have literally again not provided any single source for any of your FUD which as you're basically admitting you have none for. Not even for the "Dutch museum story" that I'm particularly curious about.

Double-standard?

Re: Qt "stuck" at v5.6 in SFOS
 

No, it was a single paragraph of the preamble, plus pointing to the relevant terms (#2, #3 and #6) implementing the statements from that paragraph.

Yes, these do fully "satisfy my point of view", if one reads them.
Specifically the quoted paragraph in the preamble clearly and abstractly depicts the goals of the GPLv3, which make its use problematic for quite some use cases (as discussed).

Yet you fail to point to something in the GPLv3 which "satisfies any point of your view".

Re: Qt "stuck" at v5.6 in SFOS
 

Yes, aka 25% of the total number of words in the license. Totally not blanket-quoting.

No, not "as discussed". You claimed that if a museum lends you a tablet with GPLv3 software it is "problematic". I disagree and the GPL FAQ disagrees.
Please don't bring in every other usecase in the world here.

Re: Qt "stuck" at v5.6 in SFOS
 

Nice, that we finally seem to agree on these three points:

and


That is fine for me.

Re: Qt "stuck" at v5.6 in SFOS
 

I am glad that we were at least entertaining for others.
True, this was definitely more heated recently than the usual postings at the "To amuse the community" thread. ;)
Well, partially I was even able to have some fun along these lines, but overall it was just tedious for me.

Back to the real topic:

I denoted in the original posting of this thread Does that answer your question?

Re: Qt "stuck" at v5.6 in SFOS
 

And for the record, after asking around, the real reason Jolla is stuck with ancient Qt is because the QtWayland compositor module "graduated" as a non-essential Qt addon and thus changed license from a mixture of BSD+LGPL to GPL only. Only essential Qt components (like the client parts of the Wayland module) remain as LGPL.

Since Silica is apparently still not fully open, this puts them in a problem as the compositor process is linking Silica and Qt Wayland Compositor together. (Plus a lot of porting to do, anyway).

The issue is not related to GPLv3 at all. In fact Jolla is already shipping some GPLv3 software in the device images (at least for the original Jolla). E.g. I've just checked and GPLv3 readline is used, for example. So much for the GPLv3 FUD...

Re: Qt "stuck" at v5.6 in SFOS
 

@javispedro,

Thank you for independently confirming what @rinigus concluded last November:

and


Combined with Jolla's clear statement,

... that they will not "open source" Silica (and will remove the few references to the LGPL in the Silica sources), a technical way out might be to let Silica not depend on Qt Wayland Compositor, anymore. This may be achieved by some interim layer, be it a new one or by extending an existing one, which is FLOSS.
Or Jolla pays a lot for a commercial license (while "The Qt Co." has a track history of raising the prices regularly), if they have not negotiated some very special conditions (unlikely due to the size difference of the companies and Qt Co's past behaviour).


Also thank you for your constructive contribution.
Hence I take back the
... because above posting has some substance.

I just assume that you seem to be a very strongly opinionated *GPLv3 and / or FSF fan for now.
Still I want to point out to you on an abstract level, that you exhibited quite some trolling properties, aside of strong fandom:

• Language: "crazy", "insane" etc. (Thanks!)
• Grasping at every string, be it a side note, example, etc., while missing (to address) the main points.
• Deliberately running down every rathole in sight.
  Like the "Dutch museum tablet", which was merely a simple example for a "transfer of the right of use and possession" (i.e., "loaned" / "borrowed" colloquially), which is incompatible with the *GPLv3 family of licenses (without granting all users full device control).
• Demanding answers to questions from you, which are not relevant for the topic discussed.
• Not really reading or ignoring what others post or link to, when it does not fit into your view.
• Ignoring all facts, which contradict your view (e.g., the GPLv3 license text, Google's license strategy, Jolla's license strategy).

Oh well, see (again) the
So Jolla clearly has "double trouble" here:

• Silica cannot depend on a newer Qt Wayland Compositor than v5.6, without conflicting with the license change imposed by The Qt Co. (LGPLv2 -> GPLv3)
• Jolla cannot depend on Qt Wayland Compositor and some other Qt components newer than v5.6, without conflicting with their self-imposed *GPLv3 strategy: A "NoGo" for SFOS components, which may be deployed by default to "big licensees" of SFOS.

Re: Qt "stuck" at v5.6 in SFOS
 

Let's keep the namecalling! Show must go on! Show must go oooooooooon....

Why are "my opinions" or "my properties" relevant to this discussion?
Sure, you're not the first one to call me troll (not the first one to retract, either), and I have been famously rash in the past. I usually reserve this for when I'm presented with extremely poor, repetitive, or outright false excuses.

Where have I called you crazy or insane?

I have definitely referred to your interpretation of the FSF as absurd, and even later as insane, specially when I thought it was something Jolla had published.

I still think it is an absurd argument: I don't know of anyone else doing it that way, and it leads to a conclusion that directly contradicts the GPLv3 FAQ itself, in addition to other, more absurd conclusions (e.g. , why would the Affero clause be needed if mere "users" of the work are already entitled to the source?). But it is a fact that at least something is mentioned in the GPLv3 FAQ, so perhaps it is not such an uncommon interpretation. I was curious, at least at the beginning.

I have also called your messages FUD. You are still spurting out FUD in this very message. See below.

The entire discussion starts when I ask about that specific example, because I smelled BS (my very first post on this thread). At the time I even offered an escape route, since _maybe_ there was indeed some Dutch lawyer that had interpreted the GPLv3 in that specific way. It would have made, at least, for an entertaining read. And I would have been forced to shut up (or email that lawyer).

But then it became obvious that you just made up the example. Which basically means you are just spreading FUD about the GPLv3. Trying to muddle what is otherwise a pretty clear definition into your own, in order to confuse the public and instill fear about the license.

And the "Dutch museum tablet" is just one example of this FUD. You prefixed it with "Dutch", as if hinting that it was a story that really happened in this world. That a Dutch museum somewhere actually had a problem with the GPLv3 and hey, "it could happen to you!". But the story has not actually happened, has it? At least nothing appears in a cursory web search and my repeated questions into it have been responded with annoyance.

It is a story you made up, and that should make anyone suspicious, because why would you make up stories that appear to back your interpretation of the license? I can only think of one answer: because you are trying to instill fear, uncertainty and doubt about it. I am not trying to claim malice, though. Perhaps it is genuine ignorance, or just to try to defend Jolla somehow. But Jolla needs no defense.

And you mentioned other examples (such as the GPLv3 being incompatible with ATMs because, according to you, users of the ATM would be entitled to the encryption keys of the machine, apparently), which are even more far-fetched, and that I didn't pursue. Suffice to say, they are similarly absurd.


And, to top it off: despite 2 pages of discussion, you still spurt again exactly the same theory about loaned devices being incompatible with the GPLv3 here in this line, as if it were evidently true, and as if nothing of the past 2 pages of discussion mattered. Never miss an opportunity for FUD, right? Well I will not miss my opportunity to rebuke it for the nth time: It is not true. It is directly contradicted by the GPLv3 FAQ.

Your only rebuke for the FAQ item has been a very cloudy argument which attacks the authors of the GPLv3, claiming they "deliberately" lie about their own license on their own supporting documents (for some unknown purpose). An argument that is again completely unsubstantiated with any source whatsoever, and thus yet another gratuitous attempt at FUD.

Your next argument, I believe, is going to be that "I had a newspaper article about the Dutch museum story, but my dog ate it, so I can't link it to you".

Yes, I demand sources for your claims when they smell like BS.
Life is so easy when I can just spurt whatever I want on a public discussion forum and get annoyed when people call me on it.

Where exactly? Notice that when I rebuke one of your arguments, I always emphasize which one it is. (E.g. I don't know how many more times I will have to repeat "Dutch museum story"). I always mention the argument or even quote the exact sentence. You don't. I am forced to guess which link I apparently ignored.

I am yet to see where is the "fact" which contradicts my view. Actually, I am yet set to see where are the "facts". Facts, facts is exactly what I am asking from you. You claim to understand the license in a specific way that no one else does. You claim that Google doesn't ship GPLv3 software, yet it turns out they do. You claim that Jolla doesn't ship GPLv3 software, yet it turned out they actually do!

And I'm most definitely NOT claiming that the GPLv3 imposes NO extra restriction on top of the GPLv2. It's your list of "blocked usecases" (aka the "Dutch museum story") that I have a problem with. You just quote GPLv3 myth over myth.

And again trying to paint it as a GPLv3 issue for no reason...

E pur, they ship GPLv3 software already, check your /usr/share/licenses/ folder...

EDIT:
Extra disclaimer: I like discussing politics, and effectively like discussing software politics even more. I acknowledge my words are harsh. But I try to criticize the arguments/messages and never the person, and in fact in my mind I will disassociate the author of the posts from the content of the posts themselves (which kind of explains why I'm harsh :) -- treating you like a generic PR person and forgetting I'm not always dealing with people who are used to my style ). So if anything seems offensive, I didn't really mean it as criticism towards you personally, and hope you are not angry (I'm not).

Re: Qt "stuck" at v5.6 in SFOS
 

Yes, Mr. Ballistic. ;)

Guess why?
Hint: I provided you with a list.

Oh, that seems to have been premature. :o


To reply to your technical points.
Side note: Nice to see how even obvious things are overlooked when one goes ballistic (happens to me, too).

Because using a software online does not include the necessary "transfer of the right of possession" to become a "user" in the sense of GPLv3 and LGPLv3.
To cover exactly this extra case ("online use") is why the AGPL was created.

Oh yes, I was given an Android tablet and wired headsets when purchasing the "multimedia guide" variant of an entrance ticket to a Dutch art museum.
This would have been legally impossible without granting me full control over the device, if then software stack would have been based on *GPLv3 components.
As I wrote, just a simple example, you love to sidetrack into.

Correctly so, as you pointed out, because that does not include the "transfer of the right of possession" of a software in source or binary form, which is necessary to become a "*GPLv3 user".
The "transfer of the right to use" alone is not sufficient.

As discussed, logically the same is true for "ticket machines", "information points" all other fixed device installations.
So I already agreed to and adopted this counterargument of yours.
That is why I remembered that I experienced a case, where also the "transfer of right of possession" happened: the "Dutch museum tablet".


I seriously have to thank you for helping me (WRT GPLv3) to

• sharpen my arguments
• look up proper references (which included rereading the GPLv3 for the Nth time)
• sort out incorrect examples (i.e., fixed device installations)
• use the correct terms for underlying, basic legal constructs: "transfer of the right of possession", "transfer of the right to use" and (not applicable / not necessary for the *GPLv3) "transfer of the ownership"
• etc.