Re: Automatic downloading of non-free software by stuff in main
On Thu, Nov 30, 2017 at 01:52:18PM +0000, Ian Jackson wrote:
> Over the years, d-legal has discussed a number of packages which
> automatically download non-free software, under some circumstances.
> The obvious example is web browsers with extension repositories
> containing both free and non-free software.
> We have also recently discussed a media downloader/player which, when
> fed a particular kind of url, will offer to automatically download a
> proprietary binary-only protocol module to access the specified
> proprietary web service.
> I would like to establish a way to prevent this. (There are even
> whole Debian derivatives who have as one of their primary goals,
> preventing this.
No, those derivatives are damage. While their hearts are in the right
place, they cause data loss and security holes by at least making people on
Intel and AMD machines use known-buggy microcode.
Yeah, opaque encrypted microcode can be used to sneak in new backdoors,
but that doesn't make past bugs (and "oh, those foul hackers found one of
our backdoors, it was a honest bug, really!") any better. At the very
least, you get new TLA-only backdoors while those fixed are usable by both
TLAs and any random punk.
Likewise, closed firmware for your wifi card is evil, but still strictly
better than the same code burned into ROM: you get some bug fixes, and can
go back to a past version. Sweeping non-free code under the carpet doesn't
help in any way -- if you have to use it, it's better kept where you can
The biggest reason for me to avoid non-free code is that neither me nor
anyone among us can fix problems. And those derivatives you're talking
about tend to reintroduce this problem for political reasons (GFDL with
Even Debian is not without fault here: for example, the ftpmasters accept
such a blatantly non-free licence as AGPL into main.
> I think the necessary new central technical component is a
> configuration somewhere, checked by programs with plugin download
> We should have a conversation about:
> * What user experience options should ideally be available
> * How those options should be represented in configuration
> * Bug severity for programs that do not respect the "only free
> stuff" setting.
I don't think any such extra infrastructure is needed: what we have already
works well, at most it could take some clarification in the Policy. I
believe the model that's in place for apt is worth adopting for browsers,
media players and such.
* no new non-free code is ever installed without the user's consent
("new" defined at package granulation, allowing splits/etc)
* it's not even proposed unless the software detects that such non-free
parts are actually needed
* once a piece of non-free code is installed, it should receive updates
unless explicitly configured otherwise
The last part matters because of recent Chromium issues. Of course, checks
for updates should be done in a way that minimizes privacy issues (which
Chromium's upstream loves to maximize), but defaulting to no updates at all
. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
AGPLed project in anything networked that has no, or cumbersome, ways to
pass advertising statements to the user (such as, eg, an IMAP server).
It also fails the Dissident Test: take a blogging software with
steganographic features, that you provide hosting for, for two classes of
users: fellow dissidents, and public at large. The former receive the code
(both binaries and source), the latter do not. Even revealing the existence
of your changes is a serious risk for the life of you and your friends.
Regular GPL has no such problems.
You might read my words as a sort of FSF bashing, as both bad licenses are
provided by them (GFDL and AGPL3), but regular GPL is generally much better
than BSD/MIT: it emulates a world without copyright much better, as in such
a world we'd have decompilers, etc.
< darkling> When all you have is a hammock, every problem looks like a nap.