Project

General

Profile

Freedom issue #1167

[chromium][qt5-webengine][electron] QTWebgine/Electron embeds "entire Chromium platform"

g4jc - almost 3 years ago - . Updated 23 days ago.

Status:
confirmed
Priority:
freedom issue
Assignee:
-
% Done:

0%


Description

Due to outstanding freedom issues with Google's Chromium project1, we should remove QTWebengine since it is non-free.

"QtWebEngine integrates chromium's fast moving web capabilities into Qt. Our goal is to bring the latest and best implementation of the web platform into the universe of Qt. It is not just a port of the core HTML/CSS rendering engine, it is the entire Chromium platform."[2]

Unfortunately, this well break all programs which have sold their souls to Google - by replacing the libre "QTWebkit" with "QTWebengine" including Qupzilla and konqueror and some other important packages.

Webkit/Webkit2 remain free software without non-free Google code.[3]

[1] http://www.mail-archive.com/gnu-linux-libre@nongnu.org/msg02199.html
[2] https://wiki.qt.io/QtWebEngine
[3] https://wiki.qt.io/QtWebKit


Related issues

Related to Packages - Packaging request #140: Possible to make a libre version of Chromium (web browser)?not-a-bug

Actions
Related to Packages - Freedom issue #1290: Lots of apps are unusable without qt5-webengineduplicate

Actions
Related to Packages - Bug #1426: [anki] depend on qt5-webengineopen

Actions
Related to Packages - Bug #1147: Qupzillanot-a-bug2016-11-202016-12-31

Actions
Related to Packages - Freedom issue #1231: [electron] embeds Chromium platform (or part of it), recommends nonfree DRM pluginsfixed2017-03-14

Actions
Related to Packages - Packaging request #1394: [revolt-git] Add package to PCRopen2017-07-03

Actions
Related to Packages - Freedom issue #1236: [apm] is useless without *atom* packagenot-a-bug

Actions
Related to Packages - Packaging request #1002: [atom-editor] add package to PCRopen2016-05-04

Actions
Related to Packages - Freedom issue #1380: [riot-desktop] requires electronfixed2017-06-26

Actions
Related to Packages - Packaging request #1191: [riot] add package to pcropen2017-01-24

Actions
Related to Packages - Packaging request #1085: [simplenote] add package to PCRopen2016-08-22

Actions
Related to Packages - Packaging request #1034: [brave] Please add package to PCRnot-a-bug2016-06-19

Actions
Related to Packages - Packaging request #1203: [Yakyak] add package to PCRnot-a-bug2017-01-29

Actions
Related to Packages - Bug #1211: Anki Broken after updatenot-a-bug2017-02-12

Actions
Related to Packages - Packaging request #1085: [simplenote] add package to PCRopen2016-08-22

Actions
Related to Packages - Freedom issue #1526: kdevplatform replaced by kdevelop which requires qt5-webenginefixed2017-11-14

Actions
Related to Packages - Freedom issue #1584: [messagelib]: depends on blacklisted 'qt5-webengine'confirmed

Actions
Related to Packages - Freedom issue #1585: [parley]: depends on blacklisted 'qt5-webengine'fixed2017-12-19

Actions
Related to Packages - Freedom issue #1788: [quassel-monolithic][quassel-client]: depends on 'qt5-webengine'fixed

Actions
Related to Packages - Freedom issue #1783: Falkon has broken dependency: qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #1808: [rssguard]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #1844: [kalarm] Unresolvable dependencies - depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #1862: [libkgapi]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2012: KDE depends on Qt5-Webengine (Duh...)confirmed

Actions
Related to Packages - Freedom issue #2107: nextcloud-client depends on qt5-webengineconfirmed

Actions
Related to Packages - Bug #2109: [electron2] analogous to [electron], embeds Chromium platform (or part of it), recommends nonfree DRM pluginsfixed

Actions
Related to Packages - Freedom issue #2117: [marble]: depends on qt5-webenginefixed

Actions
Related to Packages - Freedom issue #2114: [konqueror]: can not load any URL - depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2136: [musescore]: depends on 'qt5-webengine'fixed

Actions
Related to Packages - Freedom issue #2171: [supercollider]: requires 'qt5-webengine'forwarded upstream

Actions
Related to Packages - Freedom issue #2174: [libksysguard] Depends on qt5-webengineduplicate

Actions
Related to Packages - Freedom issue #2188: [canorus]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2189: [babe]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2190: [clipgrab]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2191: [kbibtex]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2192: [kube]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2193: [qmapshack]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2194: [radare2-cutter]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2195: [psi][psi-l10n][psi-plugins]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2196: [kalgebra]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2198: [telepathy-kde-text-ui]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2199: [luminancehdr]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2200: [pgadmin4]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Freedom issue #2201: [wire-desktop]: depends on electronconfirmed

Actions
Related to Packages - Freedom issue #2202: [cozy-desktop]: depends on electronconfirmed

Actions
Related to Packages - Freedom issue #2203: [code]: depends on electronfixed

Actions
Related to Packages - Freedom issue #2204: [keybase-gui]: depends on electronfixed

Actions
Related to Packages - Freedom issue #2210: [libkgapi]: depends on nonfree qt5-webenginefixed

Actions
Related to Packages - Freedom issue #2211: [libksysguard]: depends on nonfree qt5-webenginefixed

Actions
Related to Packages - Freedom issue #2256: [kmail] [qt5-webengine] Kmail won't run without QT-WebEngine.unconfirmed

Actions
Related to Packages - Freedom issue #2407: [electron4]: on [community]fixed

Actions
Related to Packages - Packaging request #2512: ungoogled-chromium with Guix recipe: is it a go?open

Actions
Related to Packages - Freedom issue #2523: [electron5] another one bites the dustconfirmed

Actions
Related to Packages - Freedom issue #2527: [asar]: depends on electronfixed

Actions
Related to Packages - Freedom issue #2528: [caprine]: depends on electronfixed

Actions

History

#1

Updated by Anonymous almost 3 years ago

  • Priority changed from bug to freedom issue
#2

Updated by Anonymous almost 3 years ago

  • Subject changed from QTWebgine embeds "entire Chromium platform" to [qt5-webengine] QTWebgine embeds "entire Chromium platform"
#3

Updated by Anonymous almost 3 years ago

  • Assignee set to Anonymous
#5

Updated by Anonymous almost 3 years ago

g4jc wrote:

Note to @Emulatorman: Firefox is now shipping parts of chromium API too. It has been fixed in Iceweasel-hardened -

ok, i will add it then, thanks!

#6

Updated by isacdaavid almost 3 years ago

#7

Updated by Anonymous over 2 years ago

  • % Done changed from 0 to 100
  • Status changed from open to fixed
#8

Updated by daimonion over 2 years ago

Hi there! You could package otter-browser with qt5-webkit-ng engine: https://aur.archlinux.org/packages/otter-browser/

#9

Updated by jdoe over 2 years ago

A QtWebEngine developer has recently responded to the bug report at kde.org1 claiming that QtWebEngine does not include the entirety of Chromium, and that the discussion on LibrePlanet was based on a misunderstanding. In related thread on QtWebEngine mailing list2, he explained that QtWebEngine actually removes a large amount of code from Chromium including functionalities that rely on Google's servers, so Chromium's issues may not apply to QtWebEngine. Perhaps it should be re-evaluated for possible re-inclusion?

[1]: https://bugs.kde.org/show_bug.cgi?id=374808
[2]: http://lists.qt-project.org/pipermail/qtwebengine/2017-January/000409.html

#10

Updated by Elon_Satoshi over 2 years ago

jdoe wrote:

A QtWebEngine developer has recently responded to the bug report at kde.org1 claiming that QtWebEngine does not include the entirety of Chromium, and that the discussion on LibrePlanet was based on a misunderstanding. In related thread on QtWebEngine mailing list2, he explained that QtWebEngine actually removes a large amount of code from Chromium including functionalities that rely on Google's servers, so Chromium's issues may not apply to QtWebEngine. Perhaps it should be re-evaluated for possible re-inclusion?

