Re: Automatic downloading of non-free software by stuff in main
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
Reply to: