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 <ijack...@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.