[1]: https://bugs.kde.org/show_bug.cgi?id=374808
[2]: http://lists.qt-project.org/pipermail/qtwebengine/2017-January/000409.html

I second this. I may not know enough about it, but I need qtwebengine to install Anki. And it seems pretty free to me. So we should either re-evaluate this, or modify Anki to work with qtwebkit.

Edit: If somebody can point to specific instances of nonfree-ness in qt5-webengine code, then we know it's nonfree

#11

Updated by isacdaavid over 2 years ago

  • % Done changed from 100 to 0
  • Status changed from fixed to open
#12

Updated by isacdaavid about 2 years ago

#13

Updated by isacdaavid about 2 years ago

  • Related to Bug #1426: [anki] depend on qt5-webengine added
#14

Updated by isacdaavid about 2 years ago

  • Assignee set to isacdaavid
#15

Updated by Anonymous about 2 years ago

Is there an update on this issue?

Now that the FSF Licensing and Compliance Lab is promoting QupZilla, I'm curious why QtWebEngine remains blacklisted.
"QupZilla, currently at version 2.1.2, is a free software Web browser using the new and very fast QtWebEngine browser"
https://www.fsf.org/blogs/licensing/the-licensing-and-compliance-lab-interviews-david-rosca-of-qupzilla

#16

Updated by bill-auger about 2 years ago

#17

Updated by bill-auger about 2 years ago

jdoe wrote:

so Chromium's issues may not apply to QtWebEngine. Perhaps it should
be re-evaluated for possible re-inclusion?

Elon_Satoshi wrote:

Edit: If somebody can point to specific instances of nonfree-ness in
qt5-webengine code, then we know it's nonfree

to be clear about this "Chromium's issues" amount to some accusations
that have yet to be proven - i looked into this back then scouring
emails and bug reports and i have not yet seen any person actually
point to any particular file that is question

so to the suggestion that it be "re-evaluated for possible
re-inclusion" the fact is that it was never "evaluated" for exclusion -
it was a hasty act erring on the side of paranoia - i am not saying
that was the wrong move but to be clear there never was to my knowledge
any evaluation of either chromium or qtwebengine - so to answer elon:
nobody can point to specific instances of non-free code in webengine
because whatever non-free code it has allegedly came from chromium and
nobody can point to specific instances of non-free code in chromium
either

as i remember though it was at the suggestion of the FSF that parabola
keep these projects on the blacklist - or if not suggested directly,
the decision was heavily influenced by the FSF's current opinion at the
time - if the FSF has changed their opinion then perhaps qtwebengine
should be re-instated - as well chromium, electron, and anything else
that was jettisoned or tainted by what isacdaavid called: "the great
Chromium/QtWebEngine purge"

TBH personally i dont use any of those programs so i have no stake in
this issue - im just speaking for the sake of clarity

#18

Updated by isacdaavid about 2 years ago

  • Assignee deleted (isacdaavid)

jc_gargma wrote:

Is there an update on this issue?

not really. i'm prioritizing the outstanding dbscripts backlog for the coming days. the continued existence of i686 depends on it, yet nobody has undertaken that task as far as i'm aware.

i'll report here if i start working on this. feel free to beat me to it.

#19

Updated by bill-auger about 2 years ago

i asked donaldr about this today and he asked that i post to the FSD mailing list so hopefully that will re-kindle some discussion

https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00001.html

#20

Updated by bill-auger about 2 years ago

  • Related to Freedom issue #1231: [electron] embeds Chromium platform (or part of it), recommends nonfree DRM plugins added
#21

Updated by bill-auger about 2 years ago

#22

Updated by bill-auger about 2 years ago

#23

Updated by bill-auger about 2 years ago

#24

Updated by bill-auger about 2 years ago

#25

Updated by bill-auger about 2 years ago

#26

Updated by bill-auger about 2 years ago

#27

Updated by bill-auger about 2 years ago

#28

Updated by bill-auger about 2 years ago

