Re: LCC and blobs
Martin Waitz <[EMAIL PROTECTED]> writes: > I have a PCMCIA card that lost its flash memory. > So suddenly its driver became non-free? No; the hardware is damaged. No driver can drive that. The driver you have is a driver for Foomatic Quxer cards. You don't have a Foomatix Quxer; you have a broken pile of junk. > What about all those drivers for hardware that I don't own? > They don't work for me, yet I won't flag them as non-free. > We must not consider hardware when talking about free software. > > Sending firmware to the device is not that different to sending some > magic initialization commands. Firmware should be treated as exactly > that: magic initialization data for the device. Exactly. And so we should require it to be free. Certainly, if some card required a long magic initialization sequence, but its licence prohibited distribution or modification of that sequence, we would not consider it free. The initialization sequence in these cases is long enough to be covered by copyrights. It's clearly software, and the driver clearly has a dependency on it. So either we should compromise our principles and ship the drivers without a reasonable expectation that anyone with the device will have the firmware, or else we should compromise utility and not ship with dependencies on non-free software. Since in the case of firmware on disk we can't reliably get the firmware to users *anyway*, utility's not atainable and we should keep our principles of freedom. -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen wrote: >> No; the hardware is damaged. No driver can drive that. The driver >> you have is a driver for Foomatic Quxer cards. You don't have a >> Foomatix Quxer; you have a broken pile of junk. > > So here you argue that because the firmware is gone the hardware is > broken, correct? No, I argue that because you've pried chips off the board, the hardware is broken. >> ... It's clearly software, and the driver clearly has a dependency on it. > > And now you consider it software just because the method of storage is > different? How can the nature of the bytes change because they are > stored on a disk? The nature of the bytes do not change. But my name, distributed in a Debian package, is software. My name, written in letters of granite thirty feet high, is not. How can the nature of the data change? Architectural plans for a house, shipped in a Debian package, are software. An actual house embodying those plans is not software. But gosh, the nature changes! > If the driver need to load the firmware or just needs to enable it is > the same thing. Just think of the enable sequence as highly compressed > firmware > :-). The simplest and most important difference is that we know anyone with a functioning device has the on-chip firmware. He often can't redistribute the on-disk firmware to somebody else if he sells the device, as its licence prohibits this. > So the driver has a dependency on the firmware, even if it is in the > device itself. So we have to move all drivers that use devices with > build-in firmware to contrib. > > That or we see that the firmware is actually part of the hardware and > that uploading is just a natural thing a driver should do. Some firmware is part of the hardware. Some isn't. It's easy to tell -- either it's in the hardware or it isn't. Of course, the name "firmware" should make it clear that this is an often ambiguous line. But this does seem to be a good practical place: can anybody with the device and the driver use it? Or are there some people who even with a functioning, complete device and a driver who can't get it to work? > The fact that most firmware cannot be redistributed or does not come > as source just selects what we can ship or have to ask the user to > provide. > >> Since in the case of firmware on disk we can't reliably get the >> firmware to users *anyway*, utility's not atainable and we should keep >> our principles of freedom. > > I see no limitation of my freedom in using firmware. Please tell me > how I am limited in my freedom. If I wanted a open source firmware I > could buy a device with open firmware, Then Windows isn't proprietary either. Sigh. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen wrote: >> Some firmware is part of the hardware. Some isn't. It's easy to tell >> -- either it's in the hardware or it isn't. Of course, the name >> "firmware" should make it clear that this is an often ambiguous line. >> But this does seem to be a good practical place: can anybody with the >> device and the driver use it? Or are there some people who even with >> a functioning, complete device and a driver who can't get it to work? > > This is not only a feature of a device with firmware. Some hardware > you cannot buy, you only get a license to use it. If I remember > correctly you never "buy" an EMC, you only get permission to use it > and have to pay every year to continue to use it. > > So you want to rip out all fiber-channel drivers because they might be > used to connect to an EMC? No. They have useful functionality in connecting to other fiber-channel devices. Open standards are a nice thing. The fiber-channel devices have no dependency on the EMC hardware -- and even if they did, Debian doesn't express dependencies on hardware in its packaging system. >>>I see no limitation of my freedom in using firmware. Please tell me >>>how I am limited in my freedom. If I wanted a open source firmware I >>>could buy a device with open firmware, >> Then Windows isn't proprietary either. Sigh. > > It is, but does the fact that I can boot it with grub limit my freedom? Of course not -- and grub can boot Linux or the Hurd, too. So Grub has no dependency on Windows. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > Brian Thomas Sniffen wrote: >> Peter Van Eynde <[EMAIL PROTECTED]> writes: >>>And now you consider it software just because the method of storage is >>>different? How can the nature of the bytes change because they are >>>stored on a disk? >> The nature of the bytes do not change. But my name, distributed in a >> Debian package, is software. My name, written in letters of granite > > You name is software! > Now I'm a Common Lisp hacker, you know the data is code people, but > even _we_ do not consider a string software unless it drives some > software. > > Is your name input for a state-machine? You should see what it does to TECO. My name is a killing word. >> Architectural plans for a house, shipped in a Debian package, are >> software. > > I'm stunned. So anything in a Debian package is software. With alien I > can convert a tar.gz into a debian package, so all tar files are > software. With tar I can create a tar.gz from any file, so all > electronic data is software? Bingo. Debian had this debate last year. There was a giant vote over it. Then another debate and another vote. "software" is not "program". Programs are software that happens to be executable. Data is not executable, but still software. > And you restrictions that any package that depends on non-DFSG > "software" to work cannot be in main means that after releasing sarge > we have to remove from main: > > - all bootloaders. Grub cannot start my XP without the XP > bootsector. Grub doesn't depend on XP's bootsector. It provides other useful functionality -- booting Linux -- without it. That's more of a Suggests. > - tftpd. I want to netboot my Solaris machines. The tftpd needs the > solaris code to "work". It implements the tftpd protocol all by itself. There are even plenty of tftp clients out there. Apache doesn't become non-free because you want to use it to distribute your great novel... which you haven't written yet. > Should I go on? Please at least read Policy on what "Depends" means first. If you also read the archives, you'll have a chance at understanding the position of other debaters here, and of generating original arguments. So far, this is all a repeat. It wasn't convincing any of the last couple times, so it won't be this time. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Peter Van Eynde <[EMAIL PROTECTED]> writes: > I think I'm starting to understand your point of view. So _any_ use of > the software without using non-DFSG data makes it free, right? Any reasonable use. Printing out a "firmware not found" message doesn't count! > But what if loading the firmware is not required? That if the device > was "warm-booted" in another OS? (I know there are technical > limitations here) Would the driver-firmware relation still be a > "depends"? Then there's a dependency on the other OS instead, and *it* either has a dependency on the driver, or is free software and we can just do it the same way they do. So now you have a dependency on non-free software, and several ways to fulfill it. If you could express the entire software dependency tree in free software, then the software at the root of that tree is also free and can go in Debian. > Oh, I have another use for the ipw2100 driver without firmware: it can > recognise the card from the pci-id information. :-) Great, so can lspci. Waste of time and archive space. It's a driver, not a card prober. >> Please at least read Policy on what "Depends" means first. If you > > I see no mention of this in version 3.6.1.1. There is: > |5.6.9. Package interrelationship fields > -> see chapter 7 > |7.2. Binary Dependencies > -> is for debian packages. And has: > |... > |The `Depends' field should be used if the depended-on package is > required |for the depending package to provide a significant amount of > |functionality. > |... > |7.6. Relationships between source and binary packages > ->N/A > > There is no mention of dependency of packages on external data that > fall outside the packaging system. So what meaning do you mean? > > If you extend the rules for packages to firmware then the question > becomes what "significant amount of functionality" is. In the past it > was used for "can run", optional libraries were "Suggest"ed in. Firmware that is optional is, well, optional. Suggests is a perfectly reasonable expression of that. Depends is not. > [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls > ipw2100-1.0.fwipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw > ipw2100-1.1.fwipw2100-1.2.fwipw2100-1.3.fwisl3890 > ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ > mv: cannot move `t' to a subdirectory of itself, `t/t' > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l > t/ > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko > insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko > insmod /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko > > The module loaded without firmware, not? It detected my card, but > failed to load the firmware. > > ipw2100: Detected Intel PRO/Wireless 2100 Network Connection > ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. > ipw2100: eth1: ipw2100_get_firmware failed: -2 > ipw2100: eth1: Failed to power on the adapter. > ipw2100: eth1: Failed to start the firmware. > ipw2100Error calling regiser_netdev. > ipw2100: probe of :02:02.0 failed with error -5 > > I would say this is a functional driver. It provides me with useful > information about my system. The fact that I cannot connect to a wifi > lan is the same situation as with grub not being able to load XP > without the XP bootsector, if there were a free firmware with the same > API I would be able to load and use it. No. It's a driver for an ipw 2100; it has an ipw2100 and can't drive it. It's not functional -- it failed to power on the adapter. In the case of Windows and Grub, Grub is a generic bootloader. It can usefully boot Linux, Hurd, or NetBSD without access to an XP bootsector. It has significant useful functionality. What device can the ipw2100 driver drive without the firmware? > Making Debian uninstallable because of mistaken beliefs is too much > and I care enough to resists this. This certainly doesn't make Debian uninstallable. All the drivers in question can move to contrib. It just ensures that Debian ships only free software in Debian main. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Anthony DeRobertis <[EMAIL PROTECTED]> writes: > Henning Makholm wrote: >> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]> >> >>>That would, however, cover firmware and wind up sending X to >>>contrib. So maybe: ... iff it is stored on the local machine's file >>>system. >> That would be my *intuitive* understanding of how the mail/contrib >> difference works. >> > > So would a web-based firmware loader, that never saved the firmware to > disk allow the drivers to be in main? Of course not. It's fetching software, then using that software. ICQ software merely mentions messages, but doesn't use them. -Brian -- Brian Sniffen [EMAIL PROTECTED]
Re: LCC and blobs
Anthony DeRobertis <[EMAIL PROTECTED]> writes: >>>So would a web-based firmware loader, that never saved the firmware to >>>disk allow the drivers to be in main? >> Of course not. It's fetching software, then using that software. >> ICQ software merely mentions messages, but doesn't use them. > > ICQ uses the messages as instructions telling it what glyphs to > display on your screen. That part of the message, though, might be > free. That's a dangerous route to follow. By that logic, all the https browsers have dependencies on non-free software: the private keys associated with their CA root certificates. > It does use significant features from non-packaged software --- > message routing, buddy list management, buddy tracking, file transfer, > etc. > > We've elected to ignore ICQ's dependency on an ICQ server. We've > elected to ignore a driver's dependency on firmware burnt in ROM or > stored in flash --- even when it executes that code on the main > CPU. We've elected not to ignore firmware that resides in RAM instead. No. Firmware resident in RAM but put there by, say, the BIOS is fine. We've elected not to ignore firmware which is to be handled and installed by Debian software. You're having trouble making a coherent position out of this only because you keep recasting it in terms which aren't equivalent. The issue at hand is whether somebody might ever download software from Debian and find it useless without additional software which he could download... but not from Debian, since it's not Free and not packaged. If I download an ICQ client, there are lots of reasons I might find it useful: I might not have anything to say, or I might have no network connection, or I might have no friends to talk to. Debian is not responsible for providing me with creativity, connectivity, or friends. I think the example provided elsewhere in this thread -- that we'd never say an ICQ client Depends: icq-server -- is excellent. We'd also never mark something Depends: bios, because the BIOS is essential and assumed to be present. -Brian -- Brian Sniffen [EMAIL PROTECTED]
