Re: On the freeness of a BLOB-containing driver
Goswin von Brederlow wrote: [EMAIL PROTECTED] (Nathanael Nerode) writes: Goswin von Brederlow wrote: ^^ This is wrong. Glenn Maynard? If it comes down to the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits, I can live with that. Yes, yes! Let me say that this is precisely what I think. contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. Suppose the thing being moved is not a vital part of the system. Then, although the item being moved depends on non-free software, does the *system* really depend on it? Then it pretty much comes down to what you said above. :-) -- This space intentionally left blank. You misquoted. That wasn't me. Oops, very sorry. Glenn Maynard? Hand-quoting sucks, but I've been reduced to it recently.
Re: On the freeness of a BLOB-containing driver
Marco d'Itri wrote: The reason for this is not only the additional cost of the flash chip, but also that (good) devices which use flash need to be more complex: you would have to add a programming device, possibly a dual power supply to drive it and you would need anyway some intelligent enough code on a ROM to allow emergency recovery from bad flashing. Certainly there are AVR and ARM chips that do glue-less downloading from serial FLASH chips at boot time. Atmel sells them, among others. Reprogramming of the FLASH is done via JPEG and not under the embedded processor's control. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: On the freeness of a BLOB-containing driver
Bruce Perens [EMAIL PROTECTED] wrote: Certainly there are AVR and ARM chips that do glue-less downloading from serial FLASH chips at boot time. Atmel sells them, among others. Reprogramming of the FLASH is done via JPEG and not under the embedded processor's control. Bruce, as far as I can tell, you're claiming that it's better for vendors to put code in flash because that way Debian doesn't have to worry about the non-freeness of it. While I can see ways in which that is true, I don't believe it /should/ be true. Non-free code in flash is no more or less a problem than non-free code on disk. We shouldn't be encouraging manufacturers to make their products more expensive by putting it in flash - we should be encouraging manufacturers to open the specifications so we can implement free versions, or encouraging them to open the firmware in its entirity. One of these choices does nothing to advance freedom. The other does. If anything, we should be happy that manufacturers /are/ starting to move away from flash - it makes it clearer that there's a freedom issue that we're not at liberty to ignore. -- Matthew Garrett | [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 04:09:04AM +0100, Goswin von Brederlow wrote: Is a bit of flash or rom that much bigger than ram? Isn't most of the space in the dongle air or filling material? Space is space on the board (not to mention the complexity of the board) as well as three dimenisonal space. Cost I can see, size I find a bit hard to believe. Especially with mass market products the margins can often be tiny - sell enough units and it does add up, though. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: On the freeness of a BLOB-containing driver
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: [..] There are a number of reasons that a device's firmware won't generally be opened to us: 1. The manufacturer's concerns regarding the proprietary nature of information about their device that is below the bus. 2. The fact that misprogramming the device at that level can damage the hardware. 3. They aren't going to want to support more firmware versions than they have to. And 4. They're not allowed to by regulations, eg wireless hardware whose firmware cannot be distributed by FCC rule. [..] A good hardware design would put this code in FLASH on the board. If you [..] I'm going to disagree (violently) here. FLASH costs money, which drives up costs to consumers directly. Further, if you want to support firmware upgrades, you need to find a VERY robust process else you have huge technical support and repair issues, not to mentioned unhappy customers. I'm an EE working on industrial telecommunications equipment and I always argue for putting as little as possible in FLASH, so that we can upgrade it easily later. Avoid shipping non-upgradable components at all cost, because those components are rarely bug free upfront. As a follow on, have you ever seen a PC motherboard whose BIOS can be upgraded from linux? No, you have to find floppy disks or boot Windows. Lack of FLASH firmware is definitely a convenience too. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
Goswin von Brederlow wrote: If it comes down to the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits, I can live with that. Yes, yes! Let me say that this is precisely what I think. contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. Suppose the thing being moved is not a vital part of the system. Then, although the item being moved depends on non-free software, does the *system* really depend on it? Then it pretty much comes down to what you said above. :-) -- This space intentionally left blank.
Re: On the freeness of a BLOB-containing driver
Glenn Maynard wrote: contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. It's not clear to me that the system depends on a non-free component if a single BLOB-requiring driver fails to install because the BLOB is not present, leaving the overall system working except that it can't drive one piece of hardware. The system depends on a non-free component if the whole system won't work without it. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: On the freeness of a BLOB-containing driver
Hamish Moffatt wrote: And 4. They're not allowed to by regulations, eg wireless hardware whose firmware cannot be distributed by FCC rule. It's not at all clear to me that the type-approval process depends on security by obscurity in the firmware. Some manufacturers may think it does, but I haven't seen where FCC requires that. Note also that the Radio Amateurs on the list want to operate this hardware outside of its type-approval and have the legal authority to do so. I'm going to disagree (violently) here. FLASH costs money, which drives up costs to consumers directly. Maybe, maybe not. A lot of the processors come with it on board whether you want it or not, many of the ones that don't have an expensive (in pin-count) external memory bus. Further, if you want to support firmware upgrades, you need to find a VERY robust process else you have huge technical support and repair issues, not to mentioned unhappy customers. In general the FLASH is being loaded via JTAG, and the RAM is being loaded via JTAG. No difference. You can write a device with completely wedged software via JTAG. I'm an EE working on industrial telecommunications equipment and I always argue for putting as little as possible in FLASH, so that we can upgrade it easily later. Are you sure you don't mean ROM? In general, FLASH systems are designed to upgrade in place. As a follow on, have you ever seen a PC motherboard whose BIOS can be upgraded from linux? As a matter of fact, Linux has drivers for some motherboard FLASH chips under the MTD stuff. I don't know who uses them. Thanks Bruce smime.p7s Description: S/MIME Cryptographic Signature
Re: On the freeness of a BLOB-containing driver
[EMAIL PROTECTED] (Nathanael Nerode) writes: Goswin von Brederlow wrote: If it comes down to the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits, I can live with that. Yes, yes! Let me say that this is precisely what I think. contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. Suppose the thing being moved is not a vital part of the system. Then, although the item being moved depends on non-free software, does the *system* really depend on it? Then it pretty much comes down to what you said above. :-) -- This space intentionally left blank. You misquoted. That wasn't me. MfG Goswin
Re: On the freeness of a BLOB-containing driver
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard: On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: What about the rest of the driver? I think that if you remove the BLOB, it's Free Software. It talks to a bus interface, which is a natural demarcation between our Free Software and the proprietary hardware design. It loads an arbitrary firmware file into the device. The device might not work without the BLOB, but the driver's still free as long as it does not incorporate the BLOB. It's free, but it has a non-optional dependency on non-free software, If it does, then Samba depends on non-free software as well. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: On the freeness of a BLOB-containing driver
Wouter Verhelst [EMAIL PROTECTED] writes: Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard: On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: What about the rest of the driver? I think that if you remove the BLOB, it's Free Software. It talks to a bus interface, which is a natural demarcation between our Free Software and the proprietary hardware design. It loads an arbitrary firmware file into the device. The device might not work without the BLOB, but the driver's still free as long as it does not incorporate the BLOB. It's free, but it has a non-optional dependency on non-free software, If it does, then Samba depends on non-free software as well. How so? I can install samba and use smbmount all from main or not? MfG Goswin
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 08:53:32AM -0800, Bruce Perens wrote: contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. It's not clear to me that the system depends on a non-free component if a single BLOB-requiring driver fails to install because the BLOB is not present, leaving the overall system working except that it can't drive one piece of hardware. The system depends on a non-free component if the whole system won't work without it. Huh? So you're claiming that it's OK for software in main to depend on non-free libraries, and not work at all without them, as long as the system as a whole continues to work and the packaged data itself is Free; and that contrib has no basis in the SC or DFSG at all? -- Glenn Maynard
Re: On the freeness of a BLOB-containing driver
On Dec 12, Bruce Perens [EMAIL PROTECTED] wrote: What about the rest of the driver? I think that if you remove the BLOB, it's Free Software. It talks to a bus interface, which is a natural demarcation between our Free Software and the proprietary hardware design. It loads an arbitrary firmware file into the device. The device might not work without the BLOB, but the driver's still free as long as it does not incorporate the BLOB. Agreed. A good hardware design would put this code in FLASH on the board. If you Not really. A good designer would use permanent storage if the device needs to be operational before the operating system is loaded, otherwise uploading the firmware to RAM is usually the best choice. The reason for this is not only the additional cost of the flash chip, but also that (good) devices which use flash need to be more complex: you would have to add a programming device, possibly a dual power supply to drive it and you would need anyway some intelligent enough code on a ROM to allow emergency recovery from bad flashing. If flash is not used then you only need some dumb code which takes data chunks from e.g. the USB port and copies them to RAM, which in this case would probably be a standard function provided by the EZ-USB chip (or function embedded in a single chip solution) which many devices use. -- ciao, | Marco | [9733 peekct3IX2ffY] signature.asc Description: Digital signature
Re: On the freeness of a BLOB-containing driver
Glenn Maynard [EMAIL PROTECTED] writes: On Sun, Dec 12, 2004 at 08:53:32AM -0800, Bruce Perens wrote: contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. It's not clear to me that the system depends on a non-free component if a single BLOB-requiring driver fails to install because the BLOB is not present, leaving the overall system working except that it can't drive one piece of hardware. The system depends on a non-free component if the whole system won't work without it. Huh? So you're claiming that it's OK for software in main to depend on non-free libraries, and not work at all without them, as long as the system as a whole continues to work and the packaged data itself is Free; and that contrib has no basis in the SC or DFSG at all? He is talking about the kernel. The kernel works perfectly without the firmware. Just that one module will complain on that specific hardware. That hardly constitutes a 'not work at all without them'. If the _package_ as a whole continues to work and the packaged data itself is Free then the package can be in main even if it works better with some parts from non-free. Those parts would only be a suggests not a depends. -- Glenn Maynard MfG Goswin
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote: On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: [..] There are a number of reasons that a device's firmware won't generally be opened to us: 1. The manufacturer's concerns regarding the proprietary nature of information about their device that is below the bus. 2. The fact that misprogramming the device at that level can damage the hardware. 3. They aren't going to want to support more firmware versions than they have to. And 4. They're not allowed to by regulations, eg wireless hardware whose firmware cannot be distributed by FCC rule. I'm pretty sure that FUD got killed last time someone (perhaps you, even) raised it. From memory, the FCC rules only state that there must be a means for effectively preventing the modification of the firmware used in the device. Obscurity is not the only means of doing that. - Matt signature.asc Description: Digital signature
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 02:30:51PM +0100, Wouter Verhelst wrote: Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard: On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: What about the rest of the driver? I think that if you remove the BLOB, it's Free Software. It talks to a bus interface, which is a natural demarcation between our Free Software and the proprietary hardware design. It loads an arbitrary firmware file into the device. The device might not work without the BLOB, but the driver's still free as long as it does not incorporate the BLOB. It's free, but it has a non-optional dependency on non-free software, If it does, then Samba depends on non-free software as well. Why? Samba can talk to Samba. I'm not aware of too many device drivers that can do something useful by talking to another device driver of the same type instead of the real hardware device... - Matt signature.asc Description: Digital signature
Re: On the freeness of a BLOB-containing driver
On Sunday 12 Dec 2004 00:43, Bruce Perens wrote: 1. The manufacturer's concerns regarding the proprietary nature of information about their device that is below the bus. 2. The fact that misprogramming the device at that level can damage the hardware. 3. They aren't going to want to support more firmware versions than they have to. 4. Even if they are free to open the firmware, they will likely not be able to supply the tools with which to build it. You're back in contrib. It is also worth noting that some devices that have large complex firmware may have no default firmware that can be loaded in flash in the factory, but a different firmware for different markets and system integrators. Devices I have seen like this include video codec chips and DVB tuners, I am sure there are others.
Re: On the freeness of a BLOB-containing driver
On Sun, 2004-12-12 at 17:37, Matthew Palmer wrote: On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote: On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: [..] There are a number of reasons that a device's firmware won't generally be opened to us: 1. The manufacturer's concerns regarding the proprietary nature of information about their device that is below the bus. 2. The fact that misprogramming the device at that level can damage the hardware. 3. They aren't going to want to support more firmware versions than they have to. And 4. They're not allowed to by regulations, eg wireless hardware whose firmware cannot be distributed by FCC rule. I'm pretty sure that FUD got killed last time someone (perhaps you, even) raised it. From memory, the FCC rules only state that there must be a means for effectively preventing the modification of the firmware used in the device. Obscurity is not the only means of doing that. Nor is it a means for doing that (though it's probably good enough for FCC approval). -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: On the freeness of a BLOB-containing driver
On Mon, Dec 13, 2004 at 10:37:57AM +1100, Matthew Palmer wrote: On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote: And 4. They're not allowed to by regulations, eg wireless hardware whose firmware cannot be distributed by FCC rule. I'm pretty sure that FUD got killed last time someone (perhaps you, even) raised it. From memory, the FCC rules only state that there must be a means for effectively preventing the modification of the firmware used in the device. Obscurity is not the only means of doing that. OK, my mistake. I read that on here and didn't see it shot down. I never raised it myself. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 09:07:55AM -0800, Bruce Perens wrote: Hamish Moffatt wrote: I'm going to disagree (violently) here. FLASH costs money, which drives up costs to consumers directly. Maybe, maybe not. A lot of the processors come with it on board whether you want it or not, many of the ones that don't have an expensive (in pin-count) external memory bus. If it's in the chip it costs money. If there's a non-FLASH variant available, designers will use it because it's cheaper. And whether it's in the micro or external, it costs money. If it's external it takes space too. In addition to the FLASH part, you might need some other logic (eg a CPLD) to actually transfer the contents of FLASH into the programmable device. That costs a few more dollars and takes a bit more board space. The front-end chips used in DVB (digital television) cards have their firmware loaded through I2C and I don't think they have any way to initiate that themselves. Hence if you wanted a wholly hardware solution you would need a CPLD to act as the I2C master. Instead the software drivers program these chips just fine during initialisation. Further, if you want to support firmware upgrades, you need to find a VERY robust process else you have huge technical support and repair issues, not to mentioned unhappy customers. In general the FLASH is being loaded via JTAG, and the RAM is being loaded via JTAG. No difference. You can write a device with completely wedged software via JTAG. FLASH is loaded in the factory by JTAG. RAM isn't; I'm not sure what you mean there. I'm an EE working on industrial telecommunications equipment and I always argue for putting as little as possible in FLASH, so that we can upgrade it easily later. Are you sure you don't mean ROM? In general, FLASH systems are designed to upgrade in place. Sure, but you need to develop an upgrade process that means the device still works if you lose power or unplug it during the FLASH process. It'll generate tech support calls, without a doubt. So if you can avoid it, you would (and should). The FLASH technology makes partial reprogramming easy, but you still have to use it sensibly. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
On Sun, Dec 12, 2004 at 04:09:04AM +0100, Goswin von Brederlow wrote: Steve McIntyre [EMAIL PROTECTED] writes: Depends on what you mean by a good hardware design. For example, a lot of the USB dongles becoming common would be significantly bigger and/or more expensive if they had to have sufficient space on-board for a complete firmware implementation. As cost and size can be _everything_ on these devices, downloading firmware each time they are started/connected can actually be a good design choice. Is a bit of flash or rom that much bigger than ram? No, but it's not a replacement either. So what's your point? Is a bit of flash or rom that much bigger than ram? Isn't most of the space in the dongle air or filling material? Circuit board area is the issue. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
On the freeness of a BLOB-containing driver
Is a driver that loads a BLOB Free Software? The problem is connected with distribution. The BLOB is unquestionably software. It runs below the bus, which is our usual demarcation between Free Software and the rest of the system, but it starts life above the bus at boot time, and we have to distribute it. Keep thinking about distribution, that's where our principles are being violated. There are a number of reasons that a device's firmware won't generally be opened to us: 1. The manufacturer's concerns regarding the proprietary nature of information about their device that is below the bus. 2. The fact that misprogramming the device at that level can damage the hardware. 3. They aren't going to want to support more firmware versions than they have to. So, about the most we can do with the BLOB is to stick it in non-free, not declare a dependency from the kernel to the driver, and make sure the driver fails gracefully if the firmware is not there. What about the rest of the driver? I think that if you remove the BLOB, it's Free Software. It talks to a bus interface, which is a natural demarcation between our Free Software and the proprietary hardware design. It loads an arbitrary firmware file into the device. The device might not work without the BLOB, but the driver's still free as long as it does not incorporate the BLOB. A good hardware design would put this code in FLASH on the board. If you don't have a good hardware design, BLOBs belong in files, not the driver. The 2.6 kernel boots up with at least initramfs accessable to it, and later initrd, if it needs a BLOB it should load it from there. Thanks Bruce
Re: On the freeness of a BLOB-containing driver
Bruce Perens [EMAIL PROTECTED] wrote: Is a driver that loads a BLOB Free Software? The problem is connected with distribution. The BLOB is unquestionably software. It runs below the bus, which is our /usual /demarcation between Free Software and the rest of the system, but it starts life above the bus at boot time, and *we have to distribute it. In many cases, we do not have to distribute it. We could - alternatively, we could use the copy that the user has on a CD already[1]. Bruce, why do you keep sending HTML? [1] This isn't true for a small set of drivers - the ipw2100 requires different firmware for Linux and Windows. -- Matthew Garrett | [EMAIL PROTECTED]
Re: On the freeness of a BLOB-containing driver
Bruce Perens wrote: A good hardware design would put this code in FLASH on the board. Depends on what you mean by a good hardware design. For example, a lot of the USB dongles becoming common would be significantly bigger and/or more expensive if they had to have sufficient space on-board for a complete firmware implementation. As cost and size can be _everything_ on these devices, downloading firmware each time they are started/connected can actually be a good design choice. If you don't have a good hardware design, BLOBs belong in files, not the driver. The 2.6 kernel boots up with at least initramfs accessable to it, and later initrd, if it needs a BLOB it should load it from there. Agreed on this bit. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Re: On the freeness of a BLOB-containing driver
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote: What about the rest of the driver? I think that if you remove the BLOB, it's Free Software. It talks to a bus interface, which is a natural demarcation between our Free Software and the proprietary hardware design. It loads an arbitrary firmware file into the device. The device might not work without the BLOB, but the driver's still free as long as it does not incorporate the BLOB. It's free, but it has a non-optional dependency on non-free software, which means contrib, not main. In reality, it doesn't talk to an arbitrary firmware file; it has to talk to a functional one, or the driver is not going to do anything useful. In practice, these types of drivers are not going to work on their own; they'll have a README that says go download the firmware from the vendor's site, or this driver won't work. That type of notice is a big hint that something belongs in contrib, IMO; the real effects are the same as saying go download and install this non-free JRE. One or two people have argued that these drivers still have a use, even when the firmware is not available: it can be used as a starting point for implementing a free firmware; and so it should go in main. I think that's akin to saying, this program that requires a non-free shared library can be used as a starting point for reimplementing the library, so it should go in main. That's bogus; by that logic, everything in contrib would be allowed in main. -- Glenn Maynard
Re: On the freeness of a BLOB-containing driver
Glenn Maynard wrote: It's free, but it has a non-optional dependency on non-free software, which means contrib, not main. In the case of a device driver, that dependency would still be there if the firmware was in ROM. Which would put pretty much all of our device drivers, X (talks to VESA code), APM and ACPI (talks to BIOS), and so on, in contrib too. The only logical demarcation I can see is that we have Free Software down to the bus programming interface. What lives on the other side of the bus programming interface isn't our problem unless we have to put it there, just as the fact that proprietary software runs in the other systems that we talk to on the network does not comprimise the freeness of our system. In reality, it doesn't talk to an arbitrary firmware file; it has to talk to a functional one, or the driver is not going to do anything useful. I agree that it would have to be working firmware and it is anticipated that it will not be Free Software. That type of notice is a big hint that something belongs in contrib, IMO; the real effects are the same as saying go download and install this non-free JRE. Stuff in contrib generally has a package dependency on something in non-free that is necessary to install it, and the entire package is not functional if that dependency is not fulfilled. The driver is a component of the larger kernel which remains functional. One or two people have argued that these drivers still have a use, even when the firmware is not available: it can be used as a starting point for implementing a free firmware; and so it should go in main. I think that's akin to saying, this program that requires a non-free shared library can be used as a starting point for reimplementing the library, so it should go in main. That's bogus; by that logic, everything in contrib would be allowed in main. Moving something from contrib to main doesn't violate Debian's principles. Moving something from non-free to main or contrib without the necessary license change would. Contrib is there to tell you that something is DFSG-free but is not functional without a non-DFSG-free component. Contrib provides a a message to the user and a convenience for the Debian developers, it is not a purgatory for almost-free software. Thanks Bruce
Re: On the freeness of a BLOB-containing driver
On Sat, Dec 11, 2004 at 05:52:36PM -0800, Bruce Perens wrote: In the case of a device driver, that dependency would still be there if the firmware was in ROM. Which would put pretty much all of our device drivers, X (talks to VESA code), APM and ACPI (talks to BIOS), and so on, in contrib too. Not in the same way: we don't have to include it; the device driver does not have to be supplied a copy of it for it to work. Stuff in contrib generally has a package dependency on something in non-free that is necessary to install it, and the entire package is not functional if that dependency is not fulfilled. The driver is a component of the larger kernel which remains functional. If it comes down to the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits, I can live with that. It's we're pretending the driver is fully functional and does not have a dependency on the firmware, even though it asks for it by name, opens and parses the file, and doesn't do anything useful without it that I'm uncomfortable with. Moving something from contrib to main doesn't violate Debian's principles. Moving something from non-free to main or contrib without the necessary license change would. Contrib is there to tell you that something is DFSG-free but is not functional without a non-DFSG-free component. Contrib provides a a message to the user and a convenience for the Debian developers, it is not a purgatory for almost-free software. contrib exists for software which is free but fails SC#1, we will never make the system depend on an item of non-free software. Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. -- Glenn Maynard
Re: On the freeness of a BLOB-containing driver
Bruce Perens [EMAIL PROTECTED] writes:
Is a driver that loads a BLOB Free Software? The problem is
connected with distribution. The BLOB is unquestionably software. It
runs below the bus,
Yes, I would agree that a non software blob is so unlikely that we can
rule it out. If it is non-software it should document what the data
means (like: // These are the 12000 filter offsets for the highpass
filter ...). I'm sure a documented file of constants would be
acceptable.
On the other hand the blobs mostly come as source files to be compiled
with gcc. We might not like the way the source looks (char data[] = {
... }) but does that legaly have any impact?
If the blob comes with a DFSG free license and complies to all its
terms should we still reject it because we don't like the way the code
looks?
With firmware a lot of people would say include the firmware. If
someone would try the same with a game the reaction would be quite the
opposite I believe.
Imagine a source where all variables are named vnumber and all
functions fnumber. Is that still free? Where do we draw the line?
When does source stop to be bad style and start to become obfuscated
and unacceptable for main?
which is our usual demarcation between Free Software and the rest of
the system, but it starts life above the bus at boot time, and we
have to distribute it.
Keep thinking about distribution, that's where our principles are
being violated.
There are a number of reasons that a device's firmware won't
generally be opened to us:
1. The manufacturer's concerns regarding the proprietary nature of
information about their device that is below the bus.
2. The fact that misprogramming the device at that level can damage
the hardware.
3. They aren't going to want to support more firmware versions than
they have to.
So, about the most we can do with the BLOB is to stick it in
non-free, not declare a dependency from the kernel to the driver,
and make sure the driver fails gracefully if the firmware is not
there.
What about the rest of the driver? I think that if you remove the
BLOB, it's Free Software. It talks to a bus interface, which is a
yes.
natural demarcation between our Free Software and the proprietary
hardware design. It loads an arbitrary firmware file into the
device. The device might not work without the BLOB, but the driver's
still free as long as it does not incorporate the BLOB. A good
hardware design would put this code in FLASH on the board. If you
don't have a good hardware design, BLOBs belong in files, not the
driver. The 2.6 kernel boots up with at least initramfs accessable
to it, and later initrd, if it needs a BLOB it should load it from
there.
Thanks
Bruce
So does the driver depend on the firmware and goes to contrib? When
does it depend and when suggest?
MfG
Goswin
Re: On the freeness of a BLOB-containing driver
Bruce Perens [EMAIL PROTECTED] writes: Glenn Maynard wrote: It's free, but it has a non-optional dependency on non-free software, which means contrib, not main. In the case of a device driver, that dependency would still be there if the firmware was in ROM. Which would put pretty much all of our device drivers, X (talks to VESA code), APM and ACPI (talks to BIOS), and so on, in contrib too. I draw the line there at what the user has to do. Does he have to copy the file to his filesystem and taint it or not? Preinstalled firmware in flash just is there. It's a black box that somehow magically displays coloured images on our monitor. Debian packages can only express dependencies on other packages and you couldn't make a package containing the rom (as in the chip). With a downloadable firmware file you can make a deb and most would have a deb in non-free. If there is (can be) a deb then there is a package relationship of some kind. The only logical demarcation I can see is that we have Free Software down to the bus programming interface. What lives on the other side of the bus programming interface isn't our problem unless we have to put it there, just as the fact that proprietary software runs in the other systems that we talk to on the network does not comprimise the freeness of our system. I come to the same but using the filesystem as rule. If it has to be in the filesystem tree then it is of concern. In reality, it doesn't talk to an arbitrary firmware file; it has to talk to a functional one, or the driver is not going to do anything useful. I agree that it would have to be working firmware and it is anticipated that it will not be Free Software. That type of notice is a big hint that something belongs in contrib, IMO; the real effects are the same as saying go download and install this non-free JRE. Stuff in contrib generally has a package dependency on something in non-free that is necessary to install it, and the entire package is not functional if that dependency is not fulfilled. The driver is a component of the larger kernel which remains functional. Only if it is in the kernel. As said before, drivers in the kernel should cause a suggest while as standalone package it would be depends (and then contrib). MfG Goswin
Re: On the freeness of a BLOB-containing driver
Steve McIntyre [EMAIL PROTECTED] writes: Bruce Perens wrote: A good hardware design would put this code in FLASH on the board. Depends on what you mean by a good hardware design. For example, a lot of the USB dongles becoming common would be significantly bigger and/or more expensive if they had to have sufficient space on-board for a complete firmware implementation. As cost and size can be _everything_ on these devices, downloading firmware each time they are started/connected can actually be a good design choice. Is a bit of flash or rom that much bigger than ram? Isn't most of the space in the dongle air or filling material? Cost I can see, size I find a bit hard to believe. If you don't have a good hardware design, BLOBs belong in files, not the driver. The 2.6 kernel boots up with at least initramfs accessable to it, and later initrd, if it needs a BLOB it should load it from there. Agreed on this bit. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You raise the blade, you make the change... You re-arrange me 'til I'm sane... MfG Goswin
Re: On the freeness of a BLOB-containing driver
Glenn Maynard [EMAIL PROTECTED] writes: On Sat, Dec 11, 2004 at 05:52:36PM -0800, Bruce Perens wrote: In the case of a device driver, that dependency would still be there if the firmware was in ROM. Which would put pretty much all of our device drivers, X (talks to VESA code), APM and ACPI (talks to BIOS), and so on, in contrib too. Not in the same way: we don't have to include it; the device driver does not have to be supplied a copy of it for it to work. Stuff in contrib generally has a package dependency on something in non-free that is necessary to install it, and the entire package is not functional if that dependency is not fulfilled. The driver is a component of the larger kernel which remains functional. If it comes down to the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits, I can live with that. It's we're pretending the driver is fully functional and does not have a dependency on the firmware, even though it asks for it by name, opens and parses the file, and doesn't do anything useful without it that I'm uncomfortable with. Yes, we agree there. The kernel as whole is functional without the extra firmware. The driver itself is not. But since the driver is only a small portion of the kernel it does not impede its functionality enought to force a move to contrib. MfG Goswin
