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... ;-)