libreplanet-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreplanet-discuss] [Dev] QTWebengine is nonfree


From: Hanno Böck
Subject: Re: [libreplanet-discuss] [Dev] QTWebengine is nonfree
Date: Sun, 15 Jan 2017 22:50:16 +0100

On Sat, 14 Jan 2017 20:05:52 -0600
Isaac David <isacdaavid@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
principles.

> > 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
https://hboeck.de/

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]