#29

Updated by bill-auger about 2 years ago

  • Related to Bug #1211: Anki Broken after update added
#30

Updated by bill-auger about 2 years ago

#31

Updated by bill-auger about 2 years ago

  • Subject changed from [qt5-webengine] QTWebgine embeds "entire Chromium platform" to [chromium][qt5-webengine][electron] QTWebgine/Electron embeds "entire Chromium platform"
#32

Updated by bill-auger almost 2 years ago

  • Related to Freedom issue #1526: kdevplatform replaced by kdevelop which requires qt5-webengine added
#33

Updated by bill-auger almost 2 years ago

#34

Updated by bill-auger almost 2 years ago

#35

Updated by dikasp almost 2 years ago

does someone has revaluated this package ? i just found that:

as g4jc says in [2], recently qtwebengine wiki has been updated to avoid misunderstanding and such claim as its embed entire chromium platform had been removed plus there is some note regarding relationship with chromium (https://wiki.qt.io/QtWebEngine - look into wiki history for details)

purism's pureos ship qupzilla and qtwebengine on their main repo
- http://repo.pureos.net/pureos/pool/main/q/qupzilla/
- http://repo.pureos.net/pureos/pool/main/q/qtwebengine-opensource-src/
as long as i know purism have a high standard and very strict with nonfree and privacy as this is important for distribuing their libre product (https://puri.sm/learn/freedom-roadmap/) fyi they re based on debian testing

and for the extra i found this:
- https://trisquel.info/en/forum/qupzilla-libre
- https://themusicinnoise.net/blogs/technology/posts/2017-05-12-from-parabola-to-arch.php
- https://tracker.debian.org/pkg/qtwebengine-opensource-src

#36

Updated by Anonymous almost 2 years ago

I'm still curious as to how QtWebEngine is non-free software.
As someone that uses KDE and assists development on a QtWebEngine based browser, I am very motivated to understand and resolve this situation.
If I can be provided of a list of verifiable problems, I'll bring up the issues with Qt myself.

#37

Updated by bill-auger almost 2 years ago

jc_gargma wrote:

If I can be provided of a list of verifiable problems, I'll bring up the issues with Qt myself.

that would be great - unfortunately there is no definitive list of verifiable problems and that is the crux of the problem - this issue goes back to the very first week that the *nix port of chromium was released nearly 10 years ago - here is a link to the current discussion on the FSD mailing list noting all of the information i could find on the topic including the original chromium bug report from 2009 that has never been closed - there is probably the best place to start - it lists about 65 "blocker" issues that have been resolved over te years and has about 25 still open - here is another post describing similar reasons why fedora removed electron2

[1]: https://lists.gnu.org/archive/html/directory-discuss/2017-11/msg00003.html
[2]: https://lists.gnu.org/archive/html/directory-discuss/2017-12/msg00008.html

dikasp and jc_gargma - please do declare your interest and add any information you can to that thread on the directory-discuss mailing list - i escalated this issue there because it affects all FSDG distros so that is the most current and active discussion on the topic - donoaldr from the FSF has recently told me that RMS and the FSF have taken an interest in resolving this so perhaps a conclusion will be reached soon - but chromium is a massive code-base so it needs to be a community effort

TBH if qtwebengine could be cleared that would make the biggest impact - if the alleged problems remian only in chromium that only excludes a small handful of derived browsers such as 'iridium' and 'ungoogled' - IIRC qupzilla browser is based on qtwenengine though so that could be removed from the blacklist - the only popular programs that electron accounts for is atom, riot, and vscode - but with QT deprecating qtwebkit, the qtwebengine is being increasingly more widely adopted and resulting in parabola recently losing many notable programs that it once had (most recently kdevelop)

as an indictor of just how vague this issue is, ill add that the description on the parabola blacklist currently says only this:

contains nonfree codecs{{citation needed}}, embeds parts of Chromium{{which?}}
#38

Updated by Anonymous almost 2 years ago

I see no value in posting on that fsf list. If we want to resolve this, the discussion must occur directly on the qtwebengine mailing list where actual qtwebengine developers will be kept informed and actual progress can be made. No more hiding such discussion away in the dark recesses of obscure bugtrackers, wikis, pads, ircs, mailing lists, or torrent trackers.
Face the light and let these claims either be revealed as truth or spirited away as shadows of imagination.
Free software is supposed to be about sharing information and working together, not brooding over how some software developer isn't psychicly aware of complaints never uttered.


http://lists.qt-project.org/mailman/listinfo/qtwebengine

#39

Updated by bill-auger almost 2 years ago

jc_gargma -

the reason that this issue is being discussed on the the FSD mailing list is because it is not related only to qtwebengine or any single project - the discussion is equally relevant to all FSDG distros as well as chromium and derived browsers, electron "apps", and qtwebengine clients alike - far from keeping this "in the shadows", the very reason for escalating the issue to GNU was to reach more eyes, which happened and now, finally the ball is rolling - if the discussion were to take place only on the qtwebengine mailing list then that would amount to limiting the discussion to one single project - also, the only bugtracker that is "hiding" any information in it's "dark recesses" would be upstream chromium which is at the very root of the issue so there could not be any place less obscure1

the reason that this discussion started at parabola and them moved to GNU because this is where the effect is most damaging and where the only people i know of who are actually willing to dig in and do the investigation are - im quite sure that all they would say at qtwebengine would be "show me the proof", which would be quite reasonable, but i seriously doubt that anyone at qtwebengine is going to help with the investigation so clearly the FSD mailing list would be the only place where any actual progress would be seen until any hard evidence is found because that is where the only people working on the investigation are discussing it - if nothing is found then qtwebengine nor anyone else needs to do anything - these programs can simply be removed from the blacklist and we can all forget about this mess - for now i think the best thing you could do on the qtwebengine mailing list would be ask others if they are interested to help with the investigation - other than that, there is little to discuss until something conclusive is found

if there is anything conclusive found then bug reports and/or patches surely will be filed against the appropriate project - the 10-year old open bug report against chromium1 would probably be the best place to start because chromium is at the root of the issue and so chromium is the most appropriate project to resolve it - most likely, downstreams such as qtwebengine and electron would get those patches without any need to do anything unless chromium refuses to co-operate - if that happens then qtwebengine would probably be the best downstream project to ask for co-operation - but as for today, the qtwebengine mailing list would not be the most appropriate project for the main discussion because that would be only addressing a symptom but not confronting the problems at their root

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=28291

#40

Updated by isacdaavid over 1 year ago

for everyone not following on the GNU-linux-libre and libreplanet-discuss mailing lists, here is the latest development in the story:

https://lists.nongnu.org/archive/html/gnu-linux-libre/2018-04/msg00001.html

compatibility with WideVine is a non-issue (we aren't trying to stop the user from installing nonfree software), but there may be something to the other points g4jc raised. i'm going out of a limb here, but if qt5-webengine is still pinging to google that could be an instance of spying on the user, which the Free Software Distribution Guidelines forbid.

#41

Updated by bill-auger over 1 year ago

  • Related to Freedom issue #1788: [quassel-monolithic][quassel-client]: depends on 'qt5-webengine' added
#42

Updated by bill-auger over 1 year ago

#43

Updated by bill-auger over 1 year ago

#44

Updated by bill-auger over 1 year ago

  • Related to Freedom issue #1844: [kalarm] Unresolvable dependencies - depends on qt5-webengine added
#45

Updated by bill-auger over 1 year ago

#46

Updated by bill-auger about 1 year ago

#47

Updated by bill-auger 11 months ago

#48

Updated by bill-auger 11 months ago

  • Related to Bug #2109: [electron2] analogous to [electron], embeds Chromium platform (or part of it), recommends nonfree DRM plugins added
#49

Updated by bill-auger 11 months ago

#50

Updated by bill-auger 11 months ago

  • Related to Freedom issue #2114: [konqueror]: can not load any URL - depends on qt5-webengine added
#51

Updated by bill-auger 10 months ago

#52

Updated by bill-auger 9 months ago

#53

Updated by bill-auger 9 months ago

there are several others currently on the blacklist without an associated bug report:

with libre replacement:

bibletime
kdepim-addons
kdepim-runtime
kde-development-environment-meta
kio-extras
pyqt5-common
python2-pyqt5
python-pyqt5
qutebrowser
qtcreator

without libre replacement:

fcitx-libpinyin
qt5-webview
wiznote

#54

Updated by bill-auger 9 months ago

several more (mainly KDE programs) are currently uninstallable that are consolidated into a single bug report (issue #2012):

falkon
libkgapi
kmail
kdepim-meta
kontact
kdenetwork-meta
akonadi-calendar-tools
kio-gdrive
messagelib
libksieve
akonadi-calendar
mailcommon
grantlee-editor
akregator
akonadiconsole
kalarm

(ty brettgilio for this list)

#55

Updated by hnasiet 9 months ago

Is there any chance that qt-webengine or even chromium will be "acquitted" in the near future?

#56

Updated by eschwartz 9 months ago

https://www.riverbankcomputing.com/news/pyqt-512

The latest version of pyqt5 now provides the webengine bindings separately, and are duly packaged separately in archlinux (currently in testing).

Please schedule pyqt5 to be removed from the blacklist and add python-pyqtwebengine to the blacklist instead. Progress in archlinux can be tracked in the following TODO: https://www.archlinux.org/todo/pyqtwebengine-split/

This has the additional side effect of being one less package that gets rebuilt but not fast enough for the imported repos -- remember the python 3.7 rebuild woes.
(I've said this on IRC, but these are optdepends and the actual pyqt5 library binding is legitimately LGPL, so I don't see the utility of rebuilding it in [libre]; fortunately it doesn't matter now.)

#57

Updated by bill-auger 9 months ago

i have added a commit for these 'pyqtwebengine' split packages to a new 'pyqt5' branch of blacklist.git - it can be merged when the following new packages enter the [extra] repo:

  • pyqtwebengine-common
  • python2-pyqtwebengine
  • python-pyqtwebengine

and v5.12 of the following packages:

  • pyqt5-common
  • python-pyqt5
  • python2-pyqt5
#58

Updated by bill-auger 9 months ago

#59

Updated by bill-auger 9 months ago

#60

Updated by bill-auger 9 months ago

#61

Updated by bill-auger 9 months ago

#62

Updated by bill-auger 9 months ago

#63

Updated by bill-auger 9 months ago

#64

Updated by bill-auger 9 months ago

#65

Updated by bill-auger 9 months ago

#66

Updated by bill-auger 9 months ago

#67

Updated by bill-auger 9 months ago

#68

Updated by bill-auger 9 months ago

#69

Updated by bill-auger 9 months ago

#70

Updated by bill-auger 9 months ago

#71

Updated by bill-auger 9 months ago

#72

Updated by dllud 9 months ago

It is worthwhile to check whether some of those packages can be built without qt5-webengine. That was the case for Marble, it just lost some minor functionality. Probably it is also true for many other KDE apps.

#73

Updated by bill-auger 9 months ago

#74

Updated by bill-auger 9 months ago

#75

Updated by bill-auger 9 months ago

#76

Updated by bill-auger 9 months ago

#77

Updated by bill-auger 9 months ago

dllud wrote:

It is worthwhile to check whether some of those packages can be built without qt5-webengine.

thats why most of these are still open - the first task for blacklisting any package is to find some way to liberate it; but that is often time consuming - none of these programs are actually installable so the priority is quite low unless someone indicates specifically that they want to use one - you can read the blacklisting protocol here

https://git.parabola.nu/blacklist.git/tree/README#n33

#78

Updated by oaken-source 9 months ago

#79

Updated by oaken-source 9 months ago

#80

Updated by bill-auger 9 months ago

#81

Updated by bill-auger 9 months ago

  • Status changed from open to confirmed
#82

Updated by freemor 7 months ago

  • Related to Freedom issue #2256: [kmail] [qt5-webengine] Kmail won't run without QT-WebEngine. added
#83

Updated by grizzlyuser 5 months ago

kio-extras does not recommend qt5-webengine anymore, so it's been removed from the blacklist recently: https://git.parabola.nu/blacklist.git/commit/?id=d66b6d33f041c50b7001b8a95ee866df024dcd6e

#84

Updated by bill-auger 5 months ago

yep and the pyqtwebengine patch can be applied now too, which could re-instate some others

https://git.parabola.nu/blacklist.git/commit/?h=pyqt5&id=20567813917763f2009d91c7392313b269dadd5d

#85

Updated by bill-auger 5 months ago

#86

Updated by bill-auger 5 months ago

#87

Updated by Megver83 4 months ago

This is getting insane and pointless. The official Qt Wiki says very clearly:

Relationship to Chromium

Qt WebEngine uses code from the Chromium project. However, it is not containing all of Chrome/Chromium:

  • Binary files are stripped out
  • Auxiliary services that talk to Google platforms are stripped out
  • The codebase is modularized to allow use of system libraries like OpenSSL

We do update to the latest Chromium version in use before a Qt release. After a release some bug fixes and security patches are backported. For LTS releases of Qt we might also update Chromium in a patch level release.

Is it possible to be more explicit than that? Plus, we all know that PureOS ships qt5-webengine and they've got no freedom issues with it. I vote for qt5-webengine package to be replaced in [libre] (and not unblacklist it, because Arch builds it with --proprietary-codecs and there are other issues mentioned later)

We should just dig on its documentation, maybe create a patch to remove any potentially freedom-dangerous thing like the codecs stuff, the HTML5 DRM support and Adobe Flash plugin, and build it in [libre]. We could take a look at PureOS to see how they manage it (IIRC, they take it directly from Debian)

#88

Updated by bill-auger 4 months ago

what do you mean that they have no issues with it? - you mean there are no open bug reports about it? - maybe someone should open one then? - just because their users are not complaining about licensing problems does not imply that they dont exist

if there are legitimate doubts raised about the licensing of some program, then someone should do the work of auditing it before blindly declaring it to be FSDG-compliant - regardless of explicit publicly stated suspicions, we should hope that the licensing of every software is fully verified before entering any FSDG distro - otherwise, it quite betrays the users expectations of FSDG distros as thier vanguards of "purity" - i would not expect anyone to respect any FSDG distro if the criteria for inclusion included: "... or if we are too lazy to prove that this example is unfit", and "... or its too large to audit" - generally speaking, if one is aiming for purity, then a whitelist approach (like [pcr]) is likely to be far more effective toward that goal than a blacklist approach (like your-freedom) - in other words, it is those who claim that the program is freely licensed who have the burden of proving their claim; and not merely by expressing the beleif that it is so, but demonstrating in an objectively verifiable way, that it truly is - it is not necessary for anyone to disprove that claim; because non-free is the default for anything that is copyrighted

oaken-source is the only person i know of that has even tried auditing qt5-webengine - maybe we could step up that effort - its is much smaller code-base than chromium and would have a much greater benefit in terms of the number of dependent packages - it would be nice to finally resolve this ugly controversy; but ignoring it is not any resolution at all

https://lists.nongnu.org/archive/html/gnu-linux-libre/2019-04/msg00000.html

really though, i dont see this as a very important issue anymore - not many people complain about any of these programs - there is very little or no functionality missing from parabola because of this mess - in almost every case, there is some other program that does the same job - the majority of these programs can be rescued with a little effort, by using webkit instead or by patching out web integration somehow - its usually not difficult - many are adding compile switches to disable it; because people are asking them to do so on their bug trackers - but again, there is some time involved and it is a long list

they are desktop programs after-all - they should not need to render HTML or execute javascript, aside from the small few that actually are web-browsers - adding more frivolous javascript to parabola desktops is surely not high on my list of priorities; and i wouldnt want to be seen as a careless engineer, by simply letting it in with only the assurance: "the upstream believes it is ..." - i think that even to discuss this is a waste of valuable time; unless there is a chance that someone is going to complete the audit of either program - if someone can show that there is a real need for any of these qt5-webengine dependents, i would rather prioritize the time to attend to removing that dependency for that one; and to let the rest of them sit in this graveyard of kitchen-sink engineering for as long as it takes to get them patched into [libre] one by one - even with that plan, i would prioritize the backlog of packaging requests, which is probably a longer list than this one, but do not have any deps on the blacklist

i just did that for quassel yesterday, for example - that is one rare example of a legitimate use for an integrated web browser - that is, it actual renders a web page when the mouse hovers over a web URL - its a totally optional feature, and the developers allowed to be replaced by webkit, or compiled out entirely - if all dev teams were that considerate, everything on this list would probably already be in [libre], and i would not expect any complaints about them

#89

Updated by bill-auger 3 months ago

#90

Updated by anarcobuda 23 days ago

bill-auger wrote:

really though, i dont see this as a very important issue anymore - not many people complain about any of these programs

I don't know what you mean by that. You mean that these programs that depend on qt5-webengine are not important and nobody complains about it? I do wish that I've not understood you well and hope that you didn't mean it that way.

in almost every case, there is some other program that does the same job

Yeah, almost...
In my case, I am a musician and I've used MuseScore (GPLv3) for quite some time.
In MuseScore's case, it uses the package qt5-webengine to access online sheets, although I wouldn't really miss that feature.

the majority of these programs can be rescued with a little effort, by using webkit instead or by patching out web integration somehow - its usually not difficult - many are adding compile switches to disable it; because people are asking them to do so on their bug trackers - but again, there is some time involved and it is a long list

Surely! As I said, I'm a musician, and only a musician.
I do profoundly wish I had some wizard godly tech skills so that wouldn't be much of a fuss to me and I could easily fork a libre-version of MuseScore.

And maybe that could be actually a starting point for me, to even learn to do this.
Since I rarely get the feel that people care about musicians and composers, can someone guide me as to how I can make a qt5-webengine-less version of MuseScore program?

By the way, I'd like to thank this amazing community for their commitment to the libre-philosophy.

#91

Updated by dllud 23 days ago

Hi anarcobuda,

There is a good chance it will be trivial to remove the dependency on qt5-webengine. Many applications support being built without it and in turn get some features disabled. Check out my simple example with Marble: Freedom issue #2117: [marble]: depends on qt5-webengine

#92

Updated by dllud 23 days ago

Unlike my trivial example, MuseScore may require much more than a simple compile switch. In that case you can try to open an issue with the original developers, asking if they can provide a way for it to be built without qt5-webengine. As you can see, many applications provide that already.

#93

Updated by bill-auger 23 days ago

many packages have already been modified in that way, including marble - that is how most of the BR associated with this one were closed - if you have any specific recipes for any of your favorite packages that are still on this list with open tickets, we would gladly use them to get the package into the parabola repos

of course, it is best if there is upstream support - there have been some such as supercollider, that we originaly patched ourselves, but now the upstream added a compile switch for it

generally, the first thing to do is to start by searching the bug tracker for the project upsrream to see if anyone has already asked for a non-webengine version, or a switch to disable compilation; and if not, to open a feature request, then link the to upstream ticket in the parabola ticket - that is how the supercollider devs came to decide to add the switch

what i meant by: "this issue is not very important anymore" is that it was originally very controversial and people often complained of the programs in this list - that was to to say that these programs are not important; but simply that there are not many complaints anymore - i take that to mean that most of the ones people like have already been liberated

we are probably never going to get to all of them - the only way we know if people want to use one of them is if you complain about the ones you want to use - in this case, i would add a comment to the bug report for musecore, indicating that you want to use it - so far, no one has

https://labs.parabola.nu/issues/2136

#94

Updated by bill-auger 16 days ago

#95

Updated by oaken-source 13 days ago

#96

Updated by bill-auger 12 days ago

#97

Updated by bill-auger 12 days ago

Also available in: Atom PDF