On Thu, Nov 30, 2017 at 06:54:32PM +0000, Ian Jackson wrote: > Josh Triplett writes ("Re: Automatic downloading of non-free software by > stuff in main"): > > - Packages in main must not point the user to specific non-free or > > contrib software and recommend its installation, > > I agree with this as a goal for at least some configuration settings. > I'm basically sympathetic. But: > > Unfortunately, this statement is inconsistent with the Technical > Committee decision in #681419. That is, it cannot be implemented > without a General Resolution[1], or someone persuading the TC to > reverse #681419.
I don't believe the decision in that bug in any way prevents this effort, though it may require more careful phrasing. That bug refers to Debian package dependencies; my text above was intended to refer to other mechanisms, such as prompting the user or otherwise pointing them to "you should download and isntall this specific third-party non-free thing". We could add a sentence, for instance, saying "Providing a non-default alternative in package dependencies or recommendations, or a Suggests, is acceptable." (Which I don't think is unreasonable; that's precisely the threshold that ensures the user will not automatically install such software without making an explicit choice to do so.) > > Such an opt-in > > I was hoping to get away from questions of default configuration, and > to do the technical work first. I'm not trying to talk about default configuration here; I'm trying to solve a usability issue. People who have already said "I want to be able to install non-free software with apt" are presumably also OK with being asked "you need to download and install this proprietary DRM plugin to watch Netflix, is that OK?". I also don't want to *require* that software pay attention to such system-wide settings either, just suggest that they may wish to do so for usability. > I was also hoping to avoid trying to make a long list of political > demands, which is what your bullet points are. On the contrary, I was attempting to write text suitable for Policy (modulo annotations) regarding specific mechanisms of packages in main to pull in third-party software that may potentially be non-free or contrib. None of this is intended to be "political demands", nor is it intended to be a substantial change to current practice for how we already handle software in Debian (e.g. people already, today, file serious bugs for packages in main that attempt to download and install non-free software; we just don't have a clear and unambiguous written policy). Is there something that makes this text not suitable for that purpose? (Other than the specific issues you've identified in your reply, which I'd be happy to work to address.) (Also, I just realized that all the points in my previous mail need to be prefaced by "for packages in Debian main", since they don't apply to contrib or non-free.) > Finally, your set of bullet points doesn't explain to me what the > "additional distinction" it is you are trying to make. Sorry, I meant to go back and add a note about that, and forgot to do so. The additional distinction was between auto-installing such software without prompting, prompting the user to a *specific* proprietary program, and simply exposing a collection of software (e.g. Firefox extensions) only some of which are proprietary. I think we should prohibit the first, prohibit the second unless the user has opted in, and allow the third with a recommendation (but not requirement) to make the individual software licenses clear. > > - For the sake of avoiding ambiguity, an interpreter for file formats or > > network protocols that include software, such as scripts, may consider > > the user browsing to a site or opening a file as "user interaction" > > for the purposes of processing the software embedded or referenced by > > that site or file. However, this does not extend to automatically > > downloading or installing separate non-free software to interpret such > > sites or files, such as non-free codecs or plugins; that must still > > require explicit user interaction. > > Does that mean that a web browser is allowed to execute non-free > Javascript ? What about nominally-free Javascript > (Libre-JS-permitted) which the user doesn't have the practical > capability to modify because of the way it website JS deployed and > distributed ? Yes, and yes. I wrote this additional point specifically to allow that case. People who want to deal with that particular issue are welcome to install LibreJS or another such extension, which we could even package in Debian. Without this specific point added, the previous points regarding automatically downloading and running non-free software would necessarily apply to browsers running JavaScript or WebAssembly (or, for that matter, HTML, CSS, fonts and font hinting instructions, or many other things that in some way could be considered "software"). I felt like this additional point would be the cleanest way to address that, effectively saying "if you browse to example.org, then running anything example.org references is fine, but prompting the user to install a proprietary codec or DRM plugin is still not". (Please note, in advance, that any points regarding the merits of JavaScript or WebAssembly in general, or web apps versus web pages, or graceful degradation, are all *completely* off-topic for the current discussion. This is not the place to bemoan the current state of the web and its ecosystem. I'm mentioning this explicitly because I'm sure that it would be very tempting to conflact these issues. This discussion should *only* be about licensing.) > These are questions I would prefer to avoid answering now. I don't think we *can* avoid answering those questions now, because any reasonably written description of avoiding the automatic installation or running of non-free software necessarily will appear to apply to web browsers and JavaScript unless we go out of our way to define why they do not. However, I'd like to answer those questions in the most straightforward and least disruptive way, in the spirit of policy being descriptive rather than prescriptive. > Summary: please help me try to avoid making the best the enemy of > improvement. Agreed completely. I'd like to try to come up with a reasonable policy here, one that primarily documents existing practice, that does not require massive overhauls of any existing packages, that allows things like the Firefox addons ecosystem, and that does not allow things like silent background downloads of non-free software. - Josh Triplett