inexorgame-obsolete / meta

A meta repository for all organization related issues
MIT License
0 stars 0 forks source link

CEF is (potentially) non-free #11

Open ghost opened 7 years ago

ghost commented 7 years ago

There's been a lot of talk on libreplanet-discuss recently because QTWebEngine in moving to Chromium and Chromium is assumed to be non-free. I don't play Sauerbraten because the assets are not free and I really like this project because it doesn't use Sauer's assets. But I would like for it's code to also be free.

Here's the latest post from the mailing list explaining the issue:

Chromium's subtle freedom flaws

As free software activists, we all enjoy using the latest and greatest in free software. Many users have expressed to us their desire to run Chromium web browser since it appears to be fully free software.

In our research, we discovered that the situation is improving. Just a few years ago, there were over one thousand unlicensed files which were considered to be non-free. Thanks to Debian's Lintian Reports and efforts, this number has come down to under 100 files as of this writing. Licensing the remaining code with GPL-compatible licensing is fairly trivial and is expected to be completed soon - the majority of it being minified javascript.[1]

However, Chromium by default has a number of issues that are still a concern free software users - even if all the source code is licensed properly.

-What are the issues?-

Queries to Google

By default, Chromium still has many lines of hard-coded internet queries to Google. Building it unpatched essentially puts your browser into the cloud. As mentioned in our article "Who does that server really serve?"[2], free software is only free when you are in control and should not be dependant on third-party web services. Some work has already been done to free Chromium from this enslavement, including the removal of "Google OK" after user outcry.[3]

Pre-built Binaries

By default, Chromium still includes some pre-built binaries to aid in faster compiling. In order to have fully free software, we require all software to be built from source. Packagers should not use "use_prebuilt" as a compile option.

DRM and Proprietary Codecs

Chromium supports the use of Widevine DRM, Adobe Pepper Flash, and third-party codecs which are non-free. Packagers must ensure that these are removed and disabled in the makefile options prior to compiling in order to be free software compliant.

Privacy problems

While not specific to free software, we would like for users to have control over their private information. Chromium has a number of reported privacy concerns which made it ineligible for use with Tor. Free software users should be aware of these issues and work to patch them upstream and in their packages as needed.[4]

A work in progress

There is work being done to remove queries to google and pre-built binaries, as well as strengthen user-privacy.

The patch-set called ungoogled-chromium, which itself is a combination of inox, iridium, and Debian patches is one such effort.[5] Free software advocates are advised to use these patchsets and help contribute to their maintenance. With each consecutive Chromium release a new patchset must be created to remove Google specific code and binaries which affect your freedom.

Chromium is also being used as an embedded framework in various projects.

Users should be aware that QTWebengine is based on Chromium and therefore contains many of the same flaws. Proprietary codecs and other anti-features must be disabled at compile time to ensure user's freedom is respected.[6] Due to QT being a primary component of KDE and many applications, ensuring it is compiled correctly and removing non-free software is of even greater importance to the free software movement.

We are hopeful that the various projects currently working with Chromium will continue their efforts to liberate the code, making the internet safer, as well as more freedom respecting, for everyone.

1. https://lintian.debian.org/maintainer/pkg-chromium-maint@lists.alioth.debian.org.html#chromium-browser

  1. https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
  2. http://www.pcworld.com/article/2940499/ok-google-hotword-detection-yanked-from-chromium-after-user-revolt.html

  3. https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs

  4. https://github.com/Eloston/ungoogled-chromium
  5. http://doc.qt.io/qt-5/qtwebengine-features.html#audio-and-video-codecs

This is Free work, you can redistribute it and/or modify it under the terms of either: The Creative Commons Attribution-ShareAlike 4.0 International License as published by Creative Commons; either version 4.0, or (at your option) any later version, or The GNU Free Documentation License as published by the Free Software Foundation; either version 1.3, or (at your option) any later version; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts

aschaeffer commented 7 years ago

Our CEF integration is still not fully done, but what I can say is that we don't need DRM and proprietary codecs. Currently we are using pre-built binaries. The reason is that we first get things work then make it better. Once our built stack is complete (git, cross platform built tools, cross platform package manager, build server) it will be easier to build CEF from source.

ghost commented 7 years ago

I have asked about CEF in libreplanet-discuss and will post the info when it will be available.

a-teammate commented 7 years ago

Could you maybe point them to the package we use conan-CEF? repo: https://github.com/inexor-game/conan-CEF/ conan.io package: https://www.conan.io/source/CEF/3.2704.1424.gc3f0a5b/a_teammate/testing

I think we could join forces for maintaining the package, since currently it is pretty hard to do any "build-from-source" stuff in that package (as I would need to do that stuff remotely).

If they decide to use conan ofc, but I'm pretty convinced by it (and I think for a reason), So I'd guess we get open ears.

EDIT: related: #346

ghost commented 7 years ago

I have suspicion that the Conan flavor is not going to be popular. But I barely touched web tech so I don't know.

Fohlen commented 7 years ago

I have suspicion that the Conan flavor is not going to be popular. But I barely touched web tech so I don't know.

Conan is a package manager. What does that have to do with web tech?

ghost commented 7 years ago

Making CEF free and easy to build is a noble cause. I just think there are other projects that aim for that. I'm calling CEF a web tech because this is basically a browser. I just never built any browsers or other web related projects so I don't know if there are CEF forks, what libraries are used, etc.

a-teammate commented 7 years ago

Conan is basically just a build-tool. which is specialized in refining third-party libraries: You define in a python script called conanfile.py what things need to be acquired before building cef, how to download the source, how to build it and which outputs you get. Thats it.

We would not provide any "conan flavor" of CEF, but simply apply the patches you mentioned right in the build system available via an option. Like "--disable-non-free" or sth like this.