Automatic downloading of non-free software by stuff in main
This mail is going to a lot of lists. I have set the followups to
d-policy because ultimately this is hopefully going to result in a
change to policy.
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.
We have generally put software like this in main, because it asks the
user first, and can be used perfectly well without the proprietary
parts. 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. (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this. We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)
I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.
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.
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.
NB that this is going to be a _user option_. I'm not trying to shut
down non-free extension repositories. (Indeed I sometimes use them.)
I want to give users more control.
Obviously excluded from this discussion are downloader packages, which
have the fetching and use of proprietary things as their primary
purpose, and which therefore live in contrib.
But there is another category I want to distinguish:
Applications for processing Turing-complete file formats. This
includes web browsers, because of Javascript; but it also includes
PostScript viewers; interactive fiction interpreters; and so on.
The distinction between this and the general plugins I mention above
is that these applications all restrict the capabilities of the code
being executed, by running it in some kind of sandbox or container.
The idea being that the code gets to control the user's interactions
_with the providers of that code_, but not anything else.
There are some people who object to executing any non-free code on
their computer and I don't mind providing a facility for people to
restrict that. But I don't know exactly how to design such a thing.
For web browsers, there is the FSF's libre-JS. Personally I think
that is rather quixotic (and doesn't really address the real user
freedom question anyway), but I have no objection if anyone wants to
do the work to integrate that into some kind of freeness control
system.
But with file formats, the situation is much harder. I don't feel we
can introduce a policy requirement requiring package maintainers to
support users who want this kind of restriction, until we can come up
with a scheme that will actually work and be useable (and indeed, will
be minimal effort for a package maintainer to opt into).
(The question is: how do we stop a Postscript file received by email
being rendered automatically when the user clicks on it, while
allowing the user to still open a Postscript file they generated
themselves ?)
Ian.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: