Re: Automatic downloading of non-free software by stuff in main
On 11/30/2017 08:52 AM, Ian Jackson wrote:
[...] But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,
I would like to establish a way to prevent this.
I think the ideal way would be if instead of those programs offering &
downloading the plugin at runtime, the plugin were instead packaged &
put in non-free. Then of course if you don't have non-free in your
sources.list, you won't be offered it. Of course, that's not always
feasible.
And when it's not, software should let the user know that what he/she is
about to download is non-free, especially when it's the single-plugin
case like Clementine. Worst case, that's carrying a string-changing
patch, but probably upstream won't object to that change.
This seems to get us 90%: it's true that software might still point you
to non-free stuff, but you'll be warned it's non-free (and/or have opted
in by putting non-free in your sources.list).
I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.
For the stated goal, this is oddly narrow. Especially since we've always
taken the stance that "software" is opposed to "hardware"; it is not a
synonym of "executable machine code". Just plugins (especially with that
"does not include sandboxed code" caveat later in your message) prevents
such a tiny portion of non-free stuff that I struggle to see the point.
Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.
The minimum required changes to individual packages should be small.
Ok, let's take an example: how should Firefox (or Chromium) behave
differently if the free-only flag is set?
So one option is that it claims everything is sandboxed (now that 57 has
gotten rid of the old XUL extensions). So it ignores the flag entirely.
Even, I believe, binary plugins run in a sandbox (at least on Chromium
they do—e.g., Flash does).
But let's try taking the flag seriously. At first glance, it'd appear we
just need to add code to filter addons.mozilla.org results by freeness.
First problem, the site doesn't have a field for that (which isn't
surprising), but it does have a license field. So we just need to
somehow map each license to a freeness status, which will be fun since
there isn't an official list of DFSG-free licenses and some licenses
depend on the exact options picked (e.g., invariant sections).
But then, thinking about it, depending on what you mean by plugin, those
aren't the only ones. For example, the web folks have been (for better
or worse) working towards making web applications just as functional as
desktop apps. And they've added things like Service Workers, which can
run even when the web page isn't open (to provide things like desktop
notifications). Web apps can even run offline, saving the data to local
storage, syncing (or not) when the network is available. It's hard to
see why that isn't a plugin. And there is no way for Firefox to know
which of those are free.
Josh Tripplet's example of language package managers is another good one
— I doubt any of those repositories have a "is-this-DFSG-free" field.
And they often have search features which return results regardless of
license status, and features to follow dependencies (again regardless).
Reply to: