On Tue, 02 Jul 2019 at 15:20:37 -0400, Nat Tuck wrote:
> It'd probably be necessary to go through the packages in main and see
> if any other packages download and install proprietary software at all,
> or if this is just Firefox even in the more general case.
I want to head this off right now, because continuing this train of
thought could lead to us removing all the email clients from Debian
(because they are willing to download this email[1], which I have not
placed under a Free license), and if that's the standard we are aiming
for then we might as well give up on producing a practically useful
Free Software distribution.
A program that *can* download and install proprietary software, but does
not depend on doing so, is definitely allowed in main: general-purpose
HTTP clients like Firefox and wget download whatever you tell them to,
proprietary or otherwise, and so will software package managers like
apt, Docker and pip. Even within the scope of installing executable
code through an interface specifically designed for executable code, the
extensions available from addons.mozilla.org and third-party sources are a
mixture of Free and non-Free, just like the dpkg packages available from
deb.debian.org and third-party apt sources, the Docker images available
from Dockerhub and third-party Docker registries, and the Python packages
available from PyPI and third-party pip-compatible repositories. Some
distribution points have a strict policy of Free Software only (Debian
main is one such distribution point, and I think PyPI aims for this?),
but any downloader that can't cope with multiple compatible distribution
points (federation) has an obvious missing feature, and any downloader
that *can* cope with multiple compatible distribution points can be
pointed to a distribution point that offers non-Free software.
Now, I do agree that Firefox's Widevine module is not the same as (for
example) the addons on addons.mozilla.org, because there is code in
Firefox to download and run this specific module (Widevine specifically,
not just the generic concept of an EME module), and the UI for that
feature does not make it immediately obvious that an additional module
will be downloaded and run when it is enabled. I think you might be
harming your chances of achieving your goal here by trying to make this
into a debate about DFSG-compliance (which I suspect is not one you are
likely to win), and by expanding its scope from Widevine to software
downloaders more generally.
If you approach this from the angle of "I had a reasonable expectation
of what this checkbox would do, but what it actually does is something
different, and I think this situation could be improved", then that
seems more likely to lead to changes, assuming you haven't already
antagonised the people you would have needed to persuade. It might not
lead to precisely the changes you hoped for, but sometimes compromise
is necessary.
More on the DFSG angle, because this *is* -legal:
Packages in main are not allowed to *depend on* proprietary software,
which we have generally interpreted as: imagine the proprietary software
was distributed via apt/dpkg (if it isn't already). If the strength of the
depending package's dependency on it is such that a Depends or Recommends
with no alternative would be appropriate, that isn't OK for main; but if
a Suggests or no explicit dependency at all would be more appropriate,
or if an appropriate dependency could have been an alternative-group like
"Depends: free-thing | non-free-thing"[2], then that's allowed.
So, imagine the proprietary Widevine module was included in the non-free
archive area or some third-party apt repository, so that firefox.deb
could have a Depends, Recommends or Suggests on it, rather than being
available via a non-apt mechanism. How strong would the correct dependency
be? I think the answer is probably Suggests: Policy says that means that
"the listed packages are related to this one and can perhaps enhance
its usefulness, but that installing this one without them is perfectly
reasonable", which seems about right. Installing Widevine enables an
additional feature (playing DRM-encumbered videos), but Firefox continues
to be useful for many other purposes without it.
Firefox frequently also downloads proprietary web pages, and proprietary
Javascript programs, but if anything the dependency relationship there is
the other way around: the web page and its associated Javascript programs
depend on a web browser. If (for example) Youtube was somehow packaged in
Debian[3], we'd be more likely to say
youtube Depends: firefox | chromium | www-browser than we would be
to say firefox Depends: youtube.
smcv
[1] If you believe "software" means executable code and excludes
non-executable data like the text of this email, please imagine that
I had included a shell script under a "non-commercial use only" license
in order to make my point
[2] Debian Policy ยง2.2.1, as resolved in #681419 and #587279
[3] April Fool's Day ITP, anyone?
