Re: non-free firmware: driver in main or contrib?
Glenn Maynard [EMAIL PROTECTED] wrote: On Thu, Oct 28, 2004 at 12:33:38AM +0100, Matthew Garrett wrote: That would require certain parts of d-i (and hence certain parts of main) to rely upon the contents of contrib. We can't do that. No, I believe that would create a Suggests-style relationship, not a Depends, since d-i would still work without it (for many people). Packages in main can Suggest packages not in main. d-i is modular. The module that provided that functionality would be likely to do little of any use without the presence of contrib. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Matthew Garrett [EMAIL PROTECTED] writes: Two issues: 1) The social contract doesn't give us any leeway here. There's no way to claim that hardware doesn't have to conform to the DFSG, and there's no way to claim that large parts of Debian don't require that hardware. Sure it does. The Debian Free Software Guidelines only apply to software. Hardware is hard, not soft. That's an unfortunate circumstance of naming. Anything that we could potentially ship has to be considered as software - the aspects of hardware that we're discussing are instructions that are run by a processor, and we could extract those and copy them into the distribution. Software doesn't stop being software once it's copied into ROM, even if you'd prefer it to be called hardware. 2) The contents of an eeprom can generally be touched from software. You need a firmer basis for your line. That... requires some thought. I don't mean to say that *all* drivers for firmware-using devices must go in contrib. Merely that those drivers which Depend, in the policy sense, on non-free software must go in contrib, and that any loadable firmware is software. Whether it's a Dependency depends on the individual case -- a device that ignores its firmware isn't a dependency, a driver that can drive prelaoded devices is a Suggestion, and so on. The social contract uses require, which is a stronger term than policy's depend. The driver software requires the portion of the hardware that can also be described as software. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED]: The social contract uses require, which is a stronger term than policy's depend. The driver software requires the portion of the hardware that can also be described as software. I assume the relevant quote is: We will never make the system require the use of a non-free component. I don't think this sentence can be understood by looking at each work through a magnifying glass. You need some kind of context (beyond the text of the Social Contract) to know what was intended here, not a detailed analysis of what require means. For example, you could understand the sentence to mean: We won't make the whole system dependent on a non-free component, but parts of the system might be designed to communicate with non-free software and therefore be useless without the corrresponding non-free software. Or it could mean: We won't deliberately make the system dependent on a non-free component, but if it so happens that there is no free software that implements the other side of some protocol, then that's a problem with the rest of the world, not with Debian. I don't claim it does mean either of these things, just that the sentence in isolation could be interpreted that way.
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Sure it does. The Debian Free Software Guidelines only apply to software. Hardware is hard, not soft. On Thu, Oct 28, 2004 at 12:40:02PM +0100, Matthew Garrett wrote: That's an unfortunate circumstance of naming. Anything that we could potentially ship has to be considered as software - the aspects of hardware that we're discussing are instructions that are run by a processor, and we could extract those and copy them into the distribution. Software doesn't stop being software once it's copied into ROM, even if you'd prefer it to be called hardware. It's also a circumstance of content, which is why the DFSG uses the word software so many times, and why it concerns itself with software licenses. Software which we don't and can't ship, which is a part of the platform we're running on, which is not application code, and which basically is outside the scope of the project is software we ignore. The social contract uses require, which is a stronger term than policy's depend. http://dictionary.reference.com/search?q=require The driver software requires the portion of the hardware that can also be described as software. The sentece which uses the word require is: We will never make the system require the use of a non-free component. While it's clear from context that non-free refers to non-free software, it's also clear that it's components which are what need to be free. It's also clear from contenxt that components are components of the debian system. Among other things, you're arguing that hardware [including software embedded in that hardware] is a component of the debian system (rather than being a part of its infrastructure). But we do not ship hardware, and software embedded in hardware is out of scope for us. -- Raul
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: Software which we don't and can't ship, which is a part of the platform we're running on, which is not application code, and which basically is outside the scope of the project is software we ignore. In many of these cases, we /could/ ship it (well, the license probably wouldn't let us, but that's a legal problem rather than a technical one). But at least we're in agreement that it's unambiguously software, even if it's also hardware under certain circumstances. The social contract uses require, which is a stronger term than policy's depend. http://dictionary.reference.com/search?q=require I possibly didn't make that clear. depend, when used by policy, refers to dependencies that are expressed by the package management system. As a result, it's possible to argue that a driver doesn't depend on the firmware that's in a chip on a PCB of the device it drives. But it certainly requires it. The driver software requires the portion of the hardware that can also be described as software. The sentece which uses the word require is: We will never make the system require the use of a non-free component. While it's clear from context that non-free refers to non-free software, it's also clear that it's components which are what need to be free. It's also clear from contenxt that components are components of the debian system. No, that doesn't make sense. If that was what it meant, it would just be a restatement of the second sentence (We promise that the Debian system and all its components will be free according to these guidelines). Since we've already promised that all the components in Debian will be free, then the non-free components it's referring to must be outside Debian. Among other things, you're arguing that hardware [including software embedded in that hardware] is a component of the debian system (rather than being a part of its infrastructure). I can probably be convinced that hardware in the traditional sense (something that's made out of gates and stuff) is not a component in the way that the social contract refers to. I see no way of arguing that for stuff that is plainly code. But we do not ship hardware, and software embedded in hardware is out of scope for us. I see no justification for that argument. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: Software which we don't and can't ship, which is a part of the platform we're running on, which is not application code, and which basically is outside the scope of the project is software we ignore. On Thu, Oct 28, 2004 at 05:50:09PM +0100, Matthew Garrett wrote: In many of these cases, we /could/ ship it (well, the license probably wouldn't let us, but that's a legal problem rather than a technical one). But at least we're in agreement that it's unambiguously software, even if it's also hardware under certain circumstances. We could ship it, if it were legal is not, in general, the same thing as if we shipped it, we could load it. Where these are equivalent, we're talking about something that's probably a component of our system. The social contract uses require, which is a stronger term than policy's depend. http://dictionary.reference.com/search?q=require I possibly didn't make that clear. depend, when used by policy, refers to dependencies that are expressed by the package management system. The social contract specifies policy, not the other way around. We will never make the system require the use of a non-free component. While it's clear from context that non-free refers to non-free software, it's also clear that it's components which are what need to be free. It's also clear from contenxt that components are components of the debian system. No, that doesn't make sense. If that was what it meant, it would just be a restatement of the second sentence (We promise that the Debian system and all its components will be free according to these guidelines). I agree. The difference is subjunctive. Since we've already promised that all the components in Debian will be free, then the non-free components it's referring to must be outside Debian. It's pretty clear to me that the point of this sentence is to make it clear that moving a package outside of debian does not allow us to ignore the dependency. If it makes sense to consider something as a component of our system, that's good enough. Among other things, you're arguing that hardware [including software embedded in that hardware] is a component of the debian system (rather than being a part of its infrastructure). I can probably be convinced that hardware in the traditional sense (something that's made out of gates and stuff) is not a component in the way that the social contract refers to. I see no way of arguing that for stuff that is plainly code. Then you would argue, for example, that we shouldn't remove the tcp stack because ip routers and switches use non-free software? Or maybe you also draw boundaries around what is the system and what's outside the system? -- Raul
Re: non-free firmware: driver in main or contrib?
On Thu, Oct 28, 2004 at 12:33:59PM +0100, Matthew Garrett wrote: Glenn Maynard [EMAIL PROTECTED] wrote: On Thu, Oct 28, 2004 at 12:33:38AM +0100, Matthew Garrett wrote: That would require certain parts of d-i (and hence certain parts of main) to rely upon the contents of contrib. We can't do that. No, I believe that would create a Suggests-style relationship, not a Depends, since d-i would still work without it (for many people). Packages in main can Suggest packages not in main. d-i is modular. The module that provided that functionality would be likely to do little of any use without the presence of contrib. So, libdvdread3 making use of libdvdcss by having libdvdread.so.3 dynamically open and use libdvdcss.so if it's there is OK; but if the code that did this was itself in a small stub module (dvdread3 opening /usr/lib/dvdread/libdvdcss-loader.so), that stub module would have to have its own package in contrib. You're saying that, since d-i doesn't have a monolithic design, it isn't allowed to support anything outside of main at all. -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Does anyone know if it is possible to obtain an IDE disc drive that contains no non-free software, I do not believe that this is possible. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Yes, Marco. We all understand the model you propose, based around the idea all firmware is essentially hardware, even if it's clearly a file that has to be there on disk for a driver to function. An Now it's quite clear that you did not understand at all what I have been proposing for months now, because I have never believed what you write here. No wonder this conversation has felt like it's going no where. What did you expect to achieve by asking endlessly circular socratic questions and disbelieving the answers? (BTW, please stop sending me copies of every mail, even if you never managed to read the debian document which asks to not do this it should be obvious by now that I read this list.) I only pull @debian.org addresses by default. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED] writes: Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Yes, Marco. We all understand the model you propose, based around the idea all firmware is essentially hardware, even if it's clearly a file that has to be there on disk for a driver to function. An equally valid model has been proposed around the idea that all software is software, and anything that can't be touched from software is hardware. Two issues: 1) The social contract doesn't give us any leeway here. There's no way to claim that hardware doesn't have to conform to the DFSG, and there's no way to claim that large parts of Debian don't require that hardware. Sure it does. The Debian Free Software Guidelines only apply to software. Hardware is hard, not soft. 2) The contents of an eeprom can generally be touched from software. You need a firmer basis for your line. That... requires some thought. I don't mean to say that *all* drivers for firmware-using devices must go in contrib. Merely that those drivers which Depend, in the policy sense, on non-free software must go in contrib, and that any loadable firmware is software. Whether it's a Dependency depends on the individual case -- a device that ignores its firmware isn't a dependency, a driver that can drive prelaoded devices is a Suggestion, and so on. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett wrote: It is certainly the case that I would like our users to be able to use their computers regardless of the mechanism that the vendor uses to ship firmware, yes. Remember that we don't ship contrib as part of the installer, either. Thanks to the excellent work of the installer team, debian-installer is incredibly modular. Surely someone could add hooks to load modules from contrib (only if the autodetected devices need them, and prompting first), either downloaded from the network or supplied on some physical medium? You seem to be advocating an ideological compromise solution for what sounds more like a technical problem. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote: In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. Really? Which part of policy states this? It's very interesting how quickly people who fail badly at backing their arguments on principle fall back to using Policy as a stick--despite the fact that the governing document here is the Social Contract, which I should hope still takes precedence over policy ... I explained my principles at the beginning of the discussion, and I do not feel the need to state them again because they are not relevant here: even if some people like to use it to invent new rules they think should be applied to debian, debian-legal is not the right place to update or augment the policy and social contract. I refer to policy because it's the document which explains how the SC should be applied, if it fails this job then it has bugs and you are encouraged to point them out. (I'm obviously happy to see you resorting to ad hominems as it probably means you have no more arguments.) -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote: I explained my principles at the beginning of the discussion, and I do not feel the need to state them again because they are not relevant here: How about something that is relevant, then? If that's not possible, maybe you don't want to post here? -- Raul
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote: I explained my principles at the beginning of the discussion, and I do not feel the need to state them again because they are not relevant here: How about something that is relevant, then? If that's not possible, maybe you don't want to post here? You too have no more arguments? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: This is the wrong mailing list for that sort of proposal. On Tue, Oct 26, 2004 at 08:32:47PM +0100, Matthew Garrett wrote: That's why I'm not actively proposing it here. Brian asked me a question, and I answered it. In that case, perhaps you should take your discussion elsewhere? Correct me if I'm wrong, but it doesn't seem like you can usefully resolve the point you want to discuss through discussions on this mailing list. Indeed. I'm not expecting to change people's minds here - I'm just pointing out that many of the arguments used to justify this decision process are flawed. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Josh Triplett [EMAIL PROTECTED] wrote: Matthew Garrett wrote: It is certainly the case that I would like our users to be able to use their computers regardless of the mechanism that the vendor uses to ship firmware, yes. Remember that we don't ship contrib as part of the installer, either. Thanks to the excellent work of the installer team, debian-installer is incredibly modular. Surely someone could add hooks to load modules from contrib (only if the autodetected devices need them, and prompting first), either downloaded from the network or supplied on some physical medium? You seem to be advocating an ideological compromise solution for what sounds more like a technical problem. We could do that, but it couldn't reasonably form part of the standard debian-installer. A forked d-i doesn't do anyone any favours. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett wrote: Josh Triplett [EMAIL PROTECTED] wrote: Matthew Garrett wrote: It is certainly the case that I would like our users to be able to use their computers regardless of the mechanism that the vendor uses to ship firmware, yes. Remember that we don't ship contrib as part of the installer, either. Thanks to the excellent work of the installer team, debian-installer is incredibly modular. Surely someone could add hooks to load modules from contrib (only if the autodetected devices need them, and prompting first), either downloaded from the network or supplied on some physical medium? You seem to be advocating an ideological compromise solution for what sounds more like a technical problem. We could do that, but it couldn't reasonably form part of the standard debian-installer. A forked d-i doesn't do anyone any favours. I don't see why we couldn't put support for using contrib udebs for things such as drivers in the standard d-i. The contrib udebs would need to be in the contrib archive, and they obviously couldn't go on the standard CD, but they could be downloaded if needed (again, only if the user assents to their use), or installed from a secondary CD or one of the various other media that d-i can read from. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: non-free firmware: driver in main or contrib?
On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote: (I'm obviously happy to see you resorting to ad hominems as it probably means you have no more arguments.) You're the one trying to convince people of a new position (that non-free dependencies in main are acceptable), so you're the one giving arguments; I'm among those giving counterarguments. So, unless you have further arguments, there's nothing more for me to respond to. The SC is very clear: no non-free requirements--if you want to try to change the SC, go for it. -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
Josh Triplett [EMAIL PROTECTED] wrote: Matthew Garrett wrote: We could do that, but it couldn't reasonably form part of the standard debian-installer. A forked d-i doesn't do anyone any favours. I don't see why we couldn't put support for using contrib udebs for things such as drivers in the standard d-i. The contrib udebs would need to be in the contrib archive, and they obviously couldn't go on the standard CD, but they could be downloaded if needed (again, only if the user assents to their use), or installed from a secondary CD or one of the various other media that d-i can read from. That would require certain parts of d-i (and hence certain parts of main) to rely upon the contents of contrib. We can't do that. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett wrote: Josh Triplett [EMAIL PROTECTED] wrote: Matthew Garrett wrote: We could do that, but it couldn't reasonably form part of the standard debian-installer. A forked d-i doesn't do anyone any favours. I don't see why we couldn't put support for using contrib udebs for things such as drivers in the standard d-i. The contrib udebs would need to be in the contrib archive, and they obviously couldn't go on the standard CD, but they could be downloaded if needed (again, only if the user assents to their use), or installed from a secondary CD or one of the various other media that d-i can read from. That would require certain parts of d-i (and hence certain parts of main) to rely upon the contents of contrib. We can't do that. I don't see how adding support for handling contrib udebs would actually create a dependency; it just makes it possible to install them if desired. This seems similar to the idea that apt supports loading packages from main, contrib, and non-free; it doesn't rely on any particular package in any of them. The sum total of the necessary support would be: 1) support to load udebs from main, contrib, or even non-free, with prompts for anything other than main, and either 2a) a generic prompt to say should I load udebs from contrib, in which case it loads the packages before probing devices, or 2b) a mapping from detected devices to drivers and from drivers to packages, whether in contrib or main. (Much of this already exists.) None of that seems like it actually depends on anything in contrib. For comparison, base-config used to ask users if they wanted to use contrib and/or non-free packages; it was not necessarily a good idea to do this, but I don't think it created a dependency from main to contrib/non-free. As long as we are going to include support for contrib and non-free packages, it seems consistent to offer the option of using them in the installer. - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: non-free firmware: driver in main or contrib?
On Wed, Oct 27, 2004 at 05:36:36PM -0700, Josh Triplett wrote: I don't see how adding support for handling contrib udebs would actually create a dependency; it just makes it possible to install them if desired. It doesn't create the dependency -- it just forces us to recognize their contents as software. The dependency comes in where the driver won't produce useful results without loading the firmware. The details of how this dependency exists are different from a command line invocation or a shared library reference or an interpreted script requirement, but that's an architectural issue, not a package management issue. -- Raul
Re: non-free firmware: driver in main or contrib?
On Thu, Oct 28, 2004 at 12:33:38AM +0100, Matthew Garrett wrote: That would require certain parts of d-i (and hence certain parts of main) to rely upon the contents of contrib. We can't do that. No, I believe that would create a Suggests-style relationship, not a Depends, since d-i would still work without it (for many people). Packages in main can Suggest packages not in main. -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote: That doesn't really change the fact that drivers that only work after pointing it at a non-free data block have a non-free dependency, and belong in contrib, though. The driver operates as designed regardless of what is in the firmware array, file, EEPROM, etc. The device does not. For me, the explicit interface between peripheral and CPU makes the distinction clear. Firmware not found is operating as designed, but I don't think that qualifies as the driver being functional, any more than cannot open shared object file: No such file or directory. If libdvdread3 required libdvdcss, saying dlopen failed: libdvdcss.so not found, giving up if it's missing, it's just as functional as the driver that can't bootstrap any devices without firmware; both are contrib. Instead, it still works, as long as you're not dealing with encrypted data--analogous to a driver that works with some hardware (eg. EPROM devices with the expected version) and not others, and can go in main. Drawing the line elsewhere seems to lead to a place where we forbid P6/K7/etc.-targeted binaries (optimized programs or CPU-specific kernels) from being in main because they require non-free microcode. There are three general cases: ROM, EPROM and RAM. ROM works on its own, can't be changed and there's no firmware block; EPROM works on its own[1], and you can optionally have the firmware on the drive to upload; and RAM needs the firmware file to work at all.[2] So, there are a few places where a line can be drawn. I think that both ROM and EPROM act like hardware, and should be treated as such, but that the RAM case acts like software--you have to read it from a file and send it to the device. My understanding is that the entire purpose of contrib is for this case: programs that don't do anything useful unless you plug in some non-free piece. [1] If a device has an EPROM, but the contents are never usable by the driver and it always needs to upload a firmware, it's effectively in the RAM case: the EPROM becomes irrelevant. [2] I'm overgeneralizing, of course, ignoring cases like EPROM but flashed with an incompatible firmware version (irrelevant here, as long as devices do exist with the correct version) and RAM uploaded from the from the driver, or falling back on ROM (seems to fall in the EPROM case). -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
Ken Arromdee wrote: On Mon, 25 Oct 2004, Josh Triplett wrote: However, suppose that your statement were true. Why stop there? Consider the case of a piece of hardware which could not be initialized correctly except by the Windows driver. In order for the device to work, a user would need to boot up Windows, allow the driver to initialize the device, and soft-boot into GNU/Linux, at which point the driver could control the device. Also suppose that the Windows driver was shipped on the manufacturer's CD, so the user already has it (which is almost always the case). Repeat after me: Drivers don't require initialization, hardware devices require initialization. :) So why can't this driver go in main too? I would disqualify that driver from main not because it depended on a Windows driver, but because it depended on having Windows itself. Unlike the I see; so some dependencies on non-free software are to be considered acceptable, while others are not? hardware/eprom and hardware/CD combinations, hardware/Windows isn't sold together and the user would have to get Windows separately--not because he And in many cases, the user would need to get the firmware for a device separately. Not all drivers that require firmware images provide the means to extract it from a manufacturer's CD; some choose to extract it from updates provided on the manufacturer's website, or from Windows drivers obtained separately, or downloaded from the Linux driver author's site. Some firmware images have even been sniffed off of a bus during the reverse engineering used to create the Linux driver. lost a CD that he once had, but because Windows really is a separate item in more ways than just physically being on a different disk. And what of my second suggested case (which you omitted in your reply), where the Linux driver could load the necessary piece of the Windows driver without needing Windows? Would you permit that driver to go in main, since it would only require the Windows driver and not Windows itself? Your argument seems to suggest that you would. For another example, suppose there were a new, proprietary 3D graphics interface, ClosedGL, only implemented by ATI's and nVidia's proprietary driver. Suppose someone wanted to package a game that used ClosedGL. Repeat after me: Programs don't require drivers, hardware devices require drivers (to provide APIs). :) So by your arguments, why can't this game go in main? You may as well claim that a hard drive is a piece of hardware which does word processing, that a word processor is a driver for this piece of hardware, and that without this driver you lose some functionality because the hard drive won't process words. The flaw in this reasoning is that a hard drive or a graphics card is a general purpose piece of equipment. The driver isn't a driver. Many hardware devices are also general-purpose pieces of equipment, using general-purpose processors, whose firmware is just software compiled for that architecture. The point of firmware is generally to make a piece of hardware less hard-wired and more reparable, which is to some extent a step in the direction of general-purpose. Yet just as the driver requires a certain method of talking to the firmware, the game requires a certain way of talking to the driver, which requires that whether the low-level component has a general-purpose device to work with or not, it must provide a certain interface to those components at a higher level than itself. It seems to me that your arguments for including drivers in main that require other non-free software are extremely fuzzy and involve criteria (like general purpose or not because it depended on a Windows driver, but because it depended on having Windows itself) that seem to have no relation to actual Debian policy and/or the Social Contract. On the other hand, the arguments for _not_ including such drivers in main are trivially explainable with one simple test: can someone with the necessary hardware, having only main in their sources.list, and without installing any non-Debian software, build, install, and successfully run the package? If they can, the software should go to main. If not, it should go to contrib. Finally, I'm curious: what is it that makes people so adamant that these drivers should be in main, rather than contrib? You and others have mentioned various practical arguments, but none related to freedom. Furthermore, even if practical arguments were allowed to trump freedom, I don't see any practical arguments against putting the drivers in contrib that could not be solved with a suitable technical solution. What is the reason that you fight so hard to include such items in main? - Josh Triplett signature.asc Description: OpenPGP digital signature
Re: non-free firmware: driver in main or contrib
On Mon, 25 Oct 2004, Josh Triplett wrote: I would disqualify that driver from main not because it depended on a Windows driver, but because it depended on having Windows itself. I see; so some dependencies on non-free software are to be considered acceptable, while others are not? I meant dependency in the same sense that a driver might depend on there being something in an eprom or other replaceable part. If you agree that that's dependency, then yes some dependencies on non-free software are acceptable. hardware/eprom and hardware/CD combinations, hardware/Windows isn't sold together and the user would have to get Windows separately--not because he And in many cases, the user would need to get the firmware for a device separately. Not all drivers that require firmware images provide the means to extract it from a manufacturer's CD; some choose to extract it from updates provided on the manufacturer's website, or from Windows drivers obtained separately, or downloaded from the Linux driver author's site. Some firmware images have even been sniffed off of a bus during the reverse engineering used to create the Linux driver. I think that this is a good place to stick to the spirit of the rules. If anyone with the hardware can get the firmware under restrictions no worse than if it was physically part of the hardware, then treat it as if it was physically part of the hardware. And what of my second suggested case (which you omitted in your reply), where the Linux driver could load the necessary piece of the Windows driver without needing Windows? Would you permit that driver to go in main, since it would only require the Windows driver and not Windows itself? Your argument seems to suggest that you would. It would only suggest this if hardware+Windows driver gives the user the same rights as hardware+eprom would. I think this is unlikely to be the case. Many hardware devices are also general-purpose pieces of equipment, using general-purpose processors, whose firmware is just software compiled for that architecture. The point of firmware is generally to make a piece of hardware less hard-wired and more reparable, which is to some extent a step in the direction of general-purpose. In other words, whether or not the device is general-purpose enough that something uploaded to it should be treated as part of the device is a judgment call. Yes, that is true. On the other hand, the arguments for _not_ including such drivers in main are trivially explainable with one simple test: can someone with the necessary hardware, having only main in their sources.list, and without installing any non-Debian software, build, install, and successfully run the package? Those requirements are assuming the conclusion. The question is about how to treat software in comparison to hardware. That list of requirements specifies that hardware and software should be treated differently and thus assumes a particular answer to the question. Finally, I'm curious: what is it that makes people so adamant that these drivers should be in main, rather than contrib? You and others have mentioned various practical arguments, but none related to freedom. The argument it's as free as this other thing, which you consider free enough *is* about freedom.
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Heck, for all I know there's a device out there where the firmware on disk is verilog code, and it's compiled by the driver and loaded to an FPGA on the device. Surely that's software. I'm not so sure that an FPGA design is software (for sane definitions of software). Why draw the line at software, then? Why not wish for open specs for all the chips, so you can modify the CPU or GPU? I do, don't you? But still this does not make it true, and I have to accept reality. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: While this is true, it is incomplete: the driver Depends, in the policy sense, on the device, and the device Depends on the firmware. I do not think policy can justify this. Obviously any kind of device driver has limited practical use[1] if you do not own the hardware device, and so are programs like ICQ and AIM clients if you do not have access to the proprietary servers they connect to, but still policy does not require to keep this kind of free software out of Debian. It's not just the proprietary server code, but the actual servers that are necessary. That is, you need the machines running them -- hardware, a black box outside Debian's control. So what? User's hardware is outside Debian control as well. Or you think that Debian should control user's hardware? This sounds a bit like DRM to me. I do think that closed-system clients don't belong in Debian (differentiating OSCAR, for example, from whatever the closed AIM protocol of the week is -- I don't follow technical developments there very closely.) You are entitled to your opinions however stupid they are, but they are off topic in the context of interpreting policy. [1] But it may be an invaluable source of code and ideas to use in other projects... That source of ideas is not enough to change a Depends to a Suggests, or we'd have nothing in contrib. I did not propose this. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote: Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. Then, how do you explain the ipw2200 case where driver version 0.5 and less will only work with a certain firmware and version 0.6 and more will only work with an other firmware ? Isn't that what we could call a requirement ? No, why? I can't see how this could be related to my argument. I'm telling you some drivers *do depend* on a certain firmware. You're still repeating the opposite. Now explain me how in ipw2200 case the driver doesn't *depend* on the firmware, since you seem to know the truth. You are using a different meaning of depend than the one used by policy. I can't see why it should matter if a device driver is designed to use features present in a specific firmware revision. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. The driver is opening a block of data on disk, reading it and sending it to the hardware. If that data does not exist, the driver will be incapable of driving the hardware. For the driver to work, in addition to installing it and the hardware device, you have to find and install a copy of the firmware to where the driver expects to find it. No, this is not correct. If the firmware is not loaded the hardware device will not provide some features, but the driver is still capable to use them, if they were available. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. Really? Which part of policy states this? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Heck, for all I know there's a device out there where the firmware on disk is verilog code, and it's compiled by the driver and loaded to an FPGA on the device. Surely that's software. I'm not so sure that an FPGA design is software (for sane definitions of software). Then there's no point continuing this conversation. An FPGA design, living as a file on disk and possibly even shipped by Debian is clearly software under Debian's definitions. Runtime-loaded firmware is clearly software for the same reasons. If you don't believe one, it's no surprise you won't believe the other -- but since Debian clearly disagrees with you on one, it's no surprise you're in disagreement on the other. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Yes, Marco. We all understand the model you propose, based around the idea all firmware is essentially hardware, even if it's clearly a file that has to be there on disk for a driver to function. An equally valid model has been proposed around the idea that all software is software, and anything that can't be touched from software is hardware. I think you need to not so much convince others your model is the sole right model as that it is a more attractive model, in a free software sense, than theirs. So far, your ranting and insults have done little to convince me. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 12:23:43PM +0200, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: I'm telling you some drivers *do depend* on a certain firmware. You're still repeating the opposite. Now explain me how in ipw2200 case the driver doesn't *depend* on the firmware, since you seem to know the truth. You are using a different meaning of depend than the one used by policy. I can't see why it should matter if a device driver is designed to use features present in a specific firmware revision. Let's port this sentence into an other context. I can't see why it should matter if a program is designed to use features present in a specific library revision Mike
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Yes, Marco. We all understand the model you propose, based around the idea all firmware is essentially hardware, even if it's clearly a file that has to be there on disk for a driver to function. An equally valid model has been proposed around the idea that all software is software, and anything that can't be touched from software is hardware. Two issues: 1) The social contract doesn't give us any leeway here. There's no way to claim that hardware doesn't have to conform to the DFSG, and there's no way to claim that large parts of Debian don't require that hardware. 2) The contents of an eeprom can generally be touched from software. You need a firmer basis for your line. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Glenn Maynard writes: On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote: That doesn't really change the fact that drivers that only work after pointing it at a non-free data block have a non-free dependency, and belong in contrib, though. The driver operates as designed regardless of what is in the firmware array, file, EEPROM, etc. The device does not. For me, the explicit interface between peripheral and CPU makes the distinction clear. Firmware not found is operating as designed, but I don't think that qualifies as the driver being functional, any more than cannot open shared object file: No such file or directory. Not at all. If you fill the block with random data, the driver will continue to do what you expect and what you can follow by reading its source code. It is the device that will not perform and that will not live up to its end of the interface. That is why I referred earlier to a hypothetical device that ignored the firmware you send to it. Michael Poole
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: It's different because, when the firmware is built into the device, the person who has the device has the firmware. Note that this difference is similar in character to the difference between main and contrib. How? Main is free software that doesn't require non-free code. Contrib is free software that does require non-free code. Note that the social contract does not use the word depends. Code goes in contrib if it requires non-free code regardless of whether or not that is expressed as a dependency in the package management sense. All of the hardware under discussion requires non-free code. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: It's different because, when the firmware is built into the device, the person who has the device has the firmware. Note that this difference is similar in character to the difference between main and contrib. On Tue, Oct 26, 2004 at 01:39:03PM +0100, Matthew Garrett wrote: How? Main is free software that doesn't require non-free code. Contrib is free software that does require non-free code. I said similar, not identical. The difference I was referring to was the difference of convenience -- using software from contrib requires a few extra steps. Similarly, using an external copy of firmware requires a few extra steps. Note that the social contract does not use the word depends. It uses require, which is close enough. Code goes in contrib if it requires non-free code regardless of whether or not that is expressed as a dependency in the package management sense. Agreed -- though obviously the package management sense is intended to represent a similar concept. [A different kind of similarity from the one I mentioned above.] All of the hardware under discussion requires non-free code. That's one way of looking at it. From within a framework of thought that looks at the issue that way: where meeting the hardware's non-free code requirements is totally out of our control, we don't do anything about the issue. Similarly, we distribute web browsers which visit servers where those servers require non-free code. For the cases where those servers are totally out of our control, we don't do anything about that issue. -- Raul
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote: Really? Which part of policy states this? Historical practice. -- Raul
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: Raul Miller [EMAIL PROTECTED] wrote: Note that this difference is similar in character to the difference between main and contrib. On Tue, Oct 26, 2004 at 01:39:03PM +0100, Matthew Garrett wrote: How? Main is free software that doesn't require non-free code. Contrib is free software that does require non-free code. I said similar, not identical. The difference I was referring to was the difference of convenience -- using software from contrib requires a few extra steps. Similarly, using an external copy of firmware requires a few extra steps. The contrib distinction is nothing to do with convenience - it's to do with segregation of free material from material with non-free dependencies. We do this because we are a free software distribution. You might as well claim that the difference is similar in character between Debian and Ubuntu - an installation of Debian requires a few extra steps to get X configured. It's true, but it's not useful. Note that the social contract does not use the word depends. It uses require, which is close enough. No. Depends has a very specific meaning within Debian. All dependecies are requirements - not all requirements are dependencies. All of the hardware under discussion requires non-free code. That's one way of looking at it. From within a framework of thought that looks at the issue that way: where meeting the hardware's non-free code requirements is totally out of our control, we don't do anything about the issue. That's a viewpoint that isn't enshrined in policy or the social contract. Point 1 of the social contract is quite clear that we can't distribute material in main if it requires non-free components. The firmware in these devices is non-free. The logical conclusion is that we can't ship any driver that requires non-free frimware, regardless of whether this is in ROM or on CD. The other logical conclusion is that the social contract is buggy and needs fixing. The benefit of hindsight, eh? Similarly, we distribute web browsers which visit servers where those servers require non-free code. For the cases where those servers are totally out of our control, we don't do anything about that issue. Browsers do not require non-free code - they are merely able to make use of it. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote: Really? Which part of policy states this? Historical practice. Historical practice allowed non-free material that wasn't code into main. We argued that this was not allowed under the social contract and the DFSG, and in the end people were forced to agree. I am now arguing that the social contract gives us no right to engage in this form of historical practice - given the current wording of the social contract, I think you'll find it difficult to argue otherwise. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Michael Poole [EMAIL PROTECTED] writes: Not at all. If you fill the block with random data, the driver will continue to do what you expect and what you can follow by reading its source code. It is the device that will not perform and that will not live up to its end of the interface. That is why I referred earlier to a hypothetical device that ignored the firmware you send to it. So if I have a program which loads a library, and replace the library with random data, the program will continue to do what I expect and what I can follow by reading its source. It is the library that will not perform, not living up to its end of the interface? Your arguments seem to lack an internal consistency. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED] writes: main. We argued that this was not allowed under the social contract and the DFSG, and in the end people were forced to agree. I am now arguing that the social contract gives us no right to engage in this form of historical practice - given the current wording of the social contract, I think you'll find it difficult to argue otherwise. OK. What course of action do you advocate? So far I hear you telling other people they're wrong -- useful if they are, not so useful if they're the least wrong of all possible arguments -- but I haven't heard what you'd like to do about the firmware issue. -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: OK. What course of action do you advocate? So far I hear you telling other people they're wrong -- useful if they are, not so useful if they're the least wrong of all possible arguments -- but I haven't heard what you'd like to do about the firmware issue. Modify the social contract to create a new section that would be distributed alongside main, and put the firmware in there. This doesn't compromise our desire to keep main free of non-free material, and nor does it result in us being unable to support vast swathes of users. Whatever solution we adopt (other than throwing every driver that uses any hardware containing non-free code out of main) requires altering the social contract. I see no harm in choosing the course of action that does most to benefit our users and doesn't cause any increase in the amount of non-free code on someone's machine. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen writes: Michael Poole [EMAIL PROTECTED] writes: Not at all. If you fill the block with random data, the driver will continue to do what you expect and what you can follow by reading its source code. It is the device that will not perform and that will not live up to its end of the interface. That is why I referred earlier to a hypothetical device that ignored the firmware you send to it. So if I have a program which loads a library, and replace the library with random data, the program will continue to do what I expect and what I can follow by reading its source. It is the library that will not perform, not living up to its end of the interface? The driver does not call to or use the firmware. It uses the device. This is not at all the same as the loadable library case. In my day job, I work on a device driver that can talk to a device programmed using several different firmwares. Other drivers I have worked on can downloaded firmware but the boards also have EEPROMs that hold default firmwares. Importantly, the drivers do not behave differently based on whether the default firmware or any of several custom firmwares are used; the differing behavior is of interest to the application, not the driver. Your arguments seem to lack an internal consistency. By demanding that some hardware components of a system be free, while exempting other hardware from the same requirement, your arguments are the ones that seem to lack consistency. Michael Poole
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: I said similar, not identical. The difference I was referring to was the difference of convenience -- using software from contrib requires a few extra steps. Similarly, using an external copy of firmware requires a few extra steps. On Tue, Oct 26, 2004 at 02:52:28PM +0100, Matthew Garrett wrote: The contrib distinction is nothing to do with convenience Ok, so contrib is just as convenient as main, for everyone. - it's to do with segregation of free material from material with non-free dependencies. We do this because we are a free software distribution. You might as well claim that the difference is similar in character between Debian and Ubuntu - an installation of Debian requires a few extra steps to get X configured. It's true, but it's not useful. I agree that the purpose for having contrib is so that we can easily distinguish between software which we have depend on non-free software and software where we don't have such dependencies. Note that the social contract does not use the word depends. It uses require, which is close enough. No. Depends has a very specific meaning within Debian. All dependecies are requirements - not all requirements are dependencies. Depends: has a very specific meaning within Debian. This doesn't mean that depends loses all other meaning within Debian. All of the hardware under discussion requires non-free code. That's one way of looking at it. From within a framework of thought that looks at the issue that way: where meeting the hardware's non-free code requirements is totally out of our control, we don't do anything about the issue. That's a viewpoint that isn't enshrined in policy or the social contract. True, in the sense that it's an informal point of view, and not a sacred one. However, the question is really one of scope. For example, all known instances of the x86 architecture require non-free code in their manufacture. We consider those requirements to be outside the scope of Debian. Point 1 of the social contract is quite clear that we can't distribute material in main if it requires non-free components. The firmware in these devices is non-free. The logical conclusion is that we can't ship any driver that requires non-free frimware, regardless of whether this is in ROM or on CD. The problem with logic is that when you feed it garbage you get garbage results. Alternatively, you can treat the presence of garbage results as an indication that your data is garbage. Since your claim is equivalent to claiming that Debian should distribute nothing in main, I'm going to treat your fundamental assertions as garbage. This is not a criticism of your person, I just don't see any positive benefit in what you are currently advocating. The other logical conclusion is that the social contract is buggy and needs fixing. The benefit of hindsight, eh? [1] Fixing the social contract is outside the scope of debian-legal. [2] In the context of debian-legal, the spirit of the social contract is the issue, not some narrow technical reading. [3] The social contract is written in english, which means that there will always be ambiguous interpretations which conflict with what we want. Similarly, we distribute web browsers which visit servers where those servers require non-free code. For the cases where those servers are totally out of our control, we don't do anything about that issue. Browsers do not require non-free code - they are merely able to make use of it. That's a valid point. That is, it's valid as long as you limit your scope of consideration to so that you're ignoring non-free code in the design, manufacture or support of the systems needed for the typical operation of that browser. [For example, non-free code at internet routers and switches.] -- Raul
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Then there's no point continuing this conversation. An FPGA design, living as a file on disk and possibly even shipped by Debian is clearly software under Debian's definitions. Runtime-loaded firmware I was not discussing Debian's definitions now. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. Really? Which part of policy states this? Historical practice. OK, thank you for confirming that this has no foundation in the policy. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: I'm telling you some drivers *do depend* on a certain firmware. You're still repeating the opposite. Now explain me how in ipw2200 case the driver doesn't *depend* on the firmware, since you seem to know the truth. You are using a different meaning of depend than the one used by policy. I can't see why it should matter if a device driver is designed to use features present in a specific firmware revision. Let's port this sentence into an other context. I can't see why it should matter if a program is designed to use features present in a specific library revision So? What is your point? -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Yes, Marco. We all understand the model you propose, based around the idea all firmware is essentially hardware, even if it's clearly a file that has to be there on disk for a driver to function. An Now it's quite clear that you did not understand at all what I have been proposing for months now, because I have never believed what you write here. (BTW, please stop sending me copies of every mail, even if you never managed to read the debian document which asks to not do this it should be obvious by now that I read this list.) -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen writes: So if I have a program which loads a library, and replace the library with random data, the program will continue to do what I expect and what I can follow by reading its source. It is the library that will not perform, not living up to its end of the interface? On Tue, Oct 26, 2004 at 11:33:21AM -0400, Michael Poole wrote: The driver does not call to or use the firmware. It uses the device. This is not at all the same as the loadable library case. In cases where the driver doesn't function without the proper action of the firmware loader, it's pretty clear that the driver depends on the firmware loader. If the firmware loader is in contrib, then the driver should be in contrib, too. In my day job, I work on a device driver that can talk to a device programmed using several different firmwares. Other drivers I have worked on can downloaded firmware but the boards also have EEPROMs that hold default firmwares. Importantly, the drivers do not behave differently based on whether the default firmware or any of several custom firmwares are used; the differing behavior is of interest to the application, not the driver. This sounds like a fairly well designed (and somewhat transparent) interface. That said, it sounds like the drivers do behave differently depending on the firmware -- you've asserted that the difference is not of interest to the driver, but that's not at all the same as asserting that there is no difference. Your arguments seem to lack an internal consistency. By demanding that some hardware components of a system be free, while exempting other hardware from the same requirement, your arguments are the ones that seem to lack consistency. The requirement is not that the hardware be free. The requirement is that the software be free, and that it not have dependencies on non-free software. It should be clear (even if you don't think it makes sense) that currently we make a distinction between things we deal with as if they are software and things which we deal with as if they are not software? If that's not clear, I suppose we could go over the basics again. If that's clear, but you think that something else makes more sense, maybe you could talk about what the consequences of your point of view would be on Debian? Changes which advance our goals are good things. -- Raul
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED] wrote: OK. What course of action do you advocate? On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote: Modify the social contract to create a new section that would be distributed alongside main, and put the firmware in there. This is the wrong mailing list for that sort of proposal. Debian-project is probably a better list for that discussion. Or, if you feel that you've sorted out most of the views which are important to other developers, debian-vote. But, please realise that there will be other people focussing on other issues who will interpret what you say in some fashion which is radically different from the way you're thinking about it. And, I think that you'll need to place some attention on slippery slope issues, before a proposal to add a new component of debian that's not really free section has any chance at all of getting accepted. Personally, I'm more than a little dubious of the concept -- the role of your proposed new section seems to be exactly the same role as non-free. Except -- rather than being a convenience for some of our web-connected users, you want it to have the operational status as main. -- Raul
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote: Brian Thomas Sniffen [EMAIL PROTECTED] wrote: OK. What course of action do you advocate? So far I hear you telling other people they're wrong -- useful if they are, not so useful if they're the least wrong of all possible arguments -- but I haven't heard what you'd like to do about the firmware issue. Modify the social contract to create a new section that would be distributed alongside main, and put the firmware in there. This doesn't compromise our desire to keep main free of non-free material, and nor does it result in us being unable to support vast swathes of users. 'Main' is what we ship. Splitting it into two parts and calling one part something else does not make it any different. If you're going to try to amend the social contract, you might as well amend itto allow non-free firmware into main (after satisfactorily defining 'firmware', of course). --Adam
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 11:51:22AM +0100, Matthew Garrett wrote: 1) The social contract doesn't give us any leeway here. There's no way to claim that hardware doesn't have to conform to the DFSG The S in DFSG stands for Software, so I don't see how you would get that it applies to hardware. Perhaps what we are discussing is the fuzzy line between hardware and software, but the problem lies in defining what is hardware or software, not in trying to apply the DFSG to hardware. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. Really? Which part of policy states this? [EMAIL PROTECTED] wrote: Historical practice. On Tue, Oct 26, 2004 at 06:07:28PM +0200, Marco d'Itri wrote: OK, thank you for confirming that this has no foundation in the policy. Where there is no explicit policy in either direction on some issue, good technical judgement and consensus, which historical practice generally represents, is the best foundation for future policies. -- Raul
Re: non-free firmware: driver in main or contrib
Ken Arromdee wrote: On Mon, 25 Oct 2004, Josh Triplett wrote: I would disqualify that driver from main not because it depended on a Windows driver, but because it depended on having Windows itself. I see; so some dependencies on non-free software are to be considered acceptable, while others are not? I meant dependency in the same sense that a driver might depend on there being something in an eprom or other replaceable part. If you agree that that's dependency, then yes some dependencies on non-free software are acceptable. That's an interesting way of evading the question; you never actually said why you thought it was OK to depend on a Windows driver, but not to depend on Windows. Both are non-free, and neither is in our archive. Yes, a driver does depend on something in an eprom on a hardware device, but as that something is part of the hardware, and Debian doesn't consider dependencies on hardware, then we don't express it; it isn't a dependency on non-free software, it's a dependency on hardware. On the other hand, a dependency on a software item, such as Windows, a Windows driver, or a firmware image, must be taken into account. hardware/eprom and hardware/CD combinations, hardware/Windows isn't sold together and the user would have to get Windows separately--not because he And in many cases, the user would need to get the firmware for a device separately. Not all drivers that require firmware images provide the means to extract it from a manufacturer's CD; some choose to extract it from updates provided on the manufacturer's website, or from Windows drivers obtained separately, or downloaded from the Linux driver author's site. Some firmware images have even been sniffed off of a bus during the reverse engineering used to create the Linux driver. I think that this is a good place to stick to the spirit of the rules. If anyone with the hardware can get the firmware under restrictions no worse than if it was physically part of the hardware, then treat it as if it was physically part of the hardware. If we were following the spirit of the rules, I don't think we'd be having this discussion. It is well-known that we don't express dependencies on hardware. It is also well-known that some pieces of hardware are internally implemented using firmware. However, this does not mean that it is acceptable to And what of my second suggested case (which you omitted in your reply), where the Linux driver could load the necessary piece of the Windows driver without needing Windows? Would you permit that driver to go in main, since it would only require the Windows driver and not Windows itself? Your argument seems to suggest that you would. It would only suggest this if hardware+Windows driver gives the user the same rights as hardware+eprom would. I think this is unlikely to be the case. It seems to me that you have created a criteria to compare to that is specifically designed to support the one case you are interested in, that of dependencies on non-free firmware images that must be supplied by the user. Many hardware devices are also general-purpose pieces of equipment, using general-purpose processors, whose firmware is just software compiled for that architecture. The point of firmware is generally to make a piece of hardware less hard-wired and more reparable, which is to some extent a step in the direction of general-purpose. In other words, whether or not the device is general-purpose enough that something uploaded to it should be treated as part of the device is a judgment call. Yes, that is true. Or you could just say that things which are actually *part of the device* should be considered part of the device, and things which are not part of the device, such as separate firmware images supplied by the user, should not be considered part of the device. On the other hand, the arguments for _not_ including such drivers in main are trivially explainable with one simple test: can someone with the necessary hardware, having only main in their sources.list, and without installing any non-Debian software, build, install, and successfully run the package? Those requirements are assuming the conclusion. The question is about how to treat software in comparison to hardware. That list of requirements specifies that hardware and software should be treated differently and thus assumes a particular answer to the question. It is already generally accepted that Debian does not express dependencies on hardware, and that we do express dependencies on software. If you wish to change that, then you are arguing against the status quo, so the burden of proof for why we should do that is on you. I don't think you will find anyone in this discussion seriously advocating the position that we should treat hardware and software identically; that position would imply that since almost all hardware is non-free, all hardware-dependent pieces of Debian would need to be in
Re: non-free firmware: driver in main or contrib?
That said, it sounds like the drivers do behave differently depending on the firmware -- you've asserted that the difference is not of interest to the driver, but that's not at all the same as asserting that there is no difference. On Tue, Oct 26, 2004 at 01:47:06PM -0400, Michael Poole wrote: The drivers really do nothing differently based on the firmware[1]. In the sense that providing a -1 is no different from providing a 0, or in the sense that providing a 100k message is no different from providing an empty string, sure -- no difference at all. It's a matter of point of view. If that's clear, but you think that something else makes more sense, maybe you could talk about what the consequences of your point of view would be on Debian? Changes which advance our goals are good things. Drivers that talk to firmware-requiring devices would be allowed in main, rather than in kernel modules or patches kept outside Debian proper. The firmware files themselves would have to be provided by the user or in non-free, unless they qualify under the DFSG[2]. I believe this is the direction being taken for the Linux kernel in general (to not contain opaque blobs, but to provide a facility to load them when needed). And what are the consequences to Debian with this choice? In particular, what freedoms do you think it is acceptable for us to require of any opaque blobs that we would be distributing with main? Is it acceptable for us to require that reverse engineering be allowed of things we distribute with main? Is it acceptable for us to be able to ship updated copies when the changes come from someone with no legal approval from the original author of these opaque blobs? Is it acceptable for us to distribute opaque blobs which can only be used in educational settings, or which require registration before they can be unlocked? Are you saying that you want us to ship opaque blobs where we take no responsibility whatsoever for their character? Thanks, -- Raul
Re: non-free firmware: driver in main or contrib?
Raul Miller writes: That said, it sounds like the drivers do behave differently depending on the firmware -- you've asserted that the difference is not of interest to the driver, but that's not at all the same as asserting that there is no difference. On Tue, Oct 26, 2004 at 01:47:06PM -0400, Michael Poole wrote: The drivers really do nothing differently based on the firmware[1]. In the sense that providing a -1 is no different from providing a 0, or in the sense that providing a 100k message is no different from providing an empty string, sure -- no difference at all. It's a matter of point of view. I am quite certain that you have never worked with the drivers I was describing, and the chance you have worked with any of the boards is nearly zero. Your assumption that the differences are anything like you describe is baseless, and your inference that my description is so wrong is insulting. If that's clear, but you think that something else makes more sense, maybe you could talk about what the consequences of your point of view would be on Debian? Changes which advance our goals are good things. Drivers that talk to firmware-requiring devices would be allowed in main, rather than in kernel modules or patches kept outside Debian proper. The firmware files themselves would have to be provided by the user or in non-free, unless they qualify under the DFSG[2]. I believe this is the direction being taken for the Linux kernel in general (to not contain opaque blobs, but to provide a facility to load them when needed). And what are the consequences to Debian with this choice? It depends on whether you assume users can and will use contrib or non-free. If you assume that, I do not think it has significant impact, although it is likely to save the kernel packagers lots of work. If you assume users cannot or will not use contrib or non-free, it is the difference between users needing to supply firmware or both driver and firmware (and likely recompiling their kernel). In particular, what freedoms do you think it is acceptable for us to require of any opaque blobs that we would be distributing with main? My suggestion does not involve distributing opaque blobs with main. To repeat: THE FIRMWARE FILES THEMSELVES WOULD HAVE TO BE PROVIDED BY THE USER OR IN NON-FREE, UNLESS THEY QUALIFY UNDER THE DFSG. For example, some firmware blobs in the Linux kernel are the output of an assembler, and the assembly source is included in Linux. That kind of firmware blob is not opaque, and could be distributed in main. Is it acceptable for us to require that reverse engineering be allowed of things we distribute with main? Certainly, although I think everything in main should have something like source code, which would make reverse engineering pointless in most cases. Is it acceptable for us to be able to ship updated copies when the changes come from someone with no legal approval from the original author of these opaque blobs? I am not sure what you mean. The DFSG require that Debian (or third parties) be able to freely modify anything in main and distribute those modifications (possibly in the form of patches). Is it acceptable for us to distribute opaque blobs which can only be used in educational settings, or which require registration before they can be unlocked? You are pretty clearly acting trollish here. Are you saying that you want us to ship opaque blobs where we take no responsibility whatsoever for their character? I have said nothing of the sort. Would you like to apologize for being such a boorish insulting troll, or should I just write you off as someone not worth listening to? Michael Poole
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: On Mon, Oct 25, 2004 at 11:46:03PM +0100, Matthew Garrett wrote: I see nothing that suggests that non-free component is only meant to apply to material shipped by Debian. Nor is there any suggestion that it applies only to software (which is unsurprising, given the care taken to remove all reference to software). Do you really not see the references to Software in that quoted text? The Debian Free Software Guidelines are used to determine the freeness or otherwise of any component of the Debian system or anything that it relies upon. That was made clear in the discussion surrounding the GR that changed the wording. How do you claim that the social contract allows us to ship any drivers that require non-free firmware, even if they're on the PCB? In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. Where it suits us, we ignore the social contract. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote: In cases where firmware is basically indistinguishable from hardware, we treat it as hardware, and not as software. Really? Which part of policy states this? It's very interesting how quickly people who fail badly at backing their arguments on principle fall back to using Policy as a stick--despite the fact that the governing document here is the Social Contract, which I should hope still takes precedence over policy ... -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote: Modify the social contract to create a new section that would be distributed alongside main, and put the firmware in there. This is the wrong mailing list for that sort of proposal. That's why I'm not actively proposing it here. Brian asked me a question, and I answered it. Debian-project is probably a better list for that discussion. Or, if you feel that you've sorted out most of the views which are important to other developers, debian-vote. Indeed. After Sarge is released, I intend to spend some time on working this out properly. Personally, I'm more than a little dubious of the concept -- the role of your proposed new section seems to be exactly the same role as non-free. Except -- rather than being a convenience for some of our web-connected users, you want it to have the operational status as main. It is certainly the case that I would like our users to be able to use their computers regardless of the mechanism that the vendor uses to ship firmware, yes. Remember that we don't ship contrib as part of the installer, either. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Adam McKenna [EMAIL PROTECTED] wrote: 'Main' is what we ship. Splitting it into two parts and calling one part something else does not make it any different. If you're going to try to amend the social contract, you might as well amend itto allow non-free firmware into main (after satisfactorily defining 'firmware', of course). I think there's a difference, but as Raul said, this is not the place to have this discussion. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Glenn Maynard [EMAIL PROTECTED] wrote: The status quo, as I understand it, is that firmware which is uploaded from disk by a driver is a dependency, but firmware embedded in the hardware is treated as part of the hardware--that's certainly how it looks and acts to me, as a user. I believe this is consistent with the SC, though of course I don't claim it's the only rational way to interpret it. I think it's the only rational way to interpret it that's consistent with the discussion surrounding the GR. The entire point of changing the social contract was to make it clear that the DFSG were supposed to be used on everything that Debian shipped or required on, rather than it being limited to software. Marco's argument appears to be that drivers should be allowed in main that only function if they have access to a non-free firmware blob; that a driver that, lacking the file, merely bails and says download this non-free piece first should be allowed in main. I'm fairly unconcerned about Marco's argument. I think your interpretation is a rational one, but I havn't seen an argument of why it's a better one. It seems clear that this interpretation would almost no drivers at all, which makes it impractical. If a logical interpretation of the social contract results in an impractical situation and no practical situation can be reached without some contortions of logic, it implies that the social contract doesn't say what we mean it to say and should be changed. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Don Armstrong [EMAIL PROTECTED] wrote: So your argument is, in effect, that because we can't ship DFSG Free computers (I mean, the system requires them after all) then we should just give up and go home? Or are you trying to say that because we can't satisfy SC 1 for hardware, we should also ignore it for software? No. My argument is that the social contract is unclear and should be altered. A strict interpretation of it implies that we can't produce a useful operating system - since Debian exists in order to provide a useful operating system, we need to change that implication. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 08:41:02PM +0100, Matthew Garrett wrote: I think it's the only rational way to interpret it that's consistent with the discussion surrounding the GR. The entire point of changing the social contract was to make it clear that the DFSG were supposed to be used on everything that Debian shipped or required on, rather than it being limited to software. No, the entire point was to make it clear that, as far as the Social Contract is concerned, everything in Debian is software. (This is my understanding, based both on the changes made by 2004-003 and the discussions surrounding it.) Note that the DFSG was not renamed to the Debian Free Stuff Guidelines, and the word software is still used four times in the SC (not including its use in the phrase DFSG). (The echoes of those discussions are still reverberating in my skull, so if you disagree with my interpretation above, I'll probably settle with disagreeing and not try to convince you on that point--debating the content of the discussions would mean digging them out again, and I'm just not up to that right now.) You seem to be arguing, now, that the Social Contract is inherently unfulfillable, by claiming that 2004-003 made the SC apply to hardware as well (for the purposes of require the use ...). This interpretation of the Social Contract is simply not the one Debian uses, or has ever used, nor do I recall any significant discussion during 2004-003 suggesting that this was the intent. If a logical interpretation of the social contract results in an impractical situation and no practical situation can be reached without some contortions of logic, it implies that the social contract doesn't say what we mean it to say and should be changed. There is no contortion of logic involved in the conclusion that the Social Contract is only talking about the stuff that Debian ships (or is logically capable of shipping), and not the physical hardware that stuff runs on. Now, if you believe that Debian's current interpretation of the SC and DFSG (ignoring 2004-004) is an illogical one, feel free to pose the argument to d-project. If you're correct, fixing this would require another GR to change the SC; it's not something fixable by policy, as I understand things. -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
Raul Miller writes: It's a matter of point of view. On Tue, Oct 26, 2004 at 03:42:41PM -0400, Michael Poole wrote: I am quite certain that you have never worked with the drivers I was describing, and the chance you have worked with any of the boards is nearly zero. Your assumption that the differences are anything like you describe is baseless, and your inference that my description is so wrong is insulting. I was describing data differences. The significance of data differences are in the mind of the beholder. Drivers have nothing to do with significance. You know that -- that's practically your point. And what are the consequences to Debian with this choice? It depends on whether you assume users can and will use contrib or non-free. If you assume that, I do not think it has significant impact, although it is likely to save the kernel packagers lots of work. If you assume users cannot or will not use contrib or non-free, it is the difference between users needing to supply firmware or both driver and firmware (and likely recompiling their kernel). I assume that some users will use contrib or non-free, and that some won't. That assumption shouldn't surprise you. In particular, what freedoms do you think it is acceptable for us to require of any opaque blobs that we would be distributing with main? My suggestion does not involve distributing opaque blobs with main. To repeat: THE FIRMWARE FILES THEMSELVES WOULD HAVE TO BE PROVIDED BY THE USER OR IN NON-FREE, UNLESS THEY QUALIFY UNDER THE DFSG. For example, some firmware blobs in the Linux kernel are the output of an assembler, and the assembly source is included in Linux. That kind of firmware blob is not opaque, and could be distributed in main. In that case, we should probably be treating this as analogous to players for various forms of content. If there are any significant free examples of that content we allow the player into main. If there are no significant examples of that content, the loader really does have a dependency on non-free software content. And, if the driver won't work without the loader, then the driver has a dependency on the loader. Is it really too much to ask that there be some free firmware examples before we deal with that class of firmware? Are you saying that you want us to ship opaque blobs where we take no responsibility whatsoever for their character? I have said nothing of the sort. Would you like to apologize for being such a boorish insulting troll, or should I just write you off as someone not worth listening to? You are one of a collection of people advocating similar things. If you expect me to limit my questions to addressing only you have said and to ignore issues raised by others, maybe we shouldn't be having this discussion on a public list.
Re: non-free firmware: driver in main or contrib?
Glenn Maynard [EMAIL PROTECTED] wrote: There is no contortion of logic involved in the conclusion that the Social Contract is only talking about the stuff that Debian ships (or is logically capable of shipping), and not the physical hardware that stuff runs on. Argh. Yes, but the firmware in these eeproms is something that we're entirely logically capable of shipping. Claiming that firmware is sometimes software (when it's on a compact flash card, say) and sometimes hardware (when it's on an eeprom, say) is the sort of argument that the social contract changes were meant to deal with. If it's a string of bits encoded on something, we're meant to apply the DFSG to it, not argue about whether it's software or not. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 04:42:45PM -0400, Glenn Maynard wrote: No, the entire point was to make it clear that, as far as the Social Contract is concerned, everything in Debian is software. (This is my understanding, based both on the changes made by 2004-003 and the discussions surrounding it.) Note that the DFSG was not renamed to the Debian Free Stuff Guidelines, and the word software is still used four times in the SC (not including its use in the phrase DFSG). It's probably also worth pointing out that the word software is used more times within the DFSG itself. And, that in contexts where software is not explicitly mentioned that it's pretty clear that the focus is on the license for that software. It's probably also worth noting that we don't use a very restrictive definition of software -- sequences of bits would probably work in most contexts as our definition for software. It's probably also worth noting that every time the social contract uses the word free that it is referring to the Debian Free Software Guidelines -- since those are our guidelines for what we mean by free. Finally, it's probably worth noting that all software is used by shipping it to hardware, and having the hardware do something with it. The details, of course, depend on the hardware. [In other words: I agree.] -- Raul
Re: non-free firmware: driver in main or contrib?
This is the wrong mailing list for that sort of proposal. On Tue, Oct 26, 2004 at 08:32:47PM +0100, Matthew Garrett wrote: That's why I'm not actively proposing it here. Brian asked me a question, and I answered it. In that case, perhaps you should take your discussion elsewhere? Correct me if I'm wrong, but it doesn't seem like you can usefully resolve the point you want to discuss through discussions on this mailing list. -- Raul
Re: non-free firmware: driver in main or contrib?
Raul Miller writes: In that case, we should probably be treating this as analogous to players for various forms of content. If there are any significant free examples of that content we allow the player into main. If there are no significant examples of that content, the loader really does have a dependency on non-free software content. How many significant free examples of DVD content are there? To the best of my knowledge, all of the DVDs I own contain CSS-encrypted content and are compressed using patent-encumbered formats. The CSS decryption library that libdvdread3 can use is not part of Debian, but MPEG-2 decompressors seem to be in main. It's also not very hard to find cases where the MPEG LA has filed patent infringement lawsuits based on those patents (against Compaq, Dell, Sagem S.A., effectively Apex Digital, and others). Apart from that, I do not think it is the same situation as a media player; the dependency is one remove further than for media players. If we declare that software depends on programmable bits on the other side of a well-defined interface (not one based on function calls), we have lots of problems. To pick just one example, evolution-exchange would need to move into contrib. And, if the driver won't work without the loader, then the driver has a dependency on the loader. I was not aware that any of these drivers used a non-free loader. Can you give an example? Is it really too much to ask that there be some free firmware examples before we deal with that class of firmware? We have linux-2.6.x/drivers/usb/serial/keyspan_pda.S and xircom_pgs.S, which I alluded in my previous mail. For each driver that can load firmware, do you want Debian to be responsible for tracking down whether free firmware exists anywhere in the world? I think that illustrates both the practical and logical flaws in claiming that the driver depends on the firmware. Are you saying that you want us to ship opaque blobs where we take no responsibility whatsoever for their character? I have said nothing of the sort. Would you like to apologize for being such a boorish insulting troll, or should I just write you off as someone not worth listening to? You are one of a collection of people advocating similar things. If you expect me to limit my questions to addressing only you have said and to ignore issues raised by others, maybe we shouldn't be having this discussion on a public list. I expect you to not raise strawman arguments. Your last two questions go beyond anything I have seen suggested in this discussion. I also do not see the pertinence; Debian disclaims responsibility for the performance and behavior of everything it distributes. Case in point: the fairly recent -project discussion along the lines of Reflections on Trusting Trust and whether it applied to Debian's toolchain. Michael Poole
Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 06:46:34PM -0400, Michael Poole wrote: How many significant free examples of DVD content are there? I have Debian main (sarge) on DVD, so there's at least one example. If you're talking about audio-visual materials, I imagine that the right way to find such materials would focus on academic projects and other such activities which are likely to generate the relevant kinds of content. Personally, I don't watch dvds (or tv), so I'm not the right person to ask for details. To the best of my knowledge, all of the DVDs I own contain CSS-encrypted content and are compressed using patent-encumbered formats. The CSS decryption library that libdvdread3 can use is not part of Debian, but MPEG-2 decompressors seem to be in main. It's also not very hard to find cases where the MPEG LA has filed patent infringement lawsuits based on those patents (against Compaq, Dell, Sagem S.A., effectively Apex Digital, and others). We only very rarely treat software patents as an issue that makes software non-free. There's good reasons for this, but that's tangential to this discussion. Finally, to tie this back to the current discussion, I doubt I'd need to load different firmware into my dvd drivers if I wanted to deal with audio/visual content. Apart from that, I do not think it is the same situation as a media player; the dependency is one remove further than for media players. If we declare that software depends on programmable bits on the other side of a well-defined interface (not one based on function calls), we have lots of problems. To pick just one example, evolution-exchange would need to move into contrib. I think you're being overly general here. For example, interfaces to shared libraries can (and typically are) well defined interfaces. That said, it might very well be that evolution-exchange should be in contrib. I don't know enough about evolution implementations to say for sure. And, if the driver won't work without the loader, then the driver has a dependency on the loader. I was not aware that any of these drivers used a non-free loader. Can you give an example? Well... that's not what I was saying, but I have seen hardware where you had to use some version of MS Windows to load the firmware. But my point was that packages which depend on contrib need to be in contrib. [There are, of course, other reasons for being in contrib, but this reason is rather illustrative.] Is it really too much to ask that there be some free firmware examples before we deal with that class of firmware? We have linux-2.6.x/drivers/usb/serial/keyspan_pda.S and xircom_pgs.S, which I alluded in my previous mail. For each driver that can load firmware, do you want Debian to be responsible for tracking down whether free firmware exists anywhere in the world? Ideally, we should be distributing that free firmware. Maybe we don't automatically use it -- making things automatic can cause problems for our users. However, unless the firmware is useless, it seems like we should be distributing it just as much as we should be distributing the drivers. I think that illustrates both the practical and logical flaws in claiming that the driver depends on the firmware. I'll grant that practical issues -- such as an explosion of hardware implementations -- might keep us from distributing free firmware. But practical issues which limit our support are not the same as logical issues which would prevent us from ever offering support. If you expect me to limit my questions to addressing only you have said and to ignore issues raised by others, maybe we shouldn't be having this discussion on a public list. I expect you to not raise strawman arguments. Your last two questions go beyond anything I have seen suggested in this discussion. I also do not see the pertinence; Debian disclaims responsibility for the performance and behavior of everything it distributes. Case in point: the fairly recent -project discussion along the lines of Reflections on Trusting Trust and whether it applied to Debian's toolchain. It's kinda hard for an argument to be a strawman when the argument fits within the scope of the previous arguments which had been discussed. And the scope of this argument has been very broad (up to, and including people claiming that hardware components should comply with our free software guidelines). It's true that the questions I asked were not issues which you had raised -- I had raised them. The pertinence was simply that I was trying to understand what your point of view was. I think I have a better understanding now, and will try to limit my discussion to issues which seem pertinent to the view point you are interested in discussing. About responsibility: we do try and make sure our system works right. And, I'm not specifically sure what thread you're referring to. Perhaps you're referring to Unofficial buildd network has been shut down
Re: non-free firmware: driver in main or contrib?
Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Then there's no point continuing this conversation. An FPGA design, living as a file on disk and possibly even shipped by Debian is clearly software under Debian's definitions. Runtime-loaded firmware I was not discussing Debian's definitions now. Then could you please clearly mark the subject lines of such messages as do not discuss Debian as OFF-TOPIC ? -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Sun, Oct 24, 2004 at 10:59:50PM +0100, Matthew Garrett wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Oct 24, 2004 at 03:41:13AM +0100, Matthew Garrett wrote: Is this the case even if the firmware is in a flash chip attached to the device? If the total amount of non-free software on a user's system is the same regardless, why are we concerned about how it's packaged? The total amount of non-free software on a user's system is different if the firmware comes pre-loaded on the device than if we have to load it from the OS, isn't it? By system, I'm referring to the hardware as well. If there is at least one real-world device that works with the driver without needing to load additional firmware, I think the driver is unambiguously free from this standpoint. If no one can point to a device that the driver works with without the help of an additional non-free firmware blob, I'm not certain I agree that it doesn't have a dependency on non-free software. But almost every driver requires an additional non-free firmware blob. In general, there are two cases: 1) That firmware is in an eeprom, and so was distributed to the user when the hardware was bought 2) That firmware is not in an eeprom, and so was distributed to the user when they obtained drivers In most versions of case (2), the user will already own a copy of the firmware - it'll be on the Windows driver CD in some form. It would be trivial to add code to the driver packages to copy this code off the CD. At that point, in no case does Debian distribute the firmware. Ok, I guess somewhere I lost track of exactly what was being argued in this thread. I agree, if the user (or some group of users to whom the driver is useful) already have the required firmware, either in the device's flash or on a driver CD, it shouldn't be necessary for us to consider this a dependency of the driver, and thus the driver is eligible for main. I was thinking of the possible case where *we* had to distribute a firmware blob. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: non-free firmware: driver in main or contrib?
On Sun, Oct 24, 2004 at 10:45:18PM -0700, Steve Langasek wrote: Ok, I guess somewhere I lost track of exactly what was being argued in this thread. I agree, if the user (or some group of users to whom the driver is useful) already have the required firmware, either in the device's flash or on a driver CD, it shouldn't be necessary for us to consider this a dependency of the driver, and thus the driver is eligible for main. I was thinking of the possible case where *we* had to distribute a firmware blob. Huh? If a driver requires a firmware blob be copied from a driver CD, it's a pretty clear non-free dependency--if the documentation says something like copy this software (that we're not allowed to distribute) from your CD to /usr/lib/foo before running, or this driver won't work at all, it's contrib. I don't understand how there's any disagreement in this case: it's clearly software, covered by the DFSG (or at least the one Debian will be using soon), it's required (a Depends), and clearly non-free. -- Glenn Maynard
Re: non-free firmware: driver in main or contrib?
On Sun, Oct 24, 2004 at 10:45:18PM -0700, Steve Langasek wrote: Ok, I guess somewhere I lost track of exactly what was being argued in this thread. I agree, if the user (or some group of users to whom the driver is useful) already have the required firmware, either in the device's flash or on a driver CD, it shouldn't be necessary for us to consider this a dependency of the driver, and thus the driver is eligible for main. I was thinking of the possible case where *we* had to distribute a firmware blob. Like for ipw2200 and ipw2100 drivers. We don't exactly have to distribute the firmware blob. Actually, we have to not distribute it because its license doesn't authorize it. And it is only available on the driver website. It's not even the same as the one embedded in the windows driver (yes, it is embedded in the driver, it doesn't come as an independant file on a CD or whatever). In such case, even if the license of the driver is free, it can *not* go into main. Mike
Re: non-free firmware: driver in main or contrib?
Glenn Maynard [EMAIL PROTECTED] wrote: I don't understand how there's any disagreement in this case: it's clearly software, covered by the DFSG (or at least the one Debian will be using soon), it's required (a Depends), and clearly non-free. On the other hand, if it's clearly software when it's on CD then it's clearly software when it's on eeprom. If it's a dependency when it's on CD, it's equally a dependency when it's on eeprom. The only distinction that can be drawn is whether or not it ends up on the user's hard drive. Surely the storage mechanism used does not alter the freeness of something? -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: The total amount of non-free software on a user's system is different if the firmware comes pre-loaded on the device than if we have to load it from the OS, isn't it? No. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Ken Arromdee [EMAIL PROTECTED] writes: On Sun, 24 Oct 2004, Raul Miller wrote: The person who has the device doesn't neceessarily have the firmware, because the firmware can be removed. The person doesn't have the device at that point -- only part of it. The same reasoning applies for both examples if you refer to the combination of hardware plus CD as a device. But that imagined device is broken: it needs another component to read the CD, load the firmware off of it into the computer's memory, process it there, then upload that to the device itself. Of course, there are relatively few examples where you'd *want* to remove the eeprom from the device, but similarly there are few examples where you'd want to sell the device without accompanying it with a CD. Of course, those examples include this one: inadvertently losing track of the CD. That's a difference, but it doesn't seem to be enough. It just means I need to rephrase the question: So what's the difference between a device with firmware, and a device with a CD plus a non-free license letting you copy the CD? In that case, losing the CD doesn't matter because the user can get another copy. The user can't modify the software on the CD, but then he had no permission to modify it when it's in hardware either. I'm not sure this last is true, for the same reasons that I may saw any book I have purchased in half and sell the result to you. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED] writes: Glenn Maynard [EMAIL PROTECTED] wrote: I don't understand how there's any disagreement in this case: it's clearly software, covered by the DFSG (or at least the one Debian will be using soon), it's required (a Depends), and clearly non-free. On the other hand, if it's clearly software when it's on CD then it's clearly software when it's on eeprom. False. That's why we call it firmware, not just software living on a device. It's an implementation detail of the hardware that they happen to have shipped a microprocessor and a hardwired program. If the program had been burned into a circuit in an FPGA, would you still call it software? If it's a single-use PROM, is it still software? From the point of view of the driver, the device is just a device. It gets... driven. That's it. No need to consider the things inside and force decisions about software or not onto them. Anything the user's being told to copy to /usr/local/something, on the other hand, is clearly software. If it's a dependency when it's on CD, it's equally a dependency when it's on eeprom. The only distinction that can be drawn is whether or not it ends up on the user's hard drive. Surely the storage mechanism used does not alter the freeness of something? Surely the implementation details of a device do not alter the freeness of it? -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the loadable firmware is in the dependency tree of the software Debian ships. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the This is not an use of the verb require I'm familiar with. loadable firmware is in the dependency tree of the software Debian ships. I can't find which part of policy estabilishes this criteria. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: On the other hand, if it's clearly software when it's on CD then it's clearly software when it's on eeprom. False. That's why we call it firmware, not just software living on a device. Get real. Software does not change its nature depending on the media it's stored on. It's an implementation detail of the hardware that they happen to have shipped a microprocessor and a hardwired program. If the program had been burned into a circuit in an FPGA, would you still call it software? I'm not sure if a FPGA description should be considered a program. If it's a single-use PROM, is it still software? Yes, sure. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Brian Thomas Sniffen [EMAIL PROTECTED]: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the loadable firmware is in the dependency tree of the software Debian ships. There are two slight problems with your argument here: (1) You wrote a functioning hardware device, i.e. not necessarily the particular device that requires the particular firmware. (2) If a driver requires a functioning hardware device, then presumably Debian can't ship the driver in main because Debian doesn't include any hardware devices in any part of its distribution!
Re: non-free firmware: driver in main or contrib?
On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. Then, how do you explain the ipw2200 case where driver version 0.5 and less will only work with a certain firmware and version 0.6 and more will only work with an other firmware ? Isn't that what we could call a requirement ? Mike
Re: non-free firmware: driver in main or contrib?
On Mon, Oct 25, 2004 at 01:18:18PM +0200, Marco d'Itri wrote: Get real. Software does not change its nature depending on the media it's stored on. Some aspects do change. But it's true that what a person thinks about that software doesn't need to change (depending on the person doing the thinking, of course). -- Raul
Re: non-free firmware: driver in main or contrib?
On Mon, 2004-10-25 at 07:07 -0400, Brian Thomas Sniffen wrote: Matthew Garrett [EMAIL PROTECTED] writes: On the other hand, if it's clearly software when it's on CD then it's clearly software when it's on eeprom. False. That's why we call it firmware, not just software living on a device. It's an implementation detail of the hardware that they happen to have shipped a microprocessor and a hardwired program. If the program had been burned into a circuit in an FPGA, would you still call it software? Brian, we are talking about identical code. Software doesn't stop being software if it's burned into a ROM instead of being supplied with the OS. An FPGA is a more interesting issue - would you define a set of verilog code as software if it's supplied on disk? If it's a single-use PROM, is it still software? If we would want the source code to it if we shipped the contents, then yes, it's software. From the point of view of the driver, the device is just a device. It gets... driven. That's it. No need to consider the things inside and force decisions about software or not onto them. I want a world in which all code run on a system is free, no matter whether that code is executed by the host processor or something on a card. I see no reason for us to consider non-free software more legitimate purely because it's on a chip rather than on a hard drive. As a result, I consider all arguments that apply to code on hard drives to apply equally well to code on chips. Anything the user's being told to copy to /usr/local/something, on the other hand, is clearly software. You appear to be claiming that identical code is firmware if it's on a chip and software if it's on a CD, and that we should apply different standards to each situation. I'm claiming that it's always software, and we should apply the same standards to it in all cases. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote: Brian, we are talking about identical code. Are we? Software doesn't stop being software if it's burned into a ROM instead of being supplied with the OS. It does, however, cease to be a dependency issue if those who have the hardware also have the firmware. You appear to be claiming that identical code is firmware if it's on a chip and software if it's on a CD, and that we should apply different standards to each situation. I'm claiming that it's always software, and we should apply the same standards to it in all cases. I don't think he's making this claim for all contexts. As I see it, the issue we're discussing is dependencies. In this context: For practical reasons, we don't require that all users have a piece of hardware before we distribute software which drives that hardware. However, we don't bother including that software in main unless all the software it depends on is free. If they're not, the software goes in contrib (or non-free), assuming we distribute it at all. In this context, we ignore bits which are embedded in the hardware, but we don't ignore bits that we distribute. It's really that simple. -- Raul
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote: Brian, we are talking about identical code. Are we? In many contexts, yes. Software doesn't stop being software if it's burned into a ROM instead of being supplied with the OS. It does, however, cease to be a dependency issue if those who have the hardware also have the firmware. In most cases, they do already have the firmware. It's on a CD that came with the hardware. For practical reasons, we don't require that all users have a piece of hardware before we distribute software which drives that hardware. However, we don't bother including that software in main unless all the software it depends on is free. If they're not, the software goes in contrib (or non-free), assuming we distribute it at all. The reason we don't include free software that has non-free dependencies in main is that we want to discourage people from using non-free software. If the user already has non-free code in ROM, then there is the same amount of non-free software being used. In this context, we ignore bits which are embedded in the hardware, but we don't ignore bits that we distribute. It's more complicated than that, because in several of these cases we don't have permission to distribute the firmware anyway. Your argument is either: 1) Code can go in main if it's dependent on code that is shipped with the hardware. If it depends on code that we ship instead, it has to go in contrib. 2) Code can go in main if it's dependent on code that is in an eeprom. If it depends on code that is stored on the hard drive instead, it has to go in contrib. In the case of (1), we penalise drivers that use firmware that's under a slightly more liberal (though still non-free) license. This seems wrong. In the case of (2), we penalise drivers for hardware that the vendor has made slightly cheaper and more flexible. This also seems wrong. It's really that simple. Whichever argument you're using, it leads to the following situation. A vendor releases a piece of hardware. It requires run-time loadable firmware. We put the driver in contrib. A customer comes to the vendor and asks for a version that doesn't require the firmware be loaded from userspace. The vendor adds an eeprom and puts the firmware in that instead. Despite there being the same amount of non-free code, we can now put the driver in main. Does this not strike you as mad? We make a distinction between main and contrib because we want to discourage non-free code. The distinction you're drawing instead merely encourages vendors to put their non-free code on an eeprom. It doesn't advance the cause of free software, and it doesn't help our users. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote: Brian, we are talking about identical code. Are we? In many contexts, yes. Software doesn't stop being software if it's burned into a ROM instead of being supplied with the OS. It does, however, cease to be a dependency issue if those who have the hardware also have the firmware. In most cases, they do already have the firmware. It's on a CD that came with the hardware. For practical reasons, we don't require that all users have a piece of hardware before we distribute software which drives that hardware. However, we don't bother including that software in main unless all the software it depends on is free. If they're not, the software goes in contrib (or non-free), assuming we distribute it at all. The reason we don't include free software that has non-free dependencies in main is that we want to discourage people from using non-free software. If the user already has non-free code in ROM, then there is the same amount of non-free software being used. In this context, we ignore bits which are embedded in the hardware, but we don't ignore bits that we distribute. It's more complicated than that, because in several of these cases we don't have permission to distribute the firmware anyway. Your argument is either: 1) Code can go in main if it's dependent on code that is shipped with the hardware. If it depends on code that we ship instead, it has to go in contrib. 2) Code can go in main if it's dependent on code that is in an eeprom. If it depends on code that is stored on the hard drive instead, it has to go in contrib. In the case of (1), we penalise drivers that use firmware that's under a slightly more liberal (though still non-free) license. This seems wrong. In the case of (2), we penalise drivers for hardware that the vendor has made slightly cheaper and more flexible. This also seems wrong. It's really that simple. Whichever argument you're using, it leads to the following situation. A vendor releases a piece of hardware. It requires run-time loadable firmware. We put the driver in contrib. A customer comes to the vendor and asks for a version that doesn't require the firmware be loaded from userspace. The vendor adds an eeprom and puts the firmware in that instead. Despite there being the same amount of non-free code, we can now put the driver in main. Does this not strike you as mad? We make a distinction between main and contrib because we want to discourage non-free code. The distinction you're drawing instead merely encourages vendors to put their non-free code on an eeprom. It doesn't advance the cause of free software, and it doesn't help our users. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Mon, Oct 25, 2004 at 02:21:03PM +0100, Matthew Garrett wrote: Whichever argument you're using, it leads to the following situation. A vendor releases a piece of hardware. It requires run-time loadable firmware. We put the driver in contrib. A customer comes to the vendor and asks for a version that doesn't require the firmware be loaded from userspace. The vendor adds an eeprom and puts the firmware in that instead. Despite there being the same amount of non-free code, we can now put the driver in main. Does this not strike you as mad? We make a distinction between main and contrib because we want to discourage non-free code. The distinction you're drawing instead merely encourages vendors to put their non-free code on an eeprom. It doesn't advance the cause of free software, and it doesn't help our users. It does strike me as a bit mad, to suggest that hardware vendors are going to be redesign their hardware, to move a driver from debian contrib to main. If it were that important to them, they'd should have done it right in the first place. Oh, wait, maybe you're suggesting that they had some OTHER reason for putting those bits in rom? If that's the case, your claim that it doesn't help our users is a bit specious. [Or, more succinctly, how about we discuss real cases rather than straw men.] -- Raul
Re: non-free firmware: driver in main or contrib?
Raul Miller [EMAIL PROTECTED] wrote: On Mon, Oct 25, 2004 at 02:21:03PM +0100, Matthew Garrett wrote: Does this not strike you as mad? We make a distinction between main and contrib because we want to discourage non-free code. The distinction you're drawing instead merely encourages vendors to put their non-free code on an eeprom. It doesn't advance the cause of free software, and it doesn't help our users. It does strike me as a bit mad, to suggest that hardware vendors are going to be redesign their hardware, to move a driver from debian contrib to main. If it were that important to them, they'd should have done it right in the first place. Where does right come from? You're continuing to imply that hardware that has firmware in ROM is somehow more free than hardware that requires firmware to be loaded by the OS. Neither is the right solution - it depends on your requirements. Oh, wait, maybe you're suggesting that they had some OTHER reason for putting those bits in rom? If that's the case, your claim that it doesn't help our users is a bit specious. [Or, more succinctly, how about we discuss real cases rather than straw men.] Customers make strange demands. As a result of tooling up for a single production run, it might then become cheaper for them to use the same design for the generic consumer part. Anyway. You didn't answer my question: is your definition of dependency based on who ships the firmware, or is it based on the medium which contains the firmware? -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Oh, wait, maybe you're suggesting that they had some OTHER reason for putting those bits in rom? If that's the case, your claim that it doesn't help our users is a bit specious. It's not obvious that this would be an improvement which benefits users. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. Then, how do you explain the ipw2200 case where driver version 0.5 and less will only work with a certain firmware and version 0.6 and more will only work with an other firmware ? Isn't that what we could call a requirement ? No, why? I can't see how this could be related to my argument. -- ciao, Marco
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED] writes: On Mon, 2004-10-25 at 07:07 -0400, Brian Thomas Sniffen wrote: Matthew Garrett [EMAIL PROTECTED] writes: On the other hand, if it's clearly software when it's on CD then it's clearly software when it's on eeprom. False. That's why we call it firmware, not just software living on a device. It's an implementation detail of the hardware that they happen to have shipped a microprocessor and a hardwired program. If the program had been burned into a circuit in an FPGA, would you still call it software? Brian, we are talking about identical code. Software doesn't stop being software if it's burned into a ROM instead of being supplied with the OS. An FPGA is a more interesting issue - would you define a set of verilog code as software if it's supplied on disk? Sure. Heck, for all I know there's a device out there where the firmware on disk is verilog code, and it's compiled by the driver and loaded to an FPGA on the device. Surely that's software. Hm. It proposes an interesting model of the driver as a sort of processor (like a compiler or an interpreter) for the firmware, more than the library model I've been considering. If it's a single-use PROM, is it still software? If we would want the source code to it if we shipped the contents, then yes, it's software. From the point of view of the driver, the device is just a device. It gets... driven. That's it. No need to consider the things inside and force decisions about software or not onto them. I want a world in which all code run on a system is free, no matter whether that code is executed by the host processor or something on a card. Why draw the line at software, then? Why not wish for open specs for all the chips, so you can modify the CPU or GPU? I see no reason for us to consider non-free software more legitimate purely because it's on a chip rather than on a hard drive. As a result, I consider all arguments that apply to code on hard drives to apply equally well to code on chips. Anything the user's being told to copy to /usr/local/something, on the other hand, is clearly software. You appear to be claiming that identical code is firmware if it's on a chip and software if it's on a CD, and that we should apply different standards to each situation. I'm claiming that it's always software, and we should apply the same standards to it in all cases. I think that the *dependency* doesn't exist in some reasonable models of a device as a black box, which either does or does not depend on user-loaded firmware. That is, in all reasonable models the driver depends on the device, but Debian does not reflect that dependency because the device is hardware, not software. In some reasonable models, the device depends on its firmware, whether pre-loaded or user-loaded. That's the model you're using. To be consistent, Debian must express all these dependencies -- and so most drivers go into contrib, which we all agree is impractical and bad. In some reasonable models, the device depends on user-loaded firmware, and pre-loaded firmware is inside the abstraction barrier and we don't get to see it. So we still must express all the dependencies we see, and only *some* drivers must go to contrib; those which can drive devices with no user-visible firmware can be considered free. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Mon, 25 Oct 2004, Matthew Garrett wrote: The reason we don't include free software that has non-free dependencies in main is that we want to discourage people from using non-free software. If the user already has non-free code in ROM, then there is the same amount of non-free software being used. It's not necessarily to discourage them, it's so that they know when they're using non-free software, and so that we know what free software has non-free dependencies, helping to indicate what should be reimplemented as free software. If we wanted to discourage people from using non-free software, we would make vrms Priority: Required, Essential: Yes, and install a cronjob that e-mailed the known world saying that the admin was a proprietary software floozie and slept with Bill Gates. Don Armstrong -- If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too. -- W. Somerset Maugham http://www.donarmstrong.com http://rzlab.ucr.edu
Re: non-free firmware: driver in main or contrib?
Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the This is not an use of the verb require I'm familiar with. The driver has no useful functionality without a device to drive. What's unclear about this? -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Edmund GRIMLEY EVANS [EMAIL PROTECTED] writes: Brian Thomas Sniffen [EMAIL PROTECTED]: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the loadable firmware is in the dependency tree of the software Debian ships. There are two slight problems with your argument here: (1) You wrote a functioning hardware device, i.e. not necessarily the particular device that requires the particular firmware. Wha? Yes, of course, the Foobozinator driver presumably requires a functioning Foobozinator, and will not work no matter how many functioning Quxulators you have plugged in. (2) If a driver requires a functioning hardware device, then presumably Debian can't ship the driver in main because Debian doesn't include any hardware devices in any part of its distribution! Debian only expresses dependencies on software. This is known. -- Brian Sniffen [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Sun, Oct 24, 2004 at 10:59:50PM +0100, Matthew Garrett wrote: Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Oct 24, 2004 at 03:41:13AM +0100, Matthew Garrett wrote: Is this the case even if the firmware is in a flash chip attached to the device? If the total amount of non-free software on a user's system is the same regardless, why are we concerned about how it's packaged? The total amount of non-free software on a user's system is different if the firmware comes pre-loaded on the device than if we have to load it from the OS, isn't it? By system, I'm referring to the hardware as well. If there is at least one real-world device that works with the driver without needing to load additional firmware, I think the driver is unambiguously free from this standpoint. If no one can point to a device that the driver works with without the help of an additional non-free firmware blob, I'm not certain I agree that it doesn't have a dependency on non-free software. But almost every driver requires an additional non-free firmware blob. In general, there are two cases: 1) That firmware is in an eeprom, and so was distributed to the user when the hardware was bought 2) That firmware is not in an eeprom, and so was distributed to the user when they obtained drivers In most versions of case (2), the user will already own a copy of the firmware - it'll be on the Windows driver CD in some form. It would be trivial to add code to the driver packages to copy this code off the CD. At that point, in no case does Debian distribute the firmware. Ignoring Brian's strange arguments about rodents, I can see no cases where the user has more freedom if the firmware comes from an eeprom rather than from a CD. The main/contrib split exists in order to make it clear to our users that their free software depends on non-free code. In the case of free software that interacts directly with hardware, that's almost always the case. If we're of the opinion that non-free firmware is unacceptably bad, we should move all drivers which require it to contrib regardless of the manufacturer's choice of storage device. I have an idea. Since it is starting to appear (from the discussions on this list, at least) that nothing is actually free enough for us to put in Debian, I suggest we rm -rf the package pool and simply start shipping blank CD's with Debian written on them. This will have the added benefit of drastically improving release times. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
On Oct 25, Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the This is not an use of the verb require I'm familiar with. The driver has no useful functionality without a device to drive. What's unclear about this? It's not clear how this is related to the argument. Obviously any kind of device driver has limited practical use[1] if you do not own the hardware device, and so are programs like ICQ and AIM clients if you do not have access to the proprietary servers they connect to, but still policy does not require to keep this kind of free software out of Debian. [1] But it may be an invaluable source of code and ideas to use in other projects... -- ciao, | Marco | [8732 stX1et.crwkrc] signature.asc Description: Digital signature
Re: non-free firmware: driver in main or contrib?
[EMAIL PROTECTED] (Marco d'Itri) writes: On Oct 25, Brian Thomas Sniffen [EMAIL PROTECTED] wrote: Marco d'Itri [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Huh? If a driver requires a firmware blob be copied from a driver CD, Please repeat after me: drivers do not require firmwares, hardware devices require firmwares. And the driver requires a functioning hardware device. Thus, the This is not an use of the verb require I'm familiar with. The driver has no useful functionality without a device to drive. What's unclear about this? It's not clear how this is related to the argument. Look, foowriter depends on readline. libreadline depends on libc. So foowriter depends on libc. People have been saying here that drivers depend on firmware. You have argued that they don't -- presenting as evidence that the devices depend on the firmware. While this is true, it is incomplete: the driver Depends, in the policy sense, on the device, and the device Depends on the firmware. Debian doesn't express the hardware element of the dependency, so the driver Depends on the firmware. Obviously any kind of device driver has limited practical use[1] if you do not own the hardware device, and so are programs like ICQ and AIM clients if you do not have access to the proprietary servers they connect to, but still policy does not require to keep this kind of free software out of Debian. It's not just the proprietary server code, but the actual servers that are necessary. That is, you need the machines running them -- hardware, a black box outside Debian's control. I do think that closed-system clients don't belong in Debian (differentiating OSCAR, for example, from whatever the closed AIM protocol of the week is -- I don't follow technical developments there very closely.) [1] But it may be an invaluable source of code and ideas to use in other projects... That source of ideas is not enough to change a Depends to a Suggests, or we'd have nothing in contrib. -- Brian Sniffen [EMAIL PROTECTED]
