Project

General

Profile

Freedom Issue #1167

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

g4jc - about 7 years ago - . Updated 5 days ago.

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

88%


Description

TLDR: read this summary
https://lists.parabola.nu/pipermail/dev/2022-March/008203.html

------------------------

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


Subtasks

Freedom Issue #1155: [ghostwriter] add package to PCRfixedbill-auger

Actions
Freedom Issue #1204: Min (web browser) has non-privacy search enginesfixed

Actions
Freedom Issue #2012: KDE depends on Qt5-Webengine (Duh...)fixedbill-auger

Actions
Packaging Request #2114: [konqueror]: can not load any URL - depends on qt5-webenginefixedbill-auger

Actions
Freedom Issue #2256: [kmail] Kmail won't run without QT-WebEngine.fixedbill-auger

Actions
Freedom Issue #2965: [digikam]: depends on gt5-webengineconfirmed

Actions
Freedom Issue #3108: [qt6-webengine]: same freedom issues as qt5-webengine, I supposeconfirmed

Actions
Freedom Issue #3142: [rz-cutter]: depends on 'qt5-webengine'fixedbill-auger

Actions
Freedom Issue #3163: [emby-theater]: another electron "app"fixedbill-auger

Actions
Freedom Issue #3220: [bitwarden]: depends on blacklisted 'electron'fixedbill-auger

Actions
Freedom Issue #3221: [react-native-debugger]: depends on blacklisted 'electron'fixedbill-auger

Actions
Freedom Issue #3222: [signal-desktop]: another 'electron' "app"fixedbill-auger

Actions
Bug #3394: kimagemapeditor: cannot be installedfixedbill-auger

Actions
Freedom Issue #3590: [fcitx5-chinese-addons]: depends on qt5-webenginefixedbill-auger

Actions
Freedom Issue #3593: [neochat] Depends on blacklisted "qt6-webview"fixedbill-auger

Actions
Freedom Issue #3596: [angelfish] Depends on blacklisted qt6-webenginefixedbill-auger

Actions
Freedom Issue #3597: [kaccounts-providers] Depends on blacklisted "qt6-webengine"fixedbill-auger

Actions
Freedom Issue #3598: [tokodon] Depends on blacklisted "qt6-webview"fixedbill-auger

Actions

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 - Freedom Issue #1426: [anki] depend on qt5-webenginein progress

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 pluginsin progress

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][element-desktop] requires electronfixed

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

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 #2117: [marble-common]: depends on qt5-webenginefixed

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

Actions
Related to Packages - Bug #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-webenginenot-a-bug

Actions
Related to Packages - Freedom Issue #2189: [babe]: depends on qt5-webenginenot-a-bug

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 - Packaging Request #2201: [wire-desktop]: depends on electronopen

Actions
Related to Packages - Packaging Request #2202: [cozy-desktop]: depends on electronopen

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 - Packaging Request #2512: [ungoogled-chromium]: is it a go with Guix recipe?open

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

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

Actions
Related to Packages - Freedom Issue #2597: [electron6] same freedom issues as with other electronsfixed

Actions
Related to Packages - Packaging Request #1461: [rstudio] add to PCRfixed

Actions
Related to Packages - Freedom Issue #2708: [kdeplasma-addons] controversial qt5-webengine in makedepends and optdependsconfirmed

Actions
Related to Packages - Freedom Issue #2791: [spyder] depends on webengineconfirmed

Actions
Related to Packages - Freedom Issue #1275: [otter-browser] depends on qt5-webenginefixed

Actions
Related to Packages - Freedom Issue #3171: [qtcreator]: v6 dependes on qt6-webenginein progress

Actions
Related to Packages - Freedom Issue #3173: [qmapshack]: depends on qt5-webengineconfirmed

Actions
Related to Packages - Bug #3338: [freecad]: depends on blacklisted 'qt5-webengine' and blacklisted 'python-pip'fixed

Actions
Related to Packages - Freedom Issue #3340: [frescobaldi]: depends on python-pyqt5-webenginefixed

Actions

History

#1

Updated by Anonymous about 7 years ago

  • Priority changed from bug to freedom issue
#2

Updated by Anonymous about 7 years ago

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

Updated by Anonymous about 7 years ago

  • Assignee set to Anonymous
#5

Updated by Anonymous about 7 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 about 7 years ago

#7

Updated by Anonymous almost 7 years ago

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

Updated by Anonymous almost 7 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 almost 7 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 6 years ago

jdoe wrote:

Perhaps it should be re-evaluated for possible re-inclusion?

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 6 years ago

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

Updated by isacdaavid over 6 years ago

#13

Updated by isacdaavid over 6 years ago

#14

Updated by isacdaavid over 6 years ago

  • Assignee set to isacdaavid
#15

Updated by Anonymous over 6 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 over 6 years ago

#17

Updated by bill-auger over 6 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 answer jdoe:
it can not be "re-evaluated for possible re-inclusion"; because it
has never been "evaluated" to any depth - it was simply excluded on
suspicion of its chromium lineage, which has not been evaluated either -
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 adding this observation for the sake of clarity

#18

Updated by isacdaavid over 6 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 over 6 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 over 6 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 over 6 years ago

#22

Updated by bill-auger over 6 years ago

#23

Updated by bill-auger over 6 years ago

#24

Updated by bill-auger over 6 years ago

#25

Updated by bill-auger over 6 years ago

#26

Updated by bill-auger over 6 years ago

#27

Updated by bill-auger over 6 years ago

#28

Updated by bill-auger over 6 years ago

#29

Updated by bill-auger over 6 years ago

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

Updated by bill-auger over 6 years ago

#31

Updated by bill-auger over 6 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 over 6 years ago

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

Updated by bill-auger about 6 years ago

#34

Updated by bill-auger about 6 years ago

#35

Updated by dikasp about 6 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 about 6 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 about 6 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 the 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 indicator 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 about 6 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 about 6 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 almost 6 years 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 almost 6 years ago

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

Updated by bill-auger almost 6 years ago

#43

Updated by bill-auger almost 6 years ago

#44

Updated by bill-auger almost 6 years ago

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

Updated by bill-auger over 5 years ago

#46

Updated by bill-auger over 5 years ago

#47

Updated by bill-auger over 5 years ago

#48

Updated by bill-auger over 5 years 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 over 5 years ago

#50

Updated by bill-auger over 5 years ago

#51

Updated by bill-auger about 5 years ago

#52

Updated by bill-auger about 5 years ago

  • Related to Bug #2171: [supercollider]: requires 'qt5-webengine' added
#53

Updated by bill-auger about 5 years 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 about 5 years 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 about 5 years ago

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

#56

Updated by eschwartz about 5 years 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 about 5 years 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 about 5 years ago

#59

Updated by bill-auger about 5 years ago

#60

Updated by bill-auger about 5 years ago

#61

Updated by bill-auger about 5 years ago

#62

Updated by bill-auger about 5 years ago

#63

Updated by bill-auger about 5 years ago

#64

Updated by bill-auger about 5 years ago

#65

Updated by bill-auger about 5 years ago

#66

Updated by bill-auger about 5 years ago

#67

Updated by bill-auger about 5 years ago

#68

Updated by bill-auger about 5 years ago

#69

Updated by bill-auger about 5 years ago

#70

Updated by bill-auger about 5 years ago

#71

Updated by bill-auger about 5 years ago

#72

Updated by dllud about 5 years 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 about 5 years ago

#74

Updated by bill-auger about 5 years ago

#75

Updated by bill-auger about 5 years ago

#76

Updated by bill-auger about 5 years ago

#77

Updated by bill-auger about 5 years 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 about 5 years ago

#79

Updated by oaken-source about 5 years ago

#80

Updated by bill-auger about 5 years ago

#81

Updated by bill-auger about 5 years ago

  • Status changed from open to confirmed
#82

Updated by freemor almost 5 years ago

#83

Updated by grizzlyuser over 4 years 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 over 4 years 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 over 4 years ago

#86

Updated by bill-auger over 4 years ago

#87

Updated by Megver83 over 4 years 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 over 4 years 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 allowed for software to be included in distros, if the distro does not have the time to prove that the example is unfit, or if the code-base is too large to audit - the former suggests that the distro is under-staffed and incapable of satisfying the FSDG - the latter is describing an lumpish monster with onerous demands, from which the only defense is total avoidance, and constant vigilance against any other similar monsters which may come alone

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 - merely expressing a belief that it is so, is not sufficient - it must be demonstrated in an objectively verifiable way, that it truly (legally) is libre - it is not necessary for anyone to disprove that claim; because non-free is the default for anything that is copyrighted - libre is the special case which requires explicit evidence of intent on part of the author(s), of every byte, in every file

BTW, permissive licenses make that task significantly more difficult, because authors who use them, generally do not bother to claim that it represents any specific file(s) - they tend to believe that a single generic license file, implicitly covers all other files and all contributors; though the licenses themselves do not suggest so - for example, the MITs explicitly state that they do not cover all files; and the BSDs do not bother to mention that they cover any files at all - authors of GPL software tend to put a licence/copyright notice prominently in all files; so it is much easier to demonstrate who all of the authors are, and that they all intended all for files to be under the GPL

oaken-source is the only person i know of that has even tried auditing qt5-webengine - maybe we could step up that effort - it 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 webengine; because people are asking them to do so on their bug trackers - but again, there is some time involved for each; 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 not high on my list of priorities; and i would not want to be seen as a careless engineer, by simply letting it in with only the assurance: "the upstream believes so ... but even they not 100% certain" - i think that it is a waste of valuable time to discuss this any longer; unless there is a reasonable chance that an satisfying audit of either program will ever be completed - if someone can show that there is a real need for any of these qt5-webengine dependents, i would rather prioritize the time toward removing that dependency for each specific example, and to let the rest of them sit in this graveyard of kitchen-sink/cargo-cult engineering shame, for as long as it takes to get them patched into [libre], one by one

i just did that for quassel yesterday, for example - that is one rare example, of a (semi-)legitimate use for an integrated web browser - that is, it actual renders a web page when the mouse hovers over a web URL - one can easily argue that a chat application does not need that feature; but the feature does in fact do something which could not be done without a HTML/JS/CSS rendering engine - that is as opposed to the more frivolous uses, such as using HTML/JS/CSS to render the main GUI elements, or simply pinging some remote JSON API for small bits of ephemeral data

the important factor of note, regarding the quassel example, is that the feature is totally optional - the developers fully recognized that it was an unnecessary feature, which many people would not want, and they allowed webengine to be replaced by webkit, or compiled-out entirely - if all dev teams were so considerate, everything on this list would probably already be in [libre], and i would not expect any complaints about them

however, over-all, i would still de-prioritize all of these webengine dependents, which offer no unique functionality to parabola (that is nearly all of them), and instead to prioritize the backlog of packaging requests which do offer some unique functionality to parabola - that list is longer than this one, and those do not have any blacklisted dependencies

#89

Updated by bill-auger over 4 years ago

#90

Updated by anarcobuda over 4 years 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 over 4 years 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-common]: depends on qt5-webengine

#92

Updated by dllud over 4 years 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 over 4 years 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 over 4 years ago

#95

Updated by oaken-source over 4 years ago

#96

Updated by bill-auger over 4 years ago

#97

Updated by bill-auger over 4 years ago

#98

Updated by bill-auger about 4 years ago

  • Related to Freedom Issue #2597: [electron6] same freedom issues as with other electrons added
#99

Updated by bill-auger about 4 years ago

Updated by theova almost 4 years ago

  • Related to Freedom Issue #2708: [kdeplasma-addons] controversial qt5-webengine in makedepends and optdepends added

Updated by bill-auger almost 4 years ago

Updated by jschwart over 3 years ago

What would a proper audit look like? Would a list of all files in the latest source tarball with their origin and license be sufficient? Perhaps also grepping the tree for suspect names like 'google', etc. and see if they are used for communication?

Edit: I just took a look at the source tree. It's pretty horrible and I understand bill-auger's comments much better now. It seems that it would be much better to avoid this stuff and not give in to this Google mess like KDE and even Microsoft did.

Updated by bill-auger over 3 years ago

as you described it, for chromium, that would "look like" a
50 volume library of books, listing only the file names - a tool
like fossology would be essential to put the task within the scope
of feasibility

as for the privacy concerns, the ungoogled project would (or
should) have that information already, as that seems to be the
entire goal of the project

the most important factor, which will determine the likelihood of
this ever actually happening, is whether the focus is placed
on chromium, qt5-webengine, or electron - chromium is an
absurdly enormous code-base; and there are not enough people
who are willing to do that work, so it is probably never going
to happen - electron seems to a hopeless cause for distros; so
the only reasonable project to consider, is qt5-webengine - that
is fortunate, because qt5-webengine is used by hundreds of
programs, making it the one of the three with the greatest
impact on distros, by far - to focus on chromium would probably
require 1000 times more work, only for that one extra program

after the licensing audit of qt5-webengine is completed, the
code-base would need to be reconciled with the ungoogled
treatments, to address the privacy concerns

Updated by bill-auger over 3 years ago

Updated by bill-auger over 3 years ago

Updated by bill-auger about 3 years ago

  • Related to Bug #2985: [kdenlive]: links to qt5-webengine added

Updated by bill-auger about 2 years ago

Updated by bill-auger about 2 years ago

qt6-webengine and dependents were added to the blacklist

  • pyside6 (optdepends - could possibly be rescued)
  • python-pyqt6-webengine
  • qt6-webengine
  • qt6-webview

Updated by bill-auger almost 2 years ago

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

Updated by dllud almost 2 years ago

liberating Chromium would have a knock-on effect that goes much beyond Parabola. It would positively affect all other FSDG distros.
For instance, on Replicant, it would solve many pending issues related to WebView . (For a deeper dive take a look at The Chromium mess meets Android)

It is a big project, but wide collaboration across many free-software projects is definitely possible.

Updated by bill-auger almost 2 years ago

Updated by bill-auger almost 2 years ago

please, this issue was taken to the FSDG and FSD about 4 years ago - there is nothing more to add to this ticket unless some new information becomes known - all known information is already on this ticket, and much more can be found on the links to the mailing lists

webengine is much much smaller then chromium - this ticket already notes that

the proper netiquete on bug trackers, is to read everything which was already discussed, including links to other discussions, before posting anything else to the ticket, and to post only new information to the ticket - to ask a question, which is already answered is just adding noise

if want to discuss it or re-ask old questions, please use the forum or the mailing lists instead

there is already a thread on the parabola forum about chromium
https://labs.parabola.nu/boards/19/topics/727

Updated by bill-auger almost 2 years ago

  • Related to deleted (Bug #2985: [kdenlive]: links to qt5-webengine)

Updated by bill-auger almost 2 years ago

wow-wee! - two in the same week

Updated by Zuss almost 2 years ago

Updated by bill-auger over 1 year ago

  • Description updated (diff)

Updated by bill-auger over 1 year ago

  • Related to Bug #3338: [freecad]: depends on blacklisted 'qt5-webengine' and blacklisted 'python-pip' added

Updated by bill-auger over 1 year ago

Updated by bill-auger over 1 year ago

just an update: i ran the 'parabola-dependents' detector again today - this is becoming unwieldy
(libre/freecad is a false positive - a bug in the script)

$ sudo parabola-dependents -v qt5-webengine
updating database ....
pkgbase: 'qt5-webengine' not found - creating dummy package
dummy package 'qt5-webengine' created
querying database ....
searching abslibre ....
compiling results for (47) dependents ....

direct and transitive dependents:
  libre/freecad  [qt5-webengine] <- freecad

arch dependents:
  extra/cantor
  extra/kde-education-meta
  extra/kde-applications-meta
  community/labplot
  community/clipgrab
  community/csoundqt
  community/deepin-reader
  community/deepin-voice-note
  community/freecad
  community/gambas3-gb-qt5
  community/gambas3-gb-form
  community/gambas3-gb-chart
  community/gambas3-gb-db-form
  community/gambas3-ide
  community/gambas3-gb-form-dialog
  community/gambas3-gb-form-htmlview
  community/gambas3-gb-form-mdi
  community/gambas3-gb-map
  community/gambas3-gb-markdown
  community/gambas3-gb-report
  community/gambas3-gb-form-terminal
  community/gambas3-gb-media-form
  community/gambas3-gb-qt5-opengl
  community/gambas3-gb-qt5-webkit
  community/globalprotect-openconnect
  community/iaito
  extra/kalgebra
  community/kbibtex
  community/kchmviewer
  extra/kimagemapeditor
  extra/kde-graphics-meta
  community/kiwix-desktop
  community/kmymoney
  extra/ktorrent
  extra/kde-network-meta
  community/kube
  community/libalkimia
  community/luminancehdr
  community/psi
  community/psi-l10n
  community/psi-plugins
  community/qmapshack
  community/rkward
  community/scenarist
  community/skrooge
  community/tellico
  extra/vulkan-extra-tools

Updated by gap over 1 year ago

Now we have a documented case of WebEngine integration being deprecated in a packge, and WebEngine lingering around in the dependencies list for years afterwards (#3142) I think the first step with handling a package with a dependency on WebEngine should be to check whether the WebEngine integration has been deprecated, and then forward the issue upstream to Arch asking them to remove it if this is the case.
Hopefully this situation is more common and many other packages in the libre repo can be deprecated as we fall back onto the ones from Arch.

As for the scope of this issue, I think we need to start urging projects not to use WebEngine, or at the very least, to make it optional and document which features are missing if WebEngine integration is disabled.
We need to make it clear to upstream projects that this is not just a technical preference, but is a serious freedom issue that causes us to have to maintain seperate packages.
I say this because, often when I say that I dislike Electron or WebEngine, people jump to the conclusion that it must be because this is a technical preference and that I dislike web technologies and Javascript, when these are only secondary to the core issue of non-freedom.

Updated by bill-auger over 1 year ago

Updated by bill-auger over 1 year ago

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

Updated by bill-auger over 1 year ago

Updated by bill-auger 5 days ago

Updated by bill-auger 5 days ago

Updated by bill-auger 5 days ago

Updated by bill-auger 5 days ago

Also available in: Atom PDF