Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service
Because it's so fun, let me play devil's advocate for a bit:
On 08/12/2017 08:29 AM, Dr. Bas Wijnen wrote:
> No. The question is not "is there non-free software that the program can work
> with?" That would be much too broad, and it would make anything that touches
> the network non-free. Instead, the question is "is non-free software required
> for major functionality of the program?"
I don't think this is as black and white as you paint it:
win32-loader probably doesn't run on Wine or ReactOS (though I haven't
tried it, so I may be wrong here) - should that be in contrib if that's
the case?
Consider the following scenario: I write a chat client that supports
both XMPP and ICQ - but don't separate the code. As the "major
functionality", i.e. chat, still works with free services (there are
plenty of free software XMPP servers out there), by your logic it should
be in main. But if at some point I decide to refactor that thing and
separate out the protocol implementations into libs, the library that
does ICQ should now be in contrib, and by extension the program then
should either be in contrib or drop support for ICQ. (Or implement a
plugin mechnaism, which can be a lot of work.)
So should the packaging granularity, which in the end is to a certain
extent always somewhat arbitrary, dictate whether a program goes into
main or contrib?
Or would you instead say - to be consistent here - that the ICQ part
should also be disabled in the case where the libs aren't factored
out? But would that not mean that any minor subfeature of a software
in main that only works with proprietary software should either be
disabled for refactored into a plugin-based system where the version
with support for that could live in contrib?
But if that is the case, do our efforts to de-blob the kernel go far
enough? Because while there is some free firmware available for some
devices, if we take the principle to the extreme conclusion, any
driver where there's only non-free firmware available should have
the firmware-loading capability stripped if it's to be in main. But
even if you say, well, firmware loading is mostly a memcpy() in
current times, let's ignore that for now - there are some features
of kernel drivers that only work with non-free firmware (while the
basic device functionality may already work without any firmware).
Should the driver in main disable these extended features?
(Speaking of: as far as I can tell the WiFi drivers that require
non-free firmware to work at all are in main at the moment. Or do
drivers not count as "major functionality" if they're part of the
kernel? But would they then count as "major functionality" if they
are still a separate DKMS module before it was included in the
mainline kernel? But if the code is exactly the same, why should it
then suddenly move to main, just because upstream decided to merge
it in?)
Or, I don't know if this is true, but let's say there's a feature in
the PDF standard that is currently supported by non-free authoring
tools. Should free PDF readers disable support for this specific
feature if they want to be in main because it requires non-free tools
at the moment to generate PDF files with said feature? (And even if
this is not true for PDF, there's probably some file format out there
where this holds.)
Furthermore, you can go to more extremes: "requires non-free
software to work" can also be applied to hardware drivers in more
general terms. What about devices that have firmware embedded on
them? Isn't communicating with a device firmware via USB or PCIe
not in some sense equivalent to communicating over the network?
And sure, some devices can be emulated by e.g. qemu, so there you
would have a free implementation of the "remote side", but in
many cases you don't. Couldn't you also argue that any hardware
driver that talks to hardware that has any kind of firmware on it
(even if it's pre-embedded on there and doesn't need to be loaded
during runtime) should be in contrib unless a) there firmware is
free software or b) there's something like qemu emulating that
hardware?
I do think there are easy cases:
- the Microsoft TrueType Corefonts downloader should definitely
be in contrib
- any tool dedicated to updating the firmware of devices where no
free firmware exists for any of the devices it supports should
also be in contrib (I'm talking about devices that have a flash
where the firmware is in, not about firmware loading that takes
place during device initialization)
- the ZFS DKMS module should definitely not be in main as any
binaries produced by it are (probably) non-redistributable
But in other cases I don't think the answer is quite as simple,
see the examples I gave. And I don't think there's any consensus
here, I'm not even sure what opinion I have on all of these
issues. I can just see that no matter in which way I try to create
a set of more specific principles to flesh out the more broader
idea of contrib that I accept [1], I can always easily think of
examples where I go "wait, this doesn't seem quite right".
Regards,
Christian
[1] "if it requires non-free software it should be in
contrib".
Though wait a minute, I just re-read what policy says, it's
actually:
"The contrib archive area contains supplemental packages
intended to work with the Debian distribution, but which
require software outside of the distribution to either
build or function."
Well, if I take that to its extreme conclusion, wouldn't that
also mean that I any network client I package should go into
contrib until there's a free software implementation of a
corresponding network server available in Debian as well? And
vice-versa? And what about file format readers? And what about
software that talks with other services that are free but not
in the purview of Debian? For example if you have software
that only works with a small embedded device that's connected
via e.g. USB or the network, and that embedded device will
never run Debian (say it has only 32k of RAM), but does run
free software?
This discussion just got way more interesting... ;-)
Reply to: