Hi, On 08/12/2017 11:12 AM, Dr. Bas Wijnen wrote: > On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote: >> I don't think this is as black and white as you paint it: > > It's certainly not black and white, and as I wrote elsewhere, the line can > move. But there is a line and I don't think it's anywhere near where some > people seem to draw it.
The point of my email was to illustrate that if I want to come up with a consistent set of principles that tries to further flesh out the very vague basic idea of what contrib is, and then start to follow these principles to their logical conclusion, then I always appear to be able to come up with examples that just don't seem right to me. So I don't think there's a clear and easy line to draw. And to be explicitly clear: there are two types of gray areas: ones where there is a set of consistent principles can be applied, but the question where individual examples fall might not always be easy to decide - and other ones where I don't think it's easy to come up even with a consistent set of principles. I do believe this here is the latter case, not just the former. >> 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? > > Possibly. > The GPL makes an exception for components of the OS (so "it runs on > Windows" doesn't make things non-free), Well, nobody claims that contrib is non-free. The GPL clause here is more about making an exception to the requirement that all code that a GPL'd software is linked to also has to be under a license compatible with the GPL. > and I think it is reasonable if Debian followed that rule as well. Could you then not also argue that other exceptions are reasonable? In the case of the GPL I think the rationale for this exception is much more clear-cut, because there it talks about specific issues related to copyright and licensing restrictions. >> 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? > > In practice, yes. That's how we do things. Not because package granularity > is > relevant, but because we don't want to keep software out just because it > contains the option to interact with something non-free. But if that option > is > in a package of its own, yes it belongs in contrib. I personally find this to be completely absurd. I do believe that packaging granularity as a _consequence_ of the ability to include certain things in main or not is fine and even necessary. Take for example the non-free firmware blos that are split out of the kernel. But I don't think that packaging granularity as a _reason_ for either including or dropping the _very same code_, producing the _very same binaries_, from main is a sensible position. >> Furthermore, you can go to more extremes: "requires non-free >> software to work" can also be applied to hardware drivers in more >> general terms. > > Yes, hardware is complex and I follow the principle of RMS there: if you need > it to get to a better (more free) place, it's acceptable. Couldn't you also say that about ICQ clients? That if you are in a situation where you can't get rid of ICQ it's better to use a free software client to connect to it? > Once there are free options, we should recommend them. I don't think anyone here has an objection to that. > So that means I don't think all of Debian should be in non-free because there > are no free cpu designs Ahem, nobody said anything about non-free here, we're talking about contrib. That said: for all release archs of Debian there are actually free implementations of the CPU architecture, in the form of Qemu. So I don't think this applies here. > [free CPU designs] > (although I'm sure there are...) There are, take a look at RISC-V, for example. [1] And for the requirement about not requiring non-free software, you don't need to have a fully free CPU design, just one where the microcode is free. And I believe that current POWER CPUs fall under that category. (I may be wrong though.) >> - 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) > > Why the distinction? If you have to load a firmware before the device works you have to actually ship the blob to the user to make it useful. If the firmware is already embedded in the hardware the software that is distributed doesn't have to contain any non-free parts to make the hardware work. This distinction is certainly debatable, but is one that has been made by a lot of people in the past, including the FSF. (And to be absolutely clear: I'm not trying to advocate for a specific position, because I don't have a clear position on these issues. I just think there are flaws in the arguments I've seen presented here, which I want to point out.) Regards, Christian [1] https://wiki.debian.org/RISC-V