[Dev] [libreplanet-discuss] QTWebengine is nonfree

Hanno Böck hanno at hboeck.de
Sun Jan 15 21:50:16 GMT 2017

On Sat, 14 Jan 2017 20:05:52 -0600
Isaac David <isacdaavid at isacdaavid.info> wrote:

> It could very well be free by now, but only if you are willing to
> overlook the fact that it's not actually being built from sources.
> The chromium repository still distributes and uses some object
> code, instead of the original free libraries.

Can you point to specific examples with file paths and names?
If I search for .o or .so files in the chromium source I don't find
anything that looks problematic. There are a couple, but they all seem
to be test files as part of test suites, not something that will end up
being used and executed.

> We learned that from
> the aforementioned ungoogled-chromium patchset. Following
> [1] I also found otherwise-free javascript that only seems to exist
> in minified form in the Chromium "source" tree.[2]

The example file you link seems to be a thirdpary code shipped as part
of a tool called "catapult", which itself as far as I understand it is
a tool for performance analysis. I don't see that file or anything
related to catapult in my chromium installation, so my best bet is it's
only used for development and again not part of chromium as a software.

The Chromium codebase is large and confusing and bundles a whole lot of
stuff where it's often hard for outsiders to understand what it's
doing. I'm not saying this is ideal.
But I don't see any evidence yet that it's deviating from free software

> > Issues regarding to privacy are imho orthogonal to the free software
> > state of an application, but they shouldn't pose any blocker to
> > using the rendering engine.  
> Orthogonal yet absolutely important, because QtWebEngine is
> said to contain *all* of Chromium, not just the Blink engine. Even
> if the freedom problems were fixed soon (they could be), we would
> still need to worry about Qt (and therefore KDE) possibly subjecting
> their users to the well-documented Google tracking.

Sorry, but I don't see that as a logical conclusion. Can you be more
specific what kind of google tracking you mean here?
How does QT plan to use chromium? I guess the idea is that inside a QT
application you can open some html renderer.
I don't see why such an application would be exposed to google tracking.

Chrome does connect to Google for a whole bunch of reasons, but I'd
assume a lot of them are irrelevant in such a case. E.g. it wouldn't
want to sync bookmarks or anything alike.

Hanno Böck

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

More information about the Dev mailing